Dela via

SQL Server-databassäkerhet för SAP i Azure

  • Artikel

Den här artikeln är en del av artikelserien "SAP extend and innovate security: Best practices".

Den här artikeln innehåller säkerhetsöverväganden och rekommendationer för SAP på Azure som körs på en SQL Server-databas.

Skydda vilande data

SQL Server transparent datakryptering (TDE) krypterar data och loggfiler för användardatabaser och SQL Server-systemdatabaser. När den har krypterats kan kopior av data och loggfiler eller säkerhetskopieringsfiler inte återställas och användas utan de associerade certifikaten. Den här processen kallas för att skydda vilande data. Det är en transparent teknik för SAP-systemet som stöds av SAP Note 1380493 – SQL Server TDE. Information om TDE-proceduren finns i SQL Server-kryptering.

Alla datasidor som läs- eller skrivs till disken måste krypteras eller dekrypteras, så TDE har en CPU-påföljd. När TDE tillämpas på en användardatabas ökar CPU-användningen mellan 3 % och 8 %. Program som använder TempDB för SQL Server eller utför stora genomsökningar på stora tabeller påverkas mer. När minst en användardatabas på SQL Server-instansen krypteras med TDE krypteras även systemdatabaserna, till exempel TempDB. SAP Business Warehouse (SAP BW) är ett exempel på den här typen av program.

Kommentar

Om krypteringsnycklarna eller certifikaten går förlorade går data i den krypterade databasen förlorade. Det är viktigt att upprätta omfattande processer och steg för att skydda certifikatsäkerhetskopiorna.

En lyckad TDE-implementering kräver bra och grundlig testning och väl utformade processer för att hantera certifikat och säkerhetskopior av certifikat.

SQL Server-funktioner som inte stöds

SQL Server erbjuder även andra funktioner för dataskydd. Dessa metoder tillåter partiell kryptering eller maskering på databaskolumnens kornighet:

Baserat på begränsningarna för dessa tre metoder och de ändringar som krävs på många områden av SAP NetWeaver-komponenterna stöds inte dessa funktioner av SAP.

Realtidsreplikering mellan en TDE-aktiverad databas på SQL Server och SAP HANA stöds inte. Mer information finns i SAP OSS-anmärkning 2812637 – Realtidsreplikering stöds inte för TDE-aktiverad MSSQL Server-databas.

Kryptering av säkerhetskopiering

Säkerhetskopieringskryptering är när du krypterar säkerhetskopieringsfilen medan säkerhetskopieringen görs. Den krypterar alla datasidor i säkerhetskopian och skapar ett certifikat eller ett asymmetriskt nyckelkrav för att återställa säkerhetskopian, vilket förhindrar en obehörig återställning.

Om databasen inte krypteras med TDE innan den krypterade säkerhetskopieringen tas krypteras den fortfarande inte efter återställningen. Endast säkerhetskopieringsfilerna krypteras. Databasfilen och dess innehåll ändras inte.

Du kan använda kryptering för säkerhetskopiering med TDE, men det är inte fördelaktigt eftersom data redan är krypterade i databasfilerna och i säkerhetskopieringsfilerna. När du använder kryptering för säkerhetskopiering och TDE tillsammans krypteras den krypterade databasen med TDE-certifikatet eller nyckelkrypterade datasidor igen med säkerhetskopieringscertifikatet eller nyckeln. Den här metoden förlänger säkerhetskopieringsprocessen och lägger till extra CPU-belastning i systemet medan säkerhetskopieringsprocessen körs.

Skydda SQL Server- och SAP-system

Härdning på server- och operativsystemnivå är viktiga för ett säkert system som körs.

Följ följande rekommendationer för att skydda SQL Server och ditt SAP-system. Mer information finns i SAP OSS-2417205.

SQL Server baseras på Windows-implementeringen av TLS-protokollet (Transport Layer Security) och SSL-protokollet (Secure Sockets Layer) via SCHANNEL Security Support Provider (SSP).

Du kan inaktivera SSL-protokollet eftersom TLS används i stor utsträckning och stöds. Merparten av SQL Server- och SAP-produktsupporten använder TLS 1.2-protokollet .

Du kan styra de flesta säkerhetsinställningarna för SCHANNEL SSP via registerändringar i motsvarande SCHANNEL-gren. Med de här inställningarna kan du styra:

  • Vilka protokoll, som SSL och TLS, är aktiverade för klient- och serverdelen av dialogrutan.
  • Chiffer, till exempel RC2, RC4, Triple DES och AES, som är aktiverade och den ordning som de är aktiverade.
  • Hash-algoritmerna, till exempel MD5 och SHA.
  • Algoritmerna för nyckelutbyte, till exempel Diffie-Hellman och ECDH.

De olika kombinationerna av dessa delar, till exempel protokollet, chiffer- och hash- och nyckelutbytesalgoritmen, representeras i chiffersviter. När du inaktiverar en av dessa delar, till exempel protokoll-SSL 2.0, är alla chiffersviter som innehåller den här delen oanvändbara för systemet.

Kommentar

När du kombinerar flera ändringar kanske klienten, till exempel SAP-systemet, och servern, till exempel SQL Server, inte kan använda en chiffersvit för att kommunicera, och SAP-systemet kanske inte startar.

Du kan också styra prioriteten och tillgängligheten för chiffersviter i systemet i den lokala grupprincipredigeraren.

  1. Gå till Datorkonfiguration för lokal datorKonfiguration > > Administrativa mallar Nätverks-SSL-konfigurationsinställningar > > .
  2. Definiera en anpassad SSL-chiffersvitordning.

Skärmbild som visar SSL-konfigurationen.

Den här listordningen definierar den prioritet som systemet använder chiffersviter. Om du tar bort en chiffersvit från listan kan den inte längre användas i systemet. Grupprincipinställningen har prioritet framför registerinställningen SCHANNEL. Säkerhetsavdelningen styr vanligtvis den här inställningen baserat på grupprinciper. Men sap-bas- eller SQL Server-databasadministrationsgruppen hanterar de resulterande anslutningsproblemen.

Överväg att använda SAP-verktyget SCoTT för att analysera problem med inaktiverade protokoll eller chiffersviter. Verktyget kan analysera anslutningsproblem mellan SAP-systemet, till exempel ABAP och Java, och SQL Server som körs på Linux eller Windows. Mer information finns i SAP-2846170.

Autentisering

Här följer några överväganden för autentisering med SAP i Azure.

  • SAP NetWeaver på SQL Server har specifika krav för SAP- och SQL Server-startkontona, autentisering till SQL Server-instansen, SAP-databasen och DBA-åtkomsten. Mer information finns i SAP Note 1645041 – SQL Server-inloggningar och deras användning i SAP-miljöer.

  • SAP ABAP NetWeaver-systemet kräver inte SQL Server-inloggningar eftersom alla anslutningar använder Windows-autentisering. För användaren SAPService<SID> eller <SID>administratorkan du till exempel inaktivera SQL Server-autentiseringsfunktionen.

  • SAP JAVA NetWeaver-systemet kräver SQL Server-autentiseringsfunktionen eftersom den använder en SQL Server-inloggning, till exempel SAP<SID>DB, för anslutningen.

  • För SAP på SQL Server kan du inaktivera SQL Server-systemadministratörskontot eftersom SAP-systemen på SQL Server inte använder kontot. Se till att en annan användare med systemadministratörsbehörighet kan komma åt servern innan du inaktiverar det ursprungliga systemadministratörskontot.

  • Ett system med hög tillgänglighet som använder SQL Server AlwaysOn har specifika krav för inloggningar, användare och jobb. Alla servrar som är anslutna till systemet måste ha exakt samma inloggningar och användare, så ATT SAP-systemet kan ansluta även om en redundansväxling sker till en annan nod. Alla SAP-relaterade SQL Server-jobb måste ha samma ägare på alla AlwaysOn-noder. Mer information finns i Synkronisera SAP-inloggningar, jobb och objekt.

  • SQL-inmatning är när skadlig kod slås samman med SQL-instruktioner som körs på SQL Server. När en rapport körs i SAP-systemet genererar den allmänna SQL-instruktioner från RAPPORTENs ABAP-kod. -instruktionerna skickas till och transformeras av SAP-databaslagret för SQL Server.

    Det här databasskiktet är integrerat i SAP-arbetsprocessen och är inte tillgängligt utifrån. Efter omvandlingen till SQL Server-specifika instruktioner skickas de till databasen och körs. Resultatet returneras till den anropande rapporten. Dessa instruktioner kan bara ändras mellan databasskiktet i SAP-systemet och SQL Server-instansen, som kallas för en man-in-the-middle-attack.

    I SAP-systemet använder du krypterade anslutningar mellan arbetsprocessen och SQL Server-databasen för att förhindra dessa attacker. Transaktionen DBACockpit har ett rudimentärt SQL-kommandofönster för att köra grundläggande SQL-instruktioner. Mer information finns i SAP Note 1027512 – MSSQL: DBA-cockpit för basversion 7.00 och senare.

Audit

Nästa steg