Chiffrement

En matière de chiffrement, deux domaines d'intervention sont prioritaires :

• Chiffrement en transit

• Chiffrement au repos

Le chiffrement natif DB2 est intégré à Db2 pour protéger les données au repos en chiffrant les données lorsqu'elles sont écrites sur le disque. Le chiffrement natif DB2 utilise un modèle standard à deux niveaux. Les données réelles sont cryptées avec une clé de chiffrement de données Db2 (DEK) et la DEK est cryptée avec une clé principale Db2 (MK). Le DEK est géré dans la base de données tandis que le MK est stocké en externe dans un magasin de clés.

Pour obtenir un chiffrement au repos, le chiffrement de volume Amazon Elastic Block Store (Amazon EBS) est préférable au chiffrement natif DB2 activé, car vous pouvez utiliser des solutions cloud natives pour la configuration et le dimensionnement. AWS Le chiffrement des volumes EBS permet également d'éliminer les surcharges opérationnelles inutiles et le temps consacré à la configuration du chiffrement natif lors de la migration de plusieurs serveurs de base de données. Pour plus d'informations, consultez le billet de blog Architecting for database encryption on AWS.

Le chiffrement en transit est pertinent pour les communications de données suivantes :

• Entre le client et le serveur

• Entre les serveurs de reprise après sinistre (HADR) à haute disponibilité (HADR) principaux et de secours

• Entre le serveur de base de données et les services externes

Les données transmises sont cryptées à l'aide du protocole TLS. En outre, Db2 prend en charge le chiffrement interne de l'ID utilisateur et du mot de passe à l'aide du paramètre côté serveur. AUTHENTICATION

TLS utilise les bibliothèques de l'IBM Global Security Kit (GSKit), qui fournit un tunnel sécurisé pour les données envoyées et stocke les certificats en toute sécurité dans le magasin de clés.

Le schéma suivant montre le handshake TLS entre le client et le serveur.

1. Le client demande une connexion TLS et répertorie les suites de chiffrement prises en charge.

2. Le serveur répond avec une suite de chiffrement sélectionnée et une copie de son certificat numérique, qui inclut une clé publique.

3. Le client vérifie la validité du certificat. Si le certificat est valide, une clé de session et un code d'authentification des messages (MAC) sont chiffrés avec la clé publique et renvoyés au serveur.

4. Le serveur déchiffre la clé de session et le MAC. Le serveur envoie ensuite un accusé de réception pour démarrer une session cryptée avec le client.

5. Le serveur et le client échangent des données en toute sécurité à l'aide de la clé de session et du MAC.

Lorsque les certificats expirent, vous devez les renouveler et les mettre à jour dans le magasin de clés.

À partir de la version 11.5.6 de DB2, vous pouvez inclure la validation du nom d'hôte lors de la configuration du protocole TLS. La validation du nom d'hôte permet à la connexion client de vérifier que le nom d'hôte indiqué dans le certificat du serveur correspond au nom d'hôte du client. Cette validation peut aider à prévenir les person-in-the-middle attaques. En outre, vous pouvez configurer le TLSVersion paramètre sur le client. À partir de la version 11.5.8 de DB2, le protocole TLS 1.3 est pris en charge.