Cette section décrit les mécanismes de sécurité spécifiques qu'offre le produit.
Les clients qui ont des agents pour lesquels le chiffrement est activé doivent se préoccuper principalement des problèmes suivants :
Divulgation d'informations à l'encontre de la stratégie
Perte ou destruction de données
Délai inacceptable de restauration des données en cas de panne catastrophique (par exemple, sur un site de continuité des activités)
Modification non détectée de données
Les objectifs des fonctions de sécurité d'Oracle Key Manager sont les suivants :
Protéger les données chiffrées de la divulgation.
Limiter les possibilités d'attaque.
Garantir une fiabilité et une disponibilité suffisamment élevées.
Cette section du guide de sécurité donne un bon aperçu des menaces que le système doit bloquer et de la façon dont les fonctions de sécurité individuelles se coordonnent pour éviter ces attaques.
Les principales fonctions de sécurité qui assurent ces protections sont les suivantes :
Authentification – Garantit que seules les personnes autorisées ont accès au système et aux données.
Autorisation – Contrôle d'accès aux privilèges système et aux données ; ce contrôle d'accès s'appuie sur l'authentification pour garantir que les utilisateurs ne disposent que d'un accès correspondant à leurs besoins.
Audit – Permet aux administrateurs de détecter les tentatives de violation du mécanisme d'authentification et les tentatives réussies ou non de violation du contrôle d'accès.
Pour plus d'informations concernant les aspects sécurité et authentification d'Oracle Key Manager, reportez-vous au document Oracle Key Manager Version 3.0 Security and Authentication White Paper (livre blanc sur la sécurité et l'authentification d'Oracle Key Manager Version 3.0) à l'adresse :
L'architecture d'Oracle Key Manager propose une authentification mutuelle entre tous les éléments du système : entre KMA, entre agents et KMA et entre la GUI ou CLI d'Oracle Key Manager et les KMA pour les opérations utilisateur.
Chaque élément du système (par exemple, un nouvel agent de chiffrement) est inscrit dans le système via la création d'un ID et d'une phrase de passe dans l'OKM qui est ensuite saisi dans l'élément à ajouter. Par exemple, lorsqu'un lecteur de bande est ajouté au système, l'agent et le KMA exécutent automatiquement un protocole de question/réponse en fonction de la phrase de passe partagée. De ce fait l'agent obtient un certificat d'autorité de certification (CA) racine, une nouvelle paire de clés et un certificat signé. Avec le certificat d'autorité de certification racine, le certificat d'agent et une nouvelle paire de clés, l'agent peut exécuter le protocole TLS (Transport Layer Security) pour toutes les communications ultérieures avec les KMA. Tous les certificats sont des certificats X.509.
L'OKM se comporte comme une autorité de certification racine pour générer un certificat racine que les KMA utilisent à leur tour pour dériver (auto-signer) les certificats utilisés par les agents, les utilisateurs et les nouveaux KMA.
Le contrôle d'accès présente l'un des types suivants :
Contrôle d'accès basé sur les utilisateurs et les rôles
Protection de quorum
Oracle Key Manager permet de définir plusieurs utilisateurs, chacun possédant un ID utilisateur et une phrase de passe. Chaque utilisateur reçoit un ou plusieurs rôle prédéfinis. Ces rôles déterminent quelles opérations un utilisateur est autorisé à exécuter sur un système Oracle Key Manager. Il s'agit des rôles suivants :
Agent de sécurité – Exécute la configuration et la gestion d'Oracle Key Manager
Opérateur – Effectue la configuration de l'agent et les opérations quotidiennes
Agent de conformité – Définit les groupes de clés et contrôle l'accès des agents aux groupes de clés
Opérateur de sauvegarde – Réalise des opérations de sauvegarde
Auditeur – Vérifie les pistes d'audit du système
Membre du quorum – Inspecte et approuve les opérations en attente du quorum
Un agent de sécurité est défini lors du processus QuickStart qui configure un KMA dans un cluster OKM. Plus tard, un utilisateur doit se connecter au cluster en tant qu'agent de sécurité à l'aide de la GUI d'Oracle Key Manager afin de définir les utilisateurs supplémentaires. L'agent de sécurité peut choisir d'attribuer plusieurs rôles à un utilisateur particulier ou un rôle particulier à plusieurs utilisateurs.
Pour plus d'informations sur les opérations autorisées par chaque rôle et sur la façon dont un agent de sécurité crée des utilisateurs et leur assigne des rôles, reportez-vous au Guide d'administration Oracle Key Manager inclus dans les bibliothèques de documentation d'Oracle Key Manager à l'adresse suivante :
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
Ce contrôle d'accès basé sur les rôles prend en charge les rôles opérationnels définis dans la publication spéciale (SP) 800-60 du NIST (National Institute of Standards and Technology) pour séparer les fonctions opérationnelles.
Certaines opérations très critiques nécessitent un niveau de sécurité supplémentaire. Il s'agit notamment de l'ajout d'un KMA sur un cluster OKM, du déverrouillage d'un KMA, de la création d'utilisateurs et de l'attribution de rôles aux utilisateurs. Pour implémenter cette sécurité, le système utilise un ensemble de références de scission de clés en plus de l'accès basé sur les rôles décrit ci-dessus.
Les références de scission de clés se composent de paires ID utilisateur / phrase de passe et du nombre minimum de ces paires qui est nécessaire au système pour permettre l'exécution de certaines opérations. Les références de scission de clés sont également appelées "le quorum" et le nombre minimum est appelé "le seuil du quorum".
Oracle Key Manager permet de définir jusqu'à 10 paires ID utilisateur / phrase de passe de scission de clés et un seuil. Ils sont définis lors du processus QuickStart, lorsque le premier KMA d'un cluster OKM est configuré. Les ID utilisateur et phrases de passe de scission de clés sont différents des ID utilisateur et phrases de passe utilisés pour se connecter au système. Lorsqu'un utilisateur tente une opération qui nécessite l'approbation du quorum, le nombre seuil d'utilisateurs et phrases de passe de scission de clés doit avoir accepté cette opération pour que le système l'exécute.
Chaque KMA enregistre des événements d'audit pour les opérations qu'il exécute, notamment celles émises par les agents, les utilisateurs et les KMA pairs dans le cluster OKM. Les KMA enregistrent également des événements d'audit chaque fois qu'un agent, utilisateur ou KMA pair échoue lors de son authentification. Les événements d'audit qui indiquent une violation de sécurité sont répertoriés. Un échec d'authentification est un exemple d'événement d'audit indiquant une violation de sécurité. Si des agents SNMP sont identifiés dans le cluster OKM, les KMA envoient également des SNMP INFORM à ces agents SNMP s'ils rencontrent une violation de sécurité. Si le service syslog distant est configuré, un KMA transfère également ces messages d'audit aux serveurs distants configurés. Voir la section Syslog distant.
Un utilisateur doit se connecter correctement au cluster OKM et doit être assigné à un rôle pour pouvoir consulter les événements d'audit.
Les KMA gèrent leurs événements d'audit. Les KMA suppriment les anciens événements d'audit en fonction des conditions et des limites (quantitatives) de conservation. L'agent de sécurité peut modifier ces conditions et limites de conservation, si nécessaire.
Oracle Key Manager propose d'autres fonctions de sécurité. Pour plus d'informations concernant ces fonctions de sécurité et les autres fonctions OKM, reportez-vous à la Présentation d'Oracle Key Manager à l'adresse suivante :
Le protocole de communication est le même entre un agent et un KMA, un utilisateur et un KMA et un KMA et un KMA pair. Dans chaque cas, le système utilise la phrase de passe pour que l'entité qui démarre la communication exécute un protocole de question/réponse. Si elle réussit, l'entité reçoit un certificat et la clé privée correspondante. Ce certificat et cette clé privée peuvent établir un canal TLS (Transport Layer Security) (secure sockets). Une authentification mutuelle est effectuée : chaque extrémité d'une connexion authentifie l'autre partie. Les KMA OKM 3.1+ utilisent toujours TLS 1.2 pour leur trafic de réplication entre pairs.
Les KMA proposent un module matériel de sécurité (HSM - Hardware Security Module), disponible par commande séparée. Ce module est une carte Sun Cryptographic Accelerator (SCA) 6000 certifiée FIPS 140-2 niveau 3 qui fournit des clés de chiffrement AES (Advanced Encryption Standard) 256 bits. (Ce certificat a expiré le 31/12/2015 et n'est pas renouvelé ; un autre module HSM sera fourni dans une version ultérieure.) La carte SCA 6000 prend en charge un mode d'opération FIPS 140-2 de niveau 3 et OKM l'utilise toujours de cette manière. Lorsque le cluster OKM fonctionne en mode FIPS conforme, les clés de chiffrement ne dépassent pas la limite cryptographique de la carte SCA 6000 sous forme déballée. La carte SCA 6000 utilise un générateur de nombre aléatoire approuvé par FIPS, comme indiqué dans le générateur de nombre aléatoire DSA FIPS 186-2 utilisant SHA-1 pour générer des clés de chiffrement.
Lorsqu'un KMA n'est pas configuré avec une carte SCA 6000, le chiffrement est effectué à l'aide du jeton dynamique PKCS#11 de la structure de chiffrement Solaris (SCF). La structure SCF est configurée dans le mode FIPS 140 conformément aux règles de sécurité Solaris FIPS 140-2 les plus récentes.
Oracle Key Manager utilise le chiffrement de clé AES (RFC 3994) avec des clés de chiffrement 256 bits pour protéger les clés symétriques pendant qu'elles sont créées, stockées sur le KMA, transmises aux agents ou dans des fichiers de transfert de clés.
Quand le premier KMA d'un cluster OKM est initialisé, il génère un pool de clés important. A mesure que des KMA supplémentaires sont ajoutés au cluster, les clés sont répliquées sur les nouveaux KMA et sont ensuite prêtes à être utilisées pour chiffrer des données. Chaque KMA ajouté au cluster génère un pool de clés et les réplique sur les KMA pairs dans le cluster. Tous les KMA génèrent de nouvelles clés si nécessaire afin de maintenir une taille de pool suffisante pour que les agents puissent à tout moment disposer de clés prêtes à l'emploi. Lorsqu'un agent a besoin d'une nouvelle clé, il contacte un KMA du cluster et lui demande une clé. Le KMA sort une clé du pool et l'assigne au groupe de clés par défaut de l'agent et à l'unité de données. Le KMA réplique ensuite ces mises à jour de la base de données sur les autres KMA du cluster à travers le réseau. Plus tard, l'agent pourra contacter un autre KMA du cluster pour récupérer cette clé. Les composants de clé sous forme de texte clair ne sont jamais transmis à travers le réseau.
En décembre 2013, le NIST (National Institute of Standards and Technology) a octroyé le certificat de validation FIPS 140-2 de niveau 1 #2061 au module Oracle Solaris Kernel Cryptographic Framework de Solaris 11. En janvier 2014, le NIST a octroyé le certificat de validation FIPS 140-2 de niveau 1 #2076 à la structure cryptographique utilisateur d'Oracle Solaris avec SPARC T4 et SPARC T5. Le KMA Oracle Key Manager 3.1.0 est désormais basé sur le système Solaris 11.3 dont les tests de validation FIPS 140-2 ne sont pas terminés. La structure cryptographique de noyau Oracle Solaris d'un KMA Oracle Key Manager 3.1.0 est configurée conformément à la stratégie de sécurité de la structure cryptographique de noyau Oracle. De la même manière, le KMA est configuré conformément à la stratégie de sécurité de la structure cryptographique utilisateur d'Oracle Solaris avec SPARC T4 et SPARC T5. OKM adoptera des stratégies de sécurité Solaris plus récentes dès qu'elles seront disponibles.