Info über sichere TLS-Zertifikatsbereitstellung

Diese Lösung bietet einen sicheren, flexiblen und konformen Ansatz für Unternehmen, die vertrauenswürdige TLS-Zertifikate in Umgebungen verwenden müssen, in denen die Unveränderlichkeit der Schlüssel von Oracle Cloud Infrastructure Vault ansonsten ein Blocker wäre. Es schließt effektiv die Lücke zwischen OCI-nativen Sicherheitsmodellen und realen Integrationsanforderungen über mehrere Oracle- und Nicht-Oracle-Services hinweg.

Bei der Implementierung einer sicheren TLS-Kommunikation auf Webservern oder Anwendungsservern ist der Zugriff auf die folgenden Komponenten unerlässlich:

  • Das TLS-Zertifikat
  • Wurzel und Zwischenprodukt (Zertifikatskette)
  • Der entsprechende Private Key

Oracle Cloud Infrastructure (OCI) bietet native Zertifikatsverwaltungsservices, die das Erstellen und Lebenszyklusmanagement von Zertifikaten ermöglichen, die für die Verwendung innerhalb von OCI-verwalteten Services vorgesehen sind. In diesem Modell werden Private Keys sicher in OCI Vault gespeichert und sind für Endbenutzer oder externe Systeme nicht zugänglich. Dies erhöht zwar die Sicherheit, schränkt jedoch die Flexibilität in Szenarien ein, in denen eine vollständige Zertifikats- und Schlüsselkontrolle erforderlich ist, z. B. das Deployment auf externen Anwendungsservern oder in hybriden Umgebungen. Sie stellt eine Herausforderung dar, wenn Sie versuchen, die Certificate Authority (CA) aus OCI-Zertifikaten für Systeme zu verwenden, die direkten Zugriff auf das Zertifikat und den Private Key erfordern.

Dies wird besonders problematisch bei der Integration mit Services wie:

  • Oracle Analytics Cloud
  • Oracle Integration
  • Auf OCI Compute gehostete Webserver
  • On-Premises- oder Edge-Anwendungen

Diese Plattformen erfordern in der Regel vollständige Kontrolle über das TLS-Zertifikat, einschließlich der Möglichkeit, auf den Private Key zuzugreifen, um eine sichere Kommunikation und die Beendigung von SSL/TLS-Sitzungen zu unterstützen.

In diesem Lösungs-Playbook wird eine produktübergreifende Lösung vorgestellt, die diese Einschränkung durch die Verwendung von OCI CA für hybride Umgebungen angeht:

  • Sie generieren einen Private Key und eine Certificate Signing Request (CSR) lokal außerhalb von OCI.
  • Der CSR wird dann von der OCI Certificates CA signiert, um das Vertrauen innerhalb des OCI-Ökosystems aufrechtzuerhalten.
  • Das resultierende signierte Zertifikat wird mit dem lokal generierten Private Key kombiniert und für jeden Service bereitgestellt, der es benötigt – ob in OCI, On-Premises oder in einer anderen Cloud.

Im folgenden Diagramm wird dieser Ablauf veranschaulicht.


Beschreibung vonimplement-oci-ca-ext.png folgt
Beschreibung der Abbildungimplementierung-oci-ca-ext.png

Diese Methode eignet sich am besten für:

  • Nicht-Produktions-Setups, bei denen kostengünstige selbstsignierte Zertifikate ausreichen.
  • Umgebungen, die sowohl eine Zertifikats- als auch eine Private-Key-Kontrolle erfordern (wie benutzerdefinierte Server oder On-Premise-Integrationen).
  • Szenarios, bei denen von OCI verwaltete Zertifikate (die Private Keys ausblenden) nicht mit externen Systemen kompatibel sind.

Bevor Sie beginnen

Bevor Sie beginnen, müssen Sie Folgendes tun:

  • Ein OCI Vault zum sicheren Speichern von Private Keys, die in OCI eingerichtet sind.
  • Eine in OCI eingerichtete und voll funktionsfähige OCI Certificates Certificate Authority (CA).
  • Zugriff auf die OpenSSL-Bibliothek auf dem lokalen Rechner, sodass Sie Ihren Private Key generieren können.

Erforderliche Services und Rollen

Diese Lösung erfordert den folgenden Service und die folgende Rolle:

  • Oracle Cloud Infrastructure

Dies ist die Rolle, die für den Service erforderlich ist.

Servicename: Rolle Erforderlich für...
Oracle Cloud Infrastructure: Administrator Verwalten Sie Obects in Compartments, und lesen oder verwalten Sie Zertifikate, Buckets, Vaults und Schlüssel (siehe unten).

Sie können eine einfache Policy für Certificate Authority-Administratoren verwenden oder sowohl einen Administrator als auch eine dynamische Gruppen-Policy einrichten, um Rollen und Zuständigkeiten zu trennen und nach Compartment einzuschränken. Beispiel:

### 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
```

Oder:

### 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
```

Informationen zu Ihren Anforderungen finden Sie unter Produkte, Lösungen und Services von Oracle.