OCI-Architektur und Best Practices

Die EU Sovereign Cloud bietet OCI-Kunden die folgenden einzigartigen Funktionen:

• Datenschutz über Serviceschutz und Datenreplikation
• Zugriff auf Modelle über virtuelle Netzwerke
• Sicherheitsmodelle über IAM
• Auditing von Compliancemodellierung und -Governance

Jedes dieser Modelle bietet spezifische Mechanismen, die Kunden die Möglichkeit bieten, die Souveränität ihrer Cloud-Umgebung zu stärken.

Datenschutz

Der Datenschutz innerhalb der EU Sovereign Cloud wird aus verschiedenen Perspektiven angegangen:

• Zugriff: Beschränken des Zugriffs auf Daten, um unbefugte Nutzung zu verhindern.
• Intra-EU-Datenreplikation: Erstellen von Kopien von Daten an zwei verschiedenen physischen Standorten (Regionen), während sie innerhalb der EU bleiben.
• Replikationspfad verlässt die EU nicht: Die Replikationsverbindung zwischen Regionen ist vollständig in der EU-Datenübertragung zwischen EU Sovereign Cloud-Regionen enthalten und erfolgt über ein dediziertes Rückgrat, das für die EU Sovereign Cloud eingerichtet wurde, und verlässt die EU während des Transits nicht.
• Lokale Verschlüsselungsschlüssel: Datenspeicherung und -verschlüsselung werden entweder von EU Sovereign Cloud-generierten Schlüsseln verwaltet, die in der EU verwaltet werden, oder mit vom Kunden bereitgestellten Schlüsseln. Vom Kunden bereitgestellte Schlüssel werden in einem Key Management Service (KMS) gespeichert, der sich physisch in der EU befindet und vollständig vom Kunden kontrolliert wird.
• Lokale Certificate Authoritys: Mit dem OCI Certificates-Service können Mandanten alle Aktionen im Zusammenhang mit der Zertifikatausgabe und -verwaltung ausführen. Dazu gehört der Import von Drittanbieter-Root Certificate Authority (CA), die intern an Ressourcen innerhalb der EU Sovereign Cloud verteilt werden können, ohne das Internet zu durchqueren. Diese Zertifikate können dann auf SSL und andere Anwendungen angewendet werden, um eine starke, lokal überprüfbare Verschlüsselung zwischen Sites herzustellen.

Erste Schritte mit Datenschutz

Um mit Datenschutzmethoden zu beginnen, gehen Sie wie folgt vor:

• Verwenden Sie Oracle Cloud Stacks, um eine standardisierte Infrastruktur in zwei EU Sovereign Cloud-Datenregionen zu erstellen.
• Erstellen Sie einen regionsübergreifenden Link für die Infrastruktur mit dynamischen Routinggateways (DRGs), um Regionsnetzwerke sicher miteinander zu verbinden.
• Richten Sie die Replikation zwischen beiden Sites mit Tools wie Data Guard, regionsübergreifender Object Storage-Replikation und anwendungsbasierten Replikationstools ein, um Daten zu schützen, die in EU Sovereign Cloud gehostet werden.
• Erstellen Sie einen OCI Vault in der EU Sovereign Cloud für kritische Secrets und Schlüssel, und replizieren Sie den Vault in der zweiten Datenregion.
• Laden Sie Zertifikate in den OCI Certificates-Service hoch, und verwenden Sie den Serviceendpunkt zum Laden und Validieren von Zertifikaten.

Daten an einem anderen Speicherort replizieren

Eine der gängigsten Strategien, um den Datenschutz zu gewährleisten, ist die Replikation von Daten an einem anderen Ort für die langfristige Speicherung durch die Verwendung einer heißen/warmen Website.

Im Idealfall erfolgt die Replikation über einen Link, der so direkt wie möglich zur Quelle ist und sowohl für den Datenschutz als auch für die Kommunikation zwischen Standorten verwendet werden kann, um die Kosten der Verbindung zu optimieren. Im Falle der EU sollte die Datenverbindung selbst keinen Weg haben, der es den Daten ermöglicht, die EU zu verlassen.

Beschreibung der Abbildung mad-fra-region.png

mad-fra-region-oracle.zip

EU Sovereign Cloud bietet Datenschutzmechanismen und OCI-Services, mit denen Sie die Anforderungen an Datenreplikation und -transit erfüllen können. Oracle hat die EU Sovereign Cloud-Datenregionen mit Serviceparität eingerichtet, mit der Sie die Implementierung von Speicher und Anwendungen widerspiegeln können. Speicher und Anwendungen können über einen dedizierten Backbone-Link in die andere EU Sovereign Cloud-Datenregion repliziert werden. Dabei können die Funktionen und verfügbaren Services identisch sein. Dieses dedizierte Backbone wird auch für das Management des Datenverkehrs zwischen den EU Sovereign Cloud-Regionen verwendet, und ein großer Teil der Bandbreite steht für die Nutzung durch Mieter in der EU Sovereign Cloud zur Verfügung. In allen Fällen ist der Kundendatenverkehr, der über dieses Backbone fließt, sowohl von anderen Realms als auch von Regionen isoliert, die nicht Teil der EU Sovereign Cloud sind.

Daten verschlüsseln

Die Datenverschlüsselung und/oder die Speicherung von Verschlüsselungsschlüsseln, die für verschiedene Zwecke in einem bestimmten System verwendet werden, ist ebenfalls ein kritischer Aspekt von Datenschutzstrategien. Oracle bietet eine lokalisierte KMS-Lösung, die Schlüssel verwaltet, die für die Datenspeicherverschlüsselung in der EU Sovereign Cloud verwendet werden können und Schlüssel speichert, die programmgesteuert zur Verwendung in Anwendungen oder Datenverschlüsselungsmechanismen auf Instanzebene abgerufen werden können.

Der OCI Vault-Service stellt dieses Feature bereit. Vault kann entweder als Multi-Tenant-softwarebasiertes KMS oder als dedizierte HSM-Module implementiert werden. In beiden Fällen befindet sich Vault ausschließlich innerhalb der EU Sovereign Cloud-Realm, und Oracle kann nicht auf Schlüssel oder Geheimnisse zugreifen, die entweder im Software-Vault oder im dedizierten HSM gespeichert sind. Datenverschlüsselungsaktivitäten befinden sich auch ausschließlich in der EU Sovereign Cloud, wobei jede Region ihre eigene unabhängige Vault-Implementierung beibehält. Zu den Schlüsselverschlüsselungsalgorithmen, die OCI Vault unterstützt, gehören der Advanced Encryption Standard (AES), der Rivest-Shamir-Adleman-(RSA-)Algorithmus und der digitale Signaturalgorithmus für elliptische Kurven (ECDSA). Kunden können symmetrische AES-Schlüssel und asymmetrische RSA-Schlüssel für die Verschlüsselung und Entschlüsselung erstellen und verwenden oder asymmetrische RSA- oder ECDSA-Schlüssel zum Signieren digitaler Nachrichten verwenden.

Verbindungen zu Data Consumern verschlüsseln

Es ist auch wichtig, nicht nur die Verschlüsselung von Daten im Ruhezustand zu berücksichtigen, sondern auch die Möglichkeit, Verbindungen zu Datenkonsumenten zu verschlüsseln, insbesondere über Protokolle wie HTTPS.

In vielen Fällen werden x.509-Zertifikate entweder über externe Quellen oder über dedizierte Server verarbeitet, die lokale Zertifikate zur internen Verwendung generieren. EU Sovereign Cloud bietet den OCI Certificates-Service, mit dem Kunden lokale Zertifikate für interne und externe Anwendungen erstellen, Zertifizierungs-Bundles von Drittanbietern für den Vertrieb importieren und die im Service installierten Zertifizierungen verwalten können, z. B. Schlüsselrotation. Alle Aufgaben im Zusammenhang mit der Verwaltung von Zertifikaten (Hinzufügen, Rotieren, Löschen usw.) können über einen zentralen Service ausgeführt werden, der sich vollständig in der EU Sovereign Cloud befindet.

Mit OCI Load Balancer integrieren

Durch die Integration mit dem OCI Load Balancer-Service können Kunden ein von OCI-Zertifikaten ausgestelltes oder verwaltetes TLS-Zertifikat nahtlos mit Ressourcen verknüpfen, die Zertifikate benötigen. Anwendungen oder Server, die nicht mit dem Certificates-Service integriert sind, können eine API-Struktur zum Abrufen von Zertifikaten bereitstellen, die von den IAM-Policys des Mandanten als angemessen erachtet werden. Die Zentralisierung von Zertifikaten in einer EU-basierten zuverlässigen Quelle ermöglicht die lokale Verwaltung von Zertifikaten und stellt sicher, dass Kunden innerhalb der EU Sovereign Cloud die Verschlüsselung innerhalb der EU lokalisieren können.

Zugriffsmodell

Die bereits in die OCI-Architektur integrierten Mechanismen ermöglichen es der EU Sovereign Cloud außerdem, effektive Netzwerkpaketfilterung, Zugriffskontrollen, gerichtete Konnektivität und letztendlich eine effektive Möglichkeit zur Begrenzung des Zugriffs auf bereitgestellte Ressourcen und Anwendungen nur auf Netzwerkadressen in der EU bereitzustellen.

Erste Schritte mit Access Model

Um schnell mit der Implementierung eines Zugriffsmodells zu beginnen, gehen Sie wie folgt vor:

• Implementieren Sie ein virtuelles Cloud-Netzwerk-(VCN-)Design mit einem Defense-in-Depth-Ansatz. Verwenden Sie öffentliche Subnetze im VCN nur, wenn sie für externen Zugriff erforderlich sind.
• Erstellen Sie eine DMZ, um Traffic mit öffentlichen und privaten Subnetzen zu filtern.
• Mit dem OCI Network Firewalls-(NFW-)Service können Sie den Zugriff auf kritische Subnetze, einschließlich aller öffentlichen, kontrollieren und überwachen.
• Erstellen Sie Sicherheitslisten pro Subnetz, um den internen Subnetzzugriff einzuschränken.
• Implementieren Sie Netzwerksicherheitsgruppen (NSGs) an jeder Instanz/an jedem Endpunkt, um die Zugriffsquelle eng zu kontrollieren.
• Aktivieren Sie VCN-Flowlogs regelmäßig, um Traffic zu auditieren.
• Implementieren Sie das OCI Domain Name System (DNS), um die Adressauflösung zu steuern und unerwünschte DNS-Domains zu filtern, ohne akzeptierte zu beeinträchtigen.
• Verwenden Sie Punktverbindungen wie FastConnect und CPE-Konfiguration, um administrative Backhauls einzurichten, die das öffentliche Internet nicht verwenden.

Sicherheitslisten, Netzwerksicherheitsgruppen und Netzwerkfirewalls verwenden

Die Funktionen nativer OCI-Services wie Network Firewall (NFW), Sicherheitslisten (SL) und Netzwerksicherheitsgruppen (NSG) in Kombination mit Flowlogs für virtuelle Cloud-Netzwerke (VCN) bieten starke Mechanismen, um Zugriffe von Nicht-EU-Ursprungspunkten zu verhindern und zu erkennen.

Eine der wichtigsten Methoden, um sicherzustellen, dass EU-spezifische Bereiche öffentlicher IP-Adressen Zugriff auf Ressourcen haben, ist die Verwendung einer Kombination aus SLs, NSGs und NFW. Im Hintergrund wird der gesamte Zugriff auf Instanzen/Ressourcen, die an OCI-Subnetze angehängt sind, standardmäßig "alle ablehnen". Diese Policy verhindert auch, dass Instanzen im selben Subnetz miteinander kommunizieren. Der Zugriff muss explizit erteilt werden, um Verbindungen über Ressourcen innerhalb eines bestimmten Subnetzes oder über Subnetze im VCN zu initiieren und darauf zu reagieren. Der wichtigste Weg, dies zu erreichen, ist durch SLs. Dies sind Definitionen der zulässigen Konnektivität auf Subnetzebene, die Sie nach Protokoll, Port und CIDR-Bereich angeben können. Verbindungen, die außerhalb der definierten Bereiche liegen, werden stillschweigend gelöscht. NSGs führen einige der gleichen Aufgaben aus, werden aber auf der virtuellen NIC-(VNIC-)Schicht und nicht auf das Subnetz als Ganzes angewendet. Durch die Verwendung einer Kombination aus SLs und NSGs kann ein EU Sovereign Cloud-Kunde eine eingeschränkte Zone für den Zugriff auf Ressourcen erstellen, die nur Adressen aus angegebenen öffentlichen IP-Bereichen der EU akzeptiert. Wenn der Kunde diese Limits auf einzelne Ressourcen wie Load Balancer, Compute-Instanzen, Bastionen usw. ausdehnt, kann ein gezieltes Zugriffsmuster implementiert werden, um die Anforderungen der Organisation zu erfüllen. Schließlich sind die NSGs und SLs bidirektional, was bedeutet, dass sowohl interne als auch externe Konnektivitätsregeln unabhängig voneinander festgelegt werden können. Mit dieser Funktion muss, selbst wenn eine eingehende Verbindung hergestellt wird, entweder durch Design oder durch eine Fehlkonfiguration der eingehenden Regeln, die externe Verbindung weiterhin zugelassen werden, damit die vollständige Sitzung hergestellt werden kann.

Eine "Fronttür" für Ressourcen in VCNs implementieren

EU Sovereign Cloud bietet auch einen Palo Alto-basierten Netzwerkfirewall-Service, der die Implementierung einer Vielzahl von Services und Einschränkungen als "Fronttür" für Ressourcen in VCNs ermöglicht, wie zum Beispiel:

• Zustandsbehaftete Netzwerkfilterung

  Die zustandsbehaftete Netzwerkfilterung erstellt zustandsbehaftete Netzwerkfilterregeln, die Netzwerktraffic basierend auf Quell-IP (IPv4 und IPv6), Ziel-IP (IPv4 und IPv6), Port und Protokoll zulassen oder ablehnen.

• Benutzerdefinierte URL- und FQDN-Filterung

  Die benutzerdefinierte URL- und FQDN-Filterung beschränkt Ingress- und Egress-Traffic auf eine angegebene Liste von vollqualifizierten Domainnamen (FQDNs), einschließlich Platzhaltern und benutzerdefinierten URLs.

• Intrusion Detection and Prevention (IDPS)

  Intrusion Detection and Prevention (IDPS) überwacht Ihr Netzwerk auf böswillige Aktivitäten und verhindert, dass verdächtiger Netzwerkverkehr das interne Netzwerk erreicht.

• SSL-Prüfung

  Die SSL-Prüfung entschlüsselt und prüft TLS-verschlüsselten Traffic mit ESNI-Unterstützung für Sicherheitslücken. Encrypted Server Name Indication (ESNI) ist eine TLSv1.3-Erweiterung, die die SNI (Server Name Indication) im TLS-Handshake verschlüsselt.

• Intra-VCN-Subnetztrafficprüfung

  Bei der Prüfung des Intra-VCN-Subnetztverkehrs wird der Traffic über eine Netzwerkfirewall zwischen zwei VCN-Subnetzen weitergeleitet.

• VCN-übergreifende Trafficprüfung

  Bei der Inter-VCN-Trafficprüfung wird der Traffic zwischen zwei VCNs über eine Netzwerkfirewall weitergeleitet.

Beschreibung der Abbildung Zugriffsmodell-arch.png

Zugriffsmodell-arch-oracle.zip

Im obigen Diagramm gibt es fünf Szenarien:

1. Der NFW lehnt die Verbindung basierend auf dem vom Kunden definierten Regelset ab und der Verbindungsversuch wird protokolliert.
2. Die NFW akzeptiert die Verbindung und leitet die Verbindung an die entsprechende Instanz im geschützten Subnetz weiter. Die SL lässt diese Verbindung von diesem Subnetz zu, und die NSG auf der Instanz verfügt über eine Regel, die Verbindungen von der NFW zulässt.
3. Die Instanz in Subnetz A versucht, eine Verbindung zu einer Instanz herzustellen. Während die SL Verbindungen aus Subnetz A zulässt, verhindert die NSG der Instanz die Verbindung.
4. Die Instanz in Subnetz A versucht, eine andere Verbindung zu einer anderen Instanz herzustellen. Hier ermöglichen sowohl die SL als auch die NSG den Anschluss
5. Die Instanz in Subnetz B versucht, eine Verbindung zu einer Instanz herzustellen. Dem Subnetz B wurde kein Zugriff auf das geschützte Subnetz erteilt. Daher ist keine Verbindung zulässig, unabhängig von der NSG der Instanz.

Angemessene Namensauflösung steuern und bestimmen

Darüber hinaus ist die Möglichkeit, geeignete Namensauflösungsquellen zu steuern und zu bestimmen, ein Mechanismus, der die Konnektivität bestimmen und die Namensauflösung und das Relay deterministisch an definierte DNS-Endpunkte bereitstellen kann.

Die EU Sovereign Cloud-Umgebung erbt den OCI-DNS-Service, sodass Sie sowohl die in der EU Sovereign Cloud verwendeten Endpunkte als auch die Quellen, an die Anforderungen weitergeleitet werden, genau kontrollieren können. Der OCI-DNS-Service erreicht dies, indem er den DNS-Listener-Endpunkt vom Weiterleitenden aufteilt, wobei eine Rules Engine zwischen den beiden eingebettet ist. Auf diese Weise können Sie festgelegte Regeln für die Richtung von DNS-Anforderungen definieren, möglicherweise für verschiedene Weiterleitungen basierend auf der angeforderten Domain. Die Anforderung für Domain-Lookups, die bestimmt wird, dass sie außerhalb des Regelsets liegt, oder die Auswahl mehrerer Weiterleitungen, die je nach Ergebnis der Regel-Engine auf verschiedene DNS-Quellen verweisen, gibt die Antwort NX_DOMAIN für zielgerichtete Nullumleitungen zurück. Kunden können sehr bewusst auf die DNS-Auflösungsantwort sowohl der internen EU Sovereign Cloud als auch der externen EU Sovereign Cloud reagieren und einen Filtermechanismus bereitstellen.

Beschreibung der Abbildung valid-vs-invalid-dns-request.png

valid-vs-invalid-dns-request-oracle.zip

EU Sovereign Cloud-Kunden weniger eingeschränkten Zugriff auf die Umgebung bieten

EU Sovereign Cloud-Kunden benötigen möglicherweise weniger eingeschränkten Zugang zur Umwelt als die öffentlichen Verbraucher der von den Eigentümern der EU Sovereign Cloud-Mandanten bereitgestellten Services. Dieser Zugriffstyp wird durch dieselben direkten Verbindungstypen in der OCI Public Cloud erreicht.

• FastConnect

  FastConnect ist eine direkte MPLS-Verbindung (Multiprotocol Label Switching) zu EU Sovereign Cloud Points of Presence. Diese Links werden nicht mit anderen Verbrauchern von EU Sovereign Cloud geteilt und sind dem jeweiligen Mandanten gewidmet, dem sie zugewiesen sind

• Customer Premises Equipment (PPE)

  CPE ist ein VPN-Konnektivitätsmodell, mit dem Kunden private Verbindungen im Remote-Office-Stil zur EU Sovereign Cloud implementieren können, ohne in die Infrastruktur investieren zu müssen, die für die dedizierten MPLS-Links erforderlich ist.

Während die Verbindungen direkt sind, bleiben alle Zugriffskontrollmechanismen in Kraft. Die Konnektivität über einen FastConnect-Link unterliegt also weiterhin den von den SLs und NSGs definierten Regelsets und kann von der NFW-all mit anderen Regeln überwacht werden, die auf Verbindungsquellen/-zielen basieren, als die Regeln für die öffentlich zugänglichen Ressourcen. Mit einem oder beiden dieser Verbindungstypen können EU Sovereign Cloud-Mieter unterschiedliche Konnektivität herstellen. Die Kombination der Zugriffskontrollmethoden (SLs, NSGs) und des NFW bietet einen Mechanismus zur engen Kontrolle und Überwachung des Zugriffs auf die Ressourcen der Umgebung.

Mit diesen Zugriffsfunktionen können Benutzer der EU Sovereign Cloud "Mauergärten" mit Ressourcen erstellen, die ausschließlich innerhalb der EU verwendet werden können, wie hier dargestellt:

Beschreibung der Abbildung walled-garden.png

Wandgarden-oracle.zip

Die NFW bietet die Unterstützung für Zugriffserkennung, Ablehnung und Protokollierung der ersten Ebene, wobei die SLs den Zugriff auf Ressourcen innerhalb eines bestimmten Subnetzes auf der zweiten Ebene einschränken. Die NSGs schränken den Zugriff weiter nach Ressourcen ein. Sowohl die SLs als auch die NSGs können bidirektionale Regelsätze enthalten, welche die ausgehenden IP-Adress-/Portbereiche einschränken. In diesem speziellen Fall würden jedoch Daten, Wartung und Administration der Mandantenressource über die Verbindung FastConnect bereitgestellt, die auch durch die SLs und NSGs begrenzt ist. Die in beiden Features definierten Regelsets gelten auch für die Verbindungen über FastConnect. Die Auflösung ausgehender Verbindungen, entweder zur Initiierung oder zur Validierung der Domainmitgliedschaft eingehender Verbindungen, wird über eine Kombination von DNS-Listenern/Forwardern durchgeführt, die auf bestimmte DNS-Auflösungsquellen verweisen. Zusammen ermöglichen diese Funktionen die Schaffung eines öffentlich zugänglichen, kontrollierten Zugangsdienstportals, wobei Datenmanagement und -wartung "out-of-Band" durchgeführt und auf die EU beschränkt werden.

Sicherheitsmodell

OCI verwendet den Identity and Access Management-(IAM-)Service, um Sicherheit rund um das Management "der Cloud" bereitzustellen. IAM konzentriert sich darauf, sicherzustellen, dass Operatoren von Mandanten innerhalb einer bestimmten Realm in ihren Aktionen im Mandanten eingeschränkt werden können.

Erste Schritte mit dem Sicherheitsmodell

So beginnen Sie mit dem Sicherheitsmodell:

• Erstellen Sie Sicherheitszugriffsmodelle für die "Verwaltung der Cloud" im Vergleich zu den Modellen, die für die "Verwaltung in der Cloud" erforderlich sind. Erstellen Sie eine kleine Anzahl vertrauenswürdiger Benutzer in Identity and Access Management (IAM) für die Verwaltung der Cloud.
• Implementieren Sie Identity Federation, um den Organisationszugriff zu vereinheitlichen. Verwenden Sie separate Gruppen für EU Sovereign Cloud innerhalb des Verbands, um den Zugriff auf EU-basierte Personen einzuschränken.
• Halten Sie Identitäten zwischen EU Sovereign Cloud- und Nicht-EU Sovereign Cloud IAM-Accounts einzigartig. Dadurch wird die Administratorverwirrung bei der Verwaltung von Umgebungen verringert.
• Erstellen Sie OCI-Compartments für bereitgestellte Ressourcen basierend auf funktionalen und organisatorischen Grenzen.
• Identitätsdomains für Unterorganisationen zur Selbstverwaltung ihrer lokalen Umgebungen erstellen
• Erstellen Sie mit Cloud Guard eine Sub-Sovereign Cloud-(Sub-SC-)Umgebung, um IAM-Policys zu überwachen.

Sicherheitsmodell

Der IAM-Service wird von OCI-Mitarbeitern nicht verwendet und steht ihnen in keiner Phase des Cloud-Betriebs zur Verfügung. Alle von IAM eingeschränkten Aktionen werden auf Mandantenebene angewendet. Während OCI-Mitarbeiter ein Identitäts- und Zugriffsmanagementsystem für den Betrieb der Control Plane verwenden, bietet es keinen Management- oder Betriebszugriff direkt auf Kundenmandanten.

Beschreibung der Abbildung security_structure_overview.png

security_structure_overview-oracle.zip

IAM erstreckt sich nur über die Realm, in der der Mandant selbst vorhanden ist. In diesem speziellen Fall ist die EU Sovereign Cloud in einem einzigen Bereich tätig, der derzeit aus Regionen besteht, die sich physisch in der EU befinden. Daher können alle Konten, die innerhalb von EU Sovereign Cloud-Mandanten erstellt werden, nur mit der Verwaltung von Ressourcen innerhalb des Bereichs selbst arbeiten und nur mit Ressourcen innerhalb der EU arbeiten. Benutzeraccounts haben keinen Kontext außerhalb der Realm. Auch wenn ein Benutzer identische Benutzerzugangsdaten in einer anderen Realm hat, gibt es keinen eingehenden Kontext in der EU Sovereign Cloud.

Cloud-Betriebsaccounts von EU Sovereign Cloud sind innerhalb der Realm vollständig isoliert. Die Kombination aus OCI-Realm-Architektur, Support und Betrieb in der EU und der EU-Rechtseinheitenstruktur setzt die Isolation der EU Sovereign Cloud-Realm nativ durch. Es ist keine zusätzliche Endbenutzerkonfiguration erforderlich, um sicherzustellen, dass die EU Sovereign Cloud unabhängig von anderen OCI-Realms funktioniert.

Beschreibung der Abbildung iam-2-user.png

iam-2-Benutzer-oracle.zip

IAM bietet sowohl lokale Accounts, die in der Realm verwaltet werden, als auch föderierte Accounts, die entweder mit Identity Cloud Service (IDCS) oder anderen SAML2-Föderationsmechanismen verknüpft sind. Der Zugriff auf die Bereitstellungs- und Verwaltungskomponenten Ihres EU Sovereign Cloud-Mandanten kann streng kontrolliert werden, und nur die Konten, die als EU-basiert geprüft wurden, können die Umgebung verwalten. Da es sich um ein föderiertes Accountverwaltungssystem handelt, kann dieselbe Föderation, die für die EU Sovereign Cloud verwendet wird, auch für den Zugriff auf die Compute-Ressourcen verwendet werden, die im Mandanten bereitgestellt werden. Dies bedeutet, eine einheitliche Umgebung zu schaffen, in der eine vollständig überprüfbare Zugriffsmethode sowohl für die Verwaltung "der Cloud" als auch für die Ressourcen "in der Cloud" bereitgestellt werden kann.

Beschreibung der Abbildung idp-vs-iam.png

idp-vs-iam-oracle.zip

Neben den föderierten Accountfunktionen bietet die EU Sovereign Cloud die Möglichkeit, Identitätsdomains (ID) im Mandanten zu erstellen. Eine ID ist im Wesentlichen die Partitionierung des IAM-Bereichs mit einer sekundären Gruppe von angegebenen Administratoren, die keinen Einblick in die obere Ebene der Domain haben und ihre eigenen Zugriffs-Policys erstellen und ihre eigenen Ressourcen kontrollieren können. Der Eigentümer der oberen Ebene des Mandanten kann weiterhin die Kontrolle über die gesamte Ressourcen- und IAM-Administration beeinflussen. Durch die Kombination der ID mit einem übergeordneten Compartment (Nicht-Root-Compartment) können die Mitglieder einer ID eine vollständige Umgebung erstellen, die keine Kenntnis von der Umgebung hat. Mit diesem Instrumentarium könnte eine Organisation innerhalb der EU ein so genanntes "Sub-SC"-Umfeld schaffen. Das heißt, eine Umgebung, in der die Eigenschaften des ursprünglichen Mandanten beibehalten werden, die jedoch die Erstellung einer sekundären Umgebung mit eigenen Policys und Einschränkungen bei der Mitgliedschaft ermöglicht.

Das Konzept des Sub-SC wird in den anschaulichen Fallstudien weiter unten beschrieben. Die Sub-SC-Umgebung kann auch durch die Implementierung von Cloud Guard im Mandanten eingeschränkt, kontrolliert und auditiert werden. Wenn Cloud Guard in dieser Situation angewendet wird, kann es verhindern, dass Compartments, die einer bestimmten Sub-SC zugewiesen und von einer Gruppe von Benutzern kontrolliert werden, die in einer Identitätsdomain definiert sind, Aktionen ausführen, die entweder dem kontinuierlichen Schutz gehosteter Daten widersprechen und/oder Aktionen ausführen, die Sicherheits-Policys in der Umgebung verletzen. Neben Cloud Guard bietet die EU Sovereign Cloud Security Zones, die Policy-Sets mit Vorlagen und Compartments bereitstellen, die einheitlich angewendet werden können. Sicherheitszonen können und werden häufig implementiert, um die Cloud Guard-Konfigurationen zu erweitern.

Staat, Inhalt und EU Sovereign Cloud-Serviceinventar werden in keiner Weise außerhalb des Bereichs beworben.

Auditing und Governance

Die Funktionen und Fähigkeiten der EU Sovereign Cloud bieten aktive Maßnahmen, um sicherzustellen, dass EU-basiertes Personal die Umwelt verwaltet und dass Daten geschützt sind und innerhalb der EU verbleiben. Ohne Mechanismen zur Überprüfung dieser Maßnahmen und zur Dokumentation der Einhaltung der Vorschriften ist es jedoch schwierig, externe Stellen zu versichern.

Erste Schritte mit Auditing und Governance

Um mit Auditing- und Governance-Aktivitäten zu beginnen, gehen Sie wie folgt vor:

• Mit dem OCI Audit-Service können Sie Durchsetzungsaktionen von Governance- und Compliancemodellen überwachen und generieren.
• Implementieren Sie den OCI Logging Analytics-Service, um erweiterte Analysen für die vom OCI Audit-Service generierten Daten durchzuführen.
• Erstellen Sie Policys mit Threat Intelligence und Cloud Guard, um Aktionen und den Zugriff durch unerwünschte Akteure proaktiv zu verhindern.
• Mit dem OCI Tagging-Service können Sie einen Tag-Namespace erstellen, der der Organisationsstruktur und/oder Kostenmodellen entspricht. Taggen Sie alle Ressourcen mit Schlüssel/Wert-Paaren aus den Namespaces für Audits und/oder Rückbelastungen.
• Richten Sie Quotas in Mandanten und Compartments ein, um einen ungenutzten Ressourcenverbrauch zu verhindern.
• Mit den OCI-Services für Budgets und Kostenanalyse können Sie Kosten vorhersagen, überwachen und kontrollieren.

Informationen zu Services und Features für die Überwachung der Einhaltung Ihrer Anforderungen an die Datenhoheit

OCI bietet zusätzliche Services und Features, mit denen Kunden die Einhaltung der Datensouveränitätsanforderungen Ihres Unternehmens überwachen können. Kostenkontrollen und -management können als Tool verwendet werden, um die Compliance mit Ressourcenausgaben zu prüfen, Bedrohungen zu erkennen und sicherzustellen, dass Mandanten innerhalb festgelegter Spezifikationen bleiben.

Die folgenden OCI-Services können in der EU Sovereign Cloud zur Implementierung von Audit- und Governance-Strategien verwendet werden:

• Audit

  OCI Audit zeichnet Zeit, Quelle, Ziel und Art der Aktion für OCI-Services auf, die in der EU Sovereign Cloud verfügbar sind. Aktivitäten wie die Erstellung von Compute-Instanzen, VCN-Vorgänge und andere werden für bestimmte Personen protokolliert, um die in der EU Sovereign Cloud eingerichtete Umgebung zu überwachen und zu auditieren.

• Logging Analytics

  Mit dieser Funktion kann der Kunde mithilfe des Audit-Service erfasste Logs erstellen und verschiedene Ansichten und Visualisierungen erstellen, um die organisatorischen Anforderungen zu erfüllen. Logs aus anderen Quellen können auch aufgenommen werden, um eine vollständige Ansicht der Umgebung für vollständiges Auditing und vollständige Analysen bereitzustellen.

• Threat Intelligence (mit Cloud Guard)

  Threat Intelligence nutzt Input aus verschiedenen Quellen und verwaltet die Daten, um umsetzbare Anleitungen zur Erkennung und Prävention von Bedrohungen in Cloud Guard und anderen OCI-Services bereitzustellen. Mit Cloud Guard können Sie standardisierte Aktionen ("Rezepte") implementieren, die proaktiv auf potenzielle Bedrohungen reagieren können.

• Tagging

  Während die vorherigen Einträge aktive Mechanismen sind, um aktive Bedrohungen zu verhindern, zu erkennen und darauf zu reagieren, konzentrieren sich andere Elemente des Audits und der Compliance auf die Verfolgung von Nutzung und Kosten. Die EU Sovereign Cloud bietet Mechanismen, um Ressourcen beim Provisioning Tags zuzuweisen und die Werte und das Format der Tags vor der Zuweisung zu korrigieren. Diese Tags können über die API abgefragt, in Kostenverfolgung und Abrechnung gemeldet und mit IAM-Policys bearbeitet werden, die mit bestimmten Ressourcen und Instanzen verknüpft sind. Mit Tagging können Sie derselben Ressource mehrere Tags zuweisen und die Ressourcennutzung aus mehreren Perspektiven prüfen. Beispiel: Eine Compute-Ressource kann ein Tag aufweisen, das die allgemeine Verwendung der Ressource, eine Gruppe mit der Ressource (z.B. Entwicklung), eine Kostenstelle für die Ressource oder andere Dimensionen angibt, die von Interesse sein könnten.

• Compartment Quotas

  Sie können Ressourcenquotas basierend auf dem Compartment festlegen, in dem sich die Ressource befindet. Quota können die Anzahl und/oder den Geltungsbereich der in der Quota-Definition definierten Ressource auf ein bestimmtes Compartment, eine bestimmte Region oder AD begrenzen.

• Budgets

  Budgets sind ein Tool, mit dem Kunden Alerts basierend auf einem aktuellen Ausgabenlimit, einer vorausschauenden Ausgabenobergrenze oder beidem basierend auf der Absicht des Alerts einrichten können. Basieren Sie Budgetalerts auf Kostenverfolgungstags, dem Compartment, der Ressource oder beiden Tags.

• Kostenanalyse

  Mit dem Tool für Kostenanalyse können Sie aktuelle Verbrauchskosten über Dimensionen hinweg aufschlüsseln. Zeigen Sie die Kosten über eine Kombination aus Vektoren wie Mandant, EU Sovereign Cloud-Region, Compartments und Ressourcentags sowie zu bestimmten verbrauchten Ressourcen, Services und SKUs an. Berichte können gegebenenfalls nach einzelnen Ressourcen gefiltert werden. Mit diesem Tool können Sie auch eine zukünftige Nutzung basierend auf früheren Verbrauchsmustern prognostizieren. Die Daten sind auf Dashboards erweiterbar und über APIs zugänglich. Sie können auch die Ausführung eines Kostenberichts in einem regelmäßigen Intervall planen und die Ergebnisse an einen Objektspeicher-Bucket übermitteln. Diese Berichte können als historische Referenz gespeichert und zur langfristigen Trendanalyse und -verarbeitung in ein Data Warehouse exportiert werden.