Konfigurationsmanagement in Autonomous Database on Dedicated Exadata Infrastructure

Basierend auf Oracle Cloud Infrastructure (OCI) bietet Autonomous Database on Dedicated Exadata Infrastructure standardisierte und erprobte Sicherheitskonfigurationen, sodass Sie und Ihr Team die Konfigurationen Ihrer Autonomous Database-Flotte mit geringem Aufwand verwalten können.

Sicherheitspatches und -updates werden automatisch ausgeführt, sodass Sie sich keine Gedanken um die Aktualisierung der Sicherheit machen müssen. Diese Funktionen schützen Ihre hochempfindlichen Datenbanken und Daten vor teuren und potenziell katastrophalen Sicherheitslücken und -verletzungen. Weitere Informationen finden Sie unter Servicewartung von Autonomous Database.

Verwandte Themen

Härten von autonomen virtuellen Maschinen

Autonomous Database Virtual Machine-(Autonomous VM-)Images, auch als Client-VMs bezeichnet, sind sicherheitsfest. Wie in Oracle Software Security Assurance beschrieben, werden ihre Konfigurationen über die Softwareentwicklungs- und -sicherheitspraktiken von Oracle gesichert. Autonome VMs verfügen über eine geeignete Anti-Virus- und Anti-Malware-Software, die konfiguriert ist, um nicht autorisierte Software und Malware zu erkennen. Die Asset Endpoint Protection and Configuration Management-Software von Oracle, die auf virtuellen Clientmaschinen installiert ist, stellt sicher, dass Konfigurationsänderungen nur über sichere, genehmigte Prozesse vorgenommen werden. Auditlogs des Linux-Betriebssystems werden erfasst und an ein zentrales OCI Security Information and Event Management-(SIEM-)System zur Erkennung und Prüfung von Sicherheitsvorfällen durch das Detection and Response Team (DART) von OCI übertragen. Logs werden ab dem Generierungsdatum 13 Monate lang aufbewahrt.

DART ist verantwortlich für die Verwaltung von SIEM-Dashboards, die Bewertung von Vorfallswarnungen und die Initiierung von Korrekturmaßnahmen bei echten positiven Ergebnissen, indem Tickets für interne Serviceteams geöffnet werden. Wenn ein Sicherheitsereignis ein Kundenupdate erfordert, arbeitet DART mit Global Information Security- und Serviceteams zusammen, um ein Kundenupdate auszustellen.

Alle Oracle Autonomous VMs sind DISA STIG (Defense Information Systems Agency Security Technical Implementation Guide)-konform und gemäß Oracle Linux Security Technical Implementation Guide gehärtet. Dieser Leitfaden behandelt unter anderem Probleme bei Benutzerzugriffskontrollen, offenen Ports, unerwünschten Packages und Daemon-Konfigurationen. Eine vollständige Liste der Oracle Linux DISA STIG-Steuerelemente finden Sie hier.

Der manuelle Zugriff auf autonome VMs ist auf ein zentrales Cloud-Betriebsteam beschränkt, das vom Unternehmen gründlich überprüft wurde. Mitglieder des Operations-Teams müssen sich über ein vom Unternehmen bereitgestelltes Gerät im Oracle Cloud Network Attach (ein privates, sicheres Cloud-Netzwerk) befinden, um auf die Exadata-Infrastruktur zugreifen zu können. Zugriffszugangsdaten werden als Antwort auf gültige Supporttickets dynamisch generiert. Jede Konfigurationsänderung an den Client-VMs unterliegt einer strengen internen Sicherheitsüberprüfung und einem Änderungsmanagementprozess. Alle Tools, Skripte oder Software werden erst nach Durchlaufen des genehmigten Softwarelebenszyklus und Änderungsmanagement-Prozesses installiert oder geändert.

Die Integration mit dem Operator Access Control-Service für Infrastruktur und autonome VMs schränkt diesen Zugriff weiter ein und überlässt Ihnen Zugriffsberechtigungen und Benachrichtigungen. Operatoraktionen werden nahezu in Echtzeit angemeldet und an ein vom Kunden konfiguriertes SIEM und den Oracle Logging-Service zum Herunterladen durch den Kunden gesendet. Sie können die Logs in SIEM/Storage des Kunden herunterladen oder unbegrenzt im OCI-Objektspeicher archivieren. Weitere Informationen finden Sie unter Operator Access Control-Service.

Die OCI-Sicherheitsarchitektur definiert außerdem die einzigartige mehrschichtige Hardware- und Virtualisierungssicherheit von OCI gen2. Weitere Informationen finden Sie unter Oracle Cloud Infrastructure-Sicherheitsarchitektur.

Verwaltung von Konfigurationsabweichungen

Autonomous Database-Serviceentwicklung und Autonomous VM-Image-Build sind Teil des Geltungsbereichs der unternehmensweiten Sicherheitspraktiken von Oracle. Diese Implementierung wird im Oracle Software Security Assurance-Prozess, der hier veröffentlicht wird, sorgfältig kontrolliert.

Autonome VM-Imagekonfigurationen werden über Code gesteuert und durchlaufen mehrere Codeüberprüfungen und Qualitätssicherungszyklen, bevor eine Konfigurationsänderung zu einem Produktionsrelease führt. Informationen zur Haltung von Oracle und zu den Standardverfahren zum Sichern von Softwarekonfigurationen finden Sie im Abschnitt Sichere Konfigurationen in der Oracle Software Security Assurance-Dokumentation.

Ein von Oracle entwickelter Agent, Asset Endpoint Protection and Configuration Management (AEP/CM), wird auf Control-Plane-Servern installiert, um Linux-Auditlogs und Linux Advanced Intrusion Detection Environment-(AIDE-)Logs von Infrastruktur- und autonomen VM-Instanzen zu erfassen und zu übertragen. Diese Logs werden zu Auditzwecken an ein zentrales OCI-SIEM übertragen. SIEM-Regeln für die Manipulation von Logdateien, das Herunterladen externer Inhalte, das Deaktivieren von Sicherheitstools und andere generieren Alerts, die DART wie unter Autonomous Virtual Machine Hardening beschrieben bewertet und beantwortet.

Autonome VM-Instanzen sind vor direktem ssh-Zugriff geschützt, mit Ausnahme von genehmigten Oracle-Operatoren und Automatisierung. Alle Operatoraktivitäten können über Operator Access Control überwacht werden.

Dateiintegrität und Intrusion Monitoring

Autonome VMs sind mit einem Dateieingriffs- und Überwachungsutility konfiguriert, das die Anzahl und Integrität von Dateien in einem bestimmten Build verwaltet. Jede Änderung der Dateianzahl oder Änderung einer Datei-Prüfsumme wird gekennzeichnet. AIDE- und HIDS-Logs werden ebenfalls erfasst und an OCI SIEM gesendet und über den in Autonomous Virtual Machine Hardening erläuterten DART-Prozess auf Bedrohungen gescannt.

Alle auf einem AVMC bereitgestellten Softwareartefakte, einschließlich Tools, werden über eine sichere Änderungsmanagementmethode mit Prüfsummen bereitgestellt und mit SSL-Zertifikaten digital signiert. Dies wird als zertifikatssigniertes Code-Deployment bezeichnet.

Scannen und Antworten auf autonome VM-Sicherheitslücken

Alle autonomen VM-Images werden mit den sicheren Entwicklungspraktiken von Oracle erstellt, wie in Oracle Software Security Assurance dokumentiert. Der Corporate Security Solution Assurance Process (CSSAP) ist ein Sicherheitsprüfungsprozess, der von der Corporate Security Architecture von Oracle, Global Information Security (GIS) und den IT-Organisationen von Oracle entwickelt wurde, um eine umfassende Überprüfung des Informationssicherheitsmanagements durchzuführen. GIS und CSSAP arbeiten unabhängig von OCI-Serviceteams, um die Informationen und Software-Assets von Kunden und Oracle zu schützen. Jedes Servicefeature mit einer potenziellen Sicherheitsauswirkung unterliegt einem CSSAP-Überprüfungs- und Genehmigungsprozess. Darüber hinaus verwenden Qualitätssicherungszyklen (QA-Testzyklen) geeignete Scan-Tools, um sicherzustellen, dass Bilder STIG einhalten, die Servicesicherheitsrichtlinien erfüllen und für die CSSAP-Überprüfung bereit sind.

Forensische Tools auf AVMCs spielen eine wichtige Rolle bei der Verwaltung von Sicherheitslücken. Linux-Auditlogs von jedem autonomen VM-Host werden in ein zentrales OCI SIEM hochgeladen, in dem Alertregeln potenzielle Bedrohungen erfassen und aufdecken. DART reagiert auf diese Alerts, wie unter Härtung autonomer virtueller Maschinen beschrieben. HIDS und Anti-Virus-Protokolle werden ebenfalls ähnlich verarbeitet. Ein Common Vulnerabilities and Exposures-(CVE-)Scanner sendet seine Ergebnisse an ein zentrales Automatisierungstool, in dem Schwachstellenergebnisse kategorisiert und Tickets für Serviceteams geöffnet werden, um Systeme auf einer Zeitskala zu patchen, die proportional zum Schweregrad des Befundes ist. Alle CVEs mit einem Score größer als 7 müssen innerhalb von 30 Tagen gepatcht werden.

Sie können Infrastrukturpatch-Bundles mit Hypervisor, Grid Infrastructure, Speicher- und Clientbetriebssystemen und Firmware vierteljährlich planen. Datenbankreleaseupdates und Releaseupdaterevisionen können jedes Quartal auch separat geplant werden. Alle Patches werden mit Cloud-Automatisierungstools und Autonomous Cloud Operations bereitgestellt und eingespielt, wie für das jeweilige Patchupdate erforderlich.

Die Softwarepatchentwicklung folgt bei Bedarf den sicheren Softwareentwicklungspraktiken von Oracle, Qualitätssicherungstests und CSSAP-Überprüfungen. Die Aufgabentrennung zwischen Patch-Entwicklern, QS-Tests, Release-Management und Patching-Vorgängen stellt sicher, dass mehrere Mitarbeiter beteiligt sind, bevor ein Patch zur Hardware des Kunden gelangt.

Wenn möglich, werden Updates ohne Ausfallzeiten mit Tools wie Linux ksplice auf das laufende System angewendet. Wenn für ein Update ein Neustart der Komponente erforderlich ist, führt Oracle den Komponentenneustart im Rolling-Modus durch, um die Serviceverfügbarkeit während des Aktualisierungsprozesses sicherzustellen. Sie können Patching-Startzeiten so planen, dass sie Ihren Geschäfts-SLAs entsprechen. Das Patching kann für Infrastrukturkomponenten (GI, BS) und jedes DBMS-Home separat geplant werden.

Vulnerability Scans und Patching

Autonomous Database on Dedicated Exadata Infrastructure führt externe und interne Schwachstellenscans (einschließlich der Erkennung von Supportendsystemen) häufig mit kommerziellen Tools zum Scannen von Schwachstellen durch. Identifizierte Sicherheitslücken werden vom Cloud Compliance Standard für Vulnerability Management untersucht und bis zur Lösung verfolgt. Es verwendet verschiedene technische Maßnahmen, um Updates für Drittanbieter- und Open-Source-Bibliotheken zu bewerten und zu identifizieren. Authentifizierte Sicherheitslücken-Scans von Systemen, die in der Umgebung bereitgestellt werden, sowie Scans von Systemimages vor dem Deployment wurden implementiert, um diese Librarys zu identifizieren und festzustellen, ob Sicherheitsfixes erforderlich sind. Unternehmensrichtlinien und Geschäftsbereichsverfahren regeln diese Programme und bewerten sie jährlich.

Autonomous Database verwendet einen Mechanismus, um Sicherheitsergebnisse aus mehreren Quellen (einschließlich Schwachstellenscans) zu aggregieren und dem entsprechenden Serviceteam Ergebnisse zuzuweisen. Mit diesem System können Serviceteams ihre Ergebnisse verwalten und in Ticketing-Systeme integrieren, um automatische Warteschlangen für Korrekturarbeiten zu erstellen, einschließlich Benachrichtigungen und automatischer Eskalationen. Das System fasst außerdem die Abhilfemaßnahmen im gesamten Unternehmen zusammen und treibt den täglichen Umgang mit Schwachstellen voran.

Oracle Software Security Assurance (OSSA) definiert die Methodik von Oracle, um Sicherheit in Design, Build, Test und Wartung seiner Produkte zu integrieren, unabhängig davon, ob sie von Kunden On Premise verwendet oder über Oracle Cloud bereitgestellt werden. Oracle Corporate Security-Richtlinien (einschließlich Richtlinien, die Bedrohungs- und Sicherheitslückenmanagement behandeln) werden jährlich überprüft und bei Bedarf aktualisiert. Mindestens jährlich führen unabhängige Dritte einen Systemdurchdringungstest durch.

Um allen Oracle-Kunden den besten Sicherheitsstatus zu bieten, behebt Oracle erhebliche Sicherheitslücken basierend auf dem wahrscheinlichen Risiko, das sie für Kunden darstellen. Die Probleme mit den größten Risiken werden zuerst behoben. Im Allgemeinen werden die Fixes für Sicherheitslücken in der folgenden Reihenfolge erstellt:

  • Hauptcode-Zeile zuerst – das ist die Code-Zeile, die für die nächste Hauptversion des Produkts entwickelt wird.
  • Erstellen Sie für jede unterstützte Version, die anfällig ist, einen Critical Patch Update-Patch, und wenden Sie den Fix im nächsten Patchset an, wenn ein anderes Patchset für diese unterstützte Version geplant ist.

Patches und Updates werden über Tools für kontinuierliche Integration/kontinuierliches Deployment (CI/CD) implementiert. Mit Ausnahme von Abhängigkeiten über mehrere Availability-Domains hinweg (z.B. Aktualisierungen von Domainnamenservices) werden Änderungen in jeder Region und Availability-Domain separat implementiert. Die Implementierungs-Policy für Oracle Patching and Security Alerts erfordert das Deployment der Oracle Critical Patch Update- und Security Alert-Updates und der zugehörigen Empfehlungen. Diese Policy umfasst auch Anforderungen zur Behebung von Sicherheitslücken in Nicht-Oracle-Technologie mit einem risikobasierten Ansatz. Weitere Informationen finden Sie unter Programme für kritische Patchupdates und Sicherheitswarnungen.

Oracle plant und führt neben der vierteljährlichen Wartung eine monatliche Wartung der Infrastruktursicherheit durch. Diese Sicherheitspatches werden jedoch nur in diesen Monaten mit kritischen Sicherheitsupdates eingespielt, einschließlich Korrekturen für Sicherheitslücken mit CVSS-Scores größer oder gleich 7.

  • Jede Exadata-Infrastruktur, die bereitgestellt wird, bevor Oracle die Sicherheitswartung plant, ist zur Sicherheitswartung berechtigt.
  • Der monatliche Sicherheitswartungsprozess aktualisiert Datenbankserver, um kritische Sicherheitslücken und Produktprobleme zu beheben. Außerdem aktualisieren sie Speicherserver auf ein Exadata Storage Software-Image, das bekannte Sicherheitslücken und Produktprobleme löst.

Oracle Cloud-Sicherheitstest-Policy

Oracle führt regelmäßig Penetrations- und Schwachstellentests sowie Sicherheitsbewertungen für die Oracle Cloud-Infrastruktur, -Plattformen und -Anwendungen durch, um die Gesamtsicherheit von Oracle Cloud-Services zu validieren und zu verbessern. Oracle bewertet oder testet jedoch keine Komponenten (einschließlich Nicht-Oracle-Anwendungen, Nicht-Oracle Datenbanken oder andere nicht von Oracle stammende Software, Code oder Daten, wie zutreffend), die Sie über die Oracle Cloud-Services verwalten oder in diese einführen (einschließlich der Einführung durch Ihre Entwicklung in oder Erstellung in diese Services (die "Kundenkomponenten").

Oracle Customer Security Testing Policy beschreibt die Sicherheitstests, wie Penetrationstests und Schwachstellenscans, die Oracle Kunden gegen ihre Oracle On-Premises-Produkte und Oracle Cloud Services durchführen können ("Sicherheitstests" oder "Sicherheitstests"). Er wird zusammen als "Testing Policy" bezeichnet und ist in den Servicespezifikationen für Oracle Cloud Services enthalten. Diese Policy kann keine Berechtigungen zum Testen von Drittanbietermaterialien, die in den Kundenkomponenten enthalten sind, behandeln oder bereitstellen. Nur Kunden mit einem Oracle Account, die über die erforderlichen Berechtigungen zum Einreichen von Servicewartungsanforderungen verfügen und bei der Umgebung angemeldet sind, die Gegenstand solcher Tests sein wird, können Sicherheitslücken oder Penetrationstests durchführen.

Sofern nicht anderweitig in Ihren Oracle Cloud-Servicevereinbarungen zulässig oder eingeschränkt, kann Ihr Serviceadministrator, der Zugriff auf Systemebene auf Ihren Autonomous Database-Service hat, Penetrations- und Sicherheitslückentests für die in Ihrem Autonomous Database-Service enthaltenen Kundenkomponenten gemäß den Einschränkungen unter Sicherheitstests in der Oracle Cloud ausführen.

Antworten auf Fragen zu Ihren Sicherheitstests finden Sie auch in den FAQs zu Sicherheitstests.

Schutz vor Endpunkten, Malware und Ransomware

Autonome VM-Clientrechner werden mit Endpunkt-, Malware- und Ransomware-Schutz wie unten beschrieben erstellt:

  • Geeignete Anti-Virus- und Anti-Malware-Tools werden regelmäßig installiert und aktualisiert.
  • Der Zugriff ssh/sftp auf das Clientnetzwerk ist geschlossen.
  • Benannte Benutzeraccounts auf Client-VMs sind extrem auf erforderliche Prozesse beschränkt.
  • Autonome VMs sind auf DISA STIG-Standards gehärtet, um sicherzustellen, dass keine nicht verwendeten Ports geöffnet sind oder Daemons auf dem System ausgeführt werden.
  • Der Oracle-Operatorzugriff erfolgt über eine gesicherte, ausgehende Verbindung zum Managementnetzwerk von Oracle in einer vom Kunden ausgewählten OCI-Region.
  • Oracle-Operatoraktionen können über die Operator Access Control-Serviceintegration gesteuert und auditiert werden.

Verwaltung von Sicherheitsvorfällen

Ein dediziertes Team von Sicherheitsanalysten aus dem Detection and Response Team (DART) für Sicherheitsvorfälle ist für die Verwaltung der Sicherheitsereignis-Dashboards 24/7 und die Verarbeitung von Alerts verantwortlich, um echte positive Ergebnisse zu filtern. Wenn ein wahres Positiv erkannt wird, wird eine geeignete Antwort basierend auf dem Schweregrad und der Auswirkung des Ereignisses initiiert. Dies kann eine weitere Analyse, eine Ursachenbewertung und eine Behebung mit den Serviceteams und der Kundenkommunikation umfassen.

Die Antwort-Policys für Sicherheitsvorfälle von Oracle sind unter Antwort auf Sicherheitsvorfälle beschrieben.