1 Présentation de l'intégration OKM-ICSF
Ce chapitre résume la solution d'intégration OKM-ICSF.
Fichiers de clés et mode de clé principale
Dans KMS 2.0.x et les versions ultérieures, les KMA d'un cluster Oracle Key Manager (OKM) génèrent leurs propres clés à l'aide de leurs cartes Sun Cryptographic Accelerator (SCA) 6000. Certains clients préfèrent que les KMA utilisent des clés principales créées et stockées dans un fichier de clés externe.
KMS 2.2 intègre une fonctionnalité de mode de clé principale. Lorsque cette fonctionnalité est activée, le cluster OKM dérive les clés de bande d'un ensemble de clés principales. Les clés principales sont créées et stockées dans un fichier de clés externe. Il est possible d'effectuer une récupération complète après sinistre avec seulement les bandes, les clés principales et l'équipement OKM aux valeurs d'usine.
Présentation de la solution
Dans cette solution, le fichier de clés externe se trouve dans un mainframe IBM et est accessible via un protocole TLS/XML. Ce protocole est pris en charge dans le mainframe IBM avec les clés stockées dans un ensemble de données de jeton dans IBM Integrated Cryptography Service Facility (ICSF). La Figure 1-1 présente une configuration typique.
Le cluster OKM envoie régulièrement des demandes au mainframe IBM pour solliciter la création de nouvelles clés principales (appelées clés d'application dans ICSF) et leur renvoi au cluster OKM. Les KMA utilisent ensuite ces nouvelles clés principales pour dériver de nouvelles clés de bande.
Définition des composants du système
Les composants suivants composent la solution d'intégration et sont traités dans cette section :
Fichier de clés
Les clés principales (d'application) sont stockées dans l'ensemble de données de jeton (TKDS), tel que défini dans la documentation d'IBM ICSF. Le TKDS est identifié dans l'ensemble de données des options d'installation d'ICSF. Le programmeur système z/OS peut créer le TKDS à l'aide de l'utilitaire IDCAMS.
Les clés stockées dans le TKDS ne sont pas chiffrées, mais l'accès à l'ensemble de données, ainsi qu'aux services invocables et aux jetons (ensembles de données), est contrôlé par RACF ou un équivalent. L'accès au TKDS peut être défini par la stratégie actuelle de sauvegarde et de restauration des clés principales.
Interface
Vous devez ajouter un module au logiciel Sun pour mainframes afin d'implémenter un proxy de services invocables ICSF. Ce proxy permet au cluster OKM d'invoquer des fonctions PKCS#11 pour accéder au fichier de clés. La communication sécurisée avec le cluster OKM est implémentée à l'aide d'AT-TLS (Application Transparent - Transport Layer Security) sur le mainframe IBM.
AT-TLS est une solution de chiffrement pour les applications TCP/IP qui est complètement transparente pour le serveur et le client d'application. Le chiffrement et le déchiffrement des paquets se produit dans l'espace d'adressage TCPIP z/OS au niveau du protocole TCP. La charge utile du paquet chiffré est inintelligible lorsqu'analysée ou suivie, mais devient à nouveau lisible lorsqu'elle est fournie à l'application.
Sécurité de transfert
Le cluster OKM implémente un protocole TLS (Transport Layer Security) pour communiquer avec le proxy sur le mainframe IBM.
Le programmeur système z/OS génère et exporte deux certificats X.509v3 autosignés et une paire de clés publique RSA 2048 bits, puis les transfère (via FTP) hors du mainframe IBM. Le premier certificat est un certificat d'autorité de certification (CA, Certification Authority) racine. Le programmeur système utilise ce certificat CA racine pour générer le certificat client et la paire de clés. Ces certificats et la paire de clés sont installés manuellement dans le mainframe IBM et configurés à l'aide de RACF et AT-TLS de sorte que le proxy puisse identifier une demande OKM valide. Les certificats et la clé privée de la paire de clés sont installés dans le cluster OKM de sorte qu'il puisse authentifier le proxy. Par conséquent, seuls des KMA dans un cluster OKM valide peuvent adresser des demandes au proxy et n'acceptent de réponse que de la part d'un proxy valide.
Dérivation de clé
Le cluster OKM accepte une valeur de clé principale et un ID de clé principale à 18 octets de la part du proxy. Il crée un ID de clé à 30 octets en concaténant l'en-tête à 2 octets et l'ID de clé principale à 18 octets avec une valeur à 10 octets générée en interne. Il crée ensuite une valeur de clé dérivée en chiffrant l'ID de clé (complété à 32 octets) avec la valeur de clé principale.
La gestion des clés entre les lecteurs et le cluster OKM continuent d'utiliser la stratégie OKM actuelle. Ainsi, aucune mise à niveau de microprogramme n'est requise.
Stratégie de clés
Le cluster OKM contrôle le cycle de vie de la clé principale. Il demande une valeur de clé principale actuelle de la part du proxy en fonction de la date du jour. Le proxy récupère la clé principale actuelle à partir du TKDS à l'aide d'une séquence d'invocations de fonctions PKCS#11. Si aucune valeur de clé principale actuelle n'existe, le cluster OKM adresse une demande de création de clé principale au proxy. OKM peut ensuite soumettre une nouvelle demande de valeur de clé principale actuelle au proxy.
Récupération de clé
Le cluster OKM conserve toutes les clés dérivées et tous les ID de clés qu'il crée. Si le cluster ne dispose pas de la clé pour un ensemble spécifié de données écrites, il peut dériver à nouveau la clé en formant l'ID de clé principale à partir de l'ID de clé et en émettant une demande de récupération au proxy pour obtenir la valeur de clé principale stockée dans le TKDS. OKM peut ensuite dériver à nouveau la valeur de clé pour permettre à son agent de lire les données.
Ce mécanisme de récupération de clé autorise la récupération "à partir de la base" de toutes les bandes chiffrées par ce système, uniquement en fonction de la disponibilité des clés principales archivées dans le TKDS.
Configuration système requise
Dans cette solution, le mainframe IBM et le cluster OKM doivent satisfaire la configuration système requise.