Oracle Cloud Infrastructure-Dokumentation

Überblick über Oracle Operator Access Control

Hier erfahren Sie, wie Sie den Zugriff von Oracle-Servicemitarbeitern auf Ihre Infrastruktur über Oracle Operator Access Control kontrollieren, auditieren und widerrufen können.

Was ist Oracle Operator Access Control?

Mit Oracle Operator Access Control können Sie den Zugriff erteilen, auditieren und widerrufen, den Oracle auf Ihre Exadata-Infrastruktur, auf Infrastruktur, die eine Oracle Autonomous Database auf Exadata Cloud@Customer hostet, und auf autonome Exadata-VM-Cluster (virtuelle Clientmaschinen, die auf Oracle Autonomous Database auf Exadata Cloud@Customer bereitgestellt werden) hat. Außerdem können Sie nahezu in Echtzeit Auditberichte zu allen Aktionen eines Mitarbeiters abrufen.

Oracle Operator Access Control für Exadata Cloud@Customer

Oracle Exadata Cloud@Customer Service ist ein System, für das Sie und Oracle gemeinsam Verantwortung tragen:
  • Sie sind für Aktionen in Ihren virtuellen Maschinen und für die tägliche Verwaltung von Datenbanken und Anwendungen verantwortlich, die auf Ihren virtuellen Maschinen ausgeführt werden.
  • Oracle ist für die Infrastrukturkomponenten verantwortlich: Stromversorgung, Bare-Metal-Betriebssystem, Hypervisor, Exadata Storage Server und andere Aspekte der Infrastrukturumgebung.

Wenn Sie jedoch laut Gesetz die Verantwortung für Audit und Kontrolle aller Aspekte Ihrer Systemverwaltung haben, ist das Modell der gemeinsamen Verantwortung problematisch. Sie müssen den zuständigen Regulierungsbehörden nachweisen, dass Sie die vollständige Kontrolle über Ihre Systeme haben und dass Sie Ihre Systeme gemäß den geltenden Compliancevorschriften einsetzen.

Wie können Sie alle Aktionen, die von einem Operator oder einer Software auf Ihren Systemen für Infrastrukturkomponenten ausgeführt werden, kontrollieren und auditieren? Wie können Sie in Ihren Systemen auf einheitlichem Niveau Audits durchführen, die Zugriffskontrolle verwalten und die Auditunterlagen bereitstellen, die für interne oder externe regulatorische Audits Ihrer Systeme erforderlich sind? Zur Lösung dieses Problems stellt Oracle Operator Access Control bereit, damit uneingeschränkter Zugriff von Oracle-Operatoren auf Ihre Systeme verhindert werden kann.

Operator Access Control für Oracle Autonomous Database auf Exadata Cloud@Customer

Operator Access Control wurde erweitert, um Kontrollen für virtuelle Clientmaschinen bereitzustellen, die in Oracle Autonomous Database auf Exadata Cloud@Customer bereitgestellt werden. Ähnlich wie bei der Operatorzugriffskontrolle für die Exadata Cloud@Customer-Infrastruktur können Kunden jetzt Zugriffskontrollen für Oracle-Operatoren auf ihren autonomen VM-Clustern einrichten, die auf Exadata Cloud@Customer bereitgestellt sind.

Die Bereitstellung von Autonomous Database auf dedizierter Infrastruktur (sowohl in OCI als auch in Cloud@Customer) basiert auf dem Grundsatz, dass der Kunde der "Benutzer" und Oracle der "Manager" der Datenbank ist. Zu den Aufgaben des "Managers" gehören die typischen Datenbank-Admin- oder DBA-Aufgaben wie die folgenden:
  • Autonomous Database-Ressourcen bereitstellen
  • Datenbanken sichern
  • Datenbanken wiederherstellen
  • Patching und Upgrades ausführen
  • Skalieren
  • Servicezustand überwachen
  • Audits durchführen
  • Alerts und Benachrichtigungen

Der Kunde hat keinen Zugriff auf das Clientbetriebssystem, keinen sys/system-Zugriff auf seine Containerdatenbanken und keinen Zugriff auf Systemlogs. Der Kunde ist auf die Überwachung von Anwendungszustand, -performance und -sicherheit auf allen Ebenen beschränkt. Oracle-Operatoren dagegen besitzen als "Manager" vollständigen, uneingeschränkten Zugriff auf alle Komponenten einschließlich Root-Zugriff auf Hypervisor und Client-VMs.

Das Modell der geteilten Verantwortung für die autonome Datenbank stellt mehrere betriebliche Herausforderungen für regulierte Kunden dar, die unabhängig vom Anbieter- und Deployment-Modell (On Premise, gehostet oder Cloud) die Kontrolle über alle Daten und Infrastruktur behalten müssen. Regulierte Kunden durchlaufen ihre eigene Compliance-Prüfung und formulieren ihre eigenen Sicherheitsrichtlinien, die unter Umständen Jahre in Anspruch nehmen, um zu härten und in die Praxis umzusetzen.

Das gilt insbesondere für die Unternehmenskunden von Oracle, die streng reguliert sind und ihre besonders kritischen Systeme und sicherheitssensiblen Anwendungen auf Oracle ausführen. Zur Lösung dieses Problems stellt Oracle Operator Access Control bereit, damit uneingeschränkter Zugriff von Oracle-Operatoren auf Ihre Systeme verhindert werden kann.

Oracle Operator Access Control für Oracle Cloud Infrastructure

Oracle Operator Access Control ist ein Complianceauditsystem, mit dem Sie alle Aktionen, die ein Oracle-Operator in der Infrastruktur ausführt, streng verwalten und genau auditieren können.

Mit Oracle Operator Access Control können Sie:
  • Operatoren Zugriff auf Ihre Infrastruktur erteilen und damit auch die zulässige Zeit und Dauer des Zugriffs auf das System durch Oracle-Personal festlegen.
  • nahezu in Echtzeit einen Bericht über alle Aktionen, die ein Oracle-Operator auf Ihrem System ausführt, anzeigen und speichern.
  • den Zugriff einschränken und festlegen, welche Aktionen ein Oracle-Operator auf Ihrem System ausführen kann.
  • Zugriff widerrufen, einschließlich zuvor erteiltem Zugriff.

Operatorzugriffskontrolle für Compute Cloud@Customer

Die Compute Cloud@Customer-Infrastruktur basiert auf dem Grundsatz, dass der Kunde der "Benutzer" von VMs und Services ist, die er in der Infrastruktur erstellt und ausgeführt hat, und Oracle ist der "Manager" der Infrastruktur selbst. Unter "Management" verstehen wir typische Aufgaben wie Upgrades, Patches und Monitoring der Infrastrukturkomponenten.

Der Kunde hat keinen Zugriff auf virtuelle oder Bare-Metal-Infrastrukturinstanzen in Infrastrukturkomponenten oder Verwaltungssoftware, die auf diesen Instanzen ausgeführt wird. Oracle Ops dagegen hat als Manager vollständigen, nicht eingeschränkten Zugriff auf alle Komponenten einschließlich Root-Zugriff auf Hypervisor- und Control-Plane-Server.

Dieses Modell stellt eine Reihe betrieblicher Herausforderungen für regulierte Kunden dar, die unabhängig vom Anbieter- und Bereitstellungsmodell (On Premise, gehostet oder Cloud) die Kontrolle über alle Daten und Infrastruktur behalten müssen. Regulierte Kunden müssen ihre eigene Compliance-Prüfung durchlaufen und ihre eigenen Sicherheitsrichtlinien formulieren, die möglicherweise Jahre in Anspruch nehmen, um zu härten und in die Praxis umzusetzen. Das gilt insbesondere für die Unternehmenskunden von Oracle, die streng reguliert sind und ihre besonders kritischen Systeme und sicherheitssensiblen Anwendungen auf Oracle ausführen.

Operator Access Control wurde erweitert, um diese Kundencomplianceziele zu unterstützen und es ihnen zu ermöglichen, ihre geschäftskritischen Datenbanken in Oracle Cloud zu integrieren, sodass Kunden den Zugriff auf ihre dedizierten Systeme letztendlich kontrollieren können.

In Operator Access Control verwendete Begriffe

Hier erfahren Sie, welche Begriffe in Operator Access Control verwendet werden.

Operator: Ein Oracle-Mitarbeiter, der Mitglied eines Operatorgruppen- (Ops-Gruppen)-Mandanten in Oracle Cloud Infrastructure (OCI) ist. Beispiel: Ein Operator kann ein Oracle-Mitarbeiter in der Gruppe Exadata Cloud@Customer_ops oder der Gruppe ExaCS_ops sein. Der Ops-Gruppenmandant ist eine Gruppe von Mandanten in OCI, die zur Verwaltung von Vorgangskontrollen berechtigt sind. Die Ops-Gruppen und die Operatoren, die Mitglieder dieser Gruppen sind, verfügen über keine andere Standardberechtigung als die Möglichkeit, Zugriff auf die Infrastruktur anzufordern. Die Gruppen und die Mitgliedschaft in den Operatorgruppen werden von Oracle streng kontrolliert.

Benutzer: Ein OCI-Benutzer des Mandanten, auf dessen Exadata Cloud@Customer-System die Kontrollen platziert sind.

Exadata-Infrastrukturlayer: Mehrere physische oder Betriebssystemlayer des Exadata-Systems. Derzeit sind diese als Control-Plane-Server, Host, Gast-VM, Cell-Server, Switches und ILOM definiert.

Aktion: Eine benannte, vordefinierte Gruppe von Befehlen, Dateien oder Netzwerken, auf die auf einem bestimmten Layer zugegriffen werden kann. Aktionen werden von Oracle definiert.

Operatorkontrolle: Eine vom Kunden definierte Entity, die eine Gruppe von vorab genehmigten Aktionen und Aktionen enthält, die eine explizite Genehmigung aus der Genehmigungsgruppe erfordern, um den Zugriff zu ermöglichen. Die Genehmigergruppe ist eine IAM-Standardbenutzergruppe, in der die Benutzer aufgelistet sind, die über Berechtigungen zum Genehmigen oder Widerrufen des Zugriffs verfügen.

Operatorattribute: In bestimmten Fällen kann die Operatorkontrolle Kriterien für die Operatoren definieren, die auf die Infrastruktur zugreifen dürfen.

Zuweisung der Operatorkontrolle: Dies ist der Prozess, bei dem ein Exadata Cloud@Customer-System mit einer benannten Operatorkontrolle verknüpft wird. Es kann jeweils nur eine Operatorkontrolle auf einem Exadata Cloud@Customer-System durchgesetzt werden. Die Zuweisung kann befristet oder unbefristet gelten. Wenn einem Exadata Cloud@Customer-System keine Operatorkontrolle zugewiesen ist, wird das Exadata Cloud@Customer-System mit einer Standardoperatorkontrolle ausgeführt, die jeden Zugriff für Diagnose und Wartung zulässt.

Zugriffsanforderung: Die Zugriffsanforderung ist der Prozess, mit dem ein Operator die Berechtigung zum Zugriff auf eine identifizierte Exadata-Infrastruktur anfordert. Die Exadata-Infrastruktur wird durch ihre OCID identifiziert. Die Anforderung identifiziert die Aktion, die der Operator ausführen möchte.

Zugriffsanforderung genehmigen/ablehnen: Die Genehmigung oder Ablehnung der Zugriffsanforderung ist der Prozess, mit dem ein befugter Benutzer, der durch die in der Exadata-Infrastruktur bereitgestellte Operatorkontrolle bestimmt wird, den Zugriff erteilen oder verweigern kann.

Zugriffsanforderung widerrufen: Ein befugter Benutzer kann eine Zugriffsanforderung jederzeit widerrufen. Dadurch werden die Sessions des Operators, der mit der Exadata-Infrastruktur basierend auf dieser Zugriffsanforderung verbunden ist, sofort entfernt.

Zugriffsanforderung "In Überprüfung": Bestätigt eine eingereichte Oracle-Operatorzugriffsanforderung und informiert den Anforderer, dass die Zugriffsanforderung geprüft wird.

Welche Kontrolloptionen werden von Oracle Operator Access Control bereitgestellt?

Sie erstellen Policys, die angeben, welche Gruppen von Aktionen Operatoren in Ihrer Infrastruktur ausführen können.

Eine Aktion ermöglicht die Einschränkung der Vorgänge, die ein Oracle-Operator auf von Oracle verwalteter Infrastruktur ausführen kann. Diese Einschränkungen umfassen u.a. die Kontrolle über die Ausführung von Shellbefehlen des Betriebssystems und von Oracle-Skripten. Aktionen schränken auch die Fähigkeit von Oracle-Operatoren ein, Binärdateien, Shellskripte und Perl- oder Python-Skripte auszuführen, die über den von der Aktion definierten Funktionsumfang hinausgehen. Wenn Sie über eine Aktion Berechtigungen erteilen, wird jede Aktion protokolliert, die ein Oracle-Operator ausführt. Sie können die Logs als Teil Ihrer MAC-Policy zur Einschränkung von Zugriffsrechten prüfen.

Eine Policy ist eine Gruppe von Aktionen, die Sie zum Implementieren von Einschränkungen im Rahmen der Mandatory Access Control (MAC) angeben, damit Oracle-Operatoren Wartungsarbeiten an Ihren Systemen ausführen können. Zum Definieren Ihrer Policys finden Sie nachfolgend eine Liste spezifischer Zugriffskontrollen, die Sie über Aktionen durchsetzen können:

  1. Operatorkontrollen für die Verwaltung von Oracle-Operatoren konfigurieren:
    • Operatorkontrollen zum Einschränken von Zugriffsprofilen für einen bestimmten Ressourcentyp in Ihrem Mandanten. Beispiel: Sie können separate Policys für Ressourcen wie die virtuelle Maschine (VM), den Datenbankserver der Oracle-Infrastruktur, den Control-Plane-Server oder das InfiniBand-Netzwerk einrichten. Darüber hinaus können Sie Policys konfigurieren, um Zugriffskontrollen mit einer Gruppe von Ressourcen in Ihrem Mandanten zu verknüpfen.
    • Eine Administratorgruppe von Benutzern konfigurieren, die mit den einzelnen Operatorkontrollen verknüpft sind. Mitglieder dieser Gruppen können Zugriffsanforderungen für eine Ressource, für die Sie eine Operatorkontrolle bereitgestellt haben, genehmigen, ändern oder ablehnen.
    • Aktionen für den Zugriff auf Ressourcen konfigurieren, die Sie als vorab genehmigt definieren, ohne dass eine Gruppe von Benutzern mit Administratorrechten den Zugriff kontrollieren muss.
  2. Autorisierung von Anforderungen erforderlich machen, bevor Zugriff auf Ressourcen gewährt wird. Beispiel:
    • Wenn eine Gruppe von Aktionen als vorab genehmigt gekennzeichnet ist, werden alle Zugriffsanforderungen, die nur einen Teil dieser Aktionen angeben, automatisch genehmigt, und Oracle-Mitarbeiter können auf Infrastrukturkomponenten zugreifen.
    • Wenn eine Zugriffs-Policy nicht auf Vorab genehmigt gesetzt ist, wird Oracle-Mitarbeitern der Zugriff auf Compartments verweigert, bis Sie explizit den angeforderten Zugriff erteilen.
  3. Zuvor erteilten Zugriff auf Ihre Infrastruktur widerrufen:
    • Durch automatische Zeitlimits wird jeder Zugriff auf eine Ressource, den Sie erteilt haben, widerrufen. Wenn Sie eine Zugriffsanforderung genehmigen, erhält ein Oracle-Operator eine eindeutige Benutzer-ID für den Zugriff, den Sie für eine begrenzte Zeit erteilen. Wenn dieses Zeitlimit erreicht ist, wird der gesamte durch die genehmigte Zugriffsanforderung erteilte Oracle-Zugriff auf Ihr System widerrufen. Wenn mehr Zeit benötigt wird, kann ein Oracle-Operator eine Verlängerungsanforderung einreichen.
    • Den Zugriff, der für eine Ressource bereits erteilt wurde, manuell widerrufen, bevor der zuvor erteilte Zugriff abgelaufen ist.
  4. Alle Aktionen auditieren, die ein Mitarbeiter für Ihre Ressourcen ausführt:

    • Alle von dem Mitarbeiter ausgeführten Tastatureingaben und Befehle werden geprüft. Sie erhalten vollständigen Zugriff auf alle Linux-Auditlogs.

      Sie können einen Audit eines bestimmten Oracle-Mitarbeiters in Ihrem System anfordern.

      Hinweis

      Die Identität des Mitarbeiters ist für Sie als Oracle-Kunde nicht verfügbar. Das Oracle Operator Access Control-System verwaltet jedoch Servicedatensätze des Mitarbeiters, sodass Oracle diesen mit einer bestimmten Zugriffsanforderung korrelieren kann, die Sie für den Service in Ihrem Mandanten genehmigt haben. Wenn Sie böswilliges Handeln vermuten und einen Audit verlangen, kann Oracle anhand dieser Anforderung alle Schritte prüfen, die der Mitarbeiter, der die durch die Zugriffsanforderung erlaubten Aktionen ausgeführt hat, vorgenommen hat.

Durchsetzung von Aktionen in Operator Access Control

Hier erfahren Sie, wie Sie Kontrollen für die Vorgänge durchsetzen, die ein Oracle-Operator in Ihrer Umgebung ausführen kann.

Übergeordnetes Thema: Überblick über Oracle Operator Access Control

Was ist Aktionsdurchsetzung?

In Operator Access Control dienen Aktionen zur Einschränkung der Berechtigungen, die der Operator bei der Ausführung von Befehlen, beim Zugriff auf Ressourcen und beim Ändern des Systemstatus hat.

Eine Aktion definiert die Berechtigungen, die Ressource und den Systemänderungszugriff, die einem Oracle-Operator zur Ausführung bestimmter Aufgaben für bestimmte administrative Funktionen in einer Exadata-Infrastruktur in einer Umgebung zugewiesen werden, die mit Operator Access Control verwaltet wird. Bei den Befehlen, die eine Aktion zulässt, kann es sich um Oracle Linux-Befehle oder Cell-Server-Befehle handeln.

Bei den Ressourcen, auf die eine Aktion Zugriff gewährt, handelt es sich um Dateien und Netzwerk. Systemänderungen entsprechen einer Statusänderung im Betriebssystem oder einer Statusänderung in der Software, die auf diesen Systemen ausgeführt wird. Die Statusänderung erfolgt aufgrund von Neustarts oder Konfigurationsänderungen.

Die Aktionsdurchsetzung basiert auf genehmigten Zugriffsanforderungen, die eine zeitlich begrenzte Policy einrichten, welche beschreibt, welche Änderungen ein Oracle-Operator vornehmen kann. Diese werden durch eine Gruppe von Aktionen definiert, zu denen Operatoren berechtigt werden. Jede Zugriffsanforderung erstellt temporäre Benutzerzugangsdaten in der Exadata-Infrastruktur. Die Policy für den Zugriff, die Sie definieren, basiert auf den Aktionen, die Sie in der Zugriffsanforderung genehmigen, die mit dem erstellten temporären Benutzer verknüpft ist.

Die Aktionsdurchsetzung erfolgt in der Regel auf Betriebssystemebene. Eine Policy zur Durchsetzung von Aktionen wird für eine Instanz des Betriebssystems erstellt, z.B. auf allen Hosts, Cell-Servern und Control-Plane-Servern. Die im Rahmen einer Policy genehmigten Aktionen werden entfernt, nachdem die Zugriffsanforderung ungültig wird. Dies geschieht entweder, weil die Zugriffsanforderung geschlossen wurde oder weil die Administrationsaufgabe abgeschlossen bzw. widerrufen wurde oder abgelaufen ist.

Die Aktionsdurchsetzung kann auf unterschiedliche Infrastruktur, wie zum Beispiel ein Betriebssystem, oder auf andere Software wie cellcli angewendet werden.

Operator Access Control-Aktionen: Exadata-Infrastruktur

Aktionen definieren die Vorgänge, die ein Operator auf einer Exadata Cloud@Customer-Infrastruktur ausführen kann. Sie sind auf Host, Cell-Server und Control Plane-Server begrenzt.

Aktionen gelten für die Exadata Cloud@Customer-Infrastruktur als Ganzes. Aktionen steuern die Oracle-Operatoraktionen auf mehreren Layern von Exadata Cloud@Customer. Bei den in der aktuellen Version kontrollierten Layern handelt es sich um Cell-Server, Verwaltungsdomain (Host) und die Control Plane-Server. Die Aktionen werden nach den Anforderungen organisiert, was zur Anforderung von Aktionen und zu den kritischen Auswirkungen führt, die diese Aktionen potenziell generieren.

Die Aktionen setzen Oracle Linux-Berechtigungen auf dem Exadata Cloud@Customer-Zielsystem um. Die Berechtigungen werden in Dateisystemberechtigungen, Befehlsausführungsberechtigungen und su- oder sudo-Berechtigungen kategorisiert. Die Aktionen werden nach der Art der Änderung kategorisiert, die vom Operator im Exadata Cloud@Customer-System vorgenommen werden kann.

  • Aktion: Nur Control-Plane-Server (CPS)
    Nur Control-Plane-Server (CPS), der als INFRA_CPS_ONLY gekennzeichnet ist, dient ausschließlich zur Diagnose und Lösung von CPS-Problemen. Oracle-Mitarbeiter haben keinen Zugriff auf Komponenten über das CPS hinaus, einschließlich Zellservern und Hostbetriebssystem (Dom0).
  • Aktion: Systemdiagnose
    Die Systemdiagnose, als INFRA_DIAG angegeben, ist zur Diagnose von Problemen auf dem Exadata Cloud@Customer-Infrastrukturlayer bestimmt.
  • Aktion: Systemwartung mit Neustartberechtigungen
    Die Systemwartung mit Neustartberechtigungen, als INFRA_UPDATE_RESTART angegeben, ist für Operatorzugriffsszenarios bestimmt, die eine Änderung der Systemkonfiguration oder einen Neustart des Systems erfordern.
  • Aktion: Systemwartung mit Datenzugriff/VM-Kontrollberechtigungen
    Die Systemwartung mit Datenzugriff/VM-Kontrollberechtigungen, als INFRA_HYPERVISOR angegeben, ist für Diagnose- und Wartungsszenarios bestimmt, in denen VM-Management auf dem Host erforderlich ist.
  • Aktion: Vollständiger Systemzugriff
    Der vollständige Systemzugriff, als INFRA_FULL angegeben, ermöglicht den Zugriff auf die Root-Konten in den Infrastrukturkomponenten.

Übergeordnetes Thema: Durchsetzung von Aktionen in Operator Access Control

Aktion: Nur Control Plane Server (CPS)

Nur Control-Plane-Server (CPS), der als INFRA_CPS_ONLY gekennzeichnet ist, dient zur Diagnose und Lösung von CPS-Problemen. Oracle-Mitarbeiter haben keinen Zugriff auf Komponenten über das CPS hinaus, einschließlich Zellservern und Hostbetriebssystem (Dom0).

Tabelle 1-1: Mit INFRA_CPS_ONLY aktivierte Aktionen

Aktionsname

Nur Control Plane Server (CPS)
Aktions-ID

INFRA_CPS_ONLY
Operatorberechtigungen

Linux-Benutzerberechtigung: Nicht-Root

Can su zu root: Nein

chroot jail: Ja

Kann mit "selbst" wechseln zu: Keine

sudo user + Befehlsliste: Begrenzt auf die oben angegebene Liste

Cellserverberechtigungen: Nein

Hostbetriebssystem (Dom0): Nein

Netzwerkberechtigungen: Nein

Liste der ausführbaren Befehle:

Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.

  • Alias:
    • sudols
    • sudocp
    • sudocat
    • sudotail
    • sudohead
    • sudovi
    • sudorm
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Unterstützte Sonderbefehle:
    • rootexec /root/alarm_detail.sh
    • rootexec /root/alerthistory.sh
    • rootexec /root/blackout.sh
    • rootexec /root/quarantine_ack.sh
    • rootexec /root/stateless_ack.sh
    • rootexec /root/stateless_alert.sh
    • rootexec /etc/keepalived/manual-switchover.sh

Verzeichnisse und Dateien mit expliziter Lese- und Schreibberechtigung:

  • Lesen und Schreiben:
    • /u01/
    • /opt/oci/exacc/
  • Schreibgeschützt:
    • /var/log/
    • /opt/oracle.cellos/
    • /usr/local/nessus/results/
    • /opt/nessus/var/nessus/logs/

Spezielle Operator Access Control-Befehle:

Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben):

  • sudols
  • sudocp
  • sudocat
  • sudotail
  • sudohead
  • sudovi
  • sudorm
Aktion: Systemdiagnose

Die Systemdiagnose, als INFRA_DIAG angegeben, ist zur Diagnose von Problemen auf dem Exadata Cloud@Customer-Infrastrukturlayer bestimmt.

Die Diagnose besteht darin, Logs zu lesen, Diagnosen auszuführen und Befehle zu überwachen. Mit dieser Aktion werden auch Probleme mit Diagnose-Agents im Exadata Cloud@Customer-System behoben. Die Korrektur umfasst das Neustarten von Diagnose-Daemons mit möglicherweise geänderten Parametern.

Hinweis

Bei der Aktion "Systemdiagnose" treten keine Risiken für die Kundendaten auf, und die Verfügbarkeit wird nicht beeinträchtigt.
Dier Aktion "Systemdiagnose" ermöglicht Folgendes:
  • Verwendung von cat, grep usw. durch den Operator, um Logdateien von Betriebssystem, Infrastruktursoftware und Cloud-Orchestrierungssoftware zu lesen.
  • Der Operator zur Ausführung von Oracle Linux-Diagnosebefehlen durch Oracle Linux. Beispiel: top und netstat.
  • Auf Cell-Servern kann der Operator außerdem cellcli-Befehle ausführen, um Diagnoseinformationen abzurufen.
  • Der Operator kann auf die Verwaltung der Cloud-Orchestrierungsinfrastruktur auf dem Control-Plane-Server zugreifen und alle Daemons auf dem Control-Plane-Server neu starten.

Tabelle 1-2: Mit INFRA_DIAG aktivierte Aktionen

Aktionsname

Systemdiagnose
Aktions-ID

INFRA_DIAG
Operatorberechtigungen

Oracle Linux-Benutzerberechtigung: Nicht-Root.

Kann mit "su" zu "root" wechseln: Nein

chroot jail: Ja

Kann mit "su" wechseln zu:
  • Zelle: cellmonitor
  • Host: dbmmonitor
  • Control-Plane-Server:
    • ecra
    • exawatcher
    • dbmsvc
Als "root" ausführen:
  • cat
  • head
  • tail
  • cp für Dateien in /var/log/*
  • [CPS]: systemctl

Cell-Serverberechtigungen: Als Cell-Monitor fungieren.

Netzwerkberechtigungen: SSH-Verbindungen können auf alle Hosts, Cell-Server und Control-Plane-Server angewendet werden. Der Benutzername ist jeweils gleich.

Liste der ausführbaren Befehle:

  • Control-Plane-Server (Alias): Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Cell-Server (Alias): Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.
    • cellcli: Schreibgeschützte Befehle
    • sundiag.sh
    • sosreport
    • lspci
    • imageinfo
    • imagehistory
  • Host (Alias): Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.
    • dbmcli: Schreibgeschützte Befehle
    • sundiag.sh
    • sosreport
    • virsh: Nur Listenoptionen
    • xm: Nur Listenoptionen
    • docker
    • podman
    • imageinfo
    • imagehistory

Verzeichnisse und Dateien mit expliziter Lese- und Schreibberechtigung:

  • Control-Plane-Server:
    • Lesen und Schreiben: /u01/
    • Schreibgeschützt:
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Spezielle Operator Access Control-Befehle: Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben).
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Host:
    • Lesen und schreiben: Keine
    • Schreibgeschützt: /var/log/
    • Spezielle Operator Access Control-Befehle: Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben).
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    Die folgenden Verzeichnisse werden in einem Schreibzugriffsmodus zugeordnet, damit die Tools ausgeführt werden können. Oracle-Operatoren erhalten jedoch keinen direkten Zugriff darauf.
    • /var
    • /opt/oracle
  • Cell-Server:
    • Lesen und schreiben: Keine
    • Schreibgeschützt: /var/log/
    • Spezielle Operator Access Control-Befehle: Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben).
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    Die folgenden Verzeichnisse werden in einem Schreibzugriffsmodus zugeordnet, damit die Tools ausgeführt werden können. Oracle-Operatoren erhalten jedoch keinen direkten Zugriff darauf.

    • /var
    • /opt/oracle
Aktion: Systemwartung mit Neustartberechtigungen

Die Systemwartung mit Neustartberechtigungen, als INFRA_UPDATE_RESTART angegeben, ist für Operatorzugriffsszenarios bestimmt, die eine Änderung der Systemkonfiguration oder einen Neustart des Systems erfordern.

Die INFRA_UPDATE_RESTART-Szenarios dienen in der Regel zur Wartung. Es gibt jedoch Diagnoseszenarios, in denen diese Aktion ebenfalls erforderlich ist. Änderungen der Systemkonfiguration umfassen Änderungen der Netzwerkkonfiguration, der Hardwarekonfiguration, der Betriebssystemkonfiguration wie Mounts, Inodes, Ulimits oder Änderungen der Konfiguration der Cloud-Orchestrierungssoftware. Der Neustart des Systems berechtigt den Oracle-Operator, das Betriebssystem (Host, Cell-Server), bestimmte Subsysteme wie das Netzwerk sowie Cell-Datenträger neu zu starten.

Achtung:

Beachten Sie, dass die Aktion "Systemwartung mit Neustartberechtigungen" Neustarts von Infrastrukturkomponenten (Datenbankserver, Speicherserver und Control-Plane-Server) zulässt und den Zugriff auf Kunden-VMs, Kundendaten und den Infrastrukturauditservice verhindert.
Aktion "Systemwartung mit Neustartberechtigungen":
  • Erlaubt dem Oracle-Operator, Systemwartungsaktivitäten mit root-Berechtigungen auszuführen. Der Operator kann nicht zu root werden, kann jedoch Wartungsbefehle als root ausführen.
  • Erlaubt dem Operator nicht, die Auditparameter zu ändern oder auf die Auditlogs zuzugreifen. Mit dieser Aktion kann der Operator jedoch das gesamte Exadata Cloud@Customer-System offline setzen.
  • Ermöglicht es den Benutzern, die Konfiguration des Betriebssystems dauerhaft zu verändern. Beispiel: Der Oracle-Operator darf /etc/ parameters ändern.
  • Erlaubt dem Oracle-Operator, Daemon-Prozesse zu starten und die Cell Disks mit der Cell-Admin-Berechtigung cellcli auf Cell-Servern zu verwalten.
  • Erlaubt dem Oracle-Operator, auf die Cloud-Orchestrierungsinfrastruktur auf dem Control-Plane-Server zuzugreifen und sie zu verwalten und alle Daemons auf dem Control-Plane-Server neu zu starten.

Vererbung: Alle Berechtigungen der Systemdiagnose

Tabelle 1-3: Mit INFRA_UPDATE_RESTART aktivierte Aktionen

Aktionsname

Systemwartung mit Neustartberechtigungen
Aktions-ID

INFRA_UPDATE_RESTART
Operatorberechtigungen

Wie "Systemdiagnose" +:

Kann mit "su" zu "root" wechseln: Nein

chroot jail: Ja

Kann mit "su" wechseln zu:
  • exawatcher
  • dbmsvc
  • dbmadmin
  • dbmmonitor auf dem Host
Als "root" ausführen:
  • restart
  • ip
  • ifconfig
  • lspci

Cell-Serverberechtigungen: celladmin auf dem Cell-Server

Netzwerkberechtigungen: SSH-Verbindungen können auf alle Hosts, Cell-Server und Control-Plane-Server angewendet werden. Der Benutzername ist auf allen diesen Ebenen gleich.

Liste der ausführbaren Befehle:

  • Control-Plane-Server (Alias): Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Cell-Server (Alias): Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.
    • reboot
    • sundiag.sh
    • cellcli: Alle Befehle
    • lspci
    • imageinfo
    • imagehistory
    • ethtool
    • ipmitool
    • ipmitool_interactive (entspricht ipmitool, kann verwendet werden, wenn tty erforderlich ist)
  • Host (Alias): Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.
    • reboot
    • dbmcli: Alle Befehle
    • sundiag.sh
    • virsh: Nur Listenoptionen
    • xm: Nur Listenoptionen
    • docker
    • podman
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport

Verzeichnisse und Dateien mit expliziter Lese- und Schreibberechtigung:

  • Control-Plane-Server:
    • Lesen und Schreiben: /u01/
    • Schreibgeschützt:
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Spezielle Operator Access Control-Befehle: Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben).
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Host:
    • Lesen und schreiben: Keine
    • Schreibgeschützt: /var/log/
    • Spezielle Operator Access Control-Befehle: Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben).
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    Die folgenden Verzeichnisse werden in einem Schreibzugriffsmodus zugeordnet, damit die Tools ausgeführt werden können. Oracle-Operatoren erhalten jedoch keinen direkten Zugriff darauf.
    • /var
    • /opt/oracle
    • /home/dbmadmin
  • Cell-Server:
    • Lesen und schreiben: Keine
    • Schreibgeschützt: /var/log/
    • Spezielle Operator Access Control-Befehle: Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben).
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    Die folgenden Verzeichnisse werden in einem Schreibzugriffsmodus zugeordnet, damit die Tools ausgeführt werden können. Oracle-Operatoren erhalten jedoch keinen direkten Zugriff darauf.
    • /var
    • /opt/oracle
    • /home/celladmin/
Aktion: Systemwartung mit Datenzugriff/VM-Kontrollberechtigungen

Systemwartung mit Datenzugriff/VM-Kontrollberechtigungen, als INFRA_HYPERVISOR angegeben, ist für Diagnose- und Wartungsszenarios bestimmt, bei denen ein VM-Management auf dem Host erforderlich ist.

Die Aktion "System Maintenance with Data Access/VM Control Privileges" ist für Diagnose- und Wartungsszenarios bestimmt, bei denen ein VM-Management auf dem Host erforderlich ist. Alle Daten auf der Gast-VM werden als Kundendaten behandelt. Da das VM-Management die Möglichkeit umfasst, auf die VM-Daten zuzugreifen, stellt diese Aktion möglicherweise ein Datenrisiko dar. Diese Aktion gewährt jedoch keinen Zugriff auf die TDE-Schlüssel der Daten, die auf Cell-Servern gespeichert sind. Ein VM-Management ist in Fällen erforderlich, in denen Probleme mit der VM-Softwareinfrastruktur auftreten oder eine VM-Konfiguration geändert werden muss. Die Konfiguration umfasst den externen Aspekt der VMs, wie angehängte Netzwerke, angehängte Datenträger oder zugewiesene Ressourcen (CPU, Speicher).

Hinweis

Die Systemwartung mit Datenzugriffs-/VM-Kontrollberechtigungen verhindert den Zugriff auf das Infrastrukturauditsubsystem.
Aktion "Systemverwaltung mit Datenzugriff/VM-Kontrollberechtigungen":
  • Ermöglicht dem Operator die Ausführung von Xen/KVM-Verwaltungsbefehlen mit root-Berechtigungen. Der Operator kann nicht zu root werden. Diese Aktion gilt nur für den Host.
  • Erbt die Berechtigungen von der Aktion "Systemwartung mit Neustartberechtigungen".
  • Lässt keine Änderung der Betriebssystemparameter des Hosts oder der Cell-Server zu. Dadurch kann der Operator jedoch die Gast-VM herunterfahren und die Konfiguration der Gast-VM erheblich ändern.

Vererbung: Alle Berechtigungen der Systemwartung mit Neustart.

Tabelle 1-4: Mit INFRA_HYPERVISOR aktivierte Aktionen

Aktionsname

Systemwartung mit Datenzugriff/VM-Kontrollberechtigungen
Aktions-ID

INFRA_HYPERVISOR
Operatorberechtigungen

Wie "Systemwartung mit Neustart" +:

Oracle Linux-Benutzerberechtigung: Nicht-Root.

Kann mit "su" zu "root" wechseln: Nein

chroot jail: Ja

Kann mit "su" wechseln zu: celladmin auf dem Cell-Server

Als "root" ausführen:
  • /usr/sbin/xm
  • /usr/sbin/xentop
  • /usr/sbin/virsh

Cell-Serverberechtigungen: celladmin

Netzwerkberechtigungen: SSH-Verbindungen können auf alle Hosts, Cell-Server und Control-Plane-Server angewendet werden. Der Benutzername ist jeweils gleich.

Liste der ausführbaren Befehle:

  • Control-Plane-Server (Alias): Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Cell-Server (Alias): Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.
    • cellcli: Alle Befehle
    • lspci
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport
    • reboot
    • sundiag.sh
    • ipmitool
    • ipmitool_interactive (entspricht ipmitool, kann verwendet werden, wenn tty erforderlich ist)
  • Host (Alias): Diese Befehle können direkt über die Bash-Eingabeaufforderung ausgeführt werden.
    • dbmcli: Alle Befehle
    • sundiag.sh
    • virsh: Alle Optionen
    • xm: Alle Optionen
    • virsh_interactive: Alle Optionen (entspricht virsh, können verwendet werden, wenn tty erforderlich ist)
    • xm_interactive: Alle Optionen (entspricht xm, können verwendet werden, wenn tty erforderlich ist)
    • xentop: Alle Optionen
    • vm_maker: Alle Optionen
    • docker
    • docker_interactive (entspricht docker, kann verwendet werden, wenn tty erforderlich ist)
    • podman
    • podman_interactive (entspricht podman, kann verwendet werden, wenn tty erforderlich ist)
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport
    • ipmitool
    • ipmitool_interactive (entspricht ipmitool, kann verwendet werden, wenn tty erforderlich ist)
    • ops_console.sh

Verzeichnisse und Dateien mit expliziter Lese- und Schreibberechtigung:

  • Control-Plane-Server:
    • Lesen und Schreiben: /u01/
    • Schreibgeschützt:
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Spezielle Operator Access Control-Befehle: Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben).
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Host:
    • Lesen und schreiben: Keine
    • Schreibgeschützt: /var/log/
    • Spezielle Operator Access Control-Befehle: Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben).
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    Die folgenden Verzeichnisse werden in einem Schreibzugriffsmodus zugeordnet, damit die Tools ausgeführt werden können. Oracle-Operatoren erhalten jedoch keinen direkten Zugriff darauf.

    • /var
    • /opt/oracle
    • /home/dbmadmin
  • Cell-Server:
    • Lesen und schreiben: Keine
    • Schreibgeschützt: /var/log/
    • Spezielle Operator Access Control-Befehle: Cage-Befehle zum Anzeigen oder Ändern der oben genannten Dateien oder Verzeichnisse (Lesen, Lesen/Schreiben).
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    Die folgenden Verzeichnisse werden in einem Schreibzugriffsmodus zugeordnet, damit die Tools ausgeführt werden können. Oracle-Operatoren erhalten jedoch keinen direkten Zugriff darauf.

    • /var
    • /opt/oracle
    • /home/celladmin/
Aktion: Vollständiger Systemzugriff

Der vollständige Systemzugriff, der als INFRA_FULL gekennzeichnet ist, ermöglicht den Zugriff auf die Root-Konten in den Infrastrukturkomponenten.

Die Aktion "Full System Access" wird verwendet, wenn vollständiger Zugriff auf die Exadata Cloud@Customer-Infrastruktur benötigt wird. Der Zugriff ist immer auf Nicht-Gast-VM-Layer beschränkt. Vollständiger Zugriff bedeutet hier Root-Berechtigungen für jede Betriebssysteminstanz auf dem Exadata Cloud@Customer-System (außer Gast-VMs).

Hinweis

Mit der Aktion "Vollständiger Systemzugriff" kann der Operator der Root-Benutzer in der Infrastruktur werden. So kann der Operator auf jedes Speicherregister, jede Datei, jedes Gerät und das Auditsubsystem zugreifen und dieses ändern.

Tabelle 1-5: Mit INFRA_FULL aktivierte Aktionen

Aktionsname

Vollständiger Systemzugriff
Aktions-ID

INFRA_FULL
Operatorberechtigungen

Linux-Benutzerberechtigung: Nicht-Root

Kann mit "su" zu root wechseln: Ja

chroot jail: Nein

Lesbare Verzeichnisse: Alle

Lesbare Dateien: Alle

Beschreibbare Verzeichnisse: Alle

Beschreibbare Dateien: Alle

Liste der ausführbaren Befehle: Alle

Kann mit "su" wechseln zu: root bis sudo

Sudo-Benutzer- und Befehlsliste: Keine Einschränkung

Cell-Serverberechtigungen: root und celladmin

Netzwerkberechtigungen: SSH-Verbindungen können auf alle Hosts, Cell-Server und Control-Plane-Server angewendet werden. Der Benutzername ist jeweils gleich. Außerdem können Sie direkt auf dem Host und dem Cell-Server eine Verbindung zu root mit exassh herstellen.

Operator Access Control-Aktionen: Autonomes VM-Cluster

Verwenden Sie neben "Vollständiger Systemzugriff" die eingeschränkten Zugriffskäfige "Diagnose und Wartung", um Logs anzuzeigen und servicebezogene Aufgaben auszuführen.

Übergeordnetes Thema: Durchsetzung von Aktionen in Operator Access Control

Aktion: Vollständiger Systemzugriff auf autonomes Exadata-VM-Cluster

Autonomer Exadata-VM-Cluster-Vollständiger Systemzugriff, der als AVM_FULL identifiziert wird, wird selten verwendet, wenn keine der niedrigeren Zugriffsberechtigungen das Problem lösen kann.

Die Aktion "Vollständiger Systemzugriff auf autonomes Exadata-VM-Cluster" soll verwendet werden, wenn vollständiger Zugriff auf die Gast-VMs erforderlich ist. Der vollständige Zugriff hier bedeutet die root-Berechtigungen für die Gast-VMs.

Hinweis

Eine vollständige Systemzugriffsaktion stellt extreme Verfügbarkeits- und Datenrisiken dar, die anhalten können. Mit dieser Aktion kann auch der Export von Auditlogs aus dem System verhindert werden.

Tabelle 1-6: Mit AVM_FULL aktivierte Aktionen

Aktionsname

Vollständiger Systemzugriff
Aktions-ID

AVM_FULL
Operatorberechtigungen

Linux-Benutzerberechtigung: Nicht-Root

Kann mit "su" zu root wechseln: Ja

Chroot im Cage: Nein

Lesbare Verzeichnisse: Alle

Lesbare Dateien: Alle

Beschreibbare Verzeichnisse: Alle

Beschreibbare Dateien: Alle

Liste der ausführbaren Befehle: Alle

Kann mit "su" wechseln zu: root bis sudo

Sudo-Benutzer- und Befehlsliste: Keine Einschränkung

Aktion: Diagnose des autonomen Exadata-VM-Clustersystems

Autonome Exadata-VM-Clustersystemdiagnose, die als AVM_SYS_DIAG identifiziert wird, wird zur Anzeige von Logs verwendet.

Die Diagnoseaktion des autonomen Exadata-VM-Clustersystems dient zur Anzeige von Logs. Ein schreibgeschütztes Profil, das nicht privilegierten schreibgeschützten Zugriff auf das System ermöglicht. Mit dieser Aktion werden mögliche Probleme mit dem Betriebssystem und der darauf ausgeführten Software ermittelt. Die meisten Nicht-Root-Befehle sind in diesem Modus verfügbar. In dieser Aktion sind keine privilegierten Befehle verfügbar. Operatoren dürfen sudo nicht als oracle, opc oder grid verwenden, aber sie verfügen über eine weiße Gruppe von Befehlen, die sie als dynamischer Operatorbenutzer ausführen können.

Tabelle 1-7: Mit AVM_SYS_DIAG aktivierte Aktionen

Aktionsname

Diagnose des autonomen Exadata-VM-Clustersystems
Aktions-ID

AVM_SYS_DIAG
Geltungsbereich

Gast-VM
Operatorberechtigungen

Linux-Benutzerberechtigung: Nicht-Root

Kann mit "su" zu "root", "oracle", "opc", "rid" wechseln: Nein

Chroot im Cage: Ja

Lesbare Verzeichnisse:
  • /proc
  • /sys
  • /tmp
  • /usr/lib64
  • /usr/bin
  • /usr/etc
  • /usr/include
  • /usr/lib
  • /usr/libexec
  • /usr/local
  • /usr/share
  • /opt/nessus
  • /usr/java
  • /var
  • /u01
  • /u02
  • /acfs01
  • /opt/oracle/dcs/log
  • /opt/oracle.ExaWatcher/archive

Schreibbare Verzeichnisse: /tmp

Eingeschränkte lesbare Speicherorte für Anwendungslogs:
  • /etc/oratab
  • /opt/oracle/dcs/log
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /u02/oracle.ahf
  • /u02/app/oracle/diag/rdbms
  • /opt/oracle.ExaWatcher/archive
Lesezugriff auf Konfigurationsdateien:
  • /etc/oratab
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /etc/hosts

Egress-Netzwerkzugriff: Keiner

Befehle des Betriebssystems auf der Sperrliste:
  • dd
  • kdumpctl
  • ipcrm
  • ipcmk

Liste der ausführbaren Befehle: Die Befehle ls, cat und tail werden in den Speicherorten unterstützt, in denen der dynamische Benutzer opctl keinen Lesezugriff hat.

Operatorzugriff auf eine bestimmte vom Kunden genehmigte autonome Containerdatenbank (ACD) begrenzen

Schränken Sie den Zugriff auf eine bestimmte ACD in einem autonomen VM-Cluster in den Diagnose- und Wartungscages ein.

Operatoren können angeben, ob sie Folgendes benötigen:

  • Nur SSH-Zugriff auf das autonome VM-Cluster ohne SQL-Zugriff auf die ACDs. In diesem Fall wird der gesamte SQL-Zugriff auf die ACDs blockiert.
  • SSH-Zugriff auf das autonome VM-Cluster und SQL-Zugriff auf die ACDs. Wenn Sie beide Kontrollkästchen aktivieren, müssen Sie mindestens eine ACD auswählen.

Der Kunde erhält eine Genehmigungsanforderung mit den Details, auf die die Operatoren Zugriff anfordern. So kann der Kunde sicher sein, dass die Betreiber Zugriff auf die richtige ACD haben. Sobald der Kunde die Zugriffsanforderung genehmigt hat, erhalten die Operatoren SQL-Zugriff auf die ACDs, für die sie genehmigt wurden.

Das Attribut Request Reason zeigt an, auf welche ACDs die Operatoren Zugriff anfordern.

Aktion: Wartung des autonomen Exadata-VM-Clustersystems

Die Wartung des autonomen Exadata-VM-Clustersystems, die als AVM_SYS_MAINT gekennzeichnet ist, soll für servicebezogene Änderungen verwendet werden.

Die Aktion "Autonome Exadata-VM-Clustersystemwartung" dient zur Ausführung servicebezogener Änderungen. Mit dieser Aktion werden Services gestartet und gestoppt und Servicezustandsprüfungen ausgeführt. Die meisten servicebezogenen Befehle sind in diesem Modus verfügbar. Der Operator hat Zugriff auf die Logs, ist jedoch nicht für su, oracle, opc oder grid zulässig.

Tabelle 1-8: Mit AVM_SYS_MAINT aktivierte Aktionen

Aktionsname

Wartung des autonomen Exadata-VM-Clustersystems
Aktions-ID

AVM_SYS_MAINT
Geltungsbereich

Gast-VM
Operatorberechtigungen

Linux-Benutzerberechtigung: Nicht-Root

Kann mit "su" zu "root", "oracle", "opc", "rid" wechseln: Nein

Chroot im Cage: Ja

Lesbare Verzeichnisse:
  • /proc
  • /sys
  • /tmp
  • /usr/lib64
  • /usr/bin
  • /usr/etc
  • /usr/include
  • /usr/lib
  • /usr/libexec
  • /usr/local
  • /usr/share
  • /opt/nessus
  • /usr/java
  • /var
  • /u01
  • /u02
  • /acfs01
  • /opt/oracle/dcs/log
  • /opt/oracle.ExaWatcher/archive

Schreibbare Verzeichnisse: Keine

Eingeschränkte lesbare Speicherorte für Anwendungslogs:
  • /etc/oratab
  • /opt/oracle/dcs/log
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /u02/oracle.ahf
  • /u02/app/oracle/diag/rdbms
  • /opt/oracle.ExaWatcher/archive
Lesezugriff auf Konfigurationsdateien:
  • /etc/oratab
  • /etc/crontab
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /etc/hosts

Egress-Netzwerkzugriff: Keiner

Befehle des Betriebssystems auf der Sperrliste:
  • dd
  • kdumpctl
  • ipcrm
  • ipcmk

Befehlsaliasnamen: {"job_manager" : "/var/opt/oracle/adbd/apps/job_manager/job_manager.py", "backup_api" : "/var/opt/oracle/bkup_api/bkup_api", "service_driver" : "/var/opt/oracle/pylib/DBAAS/service_driver.py"}

Liste der ausführbaren Befehle: Die Ausführung servicebezogener Befehle ist unverändert verfügbar, ohne zu Benutzer oracle oder grid zu wechseln. Die Ausführung von Skripten wird durch Aliasnamen unterstützt, ohne zu Benutzer oracle oder grid zu wechseln.

Weitere Informationen finden Sie in den folgenden Beispielen.

  • crsctl status resource adbd_archive_log_ilkzdar1
  • crsctl check cluster -all
  • crsctl stat res -t
  • crsctl stat res ora.asm -t
  • srvctl status service -db ilkzdar1_cdg1hw
  • srvctl status database -d hr5zxn5l_cdg1bg
  • srvctl status instance -i hr5zxn5l1 -d hr5zxn5l_cdg1bg
  • tfactl blackout add -targettype host -timeout 2h -reason "Testing maint cage" -c
  • dgmgrl
  • asmcmd lsdsk -p

    ( Wegen möglichem Zugriff auf die Systemkonsole nicht zulässig)

  • sysresv

    (Nicht zulässig aufgrund von Optionen zum Entfernen von IPC-Ressourcen)

  • SQL*Plus ist auf ausgewählte Abfragen beschränkt. Der Wechsel zu oracle oder grid wird nicht unterstützt.

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ execsql ORACLE_UNQNAME is required.Check /etc/oratab opctl_avm_maint_user01@atpd-exa-suzzm1:~$

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ cat /etc/oratab | grep -v '^\s*$\|^\s*\#' ownwdhci_iad2pn:/u02/app/oracle/product/19.0.0.0/db1916_0_wc139_cl_atksxzha_096_0105:Y +ASM1:/u02/app/19.0.0.0/grid1916_0_wc140_cl_atksxzha_096_1334:Y ay5sq1qf_iad2bp:/u02/app/oracle/product/19.0.0.0/db1916_0_wc141_cl_atksxzha_096_0214:Y dhb2br6k_iad22z:/u02/app/oracle/product/19.0.0.0/db1916_0_wc142_cl_atksxzha_096_0416:Y v001zhgm_iad2zs:/u02/app/oracle/product/19.0.0.0/db1916_0_wc143_cl_atksxzha_096_0419:Y drmgiyo6_iad277:/u02/app/oracle/product/19.0.0.0/db1916_0_wc138_cl_atksxzha_096_0033:Y fflilzax_iad2km:/u02/app/oracle/product/19.0.0.0/db1916_0_wc145_cl_atksxzha_096_0411:Y gytjhr9o_iad2tt:/u02/app/oracle/product/19.0.0.0/db1916_0_wc144_cl_atksxzha_096_0411:Y dqk29prh_iad2hc:/u02/app/oracle/product/19.0.0.0/db1916_0_wc146_cl_atksxzha_096_0416:Y utynogge_iad2p8:/u02/app/oracle/product/19.0.0.0/db1916_0_wc147_cl_atksxzha_096_1213:Y my06yvoe_iad2km:/u02/app/oracle/product/19.0.0.0/db1916_0_wc149_cl_atksxzha_096_1218:Y nfcteuzf_iad2j9:/u02/app/oracle/product/19.0.0.0/db1916_0_wc148_cl_atksxzha_096_1216:Y opctl_avm_maint_user01@atpd-exa-suzzm1:~$

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ execsql utynogge_iad2p8

    SQL*Plus: Release 19.0.0.0.0 - Production on Thu Oct 6 06:32:11 2022 Version 19.16.0.1.0 Copyright (c) 1982, 2020, Oracle. All rights reserved. Last Successful login time: Thu Oct 06 2022 06:29:09 +00:00 Connected to: Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production Version 19.16.0.1.0 SQL> SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS FROM V$INSTANCE; INSTANCE_NAME STATUS DATABASE_STATUS ---------------- ------------ ----------------- utynogge1 OPEN ACTIVE SQL> SELECT sys_context('userenv','instance_name') FROM dual; SYS_CONTEXT('USERENV','INSTANCE_NAME') -------------------------------------------------------------------------------- utynogge1 SQL> !whoami SP2-0738: Restricted command "! (HOST)" not available SQL> !ls -ltr SP2-0738: Restricted command "! (HOST)" not available SQL>

Skripte, die wie unten mit Aliasnamen ausgeführt werden.
  • /var/opt/oracle/adbd/apps/job_manager/job_manager.py --get_status adbd_archive_log_ilkzdar1

    Ausführung als: job_manager --get_status adbd_archive_log_ilkzdar1

  • /var/opt/oracle/pylib/DBAAS/service_driver.py --dbname=hr5zxn5l_cdg1bg

    Ausführung als: service_driver --dbname=hr5zxn5l_cdg1bg

  • /var/opt/oracle/bkup_api/bkup_api --dbname ilkzdar1 list jobs

    Ausführung als: backup_api --dbname ilkzdar1 list jobs

Operatorzugriff auf eine bestimmte vom Kunden genehmigte autonome Containerdatenbank (ACD) begrenzen

Schränken Sie den Zugriff auf eine bestimmte ACD in einem autonomen VM-Cluster in den Diagnose- und Wartungscages ein.

Operatoren können angeben, ob sie Folgendes benötigen:

  • Nur SSH-Zugriff auf das autonome VM-Cluster ohne SQL-Zugriff auf die ACDs. In diesem Fall wird der gesamte SQL-Zugriff auf die ACDs blockiert.
  • SSH-Zugriff auf das autonome VM-Cluster und SQL-Zugriff auf die ACDs. Wenn Sie beide Kontrollkästchen aktivieren, müssen Sie mindestens eine ACD auswählen.

Der Kunde erhält eine Genehmigungsanforderung mit den Details, auf die die Operatoren Zugriff anfordern. So kann der Kunde sicher sein, dass die Betreiber Zugriff auf die richtige ACD haben. Sobald der Kunde die Zugriffsanforderung genehmigt hat, erhalten die Operatoren SQL-Zugriff auf die ACDs, für die sie genehmigt wurden.

Das Attribut Request Reason zeigt an, auf welche ACDs die Operatoren Zugriff anfordern.

Operator Access Control-Aktionen: Compute Cloud@Customer

Gelegentlich müssen autorisierte Operatoren auf Ressourcen zugreifen, um Compute Cloud@Customer upzugraden, Probleme zu beheben oder Probleme zu beheben.

Übergeordnetes Thema: Durchsetzung von Aktionen in Operator Access Control

Aktion: Vollständiger Zugriff auf Compute Cloud@Customer-Infrastruktur

Vollständiger Zugriff auf Compute Cloud@Customer-Infrastruktur ist als CCC_SYS_ADMIN_FULL_ACCESS gekennzeichnet.

Tabelle 1-9: Mit CCC_SYS_ADMIN_FULL_ACCESS aktivierte Aktionen

Aktionsname

Vollständiger Systemzugriff
Aktions-ID

CCC_SYS_ADMIN_FULL_ACCESS
Operatorberechtigungen

Linux-Benutzerberechtigung: Nicht-Root

Kann mit "su" zu root wechseln: Ja

Chroot im Cage: Nein

Lesbare Verzeichnisse: Alle

Lesbare Dateien: Alle

Beschreibbare Verzeichnisse: Alle

Beschreibbare Dateien: Alle

Liste der ausführbaren Befehle: Alle

Kann mit "su" wechseln zu: root bis sudo und alle Befehle als root-Benutzer ausführen

Limits für Operator Access Control

Operator Access Control ist eine Lösung, die für das Auditing und die Compliance des Zugriffs von Oracle konzipiert ist. Sie ist keine General-Purpose-Compliancelösung.

Operator Access Control auditiert nur autorisierte Benutzer, die im Zusammenhang mit einer Zugriffsanforderung erstellt wurden, welche mit einer Oracle-Operatorzugriffskontrolle verknüpft ist. Im Folgenden finden Sie eine Liste mit Beispielen für Complianceaudit- und -kontrollaktionen, für die sich Operator Access Control nicht eignet.

  • Operator Access Control kontrolliert nur die Layer, deren Eigentümer Oracle ist. Beispiel: Operator Access Control kontrolliert den Zugriff auf den physischen Exadata-Datenbankserver und den Exadata Storage Server.
  • Operator Access Control kontrolliert keine Automatisierungsaktionen, auch nicht Aktionen, die als root oder von anderen Automatisierungsbenutzern mit höheren Berechtigungen ausgeführt werden. Dies schließt proxybasierten Automatisierungszugriff ein.
  • Operator Access Control bietet nur Kontrollen im Rahmen der definierten Aktionen. Die Aktionen selbst steuern den Zugriff auf eine Anwendung auf Betriebssystemebene.
  • Operator Access Control ist kein allgemeiner Auditservice. Es werden nur autorisierte Benutzer auditiert, die im Zusammenhang mit einer Zugriffsanforderung erstellt wurden, welche mit einer Oracle-Operatorkontrolle verknüpft ist.
  • Operator Access Control kontrolliert nur verschiedene Layer in den Exadata Cloud@Customer-Systemen. Es bietet keine Kontrollen für externe Entitys von Oracle Cloud Infrastructure, wie Switches oder andere Control-Plane-Software.

Kundenmandanten-Jobrollen für Operator Access Control

Um eine Operatorzugriffskontrolle einzurichten, definieren Sie Zugriffskontroll-Policys und legen Benutzergruppen fest, die für die Verwaltung und Überwachung des Zugriffs auf Ihre Infrastruktur verantwortlich sind.

Übergeordnetes Thema: Überblick über Oracle Operator Access Control

Operatorkontrollen für Policy-Administratoren erstellen

Policy-Administratoren sind Benutzer mit Berechtigungen zum Einrichten von Operatorkontroll-Policys (als Operatorkontrollen bezeichnet).

Um eine Operatorzugriffskontrolle für Ihre Infrastruktur zu erstellen, müssen Sie zunächst Operatorkontroll-Policy-Administratoren erstellen, die das Set von Operatorkontrollen entwickeln und erstellen, das Sie für Ihre Mandantenflottenadministratoren verwenden möchten.

Wenn Sie Operatorkontrollen erstellen, teilen Sie die Exadata-Infrastruktur normalerweise basierend auf mehreren Dimensionen in Zugriffskontrollgruppen auf:

  • Geschäftskritisch: Kritische Systeme, weniger kritische Systeme, Entwicklungssysteme
  • Sicherheit oder Compliance: Systeme mit bestimmten Complianceanforderungen und andere
  • Benutzergruppen: Welche Benutzergruppen (in der Regel mit der Flottenadministratorrolle) für eine Gruppe von Exadata-Systemen verantwortlich sein sollen

Beispiele für die Benutzergruppen, die für eine Gruppe von Exadata-Systemen verantwortlich sind:

  • Vertikale Abteilungen, deren Anwendungen von einer Reihe von Exadata-Systemen abhängen.
  • Systeme, die über mehrere Abteilungen hinweg gemeinsam genutzt werden und für deren Administration eine IT-Abteilung zuständig ist.

In der Regel erstellen Sie Compartments in Ihrer Infrastruktur basierend auf Kriterien der Kritikalität, der Einhaltung gesetzlicher Vorschriften und der Verwaltung von Benutzergruppen, da Compartments die logischen administrativen Grenzen in Oracle Cloud Infrastructure bilden. Normalerweise verfügt jedes Compartment über eine Benutzergruppe, der Managementberechtigungen für das Compartment erteilt werden. Aus diesem Grund muss der Policy-Administrator so viele Operatorkontrollen erstellen, wie Compartments mit Exadata-Infrastrukturen vorhanden sind.

Neben bestimmten Operatorkontrollelementen für Compartments müssen Sie auch eine zusätzliche Policy namens DEFAULT_OPERATOR_CONTROL erstellen, mit der Sie neue Gruppen von Exadata-Systemen in neuen Compartments erstellen können, für die Sie eine andere Gruppe von administrativen Benutzern erstellen können.

So werden Operatorzugriffsanforderungen genehmigt

Hier erfahren Sie, wie Sie Operatorkontrollgenehmigungen verwalten können, indem Sie ein Identity and Access Management-(IAM-)System mit Oracle Operator Access Control-Policys einrichten.

Mandantenadministratoren für Operatorkontrollen für ein Oracle Cloud-System sind Mitglieder der Administratorgruppe für Operatorkontrollen. Sie erhalten Operatorkontrollanforderungen für den Zugriff auf Oracle Cloud Infrastructure. Um Ihre gesetzlichen Complianceanforderungen zu unterstützen, können Sie den Zugriff auf Ihre Infrastruktur steuern. Sie können angeben, dass einige Aktionen immer den Status Automatisch genehmigt haben und dass andere Aktionen genehmigt werden müssen, bevor Oracle Systemwartungsvorgänge in Ihrem Mandanten ausführen kann. Wenn Sie Zugriff auf Ihr System gewähren, wird dieser Zugriff automatisch auf einen Standardzeitraum beschränkt. Sie können auch angeben, dass Vorgänge innerhalb eines bestimmten Zeitrahmens stattfinden müssen, den Sie angeben.

Beispiel 1-1: Operatorkontrollen für eine Oracle Cloud Infrastructure-IAM-Policy

Sie können feingranulierte Kontrollen für die Berechtigungen festlegen, die Sie auf dem System erteilen.

Beispiel: Sie haben zwei Gruppen von Exadata Cloud-Systemen in einem Compartment, für das Sie der Mandantenadministrator sind. Im Rahmen Ihrer IAM-Policy haben Sie zwei separate Sets von Exadata-Systemen erstellt: Für die erste Gruppe von Systemen sind alle Operator-Policy-Konfigurationen auf Vorab genehmigt gesetzt, und für die zweite Gruppe von Systemen ist keine Operator-Policy als Vorab genehmigt konfiguriert.

Sie haben auch zwei Gruppen von Benutzern erstellt: PRE_APPROVED_POLICY_USERS und EXPLICIT_APPROVED_POLICY_USERS. Die Operatorkontrollgruppen werden durch die Angabe von Tags identifiziert: Der Namespace optctl verfügt über zwei Operatorkontrollgruppen. Eine wird durch das Tag pre-approved-exacc identifiziert. Die zweite Gruppe wird durch das Tag explicit-approved-exacc identifiziert. Sie verfügen also über eine Gruppe von Servern, auf denen alle Aktionen vorab genehmigt sind, und eine Gruppe von Servern, auf denen keine Aktionen vorab genehmigt sind.

Als Nächstes haben Sie in Ihrem Compartment eine Reihe von Exadata Cloud-Ressourcen eingerichtet, von denen jede eine zulässige Aktionsebene darstellt:

  • system_diag gibt Berechtigungen für Aktionen zur Diagnose von Problemen auf dem Exadata Cloud@Customer-Infrastrukturlayer an, wie Lesen von Logs und Ausführen von Diagnose- und Monitoringbefehlen. Sie erteilen Mitgliedern dieser Policy die Berechtigung zum Ausführen der Aktion INFRA_DIAG.
  • system_main gibt Berechtigungen für Aktionen zur Ausführung von Systemdiagnose und -wartung an, aber auch die Option zum Neustart des Systems. Sie erteilen Mitgliedern dieser Policy die Berechtigung zum Ausführen der Aktion INFRA_UPDATE_RESTART. Die Autorisierung ist jedoch auf Autorisierung angeben gesetzt.
  • system_all erteilt vollständige Systemadministrationsberechtigungen für das System, einschließlich uneingeschränkter Verwendung von sudo. Sie erteilen Mitgliedern dieser Policy die Berechtigung zum Ausführen der Aktion INFRA_FULL. Zu dieser Aktion wurde keine Policy-Gruppe erstellt.

Für die Ressourcen, in denen Sie die Policy system_diag eingerichtet haben, haben Sie alle Administrationsaktivitäten, welche diese Aktion erlaubt, als vorab genehmigt gekennzeichnet. Sie haben angegeben, dass Mitgliedern der Gruppe PRE_APPROVED_POLICY_USERS Zugriff auf die Verwendung von system_diag mit dem Status Vorab genehmigt im Mandanten erteilt wird.

Gehen Sie als nächstes davon aus, dass ein Oracle-Operator mit PRE_APPROVED_POLICY_USERS-Gruppenmitgliedschaftsanforderungen Zugriff auf einen Server anfordert, aber die Aktion INFRA_UPDATE_RESTART anfordert, weil eine Wartungsaktion einen Neustart erfordert. Der Oracle-Operator muss weiterhin Zugriff auf die Aktion anfordern, mit der ein Operator das System im Rahmen einer Wartungsaktion neu starten kann. Sie erteilen Zugriff auf die system_main-Policy, aber alle Aktionen, für die dieser Policy-Zugriff erforderlich ist, müssen genehmigt werden.

Beachten Sie, dass Sie als Administrator unabhängig von vorhandenen Gruppenmitgliedschaften oder Genehmigungen den Zugriff auf den Operator jederzeit widerrufen können. Wenn Sie einen Oracle-Operator aus der Gruppenmitgliedschaft entfernen, hat der Operator keinen Zugriff auf das System.

So wird der Operatorzugriff geprüft

Hier erfahren Sie, wie Logs erfasst werden und wie Sie Operatoraktivitäten auditieren können.

Hinweis

Die Auditlogs werden mit dem Subsystem auditd im Linux-Kernel erfasst. Um Operator Access Control-Regeln zum Erfassen der Logs hinzuzufügen, müssen Sie das Exadata-System nach der ersten Zuweisung einer Operatorkontrolle neu starten. Für die nachfolgenden Zuweisungen brauchen Sie das Exadata-System nicht neu zu starten.

Umfang der erfassten Auditlogs

Der Operator Access Control-Service protokolliert die vom Operator ausgeführten Aktionen auf einem kontrollierten System. Die erfassten Logs werden in zwei allgemeine Kategorien unterteilt.
  • Lebenszyklusereignislogs
  • Befehlslogs

Erstere erfassen Lebenszyklusereignisse, Letztere erfassen Befehle, die vom Operator auf den Zielhosts ausgeführt werden.

Lebenszyklusereignislogs

Der Operator Access Control-Service erfasst Anmelde- und Abmeldeereignisse nur für autorisierte Benutzer des Operator Access Control-Service und erfasst keine Anmeldeereignisse für die Automatisierung.

Befehlslogs

Mit dem Operator Access Control-Service werden alle Befehle erfasst, die von den autorisierten Benutzern in einer Shell ausgeführt werden. Die Befehlseingabe wird ohne Verdeckung erfasst. Die Befehlsausgabe erfasst sie nicht. Außerdem werden alle Shellbefehle erfasst, die mit Shellskripten ausgeführt werden.

Beispiel: Der Operator Access Control-Service erfasst den folgenden Befehl: 
netstat -an | grep 8080
Darüber hinaus werden die Befehle, die in diesem Fall mit dem Shellskript searchlog.sh ausgeführt werden, ebenfalls erfasst.
./searchlog.sh –process "cellservice"
Die Befehlslogs enthalten auch Befehle, die von einem Benutzer nach einem su-Befehl ausgeführt werden. Beispiel: Wenn der autorisierte Benutzer auth_user_123 nach der Anmeldung die folgenden Befehle ausgeführt wird, erfasst der Operator Access Control-Service alle diese Befehle.
su - celladmin
tail -n 10 /var/log/messages

Keyboard Logging

Darüber hinaus können die Befehlslogs auch im Keyboard-Logging-Format erfasst werden. Das Keyboard Logging erfasst jeden Tastenanschlag der Operatoren auf ihren Rechnern. Das Keyboard Logging ist im Allgemeinen nicht sonderlich nützlich. Es gibt jedoch Fälle, in denen regulatorische Anforderungen die Erfassung der Tastenanschläge verlangen.

Nicht protokollierte Elemente

Operator Access Control-Service protokolliert keine Automatisierungsbefehle oder Lebenszyklusereignisse. Während dieser Service alle Befehle protokolliert, die entweder direkt oder über den Aufruf von Shell-Skripten an die Shell ausgegeben werden, werden keine Aktionen protokolliert, die von den binären ausführbaren Dateien ausgeführt werden. Wenn sich also ein Operator beim Cell-Server anmeldet und dann in einer cellcli-Shell arbeitet, sind die Logs auf die Erfassung der cellcli-Shellbefehle beschränkt. Operator Access Control-Service protokolliert keine Befehle, die in cellcli ausgeführt werden.

Format von Auditlogs

Die Auditlogs werden als JSON-Text formatiert. Auditlogs werden in zwei Kategorien unterteilt: Rohdaten und interpretierte Daten. Die Rohdaten sind außerhalb des Kontextes eines Linux-Rechners, auf dem das Log erfasst wurde, nicht verständlich. Beispiel: Rohdaten verweisen nicht auf Linux-Benutzernamen, sondern auf interne IDs. Die Zuordnung der ID zum Benutzer kann nur auf dem Linux-Rechner erfolgen, auf dem das Log erfasst wurde.

Neben der Interpretation legt das Format auch den Kontext fest, indem die Zugriffsanforderungs-ID ("access request ID") in den Logs angegeben wird.

Lebenszyklusereignislogs

Die folgenden beiden Beispiele zeigen das Format des Auditlogs für Lebenszyklusereignisse. Die Beispiele zeigen ein login- und ein logout-Ereignis. Der für diese Anmeldung verwendete Benutzername lautet "USERNAME".

Beispiel 1-2: Log für Anmeldeereignis

{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "89736",
"tty": "/dev/pts/2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:22 2020",
"raw_data": "type=USER_LOGIN msg=audit(10/29/2020 03:20:22.091:10777414) : pid=89736 uid=root auid=USERNAME ses=75141 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=/dev/pts/2 res=success' \n",
"event": "login",
"loginid": "USERNAME"
}

Beispiel 1-3: Log für Abmeldeereignis

{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "90456",
"tty": "ssh",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:35 2020",
"raw_data": "type=USER_LOGOUT msg=audit(10/29/2020 03:20:35.855:10777438) : pid=90456 uid=root auid=USERNAME ses=75142 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=ssh res=success' \n",
"event": "logout",
"loginid": "USERNAME"
}

Befehlslogs

Die Befehlslogs sind ausführlicher. Sie enthalten Informationen über den Befehl, die Parameter des Befehls und den effektiven Benutzer, der den Befehl ausführt. Die Befehle besitzen auch eine Hierarchie in dem Sinne, dass bei der Ausführung eines Shellskriptes zuerst ein bash -c und dann die Skriptbefehle protokolliert werden.

Beispiel 1-4: Befehlsausführung

{
"layer": "CPS",
"req_auth_id": "1",
"title": "ls\u0000/",
"raw_data": "type=PROCTITLE msg=audit(10/29/2020 03:20:29.418:10777424) : proctitle=ls / \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=1182648 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=0 name=/usr/bin/ls inode=1189225 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=CWD msg=audit(10/29/2020 03:20:29.418:10777424) : cwd=/ \ntype=EXECVE msg=audit(10/29/2020 03:20:29.418:10777424) : argc=2 a0=ls a1=/ \ntype=SYSCALL msg=audit(10/29/2020 03:20:29.418:10777424) : arch=x86_64 syscall=execve success=yes exit=0 a0=0xfff6d0 a1=0xff42d0 a2=0xfff960 a3=0x7ffc1dd337e0 items=2 ppid=90474 pid=90764 auid=USERNAME uid=USERNAME gid=USERNAMg euid=USERNAME suid=USERNAME fsuid=USERNAME egid=USERNAMg sgid=USERNAMg fsgid=USERNAMg tty=pts2 ses=75141 comm=ls exe=/usr/bin/ls key=(null) \n",
"args": [],
"rec_id": "10777424",
"tty": "pts2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:29 2020",
"loginid": "USERNAME"
}

Der Feldtitel enthält den Befehl, der ausgeführt wurde. Die Rohdaten enthalten sehr viel ausführlichere Informationen.

Häufigkeit der Erfassung

Der Operator Access Control-Service erfasst die Logs beim Auftreten der Ereignisse mit einem Zeitstempel und überträgt die Logs regelmäßig per Push an den Logging-Service. Sie versucht, die Logs alle 30 Sekunden zu übertragen.

Auf Auditlogs zugreifen

Sie können Auditlogs über den Loggingservice aufrufen. Weitere Informationen finden Sie unter Logging - Überblick.

Die in Abschnitt 2 angezeigte JSON ist im Loggingservice verfügbar. Mit Ihrem Mandanten können Sie auf den Loggingservice zugreifen. Die Logs werden in dem Compartment gepostet, in dem die Operatorkontrolle erstellt wurde. Die Logs werden per Tagging an die Operatorkontrolle angehängt.

Aufbewahrungs-Policys für Auditlogs

Die Auditlogs werden im Benutzermandanten aufbewahrt. Der Operator Access Control-Service kontrolliert daher nicht die Lebensdauer von Auditlogs. Sie können die Dauer des Aufbewahrungszeitraums steuern. Wenn dieser Service die Logs jedoch nicht in den Benutzermandanten übertragen konnte, wird versucht, die Logs in dem gemäß den Exadata-Konfigurationen zulässigen Umfang aufbewahrt. Der Aufbewahrungszeitraum kann mehrere Tage umfassen.

Operator Access Control-Auditlogs an SIEM-Systeme weiterleiten

Sie können Operator Access Control-Auditlogs direkt von Exadata Cloud@Customer an die SIEM-Systeme (Security Information and Event Management) in Ihrem Data Center weiterleiten.

Um Ihr Sicherheitsmanagement zu verbessern, können Sie Auditlogs an den OCI-Loggingservice und an die SIEM-Systeme in Ihren Data Centern übertragen. Zur Übertragung dieser Auditlogs an SIEM-Systeme wird Syslog über TCP verwendet.

Übergeordnetes Thema: Überblick über Oracle Operator Access Control

Syslog-Server im Data Center bereitstellen

Um Auditlogs von Exadata Cloud@Customer zu empfangen, stellen Sie einen Syslog-Server in Ihrem Data Center bereit. Der Syslog-Server kann beliebig gewählt werden. Die meisten Linux-Systeme werden mit rsyslog geliefert.

Sie können Auditlogs pro Exadata Cloud@Customer-Zielsystem nur an einen Syslog-Server weiterleiten. Oracle unterstützt nur die sichere Kommunikation und verwendet TLS für die Übertragungssicherheit. Der Control-Plane-Server stellt eine Verbindung zum Syslog-Server her und stellt alle Auditlogs über sicheres TCP bereit. Um eine Vertrauensbeziehung zwischen dem Control-Plane-Server und dem Syslog-Server herzustellen, verwenden Sie eine CA-Zertifikatsdatei des Syslog-Servers im PEM-Format. Die Dateierweiterung muss .pem, .cer oder .crt lauten. Weitere Informationen zur Konfiguration finden Sie unter Beispielkonfiguration für Syslog-Server.

Das Log enthält Elemente, die bereits im Kapitel Logs mit Operator Access Control verwalten und durchsuchen beschrieben sind. Das Format ist mit syslog- und audit-d-Logparsern kompatibel. Weitere Informationen finden Sie im Beispiel für ein Auditlog.

Das Senden von Auditlogs an SIEM-Systeme erfolgt auf bestmögliche Weise. Der Control-Plane-Server wiederholt das Senden von Logs bei Netzwerkausfällen. Pakete können jedoch beim Erreichen von Schwellenwerten automatisch gelöscht werden. In diesen Fällen werden die Logs, die über den OCI-Loggingservice angezeigt werden, als Referenz verwendet.

Hinweis

Um Auditlogs weiterzuleiten, müssen Sie dem Exadata Cloud@Customer-System mindestens eine Operatorkontrolle unbegrenzt zuweisen (ALWAYS ASSIGNED).

Beispielkonfiguration für Syslog-Server

In diesem Beispiel wird beschrieben, wie Sie einen Syslog-Server Ihrer Wahl konfigurieren können.

Bevor Sie versuchen, den Syslog-Server zu konfigurieren, müssen Sie folgende Schritte ausführen:
  1. Öffnen Sie einen Netzwerkport für das Empfangen von Remotelogs.
    Hinweis

    Egress-Regeln für den Syslog-Server müssen für den Syslog-Port geöffnet sein. Beispiel: Wenn der Port 6514 für Syslog verwendet wird, muss die Egress-Sicherheitsregel vorhanden sein, damit Traffic vom autonomen VM-Cluster zum Syslog zulässig ist.
  2. Aktivieren Sie die Verschlüsselung auf dem Syslog-Server für die Remotekommunikation.
  3. (Optional) Generieren und übertragen Sie ein Root-Zertifikat für die sichere Kommunikation.
Hinweis

Im folgenden Beispiel wird ein rsyslog-Server (v8.24) auf einem Rechner mit Oracle Linux 7 konfiguriert. Die Konfiguration ist im Allgemeinen unter /etc/rsyslog.conf verfügbar. In diesem Beispiel werden nur die relevanten Abschnitte behandelt.

In diesem Beispiel ist der Listening-Port 10514. Im Internet stehen mehrere Quellen zur Verfügung, die Ihnen bei der Verschlüsselung des Syslog-Traffics helfen. Eine gute Referenz ist Encrypting Syslog Trafficing with TLS (SSL) [short version] - rsyslog 8.18.0.master documentation. 

# rsyslog configuration file (8.24.0 - /etc/rsyslog.conf - Oracle Linux 7)
# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, then see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES $ModLoad imuxsock # provides support for local system logging (e.g. via logger command)# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 10514

...# certificate files
$DefaultNetstreamDriverCAFile /var/gnutls1/ca.pem
$DefaultNetstreamDriverCertFile /var/gnutls1/cert.pem
$DefaultNetstreamDriverKeyFile /var/gnutls1/key.pem$ModLoad imtcp # load TCP listener$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode
$InputTCPServerStreamDriverAuthMode anon # client is NOT authenticated
#$InputTCPServerStreamDriverAuthMode x509/name # client is NOT authenticated
$InputTCPServerRun 10514 # start up listener at port 10514
...

Konnektivität zwischen CPS und dem Syslog-Server testen

Stellen Sie sicher, dass Sie eine gültige IP-Adresse oder einen gültigen Hostnamen für den Syslog-Server angegeben haben.

Der Syslog-Server muss Logs von einem Syslog-Client empfangen können und über Exadata Cloud@Customer erreichbar sein. Überprüfen Sie Ihre Konfiguration mit dem folgenden Verfahren.
  1. Um zu validieren, dass der Syslog-Server Logs empfangen kann, führen Sie den Befehl nc zum Syslog-Server und Syslog-Port von jedem Host in Ihrem Netzwerk aus, der Zugriff auf den Syslog-Server hat.
    nc syslog server host syslog port
  2. Um sicherzustellen, dass der Pfad zwischen Exadata Cloud@Customer und dem Syslog-Server gültig ist, pingen Sie die IP-Adresse des Exadata Cloud@Customer-Control-Plane-Servers. Die IP-Adresse des Control-Plane Servers (CPS) erhalten Sie von Ihrem Netzwerkadministrator.

Beispiel für Auditlogs

Administratoren finden hier Beispiele für Auditlogs, die sicher vom Control-Plane-Server empfangen werden.

Wenn Sie Logs an den Syslog-Server übertragen, werden viele Header und die JSON-Formatierung ausgelassen. Die folgenden Beispiele zeigen die Art der über Syslog gelieferten Daten.

Beispiel 1-5 1

Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGIN msg=audit(04/12/2021 07:38:05.752:1742859) : 
pid=65327 
uid=root 
auid=830916abb78e4157b9e45b641e34fcf6 ses=32770 
msg='op=login id=830916abb78e4157b9e45b641e34fcf6 
exe=/usr/sbin/sshd 
hostname=localhost.localdomain 
addr=127.0.0.1 
terminal=/dev/pts/3 res=success'

Beispiel 1-6 2

Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGOUT msg=audit(04/12/2021 07:38:08.802:1742867) : 
pid=65327 
uid=root 
auid=830916abb78e4157b9e45b641e34fcf6 
ses=32770 
msg='op=login 
id=830916abb78e4157b9e45b641e34fcf6 exe=/usr/sbin/sshd 
hostname=? 
addr=? 
terminal=/dev/pts/3 res=success'