Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel ist Teil der Artikelreihe „Sicherheit für SAP erweitern und weiterentwickeln: Bewährte Methoden“.
- SQL Server-Datenbanksicherheit für SAP in Azure
- Microsoft Sentinel für SAP in Azure
- Sicherheitsvorgänge für SAP in Azure
Dieser Artikel enthält Sicherheitsüberlegungen und Empfehlungen für SAP in Azure, das in einer SQL Server-Datenbank ausgeführt wird.
Gesicherte ruhende Daten
Die SQL Server Transparent Data Encryption (TDE) verschlüsselt die Daten- und Protokolldateien von Benutzerdatenbanken und SQL Server-Systemdatenbanken. Nach der Verschlüsselung können Kopien der Daten- und Protokolldateien oder Sicherungsdateien ohne die zugehörigen Zertifikate nicht wiederhergestellt und verwendet werden. Dieser Prozess wird als „Sicherung ruhender Daten“ bezeichnet. Es handelt sich um eine transparente Technologie für das SAP-System – unterstützt durch den SAP-Hinweis 1380493: SQL Server TDE. Informationen zum TDE-Verfahren finden Sie unter SQL Server-Verschlüsselung.
Alle Datenseiten, die gelesen oder auf den Datenträger geschrieben werden, müssen verschlüsselt oder entschlüsselt werden, sodass durch TDE die CPU-Auslastung ansteigt (CPU Penalty). Wenn TDE auf eine Benutzerdatenbank angewendet wird, steigt die CPU-Auslastung um 3 bis 8 %. Anwendungen, die tempDB von SQL Server intensiv nutzen oder umfangreiche Scans für große Tabellen ausführen, sind stärker betroffen. Wenn mindestens eine Benutzerdatenbank auf der SQL Server-Instanz mit TDE verschlüsselt wird, werden auch die Systemdatenbanken wie TempDB verschlüsselt. SAP Business Warehouse (SAP BW) ist ein Beispiel für diesen Anwendungstyp.
Hinweis
Wenn die Verschlüsselungsschlüssel oder Zertifikate verloren gehen, gehen auch die Daten in der verschlüsselten Datenbank verloren. Es ist wichtig, umfangreiche Prozesse und Schritte zum Sichern der Zertifikatsicherungen einzurichten.
Eine erfolgreiche TDE-Implementierung erfordert umfangreiche und gründliche Tests und gut durchdachte Prozesse, um Zertifikate und Zertifikatsicherungen zu handhaben.
Nicht unterstützte SQL Server-Features
SQL Server bietet auch weitere Features für den Schutz von Daten. Diese Methoden ermöglichen eine partielle Verschlüsselung oder Maskierung für die Granularität von Datenbankspalten:
Aufgrund der Einschränkungen, die diese drei Methoden haben, sowie der Änderungen, die sie für viele Bereiche der SAP NetWeaver-Komponenten erfordern, werden diese Funktionen von SAP nicht unterstützt.
Die Echtzeitreplikation zwischen einer TDE-fähigen Datenbank auf SQL Server und SAP HANA wird nicht unterstützt. Weitere Informationen finden Sie im SAP OSS-Hinweis 2812637: Echtzeitreplikation wird für TDE-fähige MSSQL Server-Datenbank nicht unterstützt.
Sicherungsverschlüsselung
Die Sicherungsverschlüsselung erfolgt, wenn Sie die Sicherungsdatei verschlüsseln, während die Sicherung erstellt wird. Dabei werden alle Datenseiten in der Sicherungsdatei verschlüsselt und ein Zertifikat oder ein asymmetrischer Schlüssel erstellt, um die Sicherungsdatei wiederherzustellen, wodurch eine nicht autorisierte Wiederherstellung verhindert wird.
Wenn die Datenbank nicht mit TDE verschlüsselt ist, bevor die verschlüsselte Sicherung übernommen wird, wird sie nach der Wiederherstellung immer noch nicht verschlüsselt. Nur die Sicherungsdateien werden verschlüsselt. Die Datenbankdatei und deren Inhalt werden nicht geändert.
Sie können die Sicherungsverschlüsselung mit TDE verwenden, ist aber nicht von Vorteil, da die Daten bereits in den Datenbankdateien und in den Sicherungsdateien verschlüsselt sind. Wenn Sie die Sicherungsverschlüsselung und TDE zusammen verwenden, wird die verschlüsselte Datenbank mit dem TDE-Zertifikat oder den mit einem Schlüssel verschlüsselten Datenseiten erneut mit dem Sicherungszertifikat oder -schlüssel verschlüsselt. Diese Methode verlängert den Sicherungsprozess und erhöht während der Ausführung des Sicherungsvorgangs die CPU-Auslastung.
Sichern von SQL Server und dem SAP-System
Die Härtung (Hardening) auf Ebene von Server und Betriebssystem ist für ein sicher ausgeführtes System unerlässlich.
Beherzigen Sie die folgenden Empfehlungen, um SQL Server und Ihr SAP-System zu schützen. Weitere Informationen finden Sie im SAP-Hinweis 2417205.
SQL Server basiert auf der Windows-Implementierung des TLS-Protokolls (Transport Layer Security) und des SSL-Protokolls (Secure Sockets Layer) über den SCHANNEL Security Support Provider (SSP).
Sie können das SSL-Protokoll deaktivieren, da TLS weit verbreitet ist und zumeist unterstützt wird. Die meisten SQL Server- und SAP-Produktunterstützungen verwenden das TLS 1.2-Protokoll.
Sie können die meisten Sicherheitseinstellungen für den SCHANNEL-SSP mithilfe von Änderungen der Registrierung im entsprechenden SCHANNEL-Branch vornehmen. Mithilfe dieser Einstellungen können Sie Folgendes steuern:
- Welche Protokolle, z. B. SSL und TLS, für den Client- und Serverteil des Dialogfelds aktiviert sind.
- Die Verschlüsselungsverfahren, z. B. RC2, RC4, Triple DES und AES, die aktiviert sind, sowie deren Reihenfolge.
- Die Hashalgorithmen, z. B. MD5 und SHA.
- Die Schlüsselaustauschalgorithmen, z. B. Diffie-Hellman und ECDH.
Die verschiedenen Kombinationen dieser Teile, z. B. das Protokoll, die Verschlüsselung sowie der Hash- und Schlüsselaustauschalgorithmus, werden in Verschlüsselungssammlungen abgebildet. Wenn Sie einen dieser Teile deaktivieren (etwa das Protokoll SSL 2.0), sind alle Verschlüsselungssammlungen, die diesen Teil enthalten, für das System unbrauchbar.
Hinweis
Wenn Sie mehrere Änderungen kombinieren, können der Client, z. B. das SAP-System, und der Server, z. B. SQL Server, möglicherweise keine Verschlüsselungssammlung für die Kommunikation verwenden, und das SAP-System startet eventuell nicht.
Sie können auch die Priorität und Verfügbarkeit von Verschlüsselungssammlungen im System mithilfe des Editors für lokale Gruppenrichtlinien steuern.
- Wechseln Sie zu Lokale Computerrichtlinie > Computerkonfiguration > Administrative Vorlagen > Netzwerk > SSL-Konfigurationseinstellungen.
- Definieren Sie eine benutzerdefinierte Reihenfolge für eine SSL-Verschlüsselungssammlung.
Die Reihenfolge in dieser Liste definiert die Priorität, mit der das System Verschlüsselungssammlungen verwendet. Wenn Sie eine Verschlüsselungssammlung aus der Liste entfernen, ist sie im System nicht mehr verwendbar. Die Gruppenrichtlinieneinstellung hat Vorrang vor der SCHANNEL-Registrierungseinstellung. Die Sicherheitsabteilung steuert diese Einstellung in der Regel auf der Grundlage von Gruppenrichtlinien. Die resultierenden Verbindungsprobleme werden jedoch vom Team, das für die SAP Basis- oder SQL Server-Datenbankverwaltung zuständig ist, behandelt.
Erwägen Sie, das SAP-Tool SCoTT zu verwenden, um Probleme mit deaktivierten Protokollen oder Verschlüsselungssammlungen zu analysieren. Dieses Tool kann Verbindungsprobleme zwischen SAP-Systemen wie ABAP und Java und SQL Server analysieren, die unter Linux oder Windows ausgeführt werden. Weitere Informationen finden Sie im SAP-Hinweis 2846170.
Authentifizierung
Im Folgenden finden Sie einige Überlegungen zur Authentifizierung bei SAP in Azure.
SAP NetWeaver auf SQL Server hat spezifische Anforderungen an die SAP- und SQL Server-Startkonten, die Authentifizierung bei der SQL Server-Instanz, die SAP-Datenbank und den DBA-Zugriff. Weitere Informationen finden Sie im SAP-Hinweis 1645041: SQL Server Anmeldungen und ihre Verwendung in SAP-Umgebungen.
Das SAP ABAP NetWeaver-System erfordert keine SQL Server-Anmeldungen, da alle Verbindungen Windows-Authentifizierung verwenden. Beispielsweise können Sie für den Benutzer „
SAPService<SID>“ oder „<SID>administrator“ das Feature „SQL Server-Authentifizierung„ deaktivieren.Das SAP JAVA NetWeaver-System erfordert das SQL Server-Authentifizierungsfeature, da eine SQL Server-Anmeldung, wie
SAP<SID>DB, für die Verbindung verwendet wird.Für SAP auf SQL Server können Sie das SQL Server-Systemadministratorkonto deaktivieren, da die SAP-Systeme auf SQL Server das Konto nicht verwenden. Stellen Sie sicher, dass ein anderer Benutzer mit Systemadministratorrechten auf den Server zugreifen kann, bevor Sie das ursprüngliche Systemadministratorkonto deaktivieren.
Ein System mit Hochverfügbarkeit, das SQL Server AlwaysOn verwendet, hat spezifische Anforderungen hinsichtlich Anmeldungen, Benutzer und Aufträge. Alle Server, die mit dem System verbunden sind, müssen genau die gleichen Anmeldungen und Benutzer aufweisen, damit das SAP-System eine Verbindung herstellen kann, auch wenn ein Failover auf einen anderen Knoten auftritt. Alle SAP-bezogenen SQL Server-Aufträge müssen auf allen AlwaysOn-Knoten denselben Besitzer haben. Weitere Informationen finden Sie unter Synchronisieren von SAP-Anmeldungen, -Aufträgen und -Objekten.
Unter einer SQL-Einschleusung versteht man, dass schädlicher Code in SQL-Anweisungen zusammengeführt wird, die auf SQL Server ausgeführt werden. Wenn ein Bericht im SAP-System ausgeführt wird, generiert er generische SQL-Anweisungen aus dem ABAP-Code des Berichts. Diese Anweisungen werden an die SAP-Datenbankschicht für SQL Server gesendet und von ihr transformiert.
Diese Datenbankschicht ist in den SAP-Arbeitsprozess integriert und nicht von außen zugänglich. Nach der Transformation in SQL Server-spezifische Anweisungen werden sie an die Datenbank gesendet und ausgeführt. Das Ergebnis wird an den aufrufenden Bericht zurückgegeben. Diese Anweisungen können nur zwischen der Datenbankschicht des SAP-Systems und der SQL Server-Instanz bearbeitet werden, was als Man-in-the-Middle-Angriff bezeichnet wird.
Verwenden Sie im SAP-System verschlüsselte Verbindungen zwischen dem Arbeitsprozess und der SQL Server Datenbank, um solche Angriffe zu verhindern. Die Transaktion „
DBACockpit“ verfügt über ein rudimentäres SQL-Befehlsfenster zum Ausführen grundlegender SQL-Anweisungen. Weitere Informationen finden Sie im SAP-Hinweis 1027512: MSSQL: DBA-Cockpit für Basisversion 7.00 und höher.
Audit
Deaktivieren Sie
xp_cmdshell. Das SQL Server-Feature „xp_cmdshell“ aktiviert eine SQL Server-interne Befehlsshell für das Betriebssystem. Dies ist ein potenzielles Risiko bei Sicherheitsüberwachungen.Dieses Feature wird beim Installieren von SAP aktiviert. Es erfasst und zeigt Betriebssystemdaten in der Transaktion „
DBACockpit“ an. Wenn Sie die Einstellung deaktivieren, sind einige Überwachungsdaten in der Transaktion „DBACockpit“ nicht verfügbar, und im Meldungsfenster „DBACockpit“ wird eine Warnmeldung angezeigt. Weitere Informationen finden Sie im SAP-Hinweis 3019299: Fragen zur Sicherheitsüberwachung oder Sicherheitsanpassung in NetWeaver- und SQL Server-Systemen.Konfigurieren Sie Virenscanner ordnungsgemäß. SAP unterstützt Virenscanner zum Schutz vor Viren und anderer Schadsoftware. Ein schlecht konfigurierter Virenscanner kann aber zu Leistungsproblemen führen oder sogar die Datenbank beschädigen. Informationen zum Einrichten und Konfigurieren eines Virenscanners im Betriebssystem für ein SAP NetWeaver-System finden Sie im SAP-Hinweis 106267: Virenscannersoftware unter Windows. Legen Sie für eine SQL Server-Datenbank die passende Konfigurationen fest, um Leistungsprobleme und Beschädigungen zu vermeiden. Ausführliche Konfigurationen finden Sie unter Auswählen von Antivirensoftware für Computer, auf denen SQL Server ausgeführt wird.