Share via

SQL Server databassäkerhet för SAP på 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

Den 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äkerhetskopierade filer 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, så den 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 disk 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, t.ex. TempDB. SAP Business Warehouse (SAP BW) är ett exempel på den här typen av program.

Anteckning

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äldesignade processer för att hantera certifikat och säkerhetskopior av certifikat.

Funktioner i SQL Server stöds inte

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

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

Realtidsreplikering mellan en TDE-aktiverad databas på SQL Server och SAP HANA stöds inte. Mer information finns i SAP OSS-anteckning 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 obehörig återställning.

Om databasen inte krypteras med TDE innan den krypterade säkerhetskopieringen tas krypteras den fortfarande inte efter återställningen. Endast de säkerhetskopierade filerna 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äkerhetskopiorna. När du använder kryptering av säkerhetskopior 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äkerhetskopieringen körs.

Skydda SQL Server och SAP-system

Härdning på server- och operativsystemnivå är avgörande 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-anteckning 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 ofta 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, t.ex. 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 i vilken ordning 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 protokoll, chiffer och hash- och nyckelutbytesalgoritm, representeras i chiffersviter. Genom att inaktivera 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.

Anteckning

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 redigeraren för lokala grupprinciper.

  1. Gå till Lokal datorprincip > Datorkonfiguration > Administrativa mallar > Nätverksinställningar > för SSL-konfiguration.
  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 Basis 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 i Linux eller Windows. Mer information finns i SAP-2846170.

Autentisering

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

  • SAP NetWeaver på SQL Server har specifika krav för SAP- och SQL Server-startkonton, 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 funktionen SQL Server autentisering.

  • SAP JAVA NetWeaver-systemet kräver funktionen SQL Server autentisering eftersom det 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å SAP-systemet kan ansluta även om en redundansväxling till en annan nod inträffar. 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 sammanfogas 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 databaslagret ä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 manipuleras mellan databaslagret 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 den SQL Server databasen för att förhindra dessa attacker. Transaktionen DBACockpit har ett elementä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.

Granska

Nästa steg