Konfigurationsmanagement in Autonomous AI Database auf dedizierter Exadata-Infrastruktur

Autonomous AI Database on Dedicated Exadata Infrastructure basiert auf Oracle Cloud Infrastructure (OCI) und bietet standardmäßige, gehärtete Sicherheitskonfigurationen, sodass Sie und Ihr Team nicht viel Zeit und Geld für die Verwaltung von Konfigurationen in Ihrer autonomen KI-Datenbankflotte aufwenden müssen.

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 kostspieligen und potentiell katastrophalen Sicherheitslücken und -verletzungen. Weitere Informationen finden Sie unter Servicewartung der autonomen KI-Datenbank.

Härten von autonomen virtuellen Maschinen

Autonomous AI Database Virtual Machine-(Autonomous VM-)Images, auch als Client-VMs bezeichnet, sind sicherheitsgesichert. Wie in Oracle Software Security Assurance dargelegt, werden ihre Konfigurationen über Entwicklungs- und Assurance-Praktiken von Oracle gesichert. Autonome VMs verfügen über geeignete Anti-Virus- und Anti-Malware-Software, die zur Erkennung nicht autorisierter Software und Malware konfiguriert ist. 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. Linux-BS-Auditlogs werden erfasst und an ein zentrales OCI Security Information and Event Management-(SIEM-)System zur Erkennung und Prüfung von Sicherheitsvorfällen durch das OCI Security Incident Detection and Response Team (DART) übertragen. Logs werden ab dem Generierungsdatum 13 Monate lang beibehalten.

DART ist verantwortlich für die Besetzung von SIEM-Dashboards, die Bewertung von Vorfallwarnungen und die Einleitung von Korrekturmaßnahmen für echte positive Ergebnisse, 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 mit 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. Operations-Teammitglieder müssen sich über ein vom Unternehmen bereitgestelltes Gerät im Oracle Cloud Network Attach (einem privaten, sicheren Cloud-Netzwerk) befinden, um auf die Exadata-Infrastruktur zugreifen zu können. Zugriffszugangsdaten werden als Reaktion 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 installiert oder geändert, nachdem der genehmigte Software-Lebenszyklus und der Änderungsmanagementprozess durchlaufen wurden.

Durch die Integration mit dem Operator Access Control-Service für Infrastruktur und autonome VMs wird dieser Zugriff weiter eingeschränkt, und Sie erhalten Zugriffsberechtigung und Benachrichtigung. Operatoraktionen werden nahezu in Echtzeit angemeldet und an ein vom Kunden konfiguriertes SIEM und den Oracle-Loggingservice zum Download durch den Kunden gesendet. Sie können die Logs auf Kunden-SIEM/Storage herunterladen oder sie unbegrenzt im OCI-Objektspeicher archivieren. Weitere Informationen finden Sie unter Operator Access Control-Service.

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

Abweichungsmanagement für Konfiguration

Die Entwicklung von autonomen KI-Datenbankservices und die Erstellung von autonomen VM-Images sind Teil der Sicherheitspraktiken von Oracle. Diese Implementierung wird im Oracle Software Security Assurance-Prozess sorgfältig kontrolliert und hier veröffentlicht.

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

Ein von Oracle entwickelter Agent, die Asset Endpoint Protection and Configuration Management-(AEP/CM-)Software, 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, die speziell für die Manipulation von Logdateien, das Herunterladen externer Inhalte, das Deaktivieren von Sicherheitstools und andere gelten, generieren Warnungen, die DART wie beschrieben bewertet und beantwortet.

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

Dateiintegrität und Intrusion Monitoring

Autonome VMs werden mit einem Utility zum Eindringen und Überwachen von Dateien konfiguriert, das die Anzahl und Integrität von Dateien in einem bestimmten Build aufrechterhält. Jede Änderung der Dateizahl oder Änderung einer Dateiprüfsumme ist gekennzeichnet. AIDE- und HIDS-Logs werden ebenfalls erfasst und an OCI SIEM gesendet und über den DART-Prozess, der unter Autonomous Virtual Machine Hardening erläutert wird, auf Bedrohungen gescannt.

Alle in 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 vom Zertifikat signiertes Code-Deployment bezeichnet.

Scannen und Reaktion auf autonome VM-Sicherheitslücken

Alle autonomen VM-Images werden unter Verwendung der sicheren Entwicklungspraktiken von Oracle erstellt, wie in Oracle Software Security Assurance dokumentiert. Der Corporate Security Solution Assurance Process (CSSAP) ist ein Sicherheitsüberprüfungsprozess, der von der Unternehmens-Sicherheitsarchitektur von Oracle, der Global Information Security (GIS) und den IT-Organisationen von Oracle entwickelt wurde, um eine umfassende Überprüfung des Informationssicherheitsmanagements bereitzustellen. 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 potenziellen Sicherheitsauswirkungen unterliegt einem CSSAP-Überprüfungs- und Genehmigungsprozess. Darüber hinaus verwenden Qualitätssicherungs-(QA-)Testzyklen geeignete Scan-Tools, um sicherzustellen, dass Bilder STIG entsprechen, die Sicherheitsrichtlinien für Services erfüllen und für die CSSAP-Überprüfung bereit sind.

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

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

Die Entwicklung von Softwarepatches folgt nach Bedarf den sicheren Softwareentwicklungspraktiken von Oracle, QA-Tests und CSSAP-Überprüfungen. Die Aufgabentrennung zwischen Patchentwicklern, QS-Testern, Release-Management und Patching-Vorgängen stellt sicher, dass mehrere Mitarbeiter involviert sind, bevor ein Patch die Hardware des Kunden erreicht.

Wenn möglich, werden Updates ohne Ausfallzeiten mit Tools wie Linux ksplice auf das laufende System eingespielt. Wenn ein Update einen Neustart der Komponente erfordert, führt Oracle den Neustart der Komponente im Rolling-Modus aus, um die Serviceverfügbarkeit während des Aktualisierungsprozesses sicherzustellen. Sie können Patching-Startzeiten planen, um die SLAs Ihres Unternehmens zu erfüllen. Das Patching kann separat für Infrastrukturkomponenten (GI, BS) und jedes DBMS-Home geplant werden.

Scans und Patches für Sicherheitslücken

Autonome KI-Datenbank auf dedizierter Exadata-Infrastruktur führt häufig externe und interne Schwachstellenscans (einschließlich der Erkennung von Support-Endsystemen) mit kommerziellen Tools zum Scannen von Schwachstellen durch. Identifizierte Schwachstellen werden vom Cloud Compliance Standard for 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 Schwachstellenscans von Systemen, die in der Umgebung bereitgestellt werden, sowie Scans von Systemimages vor dem Deployment wurden implementiert, um solche Bibliotheken zu identifizieren und festzustellen, ob Sicherheitsfixes erforderlich sind. Unternehmensrichtlinien und Geschäftseinheitsverfahren regeln diese Programme und bewerten sie jährlich.

Die autonome KI-Datenbank verwendet einen Mechanismus, um Sicherheitsbefunde aus mehreren Quellen (einschließlich Schwachstellenscans) zu aggregieren und dem entsprechenden Serviceteam Ergebnisse zuzuweisen. Mit diesem System können Serviceteams ihre Ergebnisse verwalten und sich in Ticketing-Systeme für die automatisierte Warteschlange von Korrekturarbeiten integrieren, einschließlich Benachrichtigungen und automatischer Eskalationen nach Bedarf. Das System fasst auch die Abhilfemaßnahmen im gesamten Unternehmen zusammen und fördert die täglichen Bemühungen um das Sicherheitslückenmanagement.

Oracle Software Security Assurance (OSSA) defines Oracle’s methodology for building security into its products’ design, build, testing, and maintenance, whether used on-premises by customers or delivered through Oracle Cloud. Die Unternehmens-Sicherheitsrichtlinien von Oracle (einschließlich Richtlinien zur Behebung von Bedrohungen und Sicherheitslücken) 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 schwerwiegendsten Risiken werden zuerst behoben. Im Allgemeinen werden die Fixes für Sicherheitslücken in der folgenden Reihenfolge erstellt:

Hauptcodezeile zuerst - das ist die Codezeile, die für die nächste Hauptversion des Produkts entwickelt wird.
Erstellen Sie für jede unterstützte Version, die anfällig ist, einen Patch für kritische Patchupdates, 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 CI/CD-Tools (Continuous Integration/Continuous Deployment) implementiert. Außer wenn Abhängigkeiten über mehrere Availability-Domains hinweg bestehen (z.B. Aktualisierungen von Domain Name Services), werden Änderungen separat in jeder Region und Availability-Domain implementiert. Die Implementierungs-Policy für Oracle Patching und Sicherheitswarnungen erfordert die Bereitstellung der Oracle Critical Patch Update- und Sicherheits-Alert-Updates und der zugehörigen Empfehlungen. Diese Richtlinie umfasst auch Anforderungen für die Behebung von Sicherheitslücken in nicht von Oracle stammender Technologie mit einem risikobasierten Ansatz. Weitere Informationen finden Sie unter Critical Patch Update and Security Alert-Programme.

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 Fixes für Sicherheitslücken mit CVSS-Scores größer/gleich 7.

Alle Exadata-Infrastrukturen, die bereitgestellt werden, bevor Oracle die Sicherheitswartung plant, sind für die 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 Sicherheit der Oracle Cloud Services insgesamt zu überprüfen und zu verbessern. Oracle bewertet oder testet jedoch keine Komponenten (einschließlich nicht von Oracle stammender Anwendungen, nicht von Oracle stammenden Datenbanken oder anderer nicht von Oracle stammender Software, Code oder Daten, soweit zutreffend), die Sie durch die Verwaltung oder Einführung in die Oracle Cloud Services (die "Kundenkomponenten") verwalten oder in diese integrieren; einschließlich Einführung in Ihre Entwicklung und Erstellung darin.

Oracle Customer Security Testing Policy beschreibt die Sicherheitstests wie Penetrationstests und Scans von Sicherheitslücken, die Oracle-Kunden mit ihren Oracle On-Premises-Produkten und Oracle Cloud Services durchführen können ("Sicherheitstests" oder). Sie wird zusammenfassend als "Testing Policy" bezeichnet und in den Leistungsbeschreibungen 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 in Ihren Oracle Cloud-Servicevereinbarungen nichts anderes zulässig oder eingeschränkt ist, kann Ihr Serviceadministrator, der Zugriff auf Systemebene auf Ihren Autonomous AI Database-Service hat, Penetrations- und Sicherheitslückentests für die in Ihrem Autonomous AI Database-Service enthaltenen Kundenkomponenten gemäß den Einschränkungen ausführen, die unter Sicherheitstests in der Oracle Cloud beschrieben sind.

Außerdem finden Sie unter Häufig gestellte Fragen zu Sicherheitstests Antworten auf Fragen zu Sicherheitstests.

Schutz vor Endpunkt, Malware und Ransomware

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

Geeignete Anti-Virus- und Anti-Malware-Tools werden regelmäßig installiert und aktualisiert.
ssh/sftp-Zugriff auf das Clientnetzwerk wird geschlossen.
Named User Accounts auf Client-VMs sind extrem auf erforderliche Prozesse beschränkt.
Autonome VMs werden nach DISA STIG-Standards gehärtet, um sicherzustellen, dass keine nicht verwendeten Ports geöffnet sind oder Daemons auf dem System ausgeführt werden.
Der Zugriff von Oracle-Operatoren erfolgt über eine sichere, 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 des Detection and Response Teams (DART) für Sicherheitsereignisse ist dafür verantwortlich, die Dashboards 24/7 für Sicherheitsereignisse zu bearbeiten und Warnungen zu verarbeiten, um echte positive Ergebnisse zu filtern. Wenn ein wahres positives Ergebnis ermittelt wird, wird eine geeignete Antwort basierend auf dem Schweregrad und der Auswirkung des Ereignisses initiiert. Dies kann eine weitere Analyse, eine Ursachenbewertung und eine Korrektur mit den Serviceteams und der Kundenkommunikation umfassen.

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