Cyber-Recovery-Lösung auf Oracle Cloud Infrastructure implementieren

Cyber-Sicherheit ist zu einem immer kritischeren Thema geworden, da Malware und Ransomware-Angriffe auf der ganzen Welt weiterhin auftreten. Bei geschäftskritischen Datenbanken können solche Angriffe, die zu verlorenen Daten führen, und Systemausfallzeiten weitreichende Auswirkungen auf Umsatz, Betrieb, Reputation und sogar Strafen im gesamten Unternehmen haben.

Sie können eine Lösung zum Schutz Ihrer auf Oracle Cloud Infrastructure (OCI) gehosteten Oracle-Anwendungen vor Cyberangriffen implementieren, indem Sie unveränderliche Backups erstellen und speichern. Im Falle eines Cyberangriffs, wie einer Ransomware-Verschlüsselung, können die unveränderlichen Backups verwendet werden, um die Oracle-Anwendung in einen vorherigen Zustand wiederherzustellen, sodass Geschäftsvorgänge minimiert unterbrochen werden.

Architektur

Diese Referenzarchitektur zeigt, wie Sie eine automatisierte Backup- und Restore-Lösung implementieren können, die auf OCI bereitgestellt ist.

Oracle E-Business Suite-Anwendung (EBS) wird als Beispiel für diese Lösung verwendet. Sie können sie jedoch problemlos für andere Oracle-Anwendungen einsetzen.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung der Abbildung oci_cyber_recovery_arch.png

OCI-cyber-recovery-arch-oracle.zip

1. Um diese Referenzarchitektur bereitzustellen, erstellen Sie einen neuen OCI-Mandanten (mit dem Namen Cyber Recovery-Mandanten), um unveränderliche Kopien von Backups zu speichern.
   1. Der Cyber Recovery-Mandant stellt eine Plattform zum sicheren Testen und Wiederherstellen von Systemen im Falle eines Cyberangriffs bereit.
   2. Der Cyber-Recovery-Mandant wird aus dem Production-Netzwerk "air-gapped" und eingehende Verbindungen werden nur während eines Cyber-Recovery-Aufrufs oder eines regelmäßigen Tests zugelassen.
   3. Der OCI Cyber Recovery-Mandant unterscheidet sich hinsichtlich des Zugriffsmanagements ohne Integration mit Active Directory. Alle in den OCI Cyber Recovery-Mandanten kopierten Daten werden innerhalb des Mandanten initiiert und über den Netzwerkbackbone von OCI kopiert, um eine vollständige Sicherheit zu gewährleisten.
2. Sichern Sie alle Produktionsentitys (Datenbanken, Server, File Storage usw.) in einer Gruppe von Cyber Recovery Object Storage-Buckets im Produktionsmandanten gemäß einem definierten Backupzeitplan.
   1. Für die Cyber Recovery Object Storage-Buckets müssen die Aufbewahrungs- und Lebenszyklus-Policys Ihren Anforderungen entsprechen (Beispiel: Ein täglicher Bucket mit einer eigenen Aufbewahrungs-Policy wird verwendet).
   2. Für die Cyber Recovery Object Storage-Buckets müssen Berechtigungen festgelegt sein, damit sie von einem Synchronisierungsskript gelesen werden können, das vom Cyber Recovery-Mandanten initiiert wurde.
   3. Nutzen Sie vorhandene Produktionsbackups erneut mit zusätzlichen Backuplösungen, falls erforderlich.
   4. Im Produktionsmandanten müssen unterschiedliche Speichertechniken bereitgestellt werden, die jeweils eine andere technische Lösung aufweisen, jedoch dieselbe logische Abfolge beim Erstellen eines Cyber Recovery-Datasets befolgen.
3. Das Synchronisierungsskript aus dem CRS-Compartment des Cyber Recovery-Mandanten wird regelmäßig ausgeführt (Beispiel: alle 15 Minuten während des Backupfensters).
   1. Wenden Sie die Admin-Policy an, damit der Zugriff auf den Produktionsmandanten zulässig ist.
   2. Kopieren Sie alle neuen Objekte, die in den Cyber Recovery Object Storage-Buckets für Produktion identifiziert werden, in äquivalente Cyber Recovery-Mandanten-Objektspeicher-Buckets.
   3. Deaktivieren Sie die Admin-Policy, um den Zugriff auf den Produktionsmandanten zu verhindern.
   4. Daten werden über den Netzwerkbackbone von OCI in den Cyber Recovery-Mandanten kopiert, und der gesamte eingehende Zugriff ist auf den Zugriff auf die OCI-Konsole beschränkt.
4. Nachdem ein Objekt mit dem Cyber Recovery-Mandanten synchronisiert wurde, ist sein Lebenszyklus nicht mehr mit dem entsprechenden Produktionsäquivalent verknüpft. Beispiel: In dem unwahrscheinlichen Ereignis (z.B. eine Unstimmigkeit in Lebenszyklus-Policys) wird ein Produktionsbackupobjekt gelöscht. Dies führt NICHT zum Löschen des Cyber Recovery-Mandantenbackupobjekts.
5. Der Cyber Recovery-Objekt-Bucket wird in einem CRS-Compartment gespeichert, das eine Sicherheitszonen-Policy enthält, um nicht autorisierte Änderungen an dem Bucket zu verhindern.
6. Legen Sie Berechtigungen für die Cyber Recovery-Mandantenobjekt-Buckets so fest, dass sie nur von autorisierten Benutzern im Mandanten gelesen werden können (Berechtigungen müssen so festgelegt werden, dass nur das Synchronisierungsskript in sie schreiben kann).
7. Legen Sie Aufbewahrungs-Policys in den Cyber Recovery-Objekt-Buckets fest, um den Objektlebenszyklus zum Löschen zu verwalten (z.B. Objekte werden gelöscht, wenn sie 15 Tage alt sind) und Archivierung (z.B. Archivierungsobjekte, die 10 Tage alt sind).
8. Wenn ein neues Objekt im Cyber Recovery-Objekt-Bucket erstellt wird, wird es auf Viren gescannt und seine sha2/digitale Signatur geprüft, um sicherzustellen, dass die Backupdatei nicht manipuliert wird. Sie sollten eine sha2/digitale Signaturprüfung für die Datenbankbackups ausführen, je nach Backupgröße und Recovery Point Objective (RPO) / Recovery Time Object (RTO) der Lösung.

Hinweis:

Sie können den größten Teil des Prozesses mit Terraform-Skripten, Ansible Playbooks, Shell- und RMAN-Skripten automatisieren, die im Abschnitt Bereitstellen dieser Referenzarchitektur beschrieben werden.

Das folgende Diagramm zeigt eine Beispiel-Deployment-Topologie für den Cyber-Recovery-Mandanten.

Beschreibung der Abbildung oci_cyber_recovery_deploy.png

oci-cyber-recovery-deploy-oracle.zip

In diesem Beispiel verwenden wir dieselben IP-Bereiche wie das VCN der Produktionsanwendung in EBS_BlueRoom und EBS_RedRoom. Dieser Ansatz wurde ausgewählt, um automatisches Testen von Backups mit minimalen Änderungen zu ermöglichen, die zum Wiederherstellen der Anwendung in EBS_RedRoom erforderlich sind. Dies bestimmt das Netzwerkdesign, bei dem sowohl das VCN EBS_BlueRoom als auch das VCN EBS_RedRoom nicht gleichzeitig mit dem DRG verbunden werden können.

Die Trennung des Mandanteneigentums kann in Betracht gezogen werden mit:

1. Ein dediziertes Team, das den Cyber Recovery-Mandanten unterstützt (der keinen Zugriff auf den Produktionsmandanten hat).

   und

2. Ein Supportteam für Produktionsanwendungen mit Zugriff auf die Red Room Compartments während vierteljährlicher Anwendungstests. Dieses Team kann über das On-Premise-Unternehmensnetzwerk auf das CRS-Netzwerk zugreifen.

Die Architektur umfasst die folgenden Komponenten:

• Mandant

  Ein Mandant ist eine sichere und isolierte Partition, die Oracle in Oracle Cloud einrichtet, wenn Sie sich für Oracle Cloud Infrastructure registrieren. Sie können Ihre Ressourcen in Oracle Cloud in Ihrem Mandanten erstellen, organisieren und verwalten. Ein Mandant ist synonym zu einem Unternehmen oder einer Organisation. In der Regel verfügt ein Unternehmen über einen einzelnen Mandanten und spiegelt dessen Organisationsstruktur in diesem Mandanten wider. Ein einzelner Mandant ist in der Regel mit einem einzelnen Abonnement verknüpft, und ein einzelnes Abonnement hat in der Regel nur einen Mandanten.

• Region

  Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domains bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie voneinander trennen (über Länder oder sogar Kontinente).

• Compartment

  Compartments sind regionsübergreifende logische Partitionen in einem Oracle Cloud Infrastructure-Mandanten. Mit Compartments können Sie Ihre Ressourcen in Oracle Cloud organisieren, den Zugriff auf die Ressourcen kontrollieren und Nutzungsquoten festlegen. Um den Zugriff auf die Ressourcen in einem bestimmten Compartment zu kontrollieren, definieren Sie Policys, mit denen angegeben wird, wer auf die Ressourcen zugreifen kann und welche Aktionen sie ausführen können.

  Benutzer (sowohl lokale als auch föderierte) werden einer oder mehreren Gruppen hinzugefügt, die wiederum IAM-Policys zugeordnet sind, die den Zugriff auf die OCI-Assets pro Compartment regeln.

  Mit Compartments können Sie Ressourcen in einem Oracle Cloud Infrastructure-Mandanten organisieren und isolieren. Sie spielen eine wichtige Rolle bei der Festlegung einer Grundlage für die Bereitstellung neuer Workloads in den Mandanten. Obwohl sie scheinbar die Art der logischen Gruppierung von OCI-Ressourcen haben, dienen sie als Policy-Durchsetzungspunkte, sodass sie hinsichtlich der Sicherheit des Mandanten von größter Bedeutung sind.

  Compartments können entsprechend einer funktionalen, betrieblichen oder Projekthierarchie bereitgestellt werden. Dadurch ist eine Isolierung zwischen Ressourcen für verschiedene Rollen, Funktionen und Organisationshierarchie möglich. Eine Compartment-Hierarchie kann je nach Anforderung bis zu 6 Ebenen aufweisen. Die Zugriffskontrolle wird durch Policys definiert.

  Jedem Compartment müssen bestimmte Berechtigungen für die zugehörigen Gruppen zugewiesen sein. In der Regel können Benutzer ihre Berechtigungen nicht auf andere Compartments erweitern. Die folgende Compartment-Hierarchie wird im Cyber Recovery-Mandanten verwendet, um Probleme zwischen Anwendungen und Umgebungen zu trennen.

  
  
  
  Beschreibung der Abbildung oci_cyber_recovery_compartments.png
  
  

  OCI-cyber-recovery-Compartments-oracle.zip

• Availability-Domains

  Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Aus diesem Grund ist es wahrscheinlich, dass ein Fehler in einer Availability-Domain sich auf die anderen Availability-Domains in der Region auswirkt.

• Faultdomains

  Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain verfügt über drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverausfälle, Systemwartungen und Stromausfälle innerhalb einer Faultdomain tolerieren.

• Virtuelles Cloud-Netzwerk (VCN) und Subnetze

  Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

• Load Balancer

  Der Oracle Cloud Infrastructure Load Balancing-Service bietet eine automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt auf mehrere Server im Backend.

• Sicherheitsliste

  Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der in das und aus dem Subnetz zugelassen werden muss.

• Cloud Guard

  Mit Oracle Cloud Guard können Sie die Sicherheit Ihrer Ressourcen in Oracle Cloud Infrastructure überwachen und verwalten. Cloud Guard verwendet Detektorrezepte, die Sie definieren können, um Ihre Ressourcen auf Sicherheitsschwächen zu untersuchen und Operatoren und Benutzer auf riskante Aktivitäten zu überwachen. Wenn eine falsche Konfiguration oder unsichere Aktivität ermittelt wird, empfiehlt Cloud Guard Korrekturmaßnahmen und unterstützt das Ausführen dieser Aktionen basierend auf Responder-Rezepten, die Sie definieren können.

• Object Storage

  Object Storage bietet schnellen Zugriff auf große Mengen strukturierter und unstrukturierter Daten eines beliebigen Inhaltstyps, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und geschützt speichern und dann direkt aus dem Internet oder aus der Cloud-Plattform abrufen. Sie können den Speicher nahtlos skalieren, ohne dass sich die Performance oder Servicezuverlässigkeit verschlechtert. Verwenden Sie Standardspeicher für "Hot"-Speicher, auf den Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicher für "kalten" Speicher, den Sie über lange Zeiträume aufbewahren und selten oder selten darauf zugreifen.

• FastConnect

  Mit Oracle Cloud Infrastructure FastConnect können Sie ganz einfach eine dedizierte, private Verbindung zwischen Ihrem Data Center und Oracle Cloud Infrastructure erstellen. FastConnect bietet Optionen mit höherer Bandbreite und eine zuverlässigere Netzwerkerfahrung im Vergleich zu internetbasierten Verbindungen.

• Local Peering Gateway (LPG)

  Mit einem LPG können Sie ein VCN mit einem anderen VCN in derselben Region verbinden. Peering bedeutet, dass die VCNs mit privaten IP-Adressen kommunizieren, ohne dass der Traffic durch das Internet geleitet oder über Ihr On-Premise-Netzwerk geleitet wird.

• Exadata-DB-System

  Mit Oracle Exadata Database Service können Sie von den leistungsstarken Features von Exadata in der Cloud profitieren. Sie können flexible X8M-Systeme bereitstellen, mit denen Sie dem System Datenbank-Compute-Server und Speicherserver je nach Bedarf hinzufügen können. X8M-Systeme bieten RoCE-(RDMA over Converged Ethernet-)Netzwerke für Module mit hoher Bandbreite und geringer Latenz, persistenter Speicher (PMEM) und intelligenter Exadata-Software. Sie können X8M-Systeme mit einer Ausprägung bereitstellen, die einem Quarter-Rack-X8-System entspricht, und nach dem Provisioning jederzeit Datenbank- und Speicherserver hinzufügen.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.

• VCN

  Bestimmen Sie beim Erstellen eines VCN die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke innerhalb des standardmäßigen privaten IP-Adressraums.

  Wählen Sie CIDR-Blöcke aus, die sich mit keinem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, zu dem Sie private Verbindungen einrichten möchten.

  Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.

  Berücksichtigen Sie bei der Entwicklung der Subnetze Ihren Verkehrsfluss und Ihre Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.

• Sicherheit

  Die EBS- und SOA-Produktionssysteme werden in einem vom Kunden verwalteten OCI-Compartment gehostet, wobei die Sicherheitslage vom Kunden geteilt wird. Die Absicht besteht darin, die Sicherheitslage der Umgebung, einschließlich Sicherheitslisten und Netzwerktopologie, im Cyber-Recovery-Mandanten zu replizieren. Das Zugriffsmanagement im Cyber Recovery-Mandanten unterscheidet sich vom Produktionsmandanten, ohne dass eine IAM-Integration mit der Active Directory-Lösung des Kunden erforderlich ist.

  Der Zugriff auf die Reinräume Blau und Rot wird eingeschränkt, und der gesamte Ingress wird über Bastion-/Jump-Server weitergeleitet, die dieser Rolle zugewiesen sind. Dieser Zugriff wird nur während eines Testfensters aktiviert und entfernt, sobald der Test im roten Raum abgeschlossen ist, während täglich auf den blauen Raum zugegriffen werden kann. Der Zugriff auf den Blauen Raum ist auf den nominierten Cyber Recovery Managed Service Partner beschränkt, während der Zugriff auf den Roten Raum auf den nominierten Managed Service Partner und das Schlüsselpersonal beschränkt ist.

  Der eingehende Zugriff über den IPsec/VPN-Tunnel zum Cyber-Recovery-Mandanten ist für Blue Room täglich verfügbar, während der Zugriff auf Red Room während des normalen Betriebs vollständig gesperrt wird und nur für vordefinierte IP-Adressen während eines Red Room-Testereignisses geöffnet wird.

  Ausgehender Zugriff über den IPsec/VPN-Tunnel vom Cyber-Recovery-Mandanten wird vollständig blockiert. Der Zugriff vom Cyber Recovery-Mandanten auf den Produktionsmandanten erfolgt nur während der Synchronisierung von Backupdateien. Dieser Zugriff wird außerhalb dieser Zeiträume durch Entfernen der Policy verhindert. Es gibt keinen eingehenden oder ausgehenden Internetzugriff für den Cyber-Recovery-Mandanten.

• Cloud Guard

  Klonen und passen Sie die von Oracle bereitgestellten Standardrezepte an, um benutzerdefinierte Detektor- und Responder-Rezepte zu erstellen. Mit diesen Rezepten können Sie angeben, welche Art von Sicherheitsverletzungen eine Warnung generiert und welche Aktionen für sie ausgeführt werden dürfen. Beispiel: Sie möchten Object Storage-Buckets ermitteln, deren Sichtbarkeit auf "Öffentlich" gesetzt ist.

  Wenden Sie Cloud Guard auf Mandantenebene an, um den größten Geltungsbereich abzudecken und den administrativen Aufwand für die Verwaltung mehrerer Konfigurationen zu reduzieren.

  Sie können das Feature "Verwaltete Liste" auch verwenden, um bestimmte Konfigurationen auf Detektoren anzuwenden.

• Netzwerksicherheitsgruppen (NSGs)

  Mit NSGs können Sie eine Gruppe von Ingress- und Egress-Regeln definieren, die für bestimmte VNICs gelten. Es wird empfohlen, NSGs anstelle von Sicherheitslisten zu verwenden, da Sie mit NSGs die Subnetzarchitektur des VCN von den Sicherheitsanforderungen Ihrer Anwendung trennen können.

• Load Balancer-Bandbreite

  Beim Erstellen des Load Balancers können Sie entweder eine vordefinierte Ausprägungen auswählen, die eine feste Bandbreite bereitstellen, oder eine benutzerdefinierte (flexible) Ausprägung angeben, in der Sie einen Bandbreitenbereich festlegen und der Service die Bandbreite basierend auf Trafficmustern automatisch skalieren lässt. Bei beiden Vorgehensweisen können Sie die Ausprägungen nach dem Erstellen des Load Balancers jederzeit ändern.

Überlegungen

Beachten Sie beim Deployment dieser Referenzarchitektur die folgenden Punkte.

• Performance

  Objektspeicherübertragung: Produktionsdatenbanken und Compute-Backups können eine beträchtliche Größe aufweisen. Testen Sie, wie lange ein tägliches Backup zwischen den Mandanten dauert. Um die beste Datenübertragungsperformance zu erzielen, sollten Sie den CRS-Mandanten in derselben OCI-Region wie den Produktionsmandanten bereitstellen.

  Virenschutz und Signaturscan im CRS-Mandanten: Im Rahmen des CRS-Prozesses können Virenschutz und Signaturscans der Backupdateien einbezogen werden. Auf dem Orchestrierungsserver müssen ausreichend Ressourcen bereitgestellt werden, um die Scans zeitnah abzuschließen.

• Sicherheit

  Konfigurieren Sie Oracle Cloud Guard/Maximale Sicherheitszonen, um zu überwachen, ob die Objektspeicher-Policys vorhanden sind und den Cyber Recovery-Sicherheitsstatus erfüllen, um sicherzustellen, dass jeder Versuch, diese zu ändern, verhindert wird.

  Zusätzliche Sicherheitsmaßnahmen sollten implementiert werden, um die Cloud-Umgebung und die Backuplösung vor potenziellen Angriffen zu schützen.

• Verfügbarkeit

  Diese Lösung kann in jeder OCI-Region bereitgestellt werden. High Availability kann durch das Deployment redundanter Orchestrierungs- und Bastionserver erreicht werden.

• Kostenfaktor

  Berücksichtigen Sie bei der Schätzung der Kosten die folgenden Elemente:

  • Object Storage: Bei der Lösung werden tägliche Datenbank- und Block-Volume-Backups der Produktionsumgebung für mehrere Tage gespeichert.
  • Compute-Kosten: Für das Testen von Backups müssen Compute- und Datenbankressourcen gestartet werden.
  • Softwarelizenzkosten: Wenn der Anwendungstest enthalten ist, muss die entsprechende Softwarelizenz für die Anwendungsservices erworben werden, die während des Tests gestartet werden.

Bereitstellen

Sie können diese Referenzarchitektur bereitstellen, indem Sie den Code aus GitHub herunterladen und entsprechend Ihrer spezifischen Anforderung anpassen.

1. Richten Sie die OCI CIS-Landing Zone ein. Weitere Informationen finden Sie unter dem Link Sichere Landing Zone bereitstellen, die der CIS Foundations Benchmark für Oracle Cloud entspricht im Abschnitt Weitere Informationen.
2. Stellen Sie zwei VMs als Orchestrierungsserver im Produktionsmandanten und Cyber-Recovery-Mandanten bereit, um die Skripte auszuführen.
3. Gehen Sie zu GitHub.
4. Klonen Sie das Produktionsskript (Ansible-Skripte) aus dem Repository in den Produktionsorchestrierungsserver.
5. Klonen Sie das Cyber Recovery-Skript (Ansible-, Terraform- und Shell-Skripte) aus dem Repository in den Orchestrierungsserver des Cyber Recovery-Mandanten.
6. Befolgen Sie die Anweisungen im Dokument README, um das Backupskript (Produktionsmandanten), die Synchronisierung und Wiederherstellung (Cyber Recovery-Mandant) auszuführen.

Mehr erfahren

Weitere Informationen zu den Features dieser Referenzarchitektur finden Sie in diesen zusätzlichen Ressourcen.

• Stellen Sie eine sichere Landing Zone bereit, die der CIS Foundations Benchmark für Oracle Cloud entspricht
• Best Practices-Framework für Oracle Cloud Infrastructure
• Oracle Cloud Infrastructure - Dokumentation
• Oracle Cloud-Kostenrechner

Danksagungen

• Authors: Grzegorz Reizer, Peter Deakin, Anand Singh
• Contributors: Bala Sunil, Elwyne Mabanglo, Bhaskar Ivaturi, Hiren Mehta, Chandan Raychaudhury