Sécurité d’intégration des données pour SAP sur Azure

Article
07/27/2023

Cet article fait partie de la série d’articles « Étendre et innover des données SAP : bonnes pratiques ».

Cet article décrit les couches de sécurité pour les scénarios d’extension SAP, décompose chaque composant, et propose des considérations et des recommandations. Les ressources de gestion d’Azure Data Factory reposent sur l’infrastructure de sécurité Azure et utilisent les mesures de sécurité proposées par Azure.

La couche d’ingestion de données se compose des éléments suivants :

SAP S/4HANA, SAP BW/4HANA ou SAP HANA Édition Entreprise
Azure Data Lake Storage Gen2
Data Factory
Une machine virtuelle avec runtime d’intégration auto-hébergé (SHIR)

Le diagramme suivant est un exemple d’architecture de la sécurité de l’intégration de données SAP sur Azure. Utilisez cet exemple d’architecture comme point de départ.

Téléchargez un fichier Visio de cette architecture.

Remarques et recommandations

Les sections suivantes décrivent les considérations et les recommandations relatives à la sécurité de l’intégration de données SAP sur Azure.

Sécurité avec SAP

Le guide de sécurité avec SAP comporte des instructions détaillées pour les produits SAP.

Sécurité avec Data Lake Storage Gen2

Consultez les considérations suivantes pour la sécurité avec Data Lake Storage Gen2.

Autorisation de l’accès aux données dans le stockage Azure

Lorsque vous accédez aux données de votre compte de stockage, votre application cliente envoie une requête sur HTTP/HTTPS au Stockage. Par défaut, chaque ressource de Stockage est sécurisée, et chaque requête à une ressource sécurisée doit être autorisée. Le Stockage offre de nombreuses options pour autoriser l’accès aux données. Nous recommandons d’utiliser les informations d’identification Microsoft Entra pour autoriser les requêtes de données pour une sécurité et une simplicité optimales. Pour plus d’informations, consultez la section Protéger vos clés d’accès.

Contrôle d’accès en fonction du rôle Azure (RBAC)

Utilisez RBAC pour gérer les autorisations d’un principal de sécurité pour les ressources Blob, File d’attente et Table dans un compte de stockage. Vous pouvez également utiliser le contrôle d’accès basé sur les attributs (ABAC) Azure pour ajouter des conditions aux attributions de rôle Azure pour les ressources Blob. Pour plus d’informations, consultez la section Autoriser l’accès au Stockage Blob Azure à l’aide des conditions d’attribution de rôle Azure.

Sécurité avec le stockage Blob

Tenez compte des recommandations de sécurité pour le stockage Blob, comme la protection des données, la gestion des identités et des accès, la mise en réseau, la journalisation et la surveillance. Pour plus d’informations, consultez la section Recommandations de sécurité pour le stockage Blob.

Contrôle d’accès Data Lake Storage Gen2

Data Lake Storage Gen2 prend en charge les stratégies d’autorisation suivantes :

RBAC
Listes ACL
Groupes de sécurité
Autorisation de clé partagée et de signature d’accès partagé (SAP)

Data Lake Storage Gen2 propose deux types de listes de contrôle d’accès :

Les ACL d’accès contrôlent l’accès à un objet. Les fichiers et les répertoires ont des ACL d’accès.
Les listes de contrôle d’accès par défaut sont des modèles d’ACL associées à un répertoire. Elles déterminent les ACL d’accès pour tous les éléments enfants créés dans ce répertoire. Les fichiers n’ont pas de listes de contrôle d’accès par défaut.

Dans une entrée d’ACL, n’attribuez pas directement d’utilisateurs individuels ni de principaux de service. Utilisez toujours les groupes de sécurité Microsoft Entra comme principal attribué. Cela vous permet d’ajouter et de supprimer des utilisateurs ou des principaux de service sans devoir appliquer de nouveau les ACL à l’ensemble de la structure de répertoire. Au lieu de cela, vous pouvez ajouter ou supprimer des utilisateurs et des principaux de service dans le groupe de sécurité Microsoft Entra approprié. Pour plus d’informations, consultez la section Listes de contrôle d’accès.

Sécurité avec Data Factory

Consultez les considérations suivantes pour la sécurité avec Data Factory.

Déplacement des données

Il existe deux scénarios de déplacement de données : un premier cloud et un second hybride. Pour plus d’informations sur les considérations de sécurité pour le déplacement des données, consultez la section Considérations de sécurité relatives au déplacement des données.

Dans le scénario cloud, votre source et votre destination sont toutes deux accessibles publiquement sur Internet. La source ou la destination peut être un service de stockage cloud géré (comme le Stockage Azure, Azure Synapse Analytics, Azure SQL Database, Data Lake Storage Gen2, Amazon S3, Amazon Redshift), un service SaaS (Software-as-a-Service) (comme Salesforce) ou un protocoles web [comme FTP (File Transfer Protocol) et OData (Open Data Protocol)]. Recherchez une liste complète des sources de données prises en charge dans la section « Magasins de données et formats pris en charge ».
Dans le scénario hybride, la source ou la destination se trouve derrière un pare-feu ou à l’intérieur d’un réseau d’entreprise local. Sinon, le magasin de données est un réseau privé ou virtuel qui n’est pas accessible publiquement. Dans ce cas, le magasin de données est généralement la source. Le scénario hybride comprend également des serveurs de base de données hébergés sur des machines virtuelles.

Stratégies d’accès aux données

Votre organisation souhaite protéger ses magasins de données (magasins de données locaux ou cloud/SaaS, par exemple) contre tout accès non autorisé sur Internet. Vous pouvez contrôler l’accès à votre magasin de données cloud à l’aide des éléments suivants :

Liaison privée d’un réseau virtuel à des sources de données avec point de terminaison privé.
Règles de pare-feu qui limitent la connectivité par adresse IP.
Stratégies d’authentification qui obligent les utilisateurs à prouver leur identité.
Stratégies d’autorisation qui restreignent les utilisateurs à certaines actions et données.

Pour plus d’informations, consultez la section Stratégies d’accès aux données.

Informations d’identification dans Azure Key Vault

Vous pouvez stocker les informations d’identification des magasins de données et des calculs dans un coffre Key Vault. Data Factory récupère les informations d’identification lors de l’exécution d’une activité qui utilise le magasin de données ou le calcul. Pour plus d’informations, consultez la section Stocker les informations d’identification dans Key Vault et Utiliser des secrets Key Vault dans les activités de pipeline.

Chiffrer des informations d’identification

Dans Data Factory, envisagez de chiffrer les informations d’identification des magasins de données locaux. Sur une machine avec SHIR, vous pouvez chiffrer et stocker des informations d’identification pour vos magasins de données locaux (services liés avec informations sensibles, par exemple). Pour plus d’informations, consultez la section Chiffrer des informations d’identification pour vos magasins de données locaux dans Azure Data Factory.

Utiliser une identité managée

Lorsque vous utilisez une identité managée, vous n’avez pas à gérer les informations d’identification. Une identité managée fournit une identité à l’instance de service quand elle se connecte à des ressources qui prennent en charge l’authentification Microsoft Entra. Deux types d’identités managées sont prises en charge : les identités managées attribuées par le système et les identités managées attribuées par l’utilisateur. Pour plus d’informations, consultez la section Identité managée pour Azure Data Factory.

Chiffrer avec des clés gérées par le client

Selon vos stratégies de sécurité, envisagez de chiffrer Data Factory avec des clés gérées par le client. Pour plus d’informations, consultez la section Chiffrer Azure Data Factory avec des clés gérées par le client.

Utiliser un réseau virtuel managé

Quand vous créez un runtime d’intégration Azure au sein d’un réseau virtuel managé Data Factory, ce runtime est provisionné avec le réseau virtuel managé. Il utilise des points de terminaison privés pour se connecter de manière sécurisée aux magasins de données pris en charge. Un point de terminaison privé est une adresse IP privée au sein d’un réseau et d’un sous-réseau virtuels spécifiques. Le réseau virtuel managé est uniquement pris en charge dans la même région que celle de Data Factory. Pour plus d’informations, consultez la section Réseau virtuel managé Azure Data Factory.

Utiliser Azure Private Link

Lorsque vous utilisez Private Link, vous pouvez vous connecter aux déploiements PaaS (platform as a service) dans Azure avec un point de terminaison privé. Pour obtenir la liste des déploiements PaaS prenant en charge Private Link, consultez la section Azure Private Link pour Azure Data Factory.

Sécurité et connexions aux machines virtuelles avec SHIR

Consultez les considérations relatives à la connexion et à la sécurité des machines virtuelles avec SHIR ci-dessous.

Informations d’identification des banques de données locales

Vous pouvez stocker les informations d’identification d’un magasin de données local dans Data Factory ou les référencer avec Data Factory pendant le runtime depuis Key Vault. Si vous stockez des informations d’identification dans Data Factory, chiffrez-les toujours sur un SHIR. Pour plus d’informations, consultez la section Informations d’identification des magasins de données locaux.

Configurer un SHIR en fonction de la configuration réseau

Pour le déplacement de données hybrides, le tableau suivant récapitule les recommandations de configuration du réseau et du SHIR selon différentes combinaisons d’emplacements source et de destination.

Source	Destination	Configuration réseau	Installation du runtime d’intégration
Local	Machines virtuelles et services cloud déployés au sein de réseaux virtuels	VPN IPSec (de point à site ou de site à site)	Installez un SHIR sur une machine virtuelle Azure dans le réseau virtuel
Local	Machines virtuelles et services cloud déployés au sein de réseaux virtuels	Azure ExpressRoute (peering privé)	Installez un SHIR sur une machine virtuelle Azure dans le réseau virtuel
Local	Services Azure disposant d’un point de terminaison public	ExpressRoute (peering Microsoft)	Installer un SHIR en local ou sur une machine virtuelle Azure

ExpressRoute ou VPN IPSec

Les images suivantes décrivent comment utiliser un SHIR pour déplacer des données entre une base de données locale et un service Azure avec le réseau virtuel Azure et ExpressRoute ou un VPN IPSec.

Pour connaître les configurations de pare-feu et de liste d’autorisation pour les adresses IP, consultez la section Considérations de sécurité relatives au déplacement des données dans Azure Data Factory.

Ce diagramme décrit comment déplacer des données avec le peering privé ExpressRoute :

Ce diagramme décrit comment déplacer des données avec un VPN IPSec :

Dans le pare-feu, vérifiez que l’adresse IP de la machine avec SHIR est correctement autorisée et configurée. Les magasins de données cloud suivants exigent que vous autorisiez l’adresse IP de la machine avec SHIR. Par défaut, il est possible que certains de ces magasins de données ne requièrent pas la liste d’autorisation.

SQL Database
Azure Synapse Analytics
Data Lake Storage Gen2
Azure Cosmos DB
Amazon Redshift

Pour plus d’informations, consultez la section Considérations de sécurité relatives au déplacement des données dans Azure Data Factory et Créer et configurer un runtime d’intégration auto-hébergé.

Sécurité avec Azure Databricks

Consultez les considérations suivantes pour la sécurité avec Azure Databricks.

Base de référence de sécurité Azure pour Azure Databricks

Consultez la section Base de référence de sécurité Azure pour Azure Databricks. Cette base de référence de sécurité applique les recommandations du point de référence de sécurité du cloud Microsoft version 1.0 à Azure Databricks. Le point de référence de sécurité du cloud Microsoft fournit des recommandations sur la façon dont vous pouvez sécuriser vos solutions cloud sur Azure.

Sécurité avec Azure Synapse Analytics

Azure Synapse Analytics implémente une architecture de sécurité multicouche pour une protection de bout en bout de vos données. Il existe cinq couches :

Protection des données pour identifier et classifier les données sensibles, et chiffrer les données au repos et en mouvement. Pour obtenir des recommandations sur la détection, la classification, la gouvernance et le chiffrement des données, consultez la section Protection des données.
Contrôle d’accès pour déterminer le droit d’un utilisateur à interagir avec les données. Azure Synapse Analytics prend en charge un large éventail de fonctionnalités qui permet de contrôler qui peut accéder aux données. Pour plus d’informations, consultez Contrôle d’accès.
Authentification pour prouver l’identité des utilisateurs et des applications. L’audit Azure SQL permet de journaliser les activités d’authentification. Un administrateur informatique peut configurer des rapports et des alertes à chaque tentative de connexion depuis un lieu suspect. Pour en savoir plus, consultez Authentification.
Sécurité réseau pour isoler le trafic réseau avec des points de terminaison privés et des réseaux privés virtuels. De nombreuses options de sécurité réseau permettent de sécuriser Azure Synapse Analytics. Pour plus d’informations, consultez la section Sécurité réseau.
Protection contre les menaces pour identifier les menaces de sécurité potentielles, par exemple les lieux d’accès inhabituels, les attaques par injection de code SQL, les attaques liées à l’authentification, etc. Pour plus d’informations, consultez Détection des menaces.

Couche de présentation des données

Étudiez la façon dont vous pouvez utiliser les fonctionnalités de sécurité pour défendre la couche de présentation, y compris Power BI. Pour plus d’informations, consultez la section Sécurité dans Power BI et Planification de l’implémentation de Power BI : Sécurité.