Sicherheitsrichtlinien für Oracle Database@Azure
Dieser Artikel baut auf verschiedenen Überlegungen und Empfehlungen auf, die unter Entwurfsbereich für Sicherheit in Azure definiert sind. Er enthält wichtige Überlegungen zum Entwurf und Empfehlungen für Sicherheitsmaßnahmen in Oracle Database@Azure.
Übersicht
Die meisten Datenbanken enthalten vertrauliche Daten, die eine sichere Architektur erfordern, die über den Schutz auf Datenbankebene hinausgeht. Die detaillierte Abwehrstrategie sorgt durch mehrschichtige Abwehrmechanismen für umfassende Sicherheit. Dabei werden verschiedene Maßnahmen miteinander kombiniert, um zu vermeiden, dass nur eine Art der Sicherheit wie z. B. der Netzwerkschutz verwendet wird. Zu diesen Maßnahmen gehören Frameworks für strenge Authentifizierung und Autorisierung, Netzwerksicherheit, Verschlüsselung ruhender Daten und Verschlüsselung in Übertragung begriffener Daten. Diese mehrschichtige Strategie ist für einen effektiven Schutz von Oracle-Workloads unerlässlich.
Weitere Informationen finden Sie im Sicherheitsleitfaden für Exadata Database Service auf dedizierter Infrastruktur und Exadata-Sicherheitskontrollen.
Überlegungen zum Entwurf
Beachten Sie beim Entwerfen Ihrer Sicherheitsrichtlinien für Oracle Database@Azure die folgenden Anleitungen:
Oracle Database@Azure-Workloads umfassen Ressourcen, die in virtuellen Azure-Netzwerken und Rechenzentren bereitgestellt werden. Diese Ressourcen werden von der Azure-Steuerungsebene und der Steuerungsebene der Oracle Cloud Infrastructure (OCI) verwaltet. Die Azure-Steuerungsebene verwaltet die Initiierung der Infrastruktur und der Netzwerkkonnektivität. Die Oracle-Steuerungsebene übernimmt die Datenbankverwaltung und die individuelle Knotenverwaltung. Weitere Informationen finden Sie unter Gruppen und Rollen für Oracle Database@Azure.
Der Oracle Database@Azure-Dienst wird nur in privaten Subnetzen in Azure bereitgestellt. Der Dienst ist nicht unmittelbar über das Internet zugänglich.
Delegierte Oracle Database@Azure-Subnetze unterstützen keine Netzwerksicherheitsgruppen (NSGs).
Die Oracle Database@Azure-Lösung verwendet viele standardmäßige TCP-Ports (Transmission Control Protocol) für verschiedene Vorgänge. Die vollständige Liste der Ports finden Sie unter Standardmäßige Portzuweisungen.
Zum Speichern und Verwalten von Schlüsseln mit der standardmäßig aktivierten Transparent Data Encryption (TDE)-Lösung kann die Oracle Database@Azure.Lösung OCI Vaults oder Oracle Key Vault verwenden. Die Oracle Database@Azure-Lösung unterstützt Azure Key Vault nicht.
Standardmäßig wird die Datenbank mit von Oracle verwalteten Verschlüsselungsschlüsseln konfiguriert. Die Datenbank unterstützt auch kundenseitig verwaltete Schlüssel.
Um den Datenschutz zu verbessern, verwenden Sie Oracle Data Safe mit Oracle Database@Azure.
Nicht-Microsoft- und Oracle-Agenten können auf das Oracle Database@Azure-Betriebssystem zugreifen, wenn sie den Betriebssystemkern nicht ändern oder kompromittieren.
Entwurfsempfehlungen
Beachten Sie beim Entwerfen Ihrer Sicherheit für Oracle Database@Azure die folgenden Empfehlungen:
Trennen Sie den Infrastrukturzugriff vom Zugriff auf Datendienste, insbesondere wenn verschiedene Teams aus unterschiedlichen Gründen auf mehrere Datenbanken in derselben Infrastruktur zugreifen.
Verwenden Sie NSG-Regeln, um den Quell-IP-Adressbereich einzuschränken, der die Datenebene und den Zugriff auf virtuelle Netzwerke sichert. Öffnen Sie nur die für eine sichere Kommunikation erforderlichen Ports, um unbefugten Zugriff auf das Internet und vom Internet zu verhindern. Sie können NSG-Regeln auf OCI konfigurieren.
Konfigurieren Sie die Netzwerkadressenübersetzung (NAT), wenn Sie Internetzugriff benötigen. Verlangen Sie immer die Verschlüsselung in Übertragung begriffener Daten.
Wenn Sie Ihre eigenen Verschlüsselungsschlüssel verwenden, richten Sie einen strengen Schlüsseldrehungsprozess ein, um Sicherheits- und Compliancestandards aufrechtzuerhalten.
Wenn Sie Nicht-Microsoft- oder Oracle-Agenten auf Oracle Database@Azure verwenden, installieren Sie diese Agenten an Orten, auf die Datenbank- oder Grid-Infrastrukturpatches keine Auswirkungen haben.