Exadata Cloud Infrastructure wird vom Kunden und von Oracle gemeinsam verwaltet und ist in zwei Zuständigkeitsbereiche unterteilt.

Kunden kontrollieren und überwachen den Zugriff auf Kundenservices, einschließlich des Netzwerkzugriffs auf ihre VMs (über virtuelle OCI-Cloud-Netzwerke und OCI-Sicherheitslisten), der Authentifizierung für den Zugriff auf die VMs und der Authentifizierung für den Zugriff auf Datenbanken, die auf den VMs ausgeführt werden. Oracle kontrolliert und überwacht den Zugriff auf von Oracle verwaltete Infrastrukturkomponenten und die physische Serversicherheit. Mitarbeiter von Oracle sind nicht berechtigt, auf Kundenservices zuzugreifen, einschließlich der VMs und Datenbanken von Kunden, es sei denn, Kunden können nicht auf die Kunden-VM zugreifen.

Kunden greifen über Client- und Backup-VCNs auf Oracle-Datenbanken (DBs), die auf Exadata Cloud Infrastructure ausgeführt werden, mit Oracle-Standardverbindungsmethoden wie Oracle Net auf Port 1521 auf die Datenbanken zu, die auf der Kunden-VM ausgeführt werden. Der Zugriff von Kunden auf die VM, auf der die Oracle-Datenbanken ausgeführt werden, erfolgt über Oracle Linux-Standardmethoden wie tokenbasierte SSH auf Port 22.

Sicherheitsfunktionen, die von Exadata Cloud Infrastructure angeboten werden.

• Oracle Cloud - Physische Sicherheit

  Oracle Cloud-Data-Center orientieren sich an den ANSI/TIA-942-A Tier-3-Standards (99,982% Verfügbarkeit) oder Tier-4-Standards (99,995% Verfügbarkeit) des Uptime Institute und der Telecommunications Industry Association (TIA) und folgen einer N2-Redundanzmethode ("N" steht für Notwendigkeit) für den Betrieb kritischer Geräte. Data Center, in denen Oracle Cloud Infrastructure-Services gehostet werden, verwenden redundante Stromquellen und verfügen über Generatorbackups bei einem großräumigen Stromausfall. In Serverräumen werden Lufttemperatur und Luftfeuchtigkeit engmaschig überwacht, und es gibt Systeme zur Brandbekämpfung. Mitarbeiter in Data Centern werden zur Reaktion auf Vorfälle und zu Eskalationsprozeduren geschult, um auf eventuelle Sicherheits- und Verfügbarkeitsereignisse reagieren zu können. Weitere Informationen finden Sie unter: Oracle Cloud Infrastructure - Sicherheitsdokumentation. Weitere Informationen zur Oracle Cloud Infrastructure-Data-Center-Compliance finden Sie unter Oracle Cloud-Compliance. Siehe auch: Oracle Corporate Security Practices: Data Security: Physical and Environmental Controls.

• Oracle Data Center-Zugriffskontrollen

  Zur Bereitstellung sicherer Systeme umfassen Oracle-Zugriffsprotokolle für physische Data Center Folgendes:

  • Der physische Zugriff auf Einrichtungen zu Data Centern ist auf bestimmte Mitarbeiter, Auftragnehmer von Oracle und autorisierte Besucher beschränkt.
  • Mitarbeiter, Subunternehmer und autorisierte Besucher von Oracle erhalten Ausweise, die während des Aufenthalts an Oracle-Standorten getragen werden müssen.
  • Besucher müssen die Besucherregistrierung unterzeichnen, begleitet und/oder beobachtet werden, wenn sie sich an einem Standort von Oracle befinden, und/oder an die Bedingungen einer Vertraulichkeitsvereinbarung mit Oracle gebunden sein.
  • Die Sicherheit überwacht den Besitz von Schlüsseln/Zugriffskarten und überwacht die Möglichkeit, Einrichtungen aufzurufen. Mitarbeiter, die Oracle verlassen, müssen Schlüssel/Karten zurückgeben, die bei Kündigung deaktiviert werden.
  • Sicherheitsmitarbeiter autorisieren alle Reparaturen und Änderungen an physischen Sicherheitsbarrieren oder Eingangskontrollen an Servicestandorten.
  • Oracle verwendet je nach Risiko-/Schutzniveau der Einrichtung eine Mischung aus Sicherheitspersonal, das rund um die Uhr vor Ort ist, und Patrouillengängern. In allen Fällen sind Polizisten für Patrols, Alarmreaktion und Aufzeichnung von Sicherheitsvorfällen verantwortlich.
  • Oracle hat zentral verwaltete elektronische Zugriffskontrollsysteme mit integrierter Eindringlingsalarmfunktion implementiert. Die Zugriffslogs werden mindestens sechs Monate lang aufbewahrt. Darüber hinaus beträgt die Aufbewahrungsfrist für die CCTV-Überwachung und -Aufzeichnung je nach Funktion und Risikostufe der Einrichtung mindestens 30 bis 90 Tage.

  Weitere Informationen zu den Zugriffskontrollen für Oracle-Websites finden Sie unter: Oracle Corporate Security Practices: Oracle Access Control

• Hypervisor - Kundenisolation

  Der Hypervisor ist die Software, die virtuelle Geräte in einer Cloud-Umgebung verwaltet und für die Server- und Netzwerkvirtualisierung zuständig ist. In herkömmlichen Virtualisierungsumgebungen verwaltet der Hypervisor den Netzwerktraffic, sodass dieser zwischen VM-Instanzen und zwischen VM-Instanzen und physischen Hosts fließen kann. Dies erhöht die Komplexität und den Rechenaufwand im Hypervisor erheblich. Proof-of-Concept-Angriffe auf die Computersicherheit, wie z.B. VM-Escape-Angriffe, haben das erhebliche Risiko aufgezeigt, das mit diesem Modell einhergehen kann. Diese Angriffe nutzen die Hypervisor-Komplexität, indem sie es Angreifern ermöglichen, einen "Ausbruch" einer VM-Instanz durchzuführen, auf das zugrunde liegende Betriebssystem zuzugreifen und die Kontrolle über den Hypervisor zu erlangen. Der Angreifer kann dann, manchmal unerkannt, auf andere Hosts zugreifen. Oracle Cloud Infrastructure reduziert dieses Risiko durch die Entkopplung der Netzwerkvirtualisierung vom Hypervisor.

  Um potenzielle Angriffe abzuwehren, hat Oracle eine sicherheitsorientierte Architektur mit der isolierten Netzwerkvirtualisierung implementiert, die ein grundlegendes Element der Architektur der Oracle Cloud-Infrastruktur ist. Diese Architektur stoppt Malware mit einer benutzerdefinierten SmartNIC, um das Netzwerk zu isolieren und zu virtualisieren. Die isolierte Netzwerkvirtualisierung reduziert das Risiko durch eine Verkleinerung der Angriffsfläche. Selbst wenn ein böswilliger Akteur mit einem VM-Escape-Angriff auf einem einzelnen Host erfolgreich ist, ist die virtuelle Architektur so konzipiert, dass der Akteur nicht auf andere Hosts in der Cloud-Infrastruktur zugreifen kann. Der Angriff wird effektiv auf diesen einen Host beschränkt. Die sichere isolierte Netzwerkvirtualisierungsarchitektur wird in jedem Data Center in jeder Region implementiert. Jeder Oracle Cloud Infrastructure-Mandant erhält die Vorteile dieser Security-First-Architektur.

  Abbildung 6-1: Isolierte Netzwerkvirtualisierung reduziert das Risiko in Oracle Cloud der 2. Generation

  
  Beschreibung von "Abbildung 6-1 Isolated Network Virualization reduziert Risiken in Oracle Generation 2 Cloud"
• Oracle Multitenant-Sicherheit

  Im Einklang mit unserer Defense-in-Depth-Sicherheitsphilosophie verfügt Oracle Multitenant über eine umfassende Isolationsarchitektur.

  Sie verfügt über vier Hauptkategorien mit jeweils mehreren wichtigen Features.

  1. Zugriffskontrollmechanismus
  2. Verhinderung von nicht autorisierten Admin-Zugriffen
  3. Schutz vor direktem Zugriff auf Datendateien
  4. Ressourcenisolation
  d

  Abbildung 6-2: Umfassende Isolationsarchitektur von Oracle Multitenant

  
  Beschreibung von "Abbildung 6-2 Mehrmandanten-Umfassende Isolationsarchitektur"

• Defense-in-Depth Exadata Cloud Infrastructure bietet eine Reihe von Kontrollen, um die Vertraulichkeit, Integrität und Verfügbarkeit im gesamten Service sicherzustellen.

  Zunächst wird Exadata Cloud Infrastructure aus dem sicheren Betriebssystemimage erstellt, das von Exadata Database Machine bereitgestellt wird (https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/exadata-security-overview.html). Hierbei wird die Kernbetriebsumgebung gesichert, indem das Installationsimage nur auf die erforderlichen Softwarepackages beschränkt, unnötige Services deaktiviert und sichere Konfigurationsparameter im gesamten System implementiert werden.

  Neben allen Stärken der ausgereiften Plattform von Exadata Database Machine, die durch das Provisioning von Systemen durch Exadata Cloud Infrastructure für Kunden gegeben sind, werden zusätzliche sichere Standardkonfigurationsoptionen in den Serviceinstanzen implementiert. Beispiel: Alle Datenbank-Tablespaces erfordern transparente Datenverschlüsselung (TDE), die Durchsetzung sicherer Kennwörter für anfängliche Datenbankbenutzer und Superuser sowie erweiterte Audit- und Ereignisregeln.

  Exadata Cloud Infrastructure stellt auch ein vollständiges Deployment und einen vollständigen Service dar, weswegen es externen Branchenstandards wie PCI, HIPAA und ISO27001 unterliegt. Diese externen Auditanforderungen bedeuten, dass zusätzliche Mehrwert-Servicefeatures wie Antiviren-Scans, automatische Warnungen bei unerwarteten Systemänderungen und tägliche Scans auf Sicherheitslücken bei allen von Oracle verwalteten Infrastruktursystemen in der Flotte erforderlich sind.

• Least-Privilege-Prinzip

  Oracle Secure Coding Standards erfordern, dass Softwareprozesse auf der Mindestberechtigungsebene ausgeführt werden, um ihre Funktionalität zu implementieren.

  Jeder Prozess und jeder Daemon muss als normaler, nicht privilegierter Benutzer ausgeführt werden, es sei denn, es kann nachgewiesen werden, dass er eine höhere Berechtigungsstufe erfordert. Auf diese Weise können unvorhergesehene Probleme oder Sicherheitslücken auf den nicht privilegierten Benutzerbereich beschränkt und eine Gefährdung des gesamten Systems vermieden werden.

  Dieses Prinzip gilt auch für Mitglieder des Oracle Operations-Teams, die individuell benannte Accounts für den Zugriff auf Exadata Cloud Infrastructure zur Wartung oder Fehlerbehebung verwenden. Nur bei Bedarf verwenden sie den auditierten Zugriff auf höhere Berechtigungsstufen, um ein Problem zu lösen oder zu beheben. Die meisten Probleme werden durch automatisierte Prozesse gelöst. Daher wenden wir das Least-Privilege Prinzip auch an, indem wir Mitarbeitern keinen Zugriff auf ein System gestatten, es sei denn, eine automatisierte Lösung des Problems ist nicht möglich.

• Auditing und Rechenschaftspflicht

  Bei Bedarf ist der Zugriff auf das System zulässig, aber alle Zugriffe und Aktionen werden protokolliert und zum Zweck der Rechenschaftspflicht verfolgt.

  Exadata Cloud Infrastructure-Auditlogs werden von Oracle kontrolliert und zu Sicherheitsmonitoring- und Compliancezwecken verwendet. Oracle kann relevante Auditlogs gemäß Oracle Incident Response Practices und Oracle Data Processing Agreement an Kunden weitergeben.

  Auditfunktionen werden in allen Infrastrukturkomponenten bereitgestellt, um sicherzustellen, dass alle Aktionen erfasst werden. Kunden können Auditing auch für ihre Datenbank- und Gast-VM-Konfiguration konfigurieren und diese nach Wahl in andere Unternehmensauditsysteme integrieren.

• Automatisierung des Cloud-Betriebs

  Durch den Wegfall manueller Vorgänge für Provisioning, Patching, Wartung, Fehlerbehebung und Konfiguration von Systemen wird das Fehlerrisiko reduziert.

• Gehärtetes BS-Image

  • Minimale Packageinstallation:

    Nur die für den Betrieb eines effizienten Systems erforderlichen Packages werden installiert. Durch die Installation eines kleineren Packagesets wird die Angriffsfläche des Betriebssystems reduziert, und das System bleibt sicherer.

  • Sichere Konfiguration:

    Viele nicht standardmäßige Konfigurationsparameter werden während der Installation festgelegt, um den Sicherheitsstatus des Systems und seines Inhalts zu verbessern. Beispiel: SSH ist so konfiguriert, dass nur bestimmte Netzwerkschnittstellen überwacht werden, Sendmail ist so konfiguriert, dass nur Localhost-Verbindungen akzeptiert werden, und viele weitere ähnliche Einschränkungen werden während der Installation implementiert.

  • Nur erforderliche Services ausführen:

    Services, die zwar auf dem System installiert, jedoch für den normalen Betrieb nicht erforderlich sind, sind standardmäßig deaktiviert. Beispiel: Obwohl NFS ein Service ist, der häufig von Kunden für verschiedene Anwendungszwecke konfiguriert wird, ist er standardmäßig deaktiviert, da er für normale Datenbankvorgänge nicht erforderlich ist. Kunden können optional Services entsprechend ihren Anforderungen konfigurieren.

• Minimale Angriffsfläche

  Als Teil des gehärteten Images wird die Angriffsfläche reduziert, indem nur die Software installiert und ausgeführt wird, die für die Bereitstellung des Service erforderlich ist.

• Zusätzliche Sicherheitsfeatures aktiviert (Grub-Kennwörter, sicherer Start)

  • Mit den Exadata-Imagefunktionen verfügt ExaDB-D über die Funktionen, die in das Basisimage integriert sind, darunter Grub-Kennwörter, sicherer Start und viele andere.
  • Durch Anpassung können Kunden den Sicherheitsstatus mit zusätzlichen Konfigurationen weiter verbessern.
• Sichere Zugriffsmethoden
  • Der Zugriff auf Datenbankserver über SSH erfolgt über starke kryptografische Cipher. Schwache Cipher sind standardmäßig deaktiviert.
  • Zugriff auf Datenbanken über verschlüsselte Oracle Net-Verbindungen. Standardmäßig sind unsere Services über verschlüsselte Kanäle verfügbar, und ein Oracle Net-Client verwendet in der Standardkonfiguration verschlüsselte Sessions.
  • Zugriff auf Diagnosefunktionen über die Exadata MS-Webbenutzeroberfläche (HTTPS).
• Auditing und Logging
  • Standardmäßig ist das Auditing für administrative Vorgänge aktiviert, und die Auditdatensätze werden zur automatischen Prüfung und gegebenenfalls Benachrichtigung an interne OCI-Systeme weitergeleitet.

Mehrere Benutzeraccounts verwalten die Komponenten von Exadata Cloud Infrastructure regelmäßig. Diese Benutzer sind erforderlich und können nicht geändert werden.

Auf allen ExaDB-D-Rechnern verwendet und empfiehlt Oracle die tokenbasierte SSH-Anmeldung.

Es gibt drei Benutzerklassen:

• Standardbenutzer: Keine Anmeldeberechtigungen
  
• Standardbenutzer mit RESTRICTED SHELL-Zugriff
  Diese Benutzer werden verwendet, um eine definierte Aufgabe mit einer eingeschränkten Shellanmeldung auszuführen. Diese Benutzer dürfen nicht entfernt werden, weil die definierte Aufgabe andernfalls nicht erfolgreich ausgeführt werden kann.
• Standardbenutzer mit Anmeldeberechtigungen
  Diese privilegierten Benutzer werden zur Ausführung der meisten Aufgaben im System verwendet. Diese Benutzer dürfen niemals geändert oder gelöscht werden, da dies erhebliche Auswirkungen auf das laufende System hätte.

Zusätzlich zu allen Exadata-Features, die unter "Sicherheitsfunktionen von Oracle Exadata Database Machine" erläutert werden, gelten auch die folgenden Sicherheitseinstellungen für Exadata Cloud Infrastructure-Instanzen.

• Benutzerdefiniertes Datenbank-Deployment mit nicht standardmäßigen Parametern.
  Mit dem Befehl host_access_control werden Exadata-Sicherheitseinstellungen konfiguriert:

  • Implementierung von Richtlinien zu Kennwortablauf und -komplexität
  • Definieren von Accountsperr- und Sessiontimeout-Policys
  • Begrenzen des Remote-Root-Zugriffs.
  • Beschränken des Netzwerkzugriffs auf bestimmte Accounts.
  • Implementierung von Anmeldewarnungsbanner.
• account-disable: Deaktiviert einen Benutzeraccount, wenn bestimmte konfigurierte Bedingungen erfüllt sind.
• pam-auth: Verschiedene PAM-Einstellungen für Kennwortänderungen und Kennwortauthentifizierung.
• rootssh: Passt den Wert von PermitRootLogin in /etc/ssh/sshd_config an. So wird die Anmeldung des Benutzer root über SSH zugelassen oder verweigert.
  • Standardmäßig ist PermitRootLogin auf no gesetzt.
  • PermitRootLogin=without-password ist erforderlich, damit die Cloud-Automatisierung einige Lebenszyklusverwaltungsvorgänge ausführen kann. Wenn Sie die Root-Anmeldung deaktivieren, verläuft diese Servicefunktionalität nicht erfolgreich.
• session-limit: Legt den Parameter * hard maxlogins in /etc/security/limits.conf fest. Dies ist die maximale Anzahl der Anmeldungen für alle Benutzer. Dieser Grenzwert gilt nicht für Benutzer mit uid=0.

  Der Standardwert ist * hard maxlogins 10. Dies ist der empfohlene sichere Wert.

• ssh-macs: Gibt die verfügbaren Message Authentication Code-(MAC-)Algorithmen an.
  • Der MAC-Algorithmus wird in Protokollversion 2 zum Schutz der Datenintegrität verwendet.
  • Der Standardwert ist hmac-sha1, hmac-sha2-256, hmac-sha2-512 für Server und Client.
  • Sichere empfohlene Werte: hmac-sha2-256, hmac-sha2-512 für Server und Client.
• password-aging: Legt den aktuellen Kennwortgültigkeitszeitraum für interaktive Benutzeraccounts fest oder zeigt ihn an.
  • -M: Maximale Anzahl von Tagen, die ein Kennwort verwendet werden kann.
  • -m: Mindestanzahl Tage zwischen Kennwortänderungen.
  • -W: Warnfrist vor Kennwortablauf in Tagen.
  • Standardwerte: -M 99999, -m 0, -W 7
  • --strict_compliance_only-M 60, -m 1, -W 7
  • Sichere empfohlene Werte: -M 60, -m 1, -W 7

Eine Liste der Prozesse, die standardmäßig auf der Kunden-VM ausgeführt werden (auch als DOMU oder Gast-VM und Gast-BS bezeichnet)

• Exadata Cloud Infrastructure-VM-Agent:

  Cloud-Agent für die Verarbeitung von Datenbanklebenszyklusvorgängen.

  • Wird als opc-Benutzer ausgeführt
  • Die Prozesstabelle zeigt die Ausführung als Java-Prozess mit jar-Namen - dbcs-agent-VersionNumber-SNAPSHOT.jar und dbcs-admin-VersionNumver-SNAPSHOT.jar.
• Oracle Trace File Analyzer-Agent:

  Oracle Trace File Analyzer (TFA) bietet eine Reihe von Diagnosetools in einem Bundle. So können Diagnosedaten zu Oracle-Datenbank und -Clusterware problemlos erfasst werden, was wiederum bei der Kontaktaufnahme mit Oracle Support zur Problemlösung hilfreich ist

  • Wird als Benutzer root ausgeführt
  • Wird als initd-Dämon ausgeführt (/etc/init.d/init.tfa)
  • Prozess-Tabellen zeigen eine Java-Anwendung (oracle.rat.tfa.TFAMain)
  • Wird als Benutzer root und exawatch ausgeführt.
  • Wird als Hintergrundskript ExaWatcher.sh ausgeführt, und alle untergeordneten Prozesse werden als Perl-Prozess ausgeführt.
  • Die Prozesstabelle zeigt mehrere Perl-Anwendungen. ExaWatcher:
• Datenbank und GI (Clusterware):
  • Wird als Benutzer dbmsvc und grid ausgeführt
  • Die Prozesstabelle zeigt folgende Anwendungen:
    • oraagent.bin, apx_* und ams_* werden als Benutzer grid verwendet
    • dbrsMain und Java-Anwendungen - derbyclient.jar, weblogic.Server als Benutzer oracle.
• Management Server (MS):

  Teil der Exadata-Imagesoftware für Verwaltung und Monitoring der Imagefunktionen.

  • Wird als dbmadmin ausgeführt.
  • Die Prozesstabelle zeigt die Ausführung als Java-Prozess.

• Netzwerksicherheit für Gast-VMs
  
• Complianceanforderungen
  

Standardmäßig aktivierte und verwendete Datenbanksicherheitsfeatures:

• Transparent Database Encryption (TDE) wird für Datenbank-Tablespaces verwendet, die von Oracle Database Cloud-Tools erstellt werden.
  • CDB$ROOT: Benutzer-Tablespace ist verschlüsselt
  • PDBs: Alle Tablespaces sind verschlüsselt
  • Wallet-Kennwort wird beim ersten Erstellen der DB angegeben. Wallet-Kennwörter können mit dbaascli geändert werden. Kunden müssen dieses Kennwort regelmäßig ändern.
• Benutzer in der Datenbank
  • In der Datenbank werden keine weiteren Benutzer erstellt.
  • Nach der DB-Erstellung werden alle DB-Benutzer mit Ausnahme von SYS, SYSTEM und DBSNMP gesperrt.
  • Das Auditing ist für die folgenden Vorgänge aktiviert:
    • DATABASE LINK
    • PUBLIC DATABASE LINK
    • PUBLIC SYNONYM
    • DROP ANY PROCEDURE
    • PROCEDURE
    • ALTER SYSTEM
    • TRIGGER
    • CREATE DATABASE LINK
    • ALTER DATABASE LINK
    • CREATE PROCEDURE
    • ALTER SYSTEM
    • CREATE TRIGGER
    • CREATE ANY TRIGGER
    • SELECT ANY DICTIONARY
    • DB VERSION_11_2: EXEMPT REDACTION POLICY
    • DB VERSION_12_1 oder DB VERSION_12_2: BECOME USER
    • DB VERSION_12_1: SESSION
    • Das Profil DBAASSECURE wird erstellt und als Standardprofil für den Datenbankbenutzeraccount festgelegt.

• Native SQL*Net-Verschlüsselung für alle Netzwerkverbindungen. Relevante sqlnet.ora-Parameter, die standardmäßig in Exadata Cloud Infrastructure festgelegt sind:

  • SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)

  • SQLNET.ENCRYPTION_SERVER = requested

  • SQLNET.CRYPTO_CHECKSUM_SERVER = accepted

  • SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

• Für die Netzwerkverbindung zur Datenbank auf Port 2484 angebotenes TCPS-Protokoll (Wallet konfiguriert unter /var/opt/oracle/dbaas_acfs/grid/tcps_wallets). Relevante sqlnet.ora-Parameter, die standardmäßig in Exadata Cloud Infrastructure festgelegt sind:

  • SSL_CIPHER_SUITES = (SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
    SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

  • WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))

  • SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS = TRUE

  • SSL_VERSION = 1.2

• Remote-Listener-Registrierung: Listener werden aus dem GI-Home ausgeführt. Exadata Cloud Infrastructure stellt die in Oracle Support-Dokument 2333222.1 (Exadata Cloud Service Software Versions) angegebene Grid Infrastructure-Version bereit. Die Standardkonfiguration von Exadata Cloud Infrastructure umfasst den listener.ora-Parameter VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET in Kombination mit REMOTE_REGISTRATION_ADDRESS_<SCANLISTENER>=<value>, um Remote-Listener-Registrierungen aus Sicherheitsgründen einzuschränken.
• OCI Vault-Integration: TDE-Verschlüsselungsschlüssel kann in OCI Vault (einem Schlüsselverwaltungssystem) gespeichert werden. Weitere Informationen und Anweisungen zum Konfigurieren von Principals, Vaults usw. finden Sie unter Vom Kunden verwaltete Schlüssel in Exadata Cloud Infrastructure. Für die OCI Vault-Integration von Exadata Cloud Infrastructure werden sowohl private als auch gemeinsam verwendete Vault-Typen unterstützt. DB-Benutzerauthentifizierung ist nicht in OCI Vault integriert.

BS-/VM-Backups:

Oracle erstellt wöchentlich ein vollständiges Backup der Gast-VM und verwaltet eine oder mehrere Backupkopien. Diese Backups sind vollständige Datenträger-Snapshots der Gast-VM (lokale BS-Dateisysteme, keine ASM-Datenträgergruppen, die sich im Exadata-Speicher befinden). Dieses Backup wird wöchentlich zu einer voreingestellten Zeit ausgelöst. Die Backups werden lokal in dom0 gespeichert. Kunden können Oracle auffordern, das Gast-VM-Image aus dem letzten Backup wiederherzustellen, indem sie eine My Oracle Support-(MOS-)Serviceanfrage einreichen. Oracle kann keine spezifischen Dateien aus dem Imagebackup wiederherstellen. Kunden sollten Backups auf Dateiebene in der Gast-VM erstellen, wenn sie einzelne Dateien wiederherstellen möchten.

Verwaltete DB-Backups:

• Wöchentliches vollständiges Backup (Ebene 0)
• Tägliches inkrementelles Backup (Ebene 1) im Rolling-Modus im Sieben-Tage-Zyklus
• Automatische Backups täglich zu einem bestimmten Zeitpunkt, der beim Erstellen der Datenbank festgelegt wurde

Der Aufbewahrungszeitraum für Backups variiert zwischen 30 Tagen (im Objektspeicher) und 7 Tagen (im lokalen Speicher)

Verschlüsselung:

• Object Storage und lokaler Speicher: Alle Backups im Cloud-Speicher werden verschlüsselt.
• Nur Object Storage: Alle Backups im Cloud-Speicher werden verschlüsselt.

Alle Backups können über die CP-UI oder die CP-API konfiguriert werden.

Alle Backups werden mit demselben Masterschlüssel verschlüsselt, der für die Verschlüsselung des TDE-(Transparent Data Encryption-)Wallets verwendet wird.

Der Zugriff auf Gast-VMs ist nur für automatisierte Tools im Rahmen der Lebenszyklusautomatisierung zulässig.

Ein spezieller Anwendungsfall liegt vor, wenn die Gast-VM nicht gebootet werden kann. In diesem Fall müssen Kunden die Berechtigung für den Zugriff auf die Gast-VM zu Recovery-Zwecken erteilen. Einzelheiten zum Umgang mit diesem Szenario werden im Abschnitt "Ausnahmeworkflows" von Exadata Cloud Service-Sicherheitskontrollen beschrieben.

Kunden kontrollieren und überwachen den Zugriff auf Kundenservices, einschließlich des Netzwerkzugriffs auf ihre Gast-VMs (über auf den Gast-VMs implementierte Layer-2-VLANs und Firewalls), der Authentifizierung für den Zugriff auf die Gast-VMs und der Authentifizierung für den Zugriff auf Datenbanken, die auf den Gast-VMs ausgeführt werden. Oracle kontrolliert und überwacht den Zugriff auf von Oracle verwaltete Infrastrukturkomponenten. Mitarbeiter von Oracle sind nicht berechtigt, auf Kundenservices zuzugreifen, einschließlich der Gast-VMs und Datenbanken.

PII (Personally Identifiable Information, personenbezogene Daten): Diese Daten werden als vertraulich und sensibel eingestuft und müssen geschützt werden, um eine nicht autorisierte Verwendung personenbezogener Daten aus Gründen der Einhaltung gesetzlicher Vorschriften und finanzieller Verpflichtungen sowie zur Wahrung der persönlichen Reputation zu verhindern.

Sie müssen ein Set von expliziten Regeln konfigurieren, um die Anzeige personenbezogener Daten zu verhindern.

Die Application Performance Monitoring-Standardregeln verbergen personenbezogene Daten in URLs, indem monetäre Werte, Bankkontonummern und Datumsangaben erkannt werden. Die Standardregeln erfassen jedoch nur offenkundige personenbezogene Daten und sind nicht vollständig. Sie müssen die Standardregeln auswerten und weitere Regeln konfigurieren, um ein korrektes Reporting in Ihrer Umgebung zu gewährleisten und sicherzustellen, dass in Ihren Daten keine personenbezogenen Daten angezeigt werden.

Weitere Informationen finden Sie unter Persönliche Informationen ausblenden und Sicherheit und personenbezogene Daten

Backupaufbewahrung

Wenn Sie das Feature "Automatisches Backup" aktivieren, erstellt der Service tägliche inkrementelle Backups der Datenbank in Object Storage. Das erste erstellte Backup ist ein Backup der Ebene 0. Danach werden täglich bis zum nächsten Wochenende Backups der Ebene 1 erstellt. Jedes Wochenende wird der Zyklus beginnend mit einem neuen Backup der Ebene 0 wiederholt.

Wenn Sie automatische Backups aktivieren, können Sie einen der folgenden voreingestellten Aufbewahrungszeiträume auswählen: 7 Tage, 15 Tage, 30 Tage, 45 Tage oder 60 Tage. Das System löscht automatisch die inkrementellen Backups am Ende des ausgewählten Aufbewahrungszeitraums.

Weitere Informationen finden Sie unter Datenbankbackup und -Recovery in Oracle Exadata Database Service on Dedicated Infrastructure verwalten

Aufbewahrungszeitraum für Auditlogs

Der OCI Audit-Service stellt Datensätze von API-Vorgängen, die für unterstützte Services ausgeführt werden, als Liste von Logereignissen bereit. Die Datensätze des Audit-Service werden standardmäßig 365 Tage lang aufbewahrt.

Weitere Informationen finden Sie unter Aufbewahrungszeitraum für Auditlogs

Aufbewahrungszeitraum für Servicelogs

Oracle Cloud Infrastructure-Services wie API Gateway, Events, Functions, Load Balancing, Object Storage und VCN-Flowlogs geben Servicelogs aus. Jeder dieser unterstützten Services verfügt über eine Ressource namens Logs, mit der Sie das Logging für diesen Service aktivieren oder deaktivieren können. Standardmäßig beträgt der Logaufbewahrungszeitraum 1 Monat, kann aber auf bis zu 6 Monate festgelegt werden.

Mit Loggruppen können Sie den Zugriff auf vertrauliche Logs einschränken, die von Services mit der IAM-Policy generiert werden. Es sind keine komplexen Compartment-Hierarchien für die Sicherung Ihrer Logs erforderlich. Beispiel: Angenommen, Sie speichern Logs für den gesamten Mandanten in einer Standardloggruppe in einem einzelnen Compartment. Sie erteilen Logadministratoren wie üblich mit einer IAM-Policy Zugriff auf das Compartment. Angenommen, einige Projekte enthalten personenbezogene Daten (PII), und diese Logs können nur von einer ausgewählten Gruppe von Logadministratoren angezeigt werden. Mit Loggruppen können Sie Logs, die personenbezogene Daten enthalten, einer separaten Loggruppe hinzufügen. Anschließend können Sie mit einer IAM-Policy den Zugriff für alle bis auf einige wenige Logadministratoren einschränken.

Weitere Informationen finden Sie unter Servicelogs und Logs und Loggruppen verwalten.

In bestimmten Fällen können Probleme nur gelöst werden, wenn sich Oracle bei der Gast-VM des Kunden anmeldet.

Im Folgenden werden Situationen aufgeführt, in denen der Zugriff auf die Gast-VM des Kunden erforderlich ist, sowie empfohlene Verfahren für den Zugriff auf die Gast-VM:

1. Situationen, in denen die Startdatenbank noch nicht erstellt wurde und der Kunde noch keinen SSH-Zugriff auf seine Gast-VM hat. Beispiel: Eine vom Kunden geöffnete Serviceanfrage zur Fehlerbehebung, wenn der Kunde keine Startdatenbank erstellen kann. In diesem Fall hatte der Kunde noch nie Zugriff auf die Gast-VM, und es wurde noch keine Datenbank erstellt. Daher sind in der Gast-VM keine Kundendaten vorhanden.

   Gemäß der Sicherheits-Policy für den ExaDB-D-Service dürfen Oracle-Mitarbeiter ohne ausdrückliche Zustimmung des Kunden nicht auf die Gast-VM zugreifen. Um diese Policy einzuhalten, benötigt Oracle die Genehmigung des Kunden für den Zugriff auf die Gast-VM. Dazu wird die folgende Frage gestellt:

   "Damit Oracle das in dieser Serviceanfrage beschriebene Problem beheben kann, benötigen wir die ausdrückliche Genehmigung des Kunden, die uns zur Anmeldung bei der Gast-VM des Kunden berechtigt. Wenn Sie uns die ausdrückliche Genehmigung zum Zugriff auf die Gast-VM erteilen, bestätigen Sie, dass keine vertraulichen Daten in der Gast-VM des Kunden oder in zugehörigen Datenbanken gespeichert sind. Das Sicherheitsteam des Kunden autorisiert Oracle, auf die Gast-VM des Kunden zuzugreifen, um dieses Problem zu beheben. Erteilen Sie uns die ausdrückliche Genehmigung, auf die Gast-VM zuzugreifen?"

   Nach einer positiven Antwort des Kunden können sich die Mitarbeiter von Oracle Support bei der Gast-VM des Kunden anmelden, um das Problem zu beheben.

2. Situationen, in denen mehrere Datenbanken im Kundensystem vorhanden sind und der Kunde Zugriff auf die Gast-VM hat. Der Support muss sich jedoch bei der Gast-VM anmelden, um eines der aufgetretenen Probleme zu beheben

   Es ist ein Fehler aufgetreten (Knoten werden aufgrund von Änderungen an der Gast-VM nicht gestartet, z.B. nicht vorhandene Mounts in fstab, fsck muss ausgeführt werden, Änderung der Hugepage-/sysctl-Konfiguration oder lvm-Backup nicht erfolgreich abgeschlossen, fstab hat falsche Einträge für nicht vorhandene Mounts, der Kunde hat die sshd-Konfigurationen oder -Berechtigungen in der Datei /etc/ssh/sshd_config geändert usw.) oder einfach, weil der Kunde möchte, dass Oracle bei der Lösung des jeweiligen Problems hilft.

   Dieser Fall ist schwerwiegender als der erste, da möglicherweise sensible Daten im Dateisystem oder in der Datenbank der Gast-VM des Kunden vorhanden sind. In diesem Fall müssen unsere Supportmitarbeiter den Kunden auffordern, eine neue explizite Serviceanfrage mit dem folgenden Titel und Inhalt der Serviceanfrage zu eröffnen, um diese Berechtigung zu erhalten.

   Gemäß der Sicherheits-Policy für den ExaDB-D-Service dürfen Oracle-Mitarbeiter ohne ausdrückliche Zustimmung des Kunden nicht auf die Gast-VM zugreifen. Damit Oracle diese Policy einhalten kann, müssen wir Sie bitten, eine neue Serviceanfrage mit der genauen nachfolgenden Formulierung zu öffnen. Dadurch erteilen Sie Oracle eine ausdrückliche Genehmigung zum Zugriff auf die Gast-VM. Beachten Sie: Jede Änderung der unten angegebenen Formulierung kann die Lösung Ihrer Serviceanfrage verzögern.

   New SR Title: SR granting Oracle explicit permission to access DomU of ExaDB-C@C with AK serial number AK99999999

   New SR Content: We are opening this SR to grant explicit permission to Oracle to access our DomU in order for support to help resolve issue described in SR# 1-xxxxxxxx.

   We acknowledge that by providing this permission, we understand that Oracle will have access to ALL FILES in DomU and agree that there are no confidential

   files stored in any of the file systems in DomU. In addition, we also agree that customer security team has authorized Oracle to have access to customer DomU

   in order to resolve the issue described in the above SR.

   Nach einer positiven Antwort des Kunden in der obigen Serviceanfrage können sich die Mitarbeiter von Oracle Support bei der Gast-VM des Kunden anmelden, um das Problem zu beheben.

Eine Liste der Oracle Cloud Operations-und -Kundenzuständigkeiten für verschiedene Vorgänge nach Komponenten

• KMS-Integration (HSM-Schlüssel)
  Oracle Exadata Database Service on Dedicated Infrastructure ist in den OCI Vault-Service integriert, um Data-at-Rest-Daten für seine Datenbanken zu schützen. Benutzer haben jetzt die Möglichkeit, TDE-Masterschlüssel in OCI Vault zu erstellen und zu verwalten, die Ihre Exadata-Datenbanken schützen.
• Verwenden von nicht standardmäßigen Verschlüsselungsalgorithmen für die TDE-Tablespace-Verschlüsselung