Un HSM cloud avec un contrôle clair des clés.

La connexion privée, la résolution de noms, l'authentification et la latence influencent chaque appel cryptographique. Nous testons le chemin avec le profil de charge réel et planifions le comportement en cas de connexion interrompue. Un second point de terminaison n'est utile que si les clés et les autorisations requises y sont disponibles. Les services de clés externes ou les clés gérées côté client se distinguent en outre par les données et les services qu'ils contrôlent réellement. Nous documentons ces limites de sorte que les responsables métier comprennent l'influence résiduelle du fournisseur.

Un plan de sortie décrit quelles clés peuvent être exportées, quelles données devraient être rechiffrées et quels services doivent être remplacés. Les délais, les confirmations de suppression et les dépendances aux sauvegardes en font partie. Dans le cadre du projet, nous convenons d'objectifs d'exploitation atteignables et vérifions la reprise ainsi que la révocation des droits. Un engagement général de portabilité totale ne serait pas crédible sans cette vérification.

AWS CloudHSM et Azure Key Vault Managed HSM représentent des modèles d'intégration et d'exploitation différents. AWS CloudHSM propose des connexions clientes HSM pour les applications qui s'y prêtent ; Azure Managed HSM fournit un service de clés managé avec intégration Azure. Nous vérifions l'API, les types de clés, les identités et le modèle de restauration pour chaque charge de travail. Un changement n'est donc pas un simple remplacement d'adresse de serveur. Ce qui compte, c'est de savoir si l'application concernée et le niveau de contrôle requis correspondent au service.

Le Bring Your Own Key (BYOK) désigne avant tout l'apport de votre propre matériel de clés dans un service pris en charge. Il ne répond pas à lui seul à la question de savoir qui peut déclencher des opérations de clés ou où les données en clair sont traitées. Avec une gestion externe des clés s'ajoutent des dépendances techniques supplémentaires, par exemple un service externe pour certaines opérations de libération ou de désencapsulation. Nous documentons ces limites de confiance et testons également la révocation ciblée des droits. Les fonctions et les restrictions sont vérifiées pour le service cloud concerné.

Une application existante doit être migrée, mais l'exploitation de ses clés doit rester maîtrisable. OTOKO® vérifie d'abord si l'interface existante peut continuer à être utilisée ou si une adaptation est nécessaire. Dans le pilote, nous mesurons les temps de réponse depuis le réseau cible, vérifions la séparation des rôles d'administrateur et testons la restauration. Le plan de sortie décrit à la fois les clés exportables et les cas où une nouvelle génération de clés et une conversion des données seraient nécessaires. Il en résulte un modèle d'exploitation avec des responsables désignés.