Autonomous Database mit Referenzarchitektur konfigurieren

Dieser Anwendungsfall zeigt, wie Sie Ihre Autonomous Database-Ressourcen auf einer dedizierten Exadata-Infrastruktur konfigurieren, um ihre Funktionen besser nutzen zu können. Diese umfassende und empfohlene Konfiguration nutzt die Referenzarchitektur von Autonomous Database on Dedicated Exadata Infrastructure.

Oracle Autonomous Database on Dedicated Exadata Infrastructure ist eine hochautomatisierte, vollständig verwaltete Datenbankumgebung, die in Oracle Cloud Infrastructure (OCI) mit festgeschriebenen Hardware- und Softwareressourcen ausgeführt wird. Mit diesen isolierten Ressourcen können Unternehmen strenge Sicherheits-, Verfügbarkeits- und Performanceanforderungen erfüllen und gleichzeitig Kosten und Komplexität reduzieren.

Tipp:

Wenn Sie Anleitungen zur schnellen Konfiguration einer Autonomous Database-POC-Umgebung suchen, finden Sie weitere Informationen unter Autonomous Database für Proof of Concept (POC) konfigurieren.

Vorausgesetzte Kenntnisse

Um diesen Anwendungsfall vollständig zu verstehen und zu schätzen, sollten Sie über ein grundlegendes Verständnis von Autonomous Database on Dedicated Exadata Infrastructure verfügen, einschließlich der Deployment-Optionen, der wichtigsten Infrastrukturkomponenten, Benutzerrollen und Hauptfeatures. Ausführliche Informationen finden Sie unter Informationen zu Autonomous Database on Dedicated Exadata Infrastructure.

Verwandte Themen

Anwendungsfall

Acme Company hat sich für die Verwendung von Autonomous Database on Dedicated Exadata Infrastructure für seine internen Projektanwendungen entschieden. Die IT-Abteilung von Acme übernimmt die Rolle des Flottenadministrators, der für das Erstellen und Verwalten von Exadata-Infrastruktur-(EI-) und autonomen Exadata-VM-Cluster-(AVMC-)Ressourcen für das Unternehmen verantwortlich ist. In jedem Projektteam oder Geschäftsbereich übernehmen die benannten Benutzer die DBA-Rolle der Anwendung, mit der sie autonome Containerdatenbanken (ACDs) und Autonomous Databases für ihre Datenbankbenutzer erstellen können, einschließlich Anwendungsentwickler, Tester und Deployer.

Hinweis:

Dieses Beispiel zeigt, wie der Anwendungs-DBA die ACD-Ressourcen erstellt und verwaltet. Ihre Organisation könnte es jedoch vorziehen, dass der Flottenadministrator diese Aufgabe selbst ausführt.

Acme I.T. weist den verschiedenen Teams Ressourcen zu und stellt so die Bereitstellung von AVMCs sicher, die den erforderlichen SLAs entsprechen. Darüber hinaus möchte die IT-Abteilung von Acme keinen Projektteams oder Geschäftsbereichen Verwaltungszugriff auf die zugrunde liegende dedizierte Infrastruktur gewähren, um die Zuweisung von Ressourcen gerecht zu steuern. Darüber hinaus soll die IT-Abteilung von Acme unter Einhaltung gesetzlicher Audits nicht in der Lage sein, auf die Daten verschiedener Projektteams oder Geschäftsbereiche zuzugreifen, d.h. auf die Daten, die in ihren Anwendungsdatenbanken gespeichert sind.

AcmeHR, eine interne HR-Anwendung, die von Acme entwickelt und verwendet wird, ist in zwei unterschiedlichen Umgebungen verfügbar: eine für Entwicklung und Tests (Dev) und eine für Produktion (Prod). Acme I.T. ist bestrebt, eine strenge Isolation zwischen diesen Umgebungen aufrechtzuerhalten, um unbefugten Zugriff oder unbefugte Interaktion zwischen Entwicklungs- und Produktionsteams zu verhindern.

Benötigte Ressourcen

OCI-IAM-Komponenten


Beschreibung von configure-adb-d-resource-isolation.png folgt
Beschreibung der Abbildung configure-adb-d-resource-isolation.png

  • Drei Compartments für Ressourcenisolation wie unten beschrieben:
    • FleetComp für die von Acme I.T. erstellten Ressourcen, das Netzwerk und die privaten Subnetze, die von Entwicklungs- und Produktionsdatenbanken verwendet werden.
    • DevComp für die Entwicklungsdatenbank.
    • ProdComp für die Produktionsdatenbank.
  • Drei Gruppen, denen Benutzer zugewiesen werden können, jeweils eine für Acme I.T., Dev-Benutzer und Prod-Benutzer. Diese Gruppen heißen FAGroup, DevGroup und ProdGroup.
  • Erforderliche Policys, um den Benutzerzugriff auf die Ressourcen auf Compartment- und Mandantenebene anzugeben.

Netzwerkressourcen


Beschreibung von configure-adbd-refarch-network.png folgt
Beschreibung der Abbildung configure-adbd-refarch-network.png

Symbol für Sicherheitsliste stellt eine Sicherheitsliste dar.

  • Oracle Public Cloud-Deployments:

    • Ein VCN für Netzwerkkonnektivität zu allen dedizierten Infrastrukturressourcen. Dieses VCN verbindet sich über ein IPSec-VPN mit dem Acme-Unternehmens-VPN und verfügt über eine Internetgatewayressource, die den gesamten eingehenden Internetverkehr blockiert. Der Name lautet AcmeHRVCN.
    • Drei Subnetze zur Isolierung des Netzwerkzugriffs, jeweils eines für die Autonomous Database-Ressourcen der Dev- und Prod-Umgebungen und eines für die Client- und Mid-Tier-Ressourcen der Anwendung. Diese Subnetze heißen DevVMSubnet, ProdVMSubnet und AppSubnet.

    Hinweis:

    Der Einfachheit halber verwenden wir ein einzelnes VCN und nutzen Subnetze, um die Netzwerkisolation zu gewährleisten. Sie können jedoch auch mehrere VCNs erstellen, um die erforderliche Netzwerkzugriffsisolation bereitzustellen. In diesem Beispiel erstellen wir aus Gründen der Einfachheit alle drei Subnetze: DevVMSubnet, ProdVMSubnet und AppSubnet unter FleetComp. Je nach Ihren Anforderungen können Sie diese Subnetze optional in separaten Compartments platzieren.

  • Exadata Cloud@Customer-Deployments:

    • Richten Sie Netzwerkregeln ein, wie unter Netzwerkanforderungen für Oracle Exadata Database Service on Cloud@Customer in Exadata Database Service on Cloud@Customer vorbereiten aufgeführt.
    • Öffnen Sie außerdem Port 1522, um TCP-Traffic zwischen der Primärdatenbank und der Standbydatenbank in einem Autonomous Data Guard-Setup zuzulassen.

Autonomous Database-Ressourcen


Beschreibung von configure-adb-d-resources.eps folgt
Beschreibung der Abbildung configure-adb-d-resources.eps

Autonomous Database-Ressourcen gemäß der oben dargestellten Konfiguration.
  • Eine Exadata-Infrastruktur zum Hosten von zwei AVMCs. Der Name lautet AcmeInfrastructure.
  • Zwei AVMCs innerhalb von AcmeInfrastructure für Entwicklungs- und Produktionsumgebungen. Diese AVMCs heißen DevAVMC bzw. ProdAVMC.
  • DevAVMC:
    • hostet die autonome Containerdatenbank und Autonomous Database mit den Namen DevACD bzw. DevADB für die Entwicklung und das Testen der Anwendung AcmeHR.
    • Immer auf das neueste RU gepatcht (Releaseupdate).
    • Bewahrt Backups von sieben (7) Tagen auf.
    • Für jedes Releaseupdate (RU) oder Patchrelease wird AcmeHR, das auf DevADB bereitgestellt wird, mit der neuesten RU getestet.
    • Bei kritischen Problemen wird ein einmaliger Patch angefordert. Nach dem Einspielen des One-off-Patches wird AcmeHR erneut validiert, um sicherzustellen, dass der Code stabil und für die Hochstufung in die Produktion geeignet ist. Weitere Informationen zu One-off-Patches finden Sie unter Wartung des Autonomous Database-Service.
  • ProdAVMC:
    • hostet die für das Produktions-Deployment der Anwendung AcmeHR bereitgestellte autonome Containerdatenbank und Autonomous Database. Sie heißen ProdACD bzw. ProdADB.
    • Wird immer mit der N-1-Softwareversion ausgeführt.
    • Bewahrt Backups länger auf. Bei Bedarf sind auch langfristige Backups aktiviert.
    • Gespeicherte alternative Quartale für die validierte Software, d.h. die in DevAVMC validierten RUs werden in dieser Datenbank bereitgestellt.

Allgemeine Schritte

Bevor Acme I.T. mit der Konfiguration von Autonomous Database-Ressourcen auf einer dedizierten Exadata-Infrastruktur beginnt, fordert es eine Erhöhung des Servicelimits mit der OCI-Konsole an, um dem Mandanten Exadata-Infrastrukturressourcen hinzuzufügen - Datenbankserver und Speicherserver. Weitere Informationen finden Sie unter Erhöhung des Servicelimits beantragen.

Im Folgenden werden die allgemeinen Schritte zur Implementierung dieses Anwendungsfalls aufgeführt:

  1. Der Sicherheitsadministrator für den Cloud-Mandanten von Acme Company erstellt die folgenden Compartments, Gruppen und Compartment Policys für die Ressourcenisolierung:
    • Die Compartments FleetComp, DevComp und ProdComp.
    • Die Gruppen FAGroup, DevGroup und ProdGroup.
    • Die Policys FleetCompPolicy, DevCompPolicy und ProdCompPolicy.
  2. Für Zugriffsisolation:
    • Bei Oracle Public Cloud-Deployments erstellt Acme I.T. oder der Netzwerkadministrator für Acme die folgenden Netzwerkressourcen im Compartment FleetComp:
      • VCN: AcmeHRVCN
      • Private Subnetze: DevVMSubnet und ProdVMSubnet
      • Öffentliches Subnetz: AppSubnet
    • Bei Exadata Cloud@Customer-Deployments stellt Acme I.T. oder der Netzwerkadministrator von Acme Folgendes sicher:
      • Richten Sie Netzwerkregeln ein, wie unter Netzwerkanforderungen für Oracle Exadata Database Service on Cloud@Customer in Exadata Database Service on Cloud@Customer vorbereiten aufgeführt.
      • Öffnen Sie Port 1522, um TCP-Traffic zwischen der Primärdatenbank und der Standbydatenbank in einem Autonomous Data Guard-Setup zuzulassen.
  3. Nach dem Erstellen von Netzwerkressourcen fügt der Sicherheitsadministrator den Cloud-Benutzer eines angegebenen Acme-IT-Mitglieds zur FAGroup hinzu und autorisiert diesen Benutzer als Flottenadministrator.
  4. Der neu autorisierte Flottenadministrator erstellt die folgenden dedizierten Infrastrukturressourcen:
    • Eine Exadata-Infrastrukturressource AcmeInfrastructure im Compartment FleetComp.
    • Zwei autonome Exadata-VM-Cluster (AVMCs) im Compartment FleetComp mit Angabe der neu erstellten Exadata-Infrastruktur:
      • DevAVMC.

        Geben Sie für Oracle Public Cloud-Deployments AcmeHRVCN und DevVMSubnet als VCN und Subnetz an.

      • ProdAVMC.

        Geben Sie für Oracle Public Cloud-Deployments AcmeHRVCN und ProdVMSubnet als VCN und Subnetz an.

  5. Der Sicherheitsadministrator fügt dann den DevGroup- und ProdGroup-Umgebungen bestimmte Cloud-Benutzer hinzu und autorisiert sie als Anwendungs-DBAs für die Dev- und Prod-Umgebungen.
  6. Die neu autorisierten Anwendungs-DBAs erstellen die folgenden Ressourcen in ihren jeweiligen Arbeitsumgebungen, d.h. Dev und Prod:
    • Zwei autonome Containerdatenbanken (ACDs):
      • DevACD im Compartment DevComp, wobei DevAVMC als zugrunde liegende Ressource angegeben wird
      • ProdACD im Compartment ProdComp, wobei Prod AVMC als zugrunde liegende Ressource angegeben wird.
    • Autonomous Database mit dem Namen DevADB im Compartment DevComp.
    • Autonomous Database mit dem Namen ProdADB im Compartment ProdComp.

Schritt 1: Compartments erstellen

In diesem Schritt erstellt der Sicherheitsadministrator für den Cloud-Mandanten von Acme Company die Compartments FleetComp, DevComp und ProdComp.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator die Anweisungen unter Compartments verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole ein Compartment zu erstellen. Beim Befolgen dieser Anweisungen gibt der Sicherheitsadministrator das Root Compartment des Mandanten als übergeordnetes Compartment jedes der drei Compartments an.

Schritt 2: Gruppen erstellen

In diesem Schritt erstellt der Sicherheitsadministrator die Gruppen FAGroup, DevGroup und ProdGroup.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator die Anweisungen unter Gruppen verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole eine Gruppe zu erstellen.

Schritt 3: Policys erstellen

In diesem Schritt erstellt der Sicherheitsadministrator die Policys FleetCompPolicy, DevCompPolicy und ProdCompPolicy.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator die Anweisungen unter Policys verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole eine Policy zu erstellen.

Hinweis:

Neben dem Erstellen der erforderlichen Policy-Anweisungen erstellt der Sicherheitsadministrator in diesem Beispiel auch Policy-Anweisungen vom Typ "USE tag-namespaces", damit Gruppenmitglieder vorhandene Tags den von ihnen erstellten Ressourcen zuweisen können. Damit Gruppenmitglieder Tags erstellen und vorhandene Tags verwenden können, muss der Sicherheitsadministrator stattdessen Policy-Anweisungen vom Typ "MANAGE tag-namespaces" erstellen.

Beim Befolgen dieser Anweisungen für die Policy FleetCompPolicy führt der Sicherheitsadministrator folgende Schritte aus:

  1. Setzt das Compartment im Seitenmenü auf FleetComp, bevor er auf Policy erstellen klickt.

  2. Fügt je nach Deployment-Plattform eine der folgenden Policy-Anweisungen hinzu:

    • Oracle Public Cloud-Deployments:
      • Verwalten von cloud-exadata-infrastructures in Compartment FleetComp durch Gruppe FAGroup zulassen
      • Verwalten von Cloud-autonomous-vmclustern in Compartment FleetComp durch Gruppe FAGroup zulassen
      • Zulassen, dass die Gruppe FAGroup virtuelles Netzwerk im Compartment FleetComp verwendet
      • Zulassen, dass die Gruppe FAGroup Tag-Namespaces im Compartment FleetComp verwendet
      • Gruppe DevGroup das Lesen von cloud-exadata-infrastructures in Compartment FleetComp erlauben
      • Zulassen, dass Gruppe DevGroup cloud-autonomous-vmclusters in Compartment FleetComp liest
      • Zulassen, dass die Gruppe DevGroup virtuelles Netzwerk im Compartment FleetComp verwendet
      • Gruppe ProdGroup das Lesen von cloud-exadata-infrastructures in Compartment FleetComp erlauben
      • Zulassen, dass Gruppe ProdGroup cloud-autonomous-vmclusters in Compartment FleetComp liest
      • Zulassen, dass die Gruppe ProdGroup virtuelles Netzwerk im Compartment FleetComp verwendet
    • Exadata Cloud@Customer-Deployments:
      • Verwalten von Exadata-Infrastrukturen in Compartment FleetComp durch Gruppe FAGroup zulassen
      • Verwalten autonomer Cluster in Compartment FleetComp durch Gruppe FAGroup zulassen
      • Zulassen, dass die Gruppe FAGroup Tag-Namespaces im Compartment FleetComp verwendet
      • Lesen von Exadata-Infrastrukturen in Compartment FleetComp durch Gruppe DevGroup zulassen
      • Gruppe DevGroup das Lesen autonomer Cluster in Compartment FleetComp erlauben
      • Lesen von Exadata-Infrastrukturen in Compartment FleetComp durch Gruppe ProdGroup zulassen
      • Gruppe ProdGroup das Lesen autonomer Cluster in Compartment FleetComp erlauben

Beim Befolgen dieser Anweisungen für die Policy DevCompPolicy führt der Sicherheitsadministrator folgende Schritte aus:

  1. Setzt das Compartment im Seitenmenü auf DevComp, bevor er auf Policy erstellen klickt.

  2. Fügt die folgenden Policy-Anweisungen hinzu:

    • Zulassen, dass die Gruppe DevGroup autonome Containerdatenbanken im Compartment DevComp verwaltet
    • Gruppe DevGroup das Verwalten autonomer Datenbanken im Compartment DevComp erlauben
    • Verwalten von autonomen Backups in Compartment DevComp durch Gruppe DevGroup zulassen
    • Zulassen, dass die Gruppe DevGroup die Instanzfamilie im Compartment DevComp verwaltet
    • Zulassen, dass die Gruppe DevGroup Tag-Namespaces im Compartment DevComp verwendet
    • Verwalten von Metriken in Compartment DevComp durch Gruppe DevGroup zulassen
    • Zulassen, dass die Gruppe DevGroup Arbeitsanforderungen in Compartment DevComp INSPECT

Beim Befolgen dieser Anweisungen für die Policy ProdCompPolicy führt der Sicherheitsadministrator folgende Schritte aus:

  1. Setzt das Compartment im Seitenmenü auf ProdComp, bevor er auf Policy erstellen klickt.

  2. Fügt die folgenden Policy-Anweisungen hinzu:

    • Zulassen, dass die Gruppe ProdGroup autonome Containerdatenbanken im Compartment ProdComp verwaltet
    • Gruppe ProdGroup das Verwalten autonomer Datenbanken im Compartment ProdComp erlauben
    • Verwalten von autonomen Backups in Compartment ProdComp durch Gruppe ProdGroup zulassen
    • Zulassen, dass die Gruppe ProdGroup die Instanzfamilie im Compartment ProdComp verwaltet
    • Zulassen, dass die Gruppe ProdGroup Tag-Namespaces im Compartment ProdComp verwendet
    • Verwalten von Metriken in Compartment ProdComp durch Gruppe ProdGroup zulassen
    • Zulassen, dass die Gruppe ProdGroup Arbeitsanforderungen in Compartment ProdComp INSPECT

Schritt 4: VCN und Subnetze erstellen

Gilt nur für: Oracle Public Cloud (Anwendbar)

In diesem Schritt erstellt Acme I.T. oder der Netzwerkadministrator von Acme das VCN AcmeHRVCN und die Subnetze DevVMSubnet, ProdVMSubnet und AppSubnet im Compartment FleetComp.

Um diesen Schritt auszuführen, reserviert Acme I.T. zunächst bei der IT-Abteilung von Acme I.T. einen CIDR-IP-Adressenbereich, der nicht mit dem On-Premise-Netzwerk des Unternehmens in Konflikt steht. (Andernfalls würde das VCN mit dem On-Premise-Netzwerk in Konflikt stehen, sodass kein IPsec-VPN eingerichtet werden könnte.) Der reservierte Bereich ist CIDR 10.0.0.0/16.

Anschließend passt Acme I.T. die Anweisungen in Szenario B: Privates Subnetz mit einem VPN in der Oracle Cloud Infrastructure-Dokumentation an, um das VCN, die Subnetze und andere Netzwerkressourcen mit der Oracle Cloud-Konsole zu erstellen.

In diesem Beispiel werden die folgenden CIDR-Blöcke für die drei (3) Subnetze in AcmeHRVCN verwendet:
  • Zwei private Subnetze:
    • 10.0.10.0/24 für DevVMSubnet
    • 10.0.20.0/24 für ProdVMSubnet
  • Ein öffentliches Subnetz:
    • 10.0.100.0/24 für AppSubnet
Bei der Anpassung dieser Anweisungen erstellt Acme I.T. manuell Sicherheitslisten (anstelle der Standardsicherheitslisten), um Sicherheitsregeln zu isolieren und zu trennen und so die Netzwerkverwaltung zu vereinfachen. Dabei handelt es sich um folgende Sicherheitslisten:
  • DevSeclist: Die allgemeine Sicherheitsliste für DevVMSubnet. Wird verwendet, wenn das Subnetz DevVMSubnet erstellt wird.
  • ProdSeclist: Die allgemeine Sicherheitsliste für ProdVMSubnet. Wird verwendet, wenn das Subnetz ProdVMSubnet erstellt wird.
  • AppSeclist: Die allgemeine Sicherheitsliste für AppSubnet. Wird verwendet, wenn das Subnetz AppSubnet erstellt wird.

Weitere Informationen zu den AVMC-Ingress- und -Egress-Anforderungen finden Sie unter Anforderungen zum Provisioning eines autonomen Exadata-VM-Clusters.

Sicherheitsregeln in DevSeclist

Im Folgenden werden die Ingress-Regeln aufgeführt, die in DevSeclist erstellt wurden:

Zustandslos Quelle IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.10.0/24 ICMP Alle Alle Alle ICMP-Traffic für: alle
Nr. 10.0.10.0/24 TCP Alle Alle   TCP-Traffic für folgende Ports: alle
Nr. 10.0.100.0/24 TCP Alle 1521   TCP-Traffic für Port: 1521 Oracle Net
Nr. 10.0.100.0/24 TCP Alle 2484   TCPS-Traffic für Port: 2484 Oracle Net
Nr. 10.0.100.0/24 TCP Alle 6200   ONS/FAN für Ports: 6200
Nr. 10.0.100.0/24 TCP Alle 443   HTTPS-Datenverkehr für Port: 443

Die folgenden Egress-Regeln werden in DevSeclist erstellt:

Zustandslos Ziel IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.10.0/24 ICMP Alle Alle Alle Sämtlicher ICMP-Traffic innerhalb von DevVMSubnet
Nr. 10.0.10.0/24 TCP Alle Alle   Alle TCP-Traffic innerhalb von DevVMSubnet

Sicherheitsregeln in ProdSeclist

Hinweis:

Obwohl ProdSeclist über dieselben Sicherheitsregeln wie DevSeclist verfügt, hat der Netzwerkadministrator separate Sicherheitslisten erstellt, anstatt eine einzelne Sicherheitsliste für beide Projektteams zu erstellen, um alle zusätzlichen Sicherheitsregeln zu berücksichtigen, die von einem der Projektteams in Zukunft benötigt werden.

Im Folgenden werden die Ingress-Regeln aufgeführt, die in ProdSeclist erstellt wurden:

Zustandslos Quelle IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.20.0/24 ICMP Alle Alle Alle ICMP-Traffic für: alle
Nr. 10.0.20.0/24 TCP Alle Alle   TCP-Traffic für folgende Ports: alle
Nr. 10.0.100.0/24 TCP Alle 1521   TCP-Traffic für Port: 1521 Oracle Net
Nr. 10.0.100.0/24 TCP Alle 2484   TCPS-Traffic für Port: 2484 Oracle Net
Nr. 10.0.100.0/24 TCP Alle 6200   ONS/FAN für Ports: 6200
Nr. 10.0.100.0/24 TCP Alle 443   HTTPS-Datenverkehr für Port: 443

Die folgenden Egress-Regeln werden in ProdSeclist erstellt:

Zustandslos Ziel IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.20.0/24 ICMP Alle Alle Alle Sämtlicher ICMP-Traffic innerhalb von ProdVMSubnet
Nr. 10.0.20.0/24 TCP Alle Alle   Alle TCP-Traffic innerhalb von ProdVMSubnet

Sicherheitsregeln in AppSeclist

Die Ingress-Regel wird in AppSeclist erstellt:

Zustandslos Quelle IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 0.0.0.0/0 TCP Alle 22 Alle SSH-Traffic für Ports: 22

Hinweis:

Es wird empfohlen, 0.0.0.0/0 in den Sicherheitsregeln in die genehmigte Liste der CIDR-Bereichs-/IP-Adressen zu ändern.

Die folgenden Egress-Regeln werden in AppSeclist erstellt:

Zustandslos Ziel IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.10.0/24 TCP Alle 1521    
Nr. 10.0.10.0/24 TCP Alle 2484  
Nr. 10.0.10.0/24 TCP Alle 443    
Nr. 10.0.10.0/24 TCP Alle 6200    
Nr. 10.0.20.0/24 TCP Alle 1521    
Nr. 10.0.20.0/24 TCP Alle 2484    
Nr. 10.0.20.0/24 TCP Alle 443    
Nr. 10.0.20.0/24 TCP Alle 6200    

Schritt 5: Flottenadministrator zuweisen

In diesem Schritt fügt der Sicherheitsadministrator den Cloud-Benutzer eines angegebenen Mitglieds der IT-Abteilung von Acme I.T. zu FAGroup hinzu.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator die Anweisungen unter Benutzer verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole einer Gruppe einen Benutzer hinzuzufügen.

Schritt 6: Exadata-Infrastrukturressource erstellen

In diesem Schritt befolgt der Flottenadministrator die Anweisungen unter Exadata-Infrastrukturressource erstellen, um eine Exadata-Infrastrukturressource mit dem Namen AcmeInfrastructure im Compartment FleetComp zu erstellen.

Schritt 7: Autonome Exadata-VM-Clusterressourcen erstellen

In diesem Schritt befolgt der Flottenadministrator die Anweisungen unter Autonomes Exadata-VM-Cluster erstellen, um DevAVMC und ProdAVMC im Compartment FleetComp mit den folgenden Spezifikationen zu erstellen. Dabei behalten alle anderen Attribute ihre Standardeinstellungen bei.

Einstellung Entwicklungsumgebung Produktionsumgebung
AVMC-Name DevAVMC ProdAVMC
Zugrunde liegende Exadata-Infrastruktur AcmeInfrastructure AcmeInfrastructure
Virtuelles Cloud-Netzwerk (VCN)

Gilt nur für: Oracle Public Cloud (Anwendbar)

 AcmeHRVCN AcmeHRVCN
Subnetz

Gilt nur für: Oracle Public Cloud (Anwendbar)

 DevVMSubnet ProdVMSubnet

Schritt 8: Anwendungs-DBAs zuweisen

In diesem Schritt fügt der Sicherheitsadministrator bestimmte Cloud-Benutzer zu DevGroup hinzu und autorisiert sie so als Anwendungs-DBAs für die Entwicklungsressourcen. Anschließend wiederholt er den Prozess für ProdGroup.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator für jeden Benutzer die Anweisungen unter Benutzer verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole einer Gruppe einen Benutzer hinzuzufügen.

Schritt 9: Autonome Containerdatenbankressourcen erstellen

In diesem Schritt befolgen die jeweiligen Anwendungs-DBAs die Anweisungen unter Autonome Containerdatenbank erstellen, um die autonomen Containerdatenbanken (ACDs) für die Dev- und Prod-Umgebungen zu erstellen. Diese ACDs werden mit den folgenden Spezifikationen erstellt, sodass alle anderen Attribute in ihren Standardeinstellungen bleiben.

Einstellung Entwicklungsumgebung Produktionsumgebung
Compartment DevComp ProdComp
ACD-Name DevACD ProdACD
Zugrunde liegendes AVMC DevAVMC ProdAVMC
Softwareversion der Containerdatenbank Neueste Softwareversion (N) Sofortiger Vorgänger der Softwareversion (N-1)
Wartungsversion Neuestes RU (Releaseupdate) Nächstes RU (Release-Update)
Backupaufbewahrungszeitraum 7 Tage 30 Tage

Schritt 10. Autonomous Database-Ressourcen erstellen

In diesem Schritt befolgen die jeweiligen Anwendungs-DBAs die Anweisungen unter Autonomous Database erstellen, um die Autonomous Database-Instanzen für die Dev- und Prod-Umgebungen zu erstellen. Diese Datenbanken werden mit den folgenden Spezifikationen erstellt, wobei alle anderen Attribute ihre Standardeinstellungen beibehalten.

Einstellung Entwicklungsumgebung Produktionsumgebung
Compartment DevComp ProdComp
Datenbankname DevADB ProdADB
Zugrunde liegender ACD DevACD ProdACD
Datenbankinstanz Sie können eine Autonomous Database oder eine Autonomous Database für Entwickler erstellen Autonomous Database

Autonomous Database on Dedicated Exadata Infrastructure ist jetzt für die Entwicklung und den Test der Anwendung AcmeHR mit anschließendem Deployment in der Produktionsumgebung konfiguriert.