Zugriffskontrolle in Autonomous Database on Dedicated Exadata Infrastructure

Bei der Konfiguration von Autonomous Database on Dedicated Exadata Infrastructure müssen Sie sicherstellen, dass die Cloud-Benutzer nur die zum Ausführen ihrer Aufgaben erforderlichen Cloud-Ressourcen verwenden und erstellen können. Darüber hinaus müssen Sie sicherstellen, dass nur autorisierte Mitarbeiter und Anwendungen Zugriff auf die autonomen Datenbanken haben, die in einer dedizierten Infrastruktur erstellt wurden. Andernfalls besteht die Gefahr einer unkontrollierten Nutzung Ihrer dedizierten Infrastrukturressourcen oder unbefugter Zugriffe auf geschäftskritische Daten.

Bevor Sie mit dem Erstellen und Verwenden der Cloud-Ressourcen beginnen, die das dedizierte Infrastrukturfeature bereitstellen, müssen Sie einen Zugriffskontrollplan erstellen und durch Erstellen geeigneter IAM-(Identity and Access Management-) und Netzwerkressourcen umsetzen. Dementsprechend wird die Zugriffskontrolle innerhalb von einer Autonomous Database auf verschiedenen Ebenen implementiert:

• Oracle Cloud-Benutzerzugriffskontrolle
• Clientzugriffskontrolle
• Datenbankbenutzerzugriffskontrolle

Oracle Cloud-Benutzerzugriffskontrolle

Sie steuern, welchen Zugriff die Oracle Cloud-Benutzer in Ihrem Mandanten auf die Cloud-Ressourcen Ihres Autonomous Database on Dedicated Exadata Infrastructure-Deployments erhalten.

Mit dem Service Identity and Access Management (IAM) stellen Sie sicher, dass Cloud-Benutzer nur die Autonomous Database-Ressourcen erstellen und verwenden können, die zum Ausführen ihrer Aufgaben erforderlich sind. Um Zugriffskontrollen für Cloud-Benutzer einzurichten, definieren Sie Policys, die bestimmten Gruppen von Benutzern spezifische Zugriffsrechte für bestimmte Arten von Ressourcen in bestimmten Compartments erteilen.

Der IAM-Service bietet mehrere Arten von Komponenten, mit denen Sie eine sichere Strategie für den Cloud-Benutzerzugriff definieren und implementieren können:

• Compartment: eine Sammlung zugehöriger Ressourcen. Compartments sind eine wichtige Komponente von Oracle Cloud Infrastructure für die Organisation und Isolation der Cloud-Ressourcen.

• Gruppe: eine Sammlung von Benutzern, die alle den gleichen Zugriffstyp für ein bestimmtes Set von Ressourcen oder Compartment benötigen.

• Dynamische Gruppe: Ein spezieller Gruppentyp, der Ressourcen enthält, die von Ihnen definierten Regeln entsprechen. Daher kann sich die Mitgliedschaft dynamisch ändern, wenn übereinstimmende Ressourcen erstellt oder gelöscht werden.

• Policy: eine Gruppe von Anweisungen, die angeben, wer wie darauf zugreifen kann. Der Zugriff wird auf Gruppen- und Compartment-Ebene erteilt, d.h. Sie erstellen eine Policy-Anweisung, mit der eine bestimmte Gruppe einen bestimmten Zugriffstyp auf einen bestimmten Ressourcentyp innerhalb eines bestimmten Compartments erhält.

Policy- und Policy-Anweisungen

Das primäre Tool, mit dem Sie die Zugriffskontrolle für Cloud-Benutzer definieren, ist die Policy. Sie ist eine IAM-(Identity and Access Management-)Ressource, die Policy-Anweisungen enthält, die den Zugriff in Form von "Wer", "Wie", "Was" und "Wo" angeben.

Das Format einer Policy-Anweisung lautet:

Allow 
  group <group-name> 
  to <control-verb> 
  <resource-type> 
  in compartment <compartment-name>

• group <group-name> gibt den Namen einer vorhandenen IAM-Gruppe und eine IAM-Ressource an, der einzelne Cloud-Benutzer zugewiesen werden können.

• to <control-verb> gibt mit einem dieser vordefinierten Kontrollverben "Wie" an:

  • inspect: Die Funktion zum Auflisten von Ressourcen des angegebenen Typs ohne Zugriff auf vertrauliche Informationen oder benutzerdefinierte Metadaten, die Bestandteil dieser Ressource sein könnten.
  • read: inspect sowie die Möglichkeit, benutzerdefinierte Metadaten und die eigentliche Ressource abzurufen.
  • use: read sowie die Möglichkeit, mit vorhandenen Ressourcen zu arbeiten, diese jedoch nicht zu erstellen oder zu löschen. Darüber hinaus bezeichnet "Arbeiten mit" verschiedene Vorgänge für verschiedene Ressourcentypen.
  • manage: Alle Berechtigungen für den Ressourcentyp, einschließlich Erstellen und Löschen.

  Im Kontext einer dedizierten Infrastruktur kann ein Flottenadministrator autonome Containerdatenbanken mit manage verwalten, während ein Datenbankadministrator diese nur verwenden kann (use), um autonome Datenbanken zu erstellen.

• <resource-type> gibt den vordefinierten Ressourcentyp "Was" an. Ressourcentypwerte für die dedizierten Infrastrukturressourcen:

  • exadata-infrastructures
  • autonomous-container-databases
  • autonomous-databases
  • autonomous-backups

  Da dedizierte Infrastrukturressourcen Netzwerkressourcen verwenden, referenzieren einige der erstellten Policy-Anweisungen den Ressourcentypwert virtual-network-family. Außerdem können Sie Policy-Anweisungen erstellen, die den Ressourcentypwert tag-namespaces referenzieren, wenn Tagging in Ihrem Mandanten verwendet wird.

• in compartment <compartment-name> gibt den Namen eines vorhandenen IAM-Compartments an (einer IAM-Ressource, in der Ressourcen erstellt werden). Compartments stellen eine wichtige Komponente von Oracle Cloud Infrastructure dar, um Cloud-Ressourcen zu organisieren und zu isolieren.

Die Policy-Details für Autonomous Database finden Sie unter IAM-Policys für Autonomous Database on Dedicated Exadata Infrastructure.

Informationen zur Funktionsweise des IAM-Service und der zugehörigen Komponenten sowie zu deren Verwendung finden Sie unter Überblick über Oracle Cloud Infrastructure Identity and Access Management. Antworten auf häufig gestellte Fragen zu IAM finden Sie in den häufig gestellten Fragen zu Identity and Access Management.

Best Practices bei der Planung und Umsetzung von Zugriffskontrollen

Berücksichtigen Sie diese Best Practices bei der Planung und Umsetzung Ihrer Zugriffskontrollen für das dedizierte Infrastrukturfeature.

• Erstellen Sie ein separates VCN, das nur private Subnetze enthält. In fast jedem Fall enthalten die auf dedizierten Infrastrukturen erstellten autonomen Datenbanken sensible Unternehmensdaten, die normalerweise nur innerhalb des privaten Netzwerks des Unternehmens zugänglich sind. Selbst mit Partnern, Lieferanten, Verbrauchern und Kunden geteilte Daten werden über regulierte, sichere Kanäle zur Verfügung gestellt.

  Daher sollte der Netzwerkzugriff, den Sie solchen Datenbanken gewähren, für Ihr Unternehmen privat sein. Dazu können Sie ein VCN erstellen, das über private Subnetze und ein IPsec-VPN oder FastConnect eine Verbindung zum privaten Netzwerk Ihres Unternehmens herstellt. Informationen zum Einrichten einer solchen Konfiguration finden Sie unter Szenario B: Private Subnetze mit einem VPN in der Oracle Cloud Infrastructure-Dokumentation.

  Weitere Informationen zum Sichern der Netzwerkkonnektivität zu Ihren Datenbanken finden Sie unter Möglichkeiten zum Sichern Ihres Netzwerks in der Oracle Cloud Infrastructure-Dokumentation.

• Erstellen Sie mindestens zwei Subnetze. Sie müssen mindestens zwei Subnetze erstellen: eines für autonome Exadata-VM-Cluster- und autonome Containerdatenbankressourcen und eines für Ressourcen, die mit Clients und Anwendungen von Autonomous Database verknüpft sind.

• Erstellen Sie mindestens zwei Compartments. Sie müssen mindestens zwei Compartments erstellen: eines für Exadata-Infrastruktur-, autonome Exadata-VM-Cluster- und autonome Containerdatenbankressourcen und eines für Autonomous Database-Ressourcen.

• Erstellen Sie mindestens zwei Gruppen. Sie sollten mindestens zwei Gruppen erstellen: eine für Flottenadministratoren und eine für Datenbankadministratoren.

Clientzugriffskontrolle

Die Clientzugriffskontrolle wird in Autonomous Database implementiert, indem die Netzwerkzugriffskontrolle und Clientverbindungen gesteuert werden.

Netzwerkzugriffskontrolle

Sie definieren die Netzwerkzugriffskontrolle für autonome Datenbanken, wenn Sie das dedizierte Deployment von Oracle Autonomous Database einrichten und konfigurieren. Die Art und Weise hängt davon ab, ob sich das dedizierte Deployment in Oracle Public Cloud oder Exadata Cloud@Customer befindet:

• In Oracle Public Cloud definieren Sie die Netzwerkzugriffskontrolle mit Komponenten des Networking-Service. Sie erstellen ein virtuelles Cloud-Netzwerk (VCN), das private Subnetze enthält, in denen auf die autonomen Datenbanken zugegriffen werden kann. Außerdem erstellen Sie Sicherheitsregeln, um einen bestimmten Traffictyp zu oder von den IP-Adressen in einem Subnetz zuzulassen.

  Ausführliche Informationen zum Erstellen dieser Ressourcen finden Sie unter Lab 1: Bereiten Sie das private Netzwerk für die OCI-Implementierung vor in Oracle Autonomous Database Dedicated for Fleet Administrators.

• In Exadata Cloud@Customer, definieren Sie Netzwerkzugriffskontrollen, indem Sie ein Clientnetzwerk in Ihrem Data Center angeben und in einer VM-Clusternetzwerkressource innerhalb der Exadata-Infrastrukturressource aufzeichnen.

Zero Trust Packet Routing (ZPR)

Gilt nur für: Oracle Public Cloud ()

Oracle Cloud Infrastructure Zero Trust Packet Routing (ZPR) schützt sensible Daten vor unbefugtem Zugriff durch absichtsbasierte Sicherheits-Policys, die Sie für Ressourcen schreiben, wie ein autonomes Exadata-VM-Cluster (AVMC), dem Sie Sicherheitsattribute zuweisen.

Sicherheitsattribute sind Labels, mit denen ZPR Ressourcen identifiziert und organisiert. ZPR erzwingt Richtlinien auf Netzwerkebene bei jeder Anforderung des Zugriffs, unabhängig von potenziellen Änderungen oder Fehlkonfigurationen der Netzwerkarchitektur. ZPR basiert auf den vorhandenen Regeln für Netzwerksicherheitsgruppen (NSG) und Security Control List (SCL). Damit ein Paket ein Ziel erreicht, muss es alle NSG- und SCL-Regeln und die ZPR-Richtlinie bestehen. Die Anforderung wird gelöscht, wenn eine NSG-, SCL- oder ZPR-Regel oder -Policy keinen Traffic zulässt.

Sie können Netzwerke mit ZPR in drei Schritten sichern:

1. Erstellen Sie ZPR-Artefakte, nämlich Sicherheitsattribut-Namespaces und Sicherheitsattribute.

2. ZPR-Policys schreiben, um Ressourcen mit Sicherheitsattributen zu verbinden. ZPR verwendet eine ZPR Policy Language (ZPL) und erzwingt Einschränkungen beim Zugriff auf definierte Ressourcen. Als Autonomous Database on Dedicated Exadata Infrastructure-Kunde können Sie ZPL-basierte Policys in Ihren Mandanten schreiben, um sicherzustellen, dass nur autorisierte Benutzer und Ressourcen auf Daten von AVMCs zugreifen.

3. Weisen Sie Ressourcen Sicherheitsattribute zu, um die ZPR-Policys zu aktivieren.

Hinweis:

Geben Sie keine vertraulichen Informationen ein, wenn Sie Cloud-Ressourcen Beschreibungen, Tags, Sicherheitsattribute oder benutzerfreundliche Namen über die Oracle Cloud Infrastructure-Konsole, -API oder -CLI zuweisen.

Weitere Informationen finden Sie unter Erste Schritte mit Zero Trust Packet Routing.

Sie haben die folgenden Optionen, um ZPR-Sicherheitsattribute auf ein AVMC anzuwenden:

• Wenden Sie Sicherheitsattribute an, wenn Sie ein AVMC bereitstellen. Weitere Informationen finden Sie unter Autonomous Exadata-VM-Cluster erstellen.

• Sicherheitsattribute auf eine vorhandene AVMC-Ressource anwenden. Weitere Informationen finden Sie unter Configure Zero Trust Packet Routing (ZPR) for an AVMC.

Als Voraussetzung müssen die folgenden IAM-Policys definiert werden, um einem AVMC erfolgreich ZPR-Sicherheitsattribute hinzuzufügen:

allow group <group_name>
to { ZPR_TAG_NAMESPACE_USE, SECURITY_ATTRIBUTE_NAMESPACE_USE }
in tenancy

allow group <group_name>
to manage autonomous-database-family
in tenancy

allow group <group_name>
to read security-attribute-namespaces
in tenancy

ACLs (Access Control-Listen)

Für zusätzliche Sicherheit können Sie Access Control-Listen (ACLs) in dedizierten Deployments in Oracle Public Cloud und Exadata Cloud@Customer aktivieren. Eine ACL bietet zusätzlichen Schutz für Ihre Datenbank, da nur Clients mit bestimmten IP-Adressen eine Verbindung zur Datenbank herstellen können. Sie können IP-Adressen einzeln oder in CIDR-Blöcken hinzufügen. Sowohl IPv4- als auch IPv6-basierte IPs/CIDRs werden unterstützt. Auf diese Weise können Sie eine fein granulierte Zugriffskontroll-Policy formulieren, indem Sie den Netzwerkzugriff Ihrer Autonomous Database-Instanz auf bestimmte Anwendungen oder Clients beschränken.

Sie können eine ACL optional während des Provisionings der Datenbank oder danach erstellen. Sie können ACLs auch jederzeit bearbeiten. Wenn Sie eine ACL mit einer leeren Liste von IP-Adressen aktivieren, kann nicht auf die Datenbank zugegriffen werden. Weitere Einzelheiten finden Sie unter Access-Control-Liste für dedizierte autonome Datenbanken festlegen.

Beachten Sie folgende Hinweise zur Verwendung einer ACL mit Autonomous Database:

• Die Autonomous Database-Servicekonsole unterliegt nicht den ACL-Regeln.
• Oracle Application Express (APEX), RESTful-Services, SQL Developer Web und Performance Hub unterliegen keinen ACLs.
• Wenn beim Erstellen einer Autonomous Database-Instanz das Festlegen einer ACL nicht erfolgreich verläuft, verläuft das Provisioning der Datenbank ebenfalls nicht erfolgreich.
• Eine ACL kann nur aktualisiert werden, wenn sich die Datenbank im Status Verfügbar befindet.
• Durch das Wiederherstellen einer Datenbank werden die vorhandenen ACLs nicht überschrieben.
• Beim Klonen einer Datenbank (vollständig und Metadaten) werden die Zugriffskontrolleinstellungen der Quelldatenbank übernommen. Sie können nach Bedarf Änderungen vornehmen.
• Backup unterliegt keinen ACL-Regeln.
• Während eines ACL-Updates sind alle Vorgänge der autonomen Containerdatenbank (CDB) zulässig, Autonomous Database-Vorgänge sind jedoch nicht zulässig.

Web Application Firewall (WAF)

Für erweiterte Netzwerkkontrollen über Access-Control-Listen hinaus unterstützt Oracle Autonomous Database die Verwendung von Web Application Firewall (WAF). WAF schützt Anwendungen vor schädlichem und unerwünschtem Internettraffic. WAF kann alle internetseitigen Endpunkt schützen und bietet eine konsistente Regeldurchsetzung über alle Anwendungen eines Kunden hinweg. Mit WAF können Sie Regeln für Internetbedrohungen wie Cross-Site Scripting (XSS), SQL-Injection und andere OWASP-definierte Schwachstellen erstellen und verwalten. Durch Zugriffsregeln kann der Zugriff basierend auf der Geografie oder der Signatur von Anforderungen begrenzt werden. Informationen zur Konfiguration von WAF finden Sie unter Erste Schritte mit Web Application Firewall-Policys.

Clientverbindungskontrolle

Oracle Autonomous Database implementiert die Clientverbindungssteuerung mit der zertifikatbasierten Standardauthentifizierung TLS 1.2 und TLS 1.3 zur Authentifizierung einer Clientverbindung. TLS 1.3 wird jedoch nur auf Oracle Database 23ai oder höher unterstützt.

Standardmäßig verwendet Autonomous Database selbstsignierte Zertifikate. Sie können Ihr CA-signiertes serverseitiges Zertifikat jedoch über die Oracle Cloud Infrastructure-(OCI-)Konsole installieren. Um Ihr eigenes Zertifikat zu verwenden, müssen Sie das Zertifikat zuerst mit dem Oracle Cloud Infrastructure (OCI) Certificate Service erstellen, wie unter Zertifikat erstellen gezeigt. Diese Zertifikate müssen signiert sein und im PEM-Format vorliegen, d.h. ihre Dateierweiterung muss nur .pem, .cer oder .crt sein. Weitere Details finden Sie unter Certificate Management in Dedicated Autonomous Database.

Datenbankbenutzer-Zugriffskontrolle

Oracle Autonomous Database konfiguriert die von Ihnen erstellten Datenbanken für die Verwendung des Standardfeatures zur Benutzerverwaltung von Oracle Database. Dabei wird ein administrativer Benutzeraccount (ADMIN) erstellt, mit dem Sie zusätzliche Benutzeraccounts erstellen und Zugriffskontrollen für Accounts bereitstellen können.

Die Standardbenutzerverwaltung bietet ein robustes Set an Features und Kontrollen, wie System- und Objektberechtigungen, Rollen, Benutzerprofile und Kennwort-Policys, mit denen Sie in den meisten Fällen eine sichere Zugriffsstrategie für Datenbankbenutzer definieren und implementieren können. Ausführliche Anweisungen finden Sie unter Datenbankbenutzer erstellen und verwalten.

Grundlegende Informationen zur Standardbenutzerverwaltung finden Sie unter Benutzerkonten in Oracle Database-Konzepte. Ausführliche Informationen und Anleitungen finden Sie unter Managing Security for Oracle Database Users im Oracle Database 19c Security Guide oder im Oracle Database 23ai Security Guide.

Wenn Ihre Zugriffsstrategie für Datenbankbenutzer mehr Kontrollen erfordert, als die Standardbenutzerverwaltung bereitstellt, können Sie die autonome Datenbank für die Verwendung der folgenden Tools konfigurieren, um strengere Anforderungen zu erfüllen.

Tool	Beschreibung
Database Vault	Oracle Database Vault ist vordefiniert und kann in Autonomous Databases verwendet werden. Mit den leistungsstarken Sicherheitskontrollen können Sie den Zugriff auf Anwendungsdaten durch privilegierte Datenbankbenutzer einschränken, das Risiko von internen und externen Bedrohungen reduzieren und allgemeine Complianceanforderungen erfüllen. Weitere Informationen finden Sie unter Datenschutz unter Sicherheitsfeatures von Autonomous Database.
Oracle Cloud Infrastructure Identity and Access Management (IAM)	Sie können Autonomous Database so konfigurieren, dass Oracle Cloud Infrastructure Identity and Access Management-(IAM-)Authentifizierung und -Autorisierung verwendet wird, um IAM-Benutzern den Zugriff auf eine Autonomous Database mit IAM-Zugangsdaten zu ermöglichen. Informationen zur Verwendung dieser Option mit der Datenbank finden Sie unter Identity and Access Management-(IAM-)Authentifizierung mit Autonomous Database verwenden.
Zugriffstoken für Azure OAuth2	Sie können Oracle Autonomous Database-Benutzer mit Hilfe von Azure oAuth2-Zugriffstoken in einem Microsoft Azure Active Directory-(Azure AD-)Service zentral verwalten. Mit diesem Integrationstyp kann der Azure AD-Benutzer auf eine Oracle Autonomous Database-Instanz zugreifen. Azure AD-Benutzer und -Anwendungen können sich mit Azure AD-Single Sign-On-(SSO-)Zugangsdaten anmelden, um ein OAuth2-Zugriffstoken für Azure AD abzurufen, das an die Datenbank gesendet wird. Weitere Informationen zur Integration von Microsoft Azure Active Directory mit Ihren Datenbanken finden Sie unter Microsoft Azure Active Directory-Benutzer für Autonomous Database authentifizieren und autorisieren.
Microsoft Active Directory (CMU-AD)	Wenn Sie Microsoft Active Directory als Benutzer-Repository verwenden, können Sie Ihre Autonomous Databases für die Authentifizierung und Autorisierung von Microsoft Active Directory-Benutzern konfigurieren. Mit dieser Integration können Sie Ihr Benutzer-Repository konsolidieren und gleichzeitig eine strenge Zugriffsstrategie für Datenbankbenutzer implementieren, unabhängig davon, ob Sie die Standardbenutzermanagement, Database Vault, Real Application Security oder Virtual Private Database verwenden. Weitere Informationen zur Integration von Microsoft Active Directory mit Ihren Datenbanken finden Sie unter Microsoft Active Directory mit Autonomous Database verwenden.
Kerberos	Kerberos ist ein vertrauenswürdiges Drittanbieter-Authentifizierungssystem, das auf Shared Secrets basiert. Es wird davon ausgegangen, dass der Drittanbieter sicher ist. Das System bietet Single Sign-On-Funktionen, zentralisierten Kennwortspeicher, Datenbanklinkauthentifizierung und erweiterte PC-Sicherheit. Dies geschieht über einen Kerberos-Authentifizierungsserver. Die Autonomous Database-Unterstützung für Kerberos bietet die Vorteile von Single Sign-On und zentralisierter Authentifizierung von Oracle-Benutzern. Weitere Informationen finden Sie unter Autonomous Database-Benutzer mit Kerberos authentifizieren.
Kerberos mit CMU-AD	Die Kerberos-Authentifizierung kann zusätzlich zu CMU-AD konfiguriert werden, um Kerberos-CMU-AD-Authentifizierung für Microsoft Active Directory-Benutzer bereitzustellen. Um CMU-AD-Kerberos-Authentifizierung für Microsoft Active Directory-Benutzer bereitzustellen, können Sie die Kerberos-Authentifizierung zusätzlich zu CMU-AD aktivieren, indem Sie type auf CMU setzen und die externe Authentifizierung aktivieren, wie im Beispiel unter Kerberos-Authentifizierung in Autonomous Database aktivieren gezeigt.
Real Application Security und Virtual Private Database	Oracle Real Application Security (RAS) stellt ein deklaratives Modell bereit, das Sicherheits-Policys ermöglicht, die nicht nur die geschützten Geschäftsobjekte, sondern auch die Principals (Benutzer und Rollen) umfassen, die über Berechtigungen zum Arbeiten mit diesen Geschäftsobjekten verfügen. RAS ist sicherer, skalierbarer und kostengünstiger als der Vorgänger Oracle Virtual Private Database. Mit Oracle RAS werden Anwendungsbenutzer sowohl in der Application Tier als auch in der Datenbank authentifiziert. Unabhängig vom Datenzugriffspfad werden die Datensicherheits-Policys im Datenbank-Kernel basierend auf der nativen Endbenutzersession in der Datenbank durchgesetzt. Die dem Benutzer zugewiesenen Berechtigungen kontrollieren die Vorgangstypen (Auswählen, Einfügen, Aktualisieren und Löschen), die für Zeilen und Spalten der Datenbankobjekte ausgeführt werden können. Weitere Informationen zu Oracle RAS finden Sie unter Oracle Database Real Application Security - Einführung in der Oracle Database 19c Real Application Security - Administrator- und Entwicklerdokumentation oder in der Administrator- und Entwicklerdokumentation für Oracle Database 23ai Real Application Security. Oracle Autonomous Database unterstützt auch Oracle Virtual Private Database (VPD), den Vorgänger von Oracle RAS. Wenn Sie Oracle VPD bereits kennen und verwenden, können Sie es mit Ihren autonomen Datenbanken konfigurieren und verwenden. Weitere Informationen zu Virtual Private Database finden Sie unter Datenzugriff mit Oracle Virtual Private Database steuern in der Sicherheitsdokumentation für Oracle Database 19c oder in der Sicherheitsdokumentation für Oracle Database 23ai.

Privileged Access Management (PAM)

Die Sicherheitslage von Oracle in Bezug auf den Benutzerzugriff und das Berechtigungsmanagement für alle seine Produkte und Services ist in Oracle Access Control dokumentiert.

Autonomous Database on Dedicated Exadata Infrastructure wurde entwickelt, um Kundenservice- und Datenbankdaten vor unbefugtem Zugriff zu isolieren und zu schützen. Autonomous Database trennt Aufgaben zwischen dem Kunden und Oracle. Der Kunde kontrolliert den Zugriff auf Datenbankschemas. Oracle kontrolliert den Zugriff auf von Oracle verwaltete Infrastruktur- und Softwarekomponenten.

Autonomous Database on Dedicated Exadata Infrastructure wurde entwickelt, um Daten für die vom Kunden autorisierte Verwendung zu schützen und Daten vor unbefugtem Zugriff zu schützen, einschließlich der Verhinderung des Zugriffs auf Kundendaten durch Mitarbeiter von Oracle Cloud Ops. Zu den Sicherheitsmaßnahmen zum Schutz vor unbefugtem Zugriff auf die Exadata-Infrastruktur-, autonomen VMs- und Oracle-Datenbankdaten gehören:

• Oracle Database-Daten werden durch Oracle Transparent Data Encryption-(TDE-)Schlüssel geschützt.
• Der Kunde kontrolliert den Zugriff auf TDE-Verschlüsselungsschlüssel und kann diese Schlüssel in einem externen Oracle Key Vault-Schlüsselverwaltungssystem speichern.
• Oracle Database Vault ist vorkonfiguriert, um zu verhindern, dass berechtigte Benutzer auf Kundendaten in Autonomous Databases zugreifen können.
• Kunden können den Operatorzugriff über die Operator Access Control-Serviceanmeldung genehmigen.
• Der gesamte Operatorzugriff basiert auf der Hardware-Multifaktor-Authentifizierung gemäß FIPS 140-2 Level 3. Die Implementierung erfolgt auf einer Hardware YubiKey, die mit von Oracle genehmigten Geräten implementiert ist.
• Alle Operatoraktionen werden auf Befehlsebene protokolliert und können nahezu in Echtzeit an den OCI-Loggingservice oder an ein Kunden-SIEM gesendet werden.

• Oracle Operations Access Control stellt sicher, dass die Benutzeraccounts, die Oracle Cloud-Vorgänge und -Supportmitarbeiter zur Überwachung und Analyse der Performance verwenden, nicht auf Daten in Autonomous Databases zugreifen können. Oracle Cloud-Betriebs- und -Supportmitarbeiter haben keinen Zugriff auf die Daten in Ihren Autonomous Database-Instanzen. Wenn Sie eine autonome Containerdatenbank erstellen, aktiviert und konfiguriert Autonomous Database on Dedicated Exadata Infrastructure das Feature für die Vorgangskontrolle von Oracle Database Vault, damit gemeinsame Benutzer nicht auf Daten in Autonomous Databases zugreifen können, die in der Containerdatenbank erstellt wurden.

  Sie können bestätigen, dass Operations Control aktiv ist, indem Sie diese SQL-Anweisung in einer Autonomous Database eingeben:

  SELECT * FROM DBA_DV_STATUS;

  Der Status APPLICATION CONTROL gibt an, dass die Vorgangskontrolle aktiv ist.

  Hinweis:

  Operations Control wurde früher als Application Control bezeichnet.

PAM wird auch mit Database Vault zum Datenschutz implementiert, wie unter Sicherheitsfunktionen von Autonomous Database beschrieben.

---

Titel und Copyright-Informationen

Copyright ©2021,2025,

Oracle und/oder verbundene Unternehmen.