À propos du déploiement de certificat TLS sécurisé

Cette solution offre une approche sécurisée, flexible et conforme pour les organisations qui ont besoin d'utiliser des certificats TLS sécurisés dans des environnements où l'immuabilité clé d'Oracle Cloud Infrastructure Vault serait autrement un bloqueur. Il comble efficacement l'écart entre les modèles de sécurité natifs d'OCI et les exigences d'intégration du monde réel dans plusieurs services Oracle et non Oracle.

Lors de l'implémentation d'une communication TLS sécurisée sur des serveurs Web ou des serveurs d'applications, il est essentiel d'avoir accès aux composants suivants :

  • Certificat TLS
  • Racine et intermédiaire (chaîne de certificats)
  • La clé privée correspondante

Oracle Cloud Infrastructure (OCI) offre des services de gestion des certificats natifs qui permettent la création et la gestion du cycle de vie des certificats destinés à être utilisés dans les services gérés par OCI. Dans ce modèle, les clés privées sont stockées de manière sécurisée dans le service Chambre forte OCI et ne sont pas accessibles aux utilisateurs finaux ou aux systèmes externes. Bien que cela améliore la sécurité, il limite la flexibilité dans les scénarios où un contrôle complet des certificats et des clés est requis, tels que le déploiement vers des serveurs d'applications externes ou des environnements hybrides. Cela pose un problème lors de la tentative d'utilisation de l'autorité de certification à partir des certificats OCI pour les systèmes qui nécessitent un accès direct au certificat et à la clé privée.

Cela devient particulièrement problématique lors de l'intégration à des services tels que :

  • Oracle Analytics Cloud
  • Oracle Integration
  • Serveurs Web hébergés sur OCI Compute
  • Applications sur place ou en périphérie

Ces plates-formes nécessitent généralement un contrôle total sur le certificat TLS, y compris la possibilité d'accéder à la clé privée, afin de prendre en charge la communication sécurisée et la résiliation des sessions SSL/TLS.

Ce guide de jeu de solution présente une solution interproduits qui répond à cette limitation en permettant l'utilisation de l'autorité de certification OCI pour les environnements hybrides :

  • Vous générez une clé privée et une demande de signature de certificat localement, en dehors d'OCI.
  • La demande de signature de certificat est ensuite signée par l'autorité de certification OCI Certificates, ce qui maintient la confiance dans l'écosystème OCI.
  • Le certificat signé obtenu est combiné à la clé privée générée localement et déployé dans tout service qui l'exige, que ce soit dans OCI, sur place ou dans un autre nuage.

Le diagramme suivant illustre ce flux.



Cette méthode est la meilleure pour :

  • Configurations hors production où les certificats auto-signés rentables sont suffisants.
  • Environnements qui nécessitent à la fois un contrôle de certificat et de clé privée (comme des serveurs personnalisés ou des intégrations sur place).
  • Scénarios pour lesquels les certificats gérés par OCI (qui masquent les clés privées) ne sont pas compatibles avec les systèmes externes.

Avant de commencer

Avant de commencer, vous devez :

  • Une chambre forte OCI permettant de stocker en toute sécurité les clés privées configurées dans OCI.
  • Une autorité de certification des certificats OCI configurée et entièrement fonctionnelle dans OCI.
  • Accédez à la bibliothèque OpenSSL sur votre ordinateur local pour générer votre clé privée.

À propos des services et des rôles requis

Cette solution requiert le service et le rôle suivants :

  • Oracle Cloud Infrastructure

Il s'agit du rôle requis pour le service.

Nom du service : Rôle Requis pour...
Oracle Cloud Infrastructure : Administrateur Gérer les objets dans les compartiments et lire ou gérer les certificats, les seaux, les chambres fortes et les clés (voir ci-dessous).

Vous pouvez utiliser une politique simple pour les administrateurs d'autorité de certification ou configurer un administrateur et une politique de groupe dynamique pour séparer les rôles et les responsabilités et les restreindre par compartiment. Par exemple :

### Simple Policy for Tenant Administrators
```
Allow group CertificateAuthorityAdmins to manage certificate-authority-family in tenancy
Allow group CertificateAuthorityAdmins to manage leaf-certificate-family in tenancy
Allow group CertificateAuthorityAdmins to read vaults in tenancy
Allow group CertificateAuthorityAdmins to read keys in tenancy
Allow group CertificateAuthorityAdmins to use key-delegate in tenancy
```

Ou :

### Policy for a Dynamic Group
```
Allow dynamic-group DynamicGroup to use keys in compartment DEF
Allow dynamic-group DynamicGroup to manage objects in compartment XYZ
```
### Policy for Compartment Administrators
```
Allow group CertificateAuthorityAdmins to manage certificate-authority-family in compartment ABC
Allow group CertificateAuthorityAdmins to read keys in compartment DEF
Allow group CertificateAuthorityAdmins to use key-delegate in compartment DEF
Allow group CertificateAuthorityAdmins to read buckets in compartment XYZ
Allow group CertificateAuthorityAdmins to read vaults in compartment DEF
```

Voir Produits, solutions et services Oracle pour obtenir ce dont vous avez besoin.