Share via

sicurezza del database SQL Server per SAP in Azure

  • Articolo

Questo articolo fa parte della serie di articoli "Sap extend andnova security: Best practices".

Questo articolo fornisce considerazioni sulla sicurezza e consigli per SAP in Azure in esecuzione in un database SQL Server.

Proteggere i dati inattivi

Il SQL Server Transparent Data Encryption (TDE) crittografa i file di dati e di log per i database utente e SQL Server database di sistema. Dopo la crittografia, le copie dei file di dati e di log o dei file di backup non possono essere ripristinate e usate senza i certificati associati. Questo processo viene chiamato protezione dei dati inattivi. Si tratta di una tecnologia trasparente per il sistema SAP, quindi è supportata dalla nota SAP 1380493- SQL Server TDE. Per informazioni sulla procedura TDE, vedere crittografia SQL Server.

Tutte le pagine di dati lette o scritte su disco devono essere crittografate o decrittografate, in modo che TDE abbia una penalità della CPU. Quando TDE viene applicato a un database utente, l'utilizzo della CPU aumenta tra il 3% e l'8%. Le applicazioni che usano pesantemente TempDB di SQL Server o eseguono analisi di grandi dimensioni su tabelle di grandi dimensioni sono più interessate. Quando almeno un database utente nell'istanza di SQL Server viene crittografato con TDE, vengono crittografati anche i database di sistema, ad esempio TempDB. SAP Business Warehouse (SAP BW) è un esempio di questo tipo di applicazione.

Nota

Se le chiavi di crittografia o i certificati vengono persi, i dati nel database crittografato andranno persi. È importante stabilire processi e passaggi completi per proteggere i backup dei certificati.

Un'implementazione TDE riuscita richiede un test accurato e accurato e processi ben progettati per gestire i certificati e i backup dei certificati.

Funzionalità di SQL Server non supportate

SQL Server offre anche altre funzionalità per la protezione dei dati. Questi metodi consentono la crittografia parziale o la maschera sulla granularità delle colonne del database:

In base alle restrizioni di questi tre metodi e alle modifiche richieste in molte aree dei componenti SAP NetWeaver, queste funzionalità non sono supportate da SAP.

La replica in tempo reale tra un database abilitato per TDE in SQL Server e SAP HANA non è supportata. Per altre informazioni, vedere la nota sap OSS 2812637: la replica in tempo reale non è supportata per il database MSSQL Server abilitato per TDE.

Crittografia dei backup

La crittografia del backup è quando si crittografa il file di backup durante l'esecuzione del backup. Crittografa tutte le pagine di dati nel file di backup e crea un certificato o un requisito di chiave asimmetrica per ripristinare il file di backup, che impedisce un ripristino non autorizzato.

Se il database non è crittografato con TDE prima dell'esecuzione del backup crittografato, non viene comunque crittografato dopo il ripristino. Vengono crittografati solo i file di backup. Il file di database e il relativo contenuto non vengono modificati.

È possibile usare la crittografia di backup con TDE, ma non è utile perché i dati sono già crittografati nei file di database e nei file di backup. Quando si usa la crittografia di backup e TDE insieme, il database crittografato con il certificato TDE o le pagine di dati con crittografia della chiave vengono crittografate di nuovo con il certificato o la chiave di backup. Questo metodo prolungare il processo di backup e aggiunge un carico cpu aggiuntivo al sistema durante l'esecuzione del processo di backup.

Proteggere SQL Server e sistema SAP

La protezione avanzata a livello di server e sistema operativo è essenziale per un sistema in esecuzione sicuro.

Attenersi alle raccomandazioni seguenti per proteggere SQL Server e il sistema SAP. Per altre informazioni, vedere la nota sap OSS 2417205.

SQL Server si basa sull'implementazione di Windows del protocollo Transport Layer Security (TLS) e del protocollo SSL (Secure Sockets Layer) tramite il provider di supporto per la sicurezza SCHANNEL.

È possibile disabilitare il protocollo SSL perché TLS è ampiamente usato e supportato. La maggior parte dei prodotti SQL Server e SAP usa il protocollo TLS 1.2.

È possibile controllare la maggior parte delle impostazioni di sicurezza per il provider di servizi condivisi SCHANNEL tramite le modifiche del Registro di sistema nel ramo SCHANNEL corrispondente. Con queste impostazioni, è possibile controllare:

  • Quali protocolli, ad esempio SSL e TLS, sono abilitati per la parte client e server del dialogo.
  • Le crittografie, ad esempio RC2, RC4, Triple DES e AES, abilitate e l'ordine in cui sono abilitati.
  • Algoritmi hash, ad esempio MD5 e SHA.
  • Algoritmi di scambio delle chiavi, ad esempio Diffie-Hellman ed ECDH.

Le varie combinazioni di queste parti, ad esempio il protocollo, la crittografia e l'algoritmo di scambio di chiavi e hash, sono rappresentate in suite di crittografia. Disabilitando una di queste parti, ad esempio il protocollo SSL 2.0, tutti i pacchetti di crittografia che contengono questa parte non sono utilizzabili per il sistema.

Nota

Quando si combinano più modifiche, il client, ad esempio il sistema SAP e il server, ad esempio SQL Server, potrebbero non essere in grado di usare una suite di crittografia per comunicare e il sistema SAP potrebbe non essere avviato.

È anche possibile controllare la priorità e la disponibilità dei pacchetti di crittografia nel sistema nell'editor criteri di gruppo locale.

  1. Passare a Criteri computer locali Configurazione computer > Modelli >> amministrativi Impostazioni di configurazione SSL di rete > .
  2. Definire un ordine personalizzato della suite di crittografia SSL.

Screenshot che mostra la configurazione SSL.

Questo ordine di elenco definisce la priorità utilizzata dal sistema per i pacchetti di crittografia. Se si rimuove una suite di crittografia dall'elenco, non è più utilizzabile nel sistema. L'impostazione di Criteri di gruppo ha priorità rispetto all'impostazione del Registro di sistema SCHANNEL. Il reparto sicurezza controlla in genere questa impostazione in base ai criteri di gruppo. Sap Basis o SQL Server gruppo di amministrazione del database gestisce tuttavia i problemi di connessione risultanti.

Prendere in considerazione l'uso dello strumento SAP SCoTT per analizzare i problemi relativi a protocolli o pacchetti di crittografia disabilitati. Lo strumento consente di analizzare i problemi di connessione tra il sistema SAP, ad esempio ABAP e Java, e SQL Server in esecuzione in Linux o Windows. Per altre informazioni, vedere la nota SAP 2846170.

Authentication

Ecco alcune considerazioni per l'autenticazione con SAP in Azure.

  • SAP NetWeaver in SQL Server presenta requisiti specifici per gli account di avvio SAP e SQL Server, l'autenticazione all'istanza di SQL Server, al database SAP e all'accesso DBA. Per altre informazioni, vedere sap note 1645041 - SQL Server account di accesso e il relativo utilizzo in ambienti SAP.

  • Il sistema SAP ABAP NetWeaver non richiede SQL Server account di accesso perché tutte le connessioni usano autenticazione di Windows. Ad esempio, per l'utente SAPService<SID> o <SID>administrator, è possibile disabilitare la funzionalità di autenticazione SQL Server.

  • Il sistema SAP JAVA NetWeaver richiede la funzionalità di autenticazione SQL Server perché usa un account di accesso SQL Server, ad esempio SAP<SID>DB, per la connessione.

  • Per SAP in SQL Server, è possibile disabilitare l'account amministratore di sistema SQL Server perché i sistemi SAP in SQL Server non usano l'account. Assicurarsi che un altro utente con diritti di amministratore di sistema possa accedere al server prima di disabilitare l'account amministratore di sistema originale.

  • Un sistema a disponibilità elevata che usa SQL Server AlwaysOn ha requisiti specifici per account di accesso, utenti e processi. Tutti i server connessi al sistema devono avere gli stessi account di accesso e gli stessi utenti, in modo che il sistema SAP possa connettersi anche se si verifica un failover in un altro nodo. Tutti i processi di SQL Server correlati a SAP devono avere lo stesso proprietario in tutti i nodi AlwaysOn. Per altre informazioni, vedere Sincronizzare account di accesso, processi e oggetti SAP.

  • SQL injection si verifica quando il codice dannoso viene unito in istruzioni SQL eseguite in SQL Server. Quando un report viene eseguito nel sistema SAP, genera istruzioni SQL generiche dal codice ABAP del report. Le istruzioni vengono inviate e trasformate dal livello di database SAP per SQL Server.

    Questo livello di database è integrato nel processo di lavoro SAP e non è accessibile dall'esterno. Dopo la trasformazione in istruzioni specifiche di SQL Server, vengono inviate al database ed eseguite. Il risultato viene restituito al report chiamante. Queste istruzioni possono essere modificate solo tra il livello di database del sistema SAP e l'istanza di SQL Server, denominata attacco man-in-the-middle.

    Nel sistema SAP usare connessioni crittografate tra il processo di lavoro e il database SQL Server per evitare questi attacchi. La DBACockpit transazione ha una finestra di comando SQL rudimentale per eseguire istruzioni SQL di base. Per altre informazioni, vedere nota SAP 1027512 - MSSQL: cockpit DBA per la versione 7.00 e successive.

Audit

Passaggi successivi