Illustrative EU-basierte Organisationsfallstudie

Während die Details der verschiedenen Features informativ sind, ist es hilfreich, die Implementierung von Umgebungen mit Beispielen zu veranschaulichen. In den folgenden Beispielen wird das Konzept eines Sub-SC-Benutzers vorgestellt.

Ein Sub-SC-Benutzer weist die folgenden Eigenschaften auf:
  • Direkter Bezug zur Kundenentität durch Organisation oder Vertrag und hat eine behördliche oder geschäftliche Beziehung zur Kundenentität.
  • Sie sind vollständig innerhalb der EU enthalten und unterliegen mindestens den gleichen Datenschutz- und Souveränitätsanforderungen wie das Unternehmen selbst.
  • Sie sind nicht nur Organisationsgruppen innerhalb des Kunden selbst, sondern eigenständige Einheiten. Dies kann eine Regierungsabteilung oder eine Tochtergesellschaft einer kommerziellen Unternehmenseinheit sein. Sie haben möglicherweise eine Obermenge von Anforderungen in Bezug auf Datenschutz und Klassifizierung, können jedoch nicht unter die Mindestanforderungen der Kundenentität selbst fallen. Beispiel: Wenn ein Beispielkunde eine Gruppe von Compartments und Ressourcen für sich selbst verwaltet, aber Sub-SC-Benutzern Zugriff gewährt, behält der Kunde die Kontrolle über die Ressourcen, die vom Sub-SC-Benutzer bereitgestellt werden, gemäß dem jeweiligen rechtlichen Rahmen des Sub-SC-Benutzers.
Diese Fallstudie nutzt eine hypothetische Situation, in der der Kunde eine Reihe von Cloud-Services für eine Gruppe von Tochtergesellschaften oder Sub-SC-Benutzern bereitstellen möchte, einschließlich der Möglichkeit für diese Sub-SC-Benutzer, ihre eigenen Services zu hosten, die mit den globalen Services interagieren, die der Kunde selbst bereitstellt. Der Kunde würde den Mandanten hinsichtlich der Kosten, der Zuweisung von Compartments im gesamten Mandanten und der Erstellung globaler Gruppen für die Verwaltung des Mandanten kontrollieren. Jede Sub-SC verfügt jedoch über eine eigene Umgebung, die durch Compartment Spaces definiert ist, die sie "eigen" haben und vollständig von ihrer Benutzerbasis kontrolliert werden und über eine Identitätsdomain bereitgestellt werden. Innerhalb der untergeordneten oder "root"-Compartments jeder Sub-SC können zusätzliche Compartments erstellt und Ressourcen bereitgestellt werden.

Die Sub-SC-Compartments sind exklusiv für jeden Sub-SC-Benutzer, wobei kein anderer Sub-SC-Benutzer die Compartment-Struktur, Ressourcen oder Aktivitäten anderer Sub-SC-Benutzer anzeigen kann. Auditlogs und andere Auditing- und Complianceaktivitäten werden auf Kundenebene ausgeführt, jedoch für jede Identitätsdomain sichtbar gemacht - gefiltert nach ihrem individuellen "Root"-Compartment und eingeschränkt basierend auf ihrer Identitätsmitgliedschaft für Sichtbarkeit. Dadurch können sowohl der Kunde als auch der einzelne Sub-SC-Benutzer unabhängig auf Kosten-, Compliance- und Bedrohungserkennung prüfen. Die erstellten Ressourcen liegen im Ermessen des Kunden (für seine eigenen Compartments) und jedes Sub-SC-Benutzers und können durch OCI Compartment Quotas- und Budgetfeatures in EU Sovereign Cloud eingeschränkt werden.

Beispielsicherheitsmodell

Das Sicherheitsmodell für dieses Beispiel ist im folgenden Diagramm dargestellt:


Beschreibung von iam-security-model.png folgt
Beschreibung der Abbildung iam-security-model.png

iam-Sicherheitsmodell-oracle.zip

Hier richtet der Kunde einen Mandanten ein und erstellt sowohl eine Gruppe von Compartments für die eigene Verwendung (die "Division"-Compartments) als auch eine Gruppe von Basis-Compartments zur Verwendung durch jedes Sub-SC-Element. Wenn sich jeder Sub-SC-Benutzer für die Verwendung von Ressourcen im Mandanten anmeldet, wird eine Identitätsdomain um das spezifische übergeordnete Compartment erstellt, das für den Sub-SC-Benutzer erstellt wurde. Der Sub-SC-Benutzer kann dann seine eigene Benutzerbasis mit seiner individuellen Identitätsdomain föderieren und Berechtigungen unabhängig von den vom Kunden zugewiesenen Berechtigungen zuweisen. Diese Bereiche könnten als quasi-unabhängige Einheiten funktionieren, mit Beziehungen, die auf der Grundlage einer gemeinsamen Vereinbarung definiert werden.

Datenschutz-Anwendungsfall

Der Sub-SC-Benutzer hätte mehrere nicht-exklusive Optionen für die Einleitung des Datenschutzes mit EU Sovereign Cloud. Zunächst wäre es einfach, das oben dargestellte bestehende Datenschutzmodell zu verwenden. Die Sub-SC-Identitätsdomain ist über den gesamten Mandanten hinweg vorübergehend. Mit anderen Worten: Da die Identitätsdomain eine mandantenweite Ressource ist, sind Zugriffsoptionen in beiden Regionen basierend auf den Policys verfügbar, die für den gesamten Mandanten eingerichtet wurden.

Compartments folgen ebenfalls diesem Modell. Auf diese Weise kann jeder Sub-SC-Benutzer die Datenreplikation ausführen, indem er die einzelnen Ressourcen verwendet, die in seinen eigenen Compartments - über zwei Datenregionen hinweg - erstellt wurden, um als Replikationsziele oder -quellen zu fungieren. Dies ermöglicht die Verwendung von aktiven/aktiven und aktiven/passiven Datenschutzmodellen, abhängig von der Fähigkeit einzelner Anwendungen, die von der Sub-SC bereitgestellt werden, und der RTO/RPO-Toleranz von Anwendungen, die nicht aktiv/aktiv arbeiten können. Der Datenschutz wäre unabhängig und von anderen Sub-SC-Nutzern isoliert. Es wäre vom Kunden zu beobachten, dass er die Baseline-Services aufgrund der Tatsache erbringt, dass die Replikation existiert, aber nicht durch die Beobachtung der Daten selbst. Backup- und/oder Snapshot-Services können vom Sub-SC-Benutzer verwendet werden (im Fall von Block Storage und Object Storage) und wären in der Identitätsdomain/im Compartment jedes Sub-SC-Benutzers lokalisiert - für andere Sub-SC-Benutzer nicht zugänglich.

Alternativ kann jeder Sub-SC-Benutzer Drittanbieter- oder lokale Ressourcen (innerhalb der physischen Grenzen der Sub-SC-Umgebung) als Datenschutzziele verwenden. Dies würde durch die Einrichtung privater FastConnect- oder CPE-VPN-Verbindungen zu Compartments erreicht werden, die vom Sub-SC-Benutzer gesteuert werden. Die Datenverbindung wäre vollständig vom anderen Sub-SC-Benutzer und vom Kunden isoliert, da jeder Verbindungspunkt ausschließlich in der Identitätsdomain-/Compartment-Struktur des Sub-SC-Benutzers selbst vorhanden wäre. Dieses Modell würde den Schutz und die Extraktion von Daten an einen Dritten außerhalb der Kontrolle des Kunden in ein lokales Daten-Repository innerhalb der physischen Grenzen der Sub-SC-Umgebung oder eine Kombination davon je nach den Bedürfnissen des einzelnen Sub-SC-Benutzers ermöglichen.


Beschreibung von security_structure_overview.png folgt
Beschreibung der Abbildung security_structure_overview.png

security_structure_overview-oracle.zip