Architecture de protection contre l’exfiltration de données
Cette page est une architecture de référence fonction par fonction pour la protection contre l'exfiltration de données au niveau du réseau sur AWS. Chaque section décrit un contrôle, comme l'identité, la gouvernance Unity Catalog, les restrictions de workspace, le monitoring et l'isolation réseau spécifique au cloud, et des liens vers son guide d'implémentation. Pour les concepts et les priorités de la couche de sécurité sous-jacents à ces contrôles, consultez la section Protection contre l'exfiltration de données.
- Pour déployer l'ensemble complet des contrôles sous la forme d'un bundle unique, utilisez le module Terraform d'architecture de référence de sécurité Databricks, qui implémente l'architecture d'environnement isolé de bout en bout. Consultez le module Terraform d'architecture de référence de sécurité AWS.
- Pour configurer les contrôles individuellement, utilisez le guide ci-dessous.
Contrôles d'identité et d'accès
Les contrôles basés sur l'identité sont la première ligne de défense contre l'exfiltration de données. Sans authentification forte et accès fiable, une identité faible compromet les contrôles au niveau du réseau.
Connexion unifiée avec SSO
Appliquez le Single Sign On (SSO) à tous les Workspace du compte Databricks en utilisant la connexion unifiée. Ceci garantit que les utilisateurs s'authentifient via votre fournisseur d'identité d'entreprise plutôt que d'utiliser des comptes personnels ou des méthodes non-SSO.
Activez l'authentification multifacteur (MFA) au sein de votre fournisseur d'identité pour une couche de vérification supplémentaire.
Voir Activer la connexion unifiée et Configurer la SSO dans Databricks.
Gestion automatisée des identités
Implémenter le provisionnement SCIM pour automatiser la gestion du cycle de vie des utilisateurs. Cela garantit que les anciens employés sont automatiquement déprovisionnés et ne peuvent plus accéder aux Workspace après leur départ.
Voir Synchroniser les utilisateurs et les groupes depuis votre fournisseur d'identité à l'aide de SCIM.
Contrôles d'accès réseau
Restreindre l'accès à la console du workspace et du compte aux réseaux de confiance :
- Listes d'accès IP au niveau du compte : contrôlent l'accès à la console du compte. Voir Configurer les listes d'accès IP pour la console du compte.
- Listes d'accès IP au niveau du Workspace : Contrôlez l'accès aux Workspace individuels. Voir Configurer les listes d'accès IP pour les Workspace.
- Connectivité privée : Utilisez PrivateLink entrant pour éliminer entièrement l'accès public au workspace. Voir configurer PrivateLink entrant pour les Workspace.
Contrôles de gouvernance des données
Les contrôles réseau empêchent les chemins de sortie non autorisés, mais les contrôles de gouvernance des données garantissent que même les ressources de compute autorisées ne peuvent accéder qu'aux destinations de données approuvées. Appliquez ces contrôles quelle que soit l'architecture de sécurité réseau que vous déployez.
Contrôle d'accès standard
Utilisez les privilèges d'Unity Catalog pour restreindre qui peut lire, écrire ou modifier chaque catalogue, schéma, table et volume. Accordez les privilèges minimaux requis pour chaque rôle et groupe.
Les privilèges sont transmis hiérarchiquement : un octroi sur un catalogue s'applique à tous les schémas et tables qu'il contient. Utilisez ceci pour appliquer des default étendues, puis affiner l'accès à des niveaux inférieurs pour les données sensibles.
Consultez Gérer les privilèges dans Unity Catalog.
Contrôle d'accès basé sur les attributs (ABAC)
L'ABAC régit l'accès aux données en fonction des étiquettes associées aux objets de données, et pas seulement de l'identité de l'objet. Utilisez l'ABAC pour appliquer des stratégies telles que « les utilisateurs ne peuvent interroger que les tables étiquetées pii=false» ou « les utilisateurs du groupe de l'UE ne peuvent pas lire les tables étiquetées region=US ».
L'ABAC s'adapte mieux que les GRANTs par objet dans les grands environnements où les conventions de tags sont déjà en place. Il s'associe également bien avec les filtres de lignes et les masques de colonnes (voir ci-dessous).
Voir Contrôle d'accès basé sur les attributs dans Unity Catalog.
Filtres de ligne et masques de colonne
Restreindre ce que les utilisateurs voient dans une table :
- Filtres de ligne : appliquez une fonction SQL qui détermine les lignes qu'un utilisateur peut interroger. Par exemple, restreignez une table de ventes afin que chaque responsable régional ne voie que les lignes de sa région.
- Masques de colonne : Appliquez une fonction SQL qui transforme la valeur d'une colonne avant qu'elle ne soit renvoyée à l'utilisateur. Par exemple, masquez les numéros de carte de crédit en
XXXX-XXXX-XXXX-1234pour les utilisateurs non financiers.
Les filtres de ligne et les masques de colonne sont évalués au moment de la query, de sorte que les utilisateurs ne peuvent pas les contourner avec SELECT *.
Consultez Filtres de lignes et masques de colonne.
Restrictions administratives d'Unity Catalog
Limitez la création d'éléments sécurisables d'accès aux données aux seuls administrateurs :
- Identifiants de stockage : Seuls les administrateurs sont autorisés à créer des identifiants de stockage. Appliquez des politiques d'accès au cloud avec le moindre privilège (rôles IAM, identités gérées) pour chaque identifiant. Voir Gérer les identifiants de stockage.
- Emplacements externes : autorisez uniquement les administrateurs à créer des emplacements externes qui sont mappés sur des chemins de stockage cloud. Consultez Gérer les emplacements externes.
- Connexions aux bases de données : seuls les administrateurs sont autorisés à créer des connexions à des bases de données externes via Lakehouse Federation. Consultez Gérer les connexions pour Lakehouse Federation.
- Identifiants de service : Permettez uniquement aux administrateurs de créer des identifiants de service pour les services cloud externes. Voir Créer des identifiants de service.
Accorder aux utilisateurs des autorisations d'utiliser des sécurisables approuvés plutôt que d'en créer de nouveaux. Cela empêche les utilisateurs de diriger le compute vers un stockage ou des endpoints non fiables.
Liaisons du Workspace pour les catalogues
Lie les catalogues Unity Catalog à des workspaces spécifiques pour empêcher l'accès aux données entre les environnements. Par exemple, empêchez les Workspace de développement de lire les données de production.
Politiques de compte de stockage
Implémentez des pare-feu ou des politiques de compartiment sur les comptes de stockage pour accepter le trafic uniquement à partir de destinations sources approuvées :
- Configurez les politiques de compartiment S3 pour n'autoriser l'accès qu'à partir du Virtual Private Cloud (VPC) Databricks ou d'endpoints VPC spécifiques. Utilisez des clés de condition pour restreindre l'accès en fonction de la source.
- Créez des rôles IAM avec des autorisations minimales et des politiques de confiance limitant les Ressources Databricks qui peuvent les assumer.
Restrictions de Workspace
Les paramètres d'administration du Workspace contrôlent les chemins de download et d'exportation des données via l'interface utilisateur de Databricks. Désactivez ces paramètres pour empêcher les utilisateurs d'extraire des données via l'interface du workspace.
Paramètre | Risque atténué |
|---|---|
Désactiver le download des résultats du notebook | Utilisateurs qui download des résultats de query sur des machines locales |
Désactiver le download des fichiers de volume | Utilisateurs téléchargeant des fichiers de volume sur des machines locales |
Désactiver l'exportation de Notebooks et de fichiers | Utilisateurs exportant des Notebooks ou des fichiers depuis le Workspace |
Désactiver le download des résultats SQL. | Utilisateurs download les résultats de requêtes SQL |
Désactiver le download d'artefacts d'exécution MLflow | Utilisateurs download des artefacts d'Experimentation MLflow |
Désactiver le presse-papiers du tableau des résultats | Utilisateurs copiant des données tabulaires dans le presse-papiers |
Configurez ces paramètres dans la console d'administration du workspace, sous les paramètres de sécurité. Veuillez consulter Gérer votre Workspace.
Monitoring et détection
Les contrôles préventifs réduisent le risque d'exfiltration de données, mais le monitoring détecte lorsque les contrôles échouent ou lorsque les attaquants les contournent.
Tables système pour le monitoring d'audit
Utilisez Surveiller les coûts à l'aide des tables système de Databricks pour surveiller les modèles d'accès aux données. La référence de table système des logs d'audit capture les événements de workspace, notamment :
- Authentification de l'utilisateur et tentatives d'accès.
- Opérations de lecture et d'écriture de données.
- Modifications de la configuration administrative.
- Utilisation des identifiants et accès aux emplacements externes.
Configurez des alertes pour les activités suspectes, telles que des volumes de données inhabituels, un accès depuis des emplacements inattendus ou des tentatives d'accès à des Ressources non autorisées.
Intégration de Logs cloud natif
Ingérez des Logs spécifiques au cloud pour compléter les tables système Databricks :
- Configurez AWS CloudTrail pour capturer les événements d'accès S3, les attributions de rôles IAM et les journaux de flux Virtual Private Cloud (VPC).
Corrélez les logs cloud natifs avec les logs d'audit Databricks pour une visibilité complète sur les mouvements de données dans votre environnement.
Architecture AWS
Isolement du réseau
Déployer Databricks dans un VPC géré par le client avec des sous-réseaux privés :
- Activez le réseau de plan de compute classique pour éliminer les adresses IP publiques.
- Configurez les groupes de sécurité pour restreindre l'égression aux destinations autorisées uniquement.
- Utilisez des tables de routage pour empêcher l'accès direct à Internet.
Connectivité privée
Établissez des connexions privées aux services AWS et au plan de contrôle Databricks :
- PrivateLink de plan de compute classique : Connectez-vous au Workspace et au relais SCC. Consultez Configurer la connectivité privée classique à Databricks.
- PrivateLink entrant : Permet l’accès utilisateur sans Internet public. Voir configurer PrivateLink entrant pour les Workspace.
- **Endpoints Virtual Private Cloud (VPC)** : Créez un endpoint de passerelle S3 (sans coût) et des endpoints d'interface pour STS et Kinesis.
- Politiques d'Endpoint Virtual Private Cloud (VPC) : Limitez l'accès uniquement aux Ressources AWS autorisées.
Contrôle de sortie
Déployez un appliance de pare-feu tiers (tel que Palo Alto) intégré à Gateway Load Balancer pour inspecter le trafic sortant :
- Configurez des règles de pare-feu pour les destinations approuvées (par exemple, PyPI, Maven et les APIs externes).
- Acheminez le trafic destiné à Internet (
0.0.0.0/0) via le pare-feu. - Acheminez le trafic du service AWS via les Endpoint Virtual Private Cloud (VPC).
Stratégies d'accès
Implémenter l'accès au moindre privilège à l'aide des stratégies IAM et de compartiment :
- Rôles IAM : créez des rôles avec des autorisations minimales et des politiques de confiance limitant les ressources Databricks qui peuvent les endosser.
- Politiques de compartiment S3 : Autorisez l'accès uniquement depuis le VPC Databricks ou des Endpoint Virtual Private Cloud (VPC) spécifiques. Utilisez des clés de condition pour restreindre l'accès en fonction de la source.
Sécurité serverless
Configurez Qu’est-ce que le contrôle des sorties serverless ? pour le contrôle des sorties de compute serverless. Définissez les destinations autorisées à l’aide de plages d’adresses IP, de FQDN ou d’Endpoint privés.
Voir aussi
-
- Architectures de référence réseau
- Architectures de sécurité réseau (gérées, renforcées, isolées).
-
- Sécurité et conformité
- Contrôles de sécurité et de conformité au-delà du réseau.