Sécurité des bases de données SQL Server pour SAP sur Azure

  • Article

Cet article fait partie de la série d’articles « SAP extend and innovate security: Best practices ».

Cet article fournit des considérations et des recommandations en matière de sécurité pour SAP sur Azure qui s’exécute sur une base de données SQL Server.

Sécuriser des données au repos

Le chiffrement transparent des données (TDE) SQL Server chiffre les fichiers de données et les fichiers journaux des bases de données utilisateur et des bases de données système SQL Server. Une fois les données chiffrées, les copies des fichiers journaux et de données ou des fichiers de sauvegarde ne peuvent pas être restaurées et utilisées sans les certificats associés. Ce processus est appelé sécurisation des données au repos. Il s’agit d’une technologie transparente pour le système SAP. Elle est donc prise en charge par la note SAP 1380493 : SQL Server TDE. Pour plus d’informations sur la procédure TDE, consultez chiffrement SQL Server.

Toutes les pages de données lues ou écrites sur le disque doivent être chiffrées ou déchiffrées, de sorte que TDE est pénalisé par le processeur. Lorsque TDE est appliqué à une base de données utilisateur, l’utilisation du processeur augmente entre 3 % et 8 %. Les applications qui utilisent fortement TempDB de SQL Server ou effectuent des analyses volumineuses sur des tables volumineuses sont plus affectées. Quand au moins une base de données utilisateur sur l’instance SQL Server est chiffrée avec TDE, les bases de données système, comme TempDB, sont également chiffrées. SAP Business Warehouse (SAP BW) est un exemple de ce type d’application.

Notes

Si les clés de chiffrement ou les certificats sont perdus, les données de la base de données chiffrée sont perdues. Il est important d’établir des processus et des étapes complets pour sécuriser les sauvegardes de certificats.

Une implémentation TDE réussie nécessite des tests approfondis et des processus bien conçus pour gérer les certificats et les sauvegardes de certificats.

Fonctionnalités SQL Server non prises en charge

SQL Server offre également d’autres fonctionnalités de protection des données. Ces méthodes autorisent le chiffrement partiel ou le masquage sur la granularité des colonnes de base de données :

En fonction des restrictions de ces trois méthodes et des modifications qu’elles nécessitent sur de nombreux domaines des composants SAP NetWeaver, ces fonctionnalités ne sont pas prises en charge par SAP.

La réplication en temps réel entre une base de données compatible TDE sur SQL Server et SAP HANA n’est pas prise en charge. Pour plus d’informations, consultez la note SAP OSS 2812637 : la réplication en temps réel n’est pas prise en charge pour la base de données MSSQL Server compatible TDE.

Chiffrement de sauvegarde

Le chiffrement de sauvegarde signifie que vous chiffrez le fichier de sauvegarde pendant la sauvegarde. Il chiffre toutes les pages de données du fichier de sauvegarde et crée un certificat ou une exigence de clé asymétrique pour restaurer le fichier de sauvegarde, ce qui empêche une restauration non autorisée.

Si la base de données n’est pas chiffrée avec TDE avant la sauvegarde chiffrée, elle n’est toujours pas chiffrée après la restauration. Seuls les fichiers de sauvegarde sont chiffrés. Le fichier de base de données et son contenu ne sont pas modifiés.

Vous pouvez utiliser le chiffrement de sauvegarde avec TDE, mais cela n’est pas avantageux, car les données sont déjà chiffrées dans les fichiers de base de données et dans les fichiers de sauvegarde. Lorsque vous utilisez le chiffrement de sauvegarde et le chiffrement TDE ensemble, la base de données chiffrée avec le certificat TDE ou les pages de données chiffrées par clé sont chiffrées à nouveau avec le certificat ou la clé de sauvegarde. Cette méthode prolonge le processus de sauvegarde et ajoute une charge processeur supplémentaire au système pendant l’exécution du processus de sauvegarde.

Sécuriser SQL Server et le système SAP

Le renforcement au niveau du serveur et du système d’exploitation est essentiel pour un système en cours d’exécution sécurisé.

Respectez les recommandations suivantes pour sécuriser SQL Server et votre système SAP. Pour plus d’informations, consultez la note SAP OSS 2417205.

SQL Server est basé sur l’implémentation Windows du protocole TLS (Transport Layer Security) et du protocole SSL (Secure Sockets Layer) via le fournisseur SSP du canal S.

Vous pouvez désactiver le protocole SSL, car TLS est largement utilisé et pris en charge. La plupart des instances SQL Server et des produits SAP prennent en charge l’utilisation du protocole TLS 1.2.

Vous pouvez contrôler la plupart des paramètres de sécurité du SSP du canal S par le biais des modifications apportées au registre dans la branche du canal S correspondante. Avec ces paramètres, vous pouvez contrôler :

  • Quels protocoles, tels que SSL et TLS, sont activés pour la partie client et serveur de la boîte de dialogue.
  • Les chiffrements, par exemple RC2, RC4, Triple DES et AES, qui sont activés et l’ordre dans lequel ils sont activés.
  • Les algorithmes de hachage, par exemple MD5 et SHA.
  • Les algorithmes d’échange de clés, par exemple Diffie-Hellman et ECDH.

Les différentes combinaisons de ces parties, telles que le protocole, le chiffrement, le hachage et l’algorithme d’échange de clés, sont représentées dans des suites de chiffrement. En désactivant l’une de ces parties, par exemple le protocole SSL 2.0, toutes les suites de chiffrement qui contiennent cette partie sont inutilisables pour le système.

Notes

Lorsque vous combinez plusieurs modifications, le client, par exemple le système SAP, et le serveur, par exemple SQL Server, peuvent ne pas être en mesure d’utiliser une suite de chiffrement pour communiquer, et le système SAP peut ne pas démarrer.

Vous pouvez également contrôler la priorité et la disponibilité des suites de chiffrement sur le système dans l’éditeur de stratégie de groupe local.

  1. Accédez à Stratégie ordinateur local > Configuration ordinateur > Modèles d’administration > Réseau > Paramètres de configuration SSL.
  2. Définissez un ordre de suite de chiffrement SSL personnalisé.

Capture d’écran montrant la configuration SSL.

Cet ordre de liste définit la priorité avec laquelle le système utilise les suites de chiffrement. Si vous supprimez une suite de chiffrement de la liste, elle n’est plus utilisable dans le système. Le paramètre de stratégie de groupe a la priorité sur le paramètre de registre SCHANNEL. Le service de sécurité contrôle généralement ce paramètre en fonction des stratégies de groupe. Mais le groupe d’administration de base de données SQL Server ou SAP Basis gère les problèmes de connexion résultants.

Envisagez d’utiliser l’outil SAP, SCoTT, pour analyser les problèmes liés aux suites de chiffrement ou aux protocoles désactivés. L’outil peut analyser les problèmes de connexion entre le système SAP, comme ABAP et Java, et SQL Server qui s’exécute sur Linux ou Windows. Pour plus d’informations, consultez la note SAP 2846170.

Authentification

Voici quelques considérations relatives à l’authentification avec SAP sur Azure.

  • SAP NetWeaver sur SQL Server a des exigences spécifiques pour les comptes de démarrage SAP et SQL Server, l’authentification auprès de l’instance SQL Server, la base de données SAP et l’accès DBA. Pour plus d’informations, consultez la note SAP 1645041 : connexions SQL Server et leur utilisation dans les environnements SAP.

  • Le système SAP ABAP NetWeaver ne nécessite pas de connexions SQL Server, car toutes les connexions utilisent l’authentification Windows. Par exemple, pour l’utilisateur SAPService<SID> ou <SID>administrator, vous pouvez désactiver la fonctionnalité d’authentification SQL Server.

  • Le système SAP JAVA NetWeaver nécessite la fonctionnalité d’authentification SQL Server, car il utilise une connexion SQL Server, telle que SAP<SID>DB, pour la connexion.

  • Pour SAP sur SQL Server, vous pouvez désactiver le compte d’administrateur système SQL Server, car les systèmes SAP sur SQL Server n’utilisent pas le compte. Assurez-vous qu’un autre utilisateur disposant de droits d’administrateur système peut accéder au serveur avant de désactiver le compte d’administrateur système d’origine.

  • Un système à haute disponibilité qui utilise SQL Server AlwaysOn a des exigences spécifiques pour les connexions, les utilisateurs et les travaux. Tous les serveurs connectés au système doivent avoir exactement les mêmes connexions et utilisateurs, afin que le système SAP puisse se connecter même si un basculement vers un autre nœud se produit. Tous les travaux SQL Server liés à SAP doivent avoir le même propriétaire sur tous les nœuds AlwaysOn. Pour plus d’informations, consultez Synchroniser les connexions, les travaux et les objets SAP.

  • L’injection de code SQL se produit lorsque du code malveillant fusionne dans des instructions SQL qui s’exécutent sur SQL Server. Lorsqu’un rapport s’exécute dans le système SAP, il génère des instructions SQL génériques à partir du code ABAP du rapport. Les instructions sont envoyées et transformées par la couche de base de données SAP pour SQL Server.

    Cette couche de base de données est intégrée au processus de travail SAP et n’est pas accessible de l’extérieur. Après la transformation en instructions spécifiques à SQL Server, elles sont envoyées à la base de données et exécutées. Le résultat est retourné au rapport appelant. Ces instructions ne peuvent être manipulées qu’entre la couche de base de données du système SAP et l’instance SQL Server, ce qu’on appelle une attaque de l’intercepteur.

    Dans le système SAP, utilisez des connexions chiffrées entre le processus de travail et la base de données SQL Server pour empêcher ces attaques. La transaction DBACockpit a une fenêtre de commande SQL rudimentaire pour exécuter des instructions SQL de base. Pour plus d’informations, consultez la note SAP 1027512 : MSSQL : DBA Cockpit pour la version de base 7.00 et les versions ultérieures.

Audit

Étapes suivantes