Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Établissez un environnement d’exécution contrôlé, régissez la sortie des données et appliquez le privilège minimum tout en activant l’accès secret sécurisé.
Point de terminaison privé managé (MPE)
Scénario : Vous êtes ingénieur données travaillant avec des données sensibles dans Fabric Spark. Votre équipe de sécurité a besoin d’exécuter tous les codes dans un environnement isolé réseau pour renforcer la sécurité.
Activer un réseau virtuel managé (VNets). Pour activer les réseaux virtuels managés, consultez la documentation publique. Microsoft Fabric crée et gère des réseaux virtuels managés pour chaque espace de travail Fabric. Ils fournissent une isolation réseau pour les charges de travail Fabric Spark, ce qui signifie que Microsoft Fabric déploie les clusters de calcul dans un réseau dédié par espace de travail, les supprimant du réseau virtuel partagé.
En production, utilisez des réseaux virtuels managés pour l’exécution sécurisée des notebooks Spark.
Lorsque vous créez un point de terminaison privé managé (MPE), il est créé au niveau de l’espace de travail par défaut.
Lorsque vous activez Private Link (PL) au niveau du locataire, le système active les réseaux virtuels managés pour tous les espaces de travail du locataire. Après avoir activé le paramètre PL, le système crée un réseau virtuel managé pour l’espace de travail lorsque vous exécutez le premier travail Spark (notebook ou définitions de travaux Spark). Le système crée également le réseau virtuel lorsque vous effectuez une opération Lakehouse, telle que charger dans une table ou une opération de maintenance de table (optimisation ou nettoyage).
Note
Lorsque vous activez des réseaux virtuels managés, les pools de démarrage deviennent indisponibles, car ils s’exécutent dans un réseau partagé.
Protection de l’accès sortant de l’espace de travail (OAP WS)
Scénario : vous êtes préoccupé par le fait que quelqu’un peut écrire accidentellement des données de production dans des destinations non autorisées à l’aide de notebooks Spark et que vous souhaitez le contrôler.
Activer la protection d’accès sortant de l’espace de travail (WS OAP). Cela garantit que la connectivité Internet sortante de Spark ne passe qu’aux destinations approuvées via des points de terminaison privés managés.
- Blocage des bibliothèques publiques : cela bloque également l’installation des bibliothèques publiques (à partir de PyPi, Maven, etc.). Par conséquent, vous devez empaqueter vos bibliothèques en tant que fichiers JAR ou Wheel et charger des bibliothèques personnalisées dans l’environnement ou vers des ressources et installer avec % pip install à l’intérieur des notebooks. Notez que si vous l’ajoutez aux ressources et que vous l’installez avec l’installation inline %pip, le temps de publication de l’environnement est inférieur. Cela est utile pour le développement et les tests rapides. Pour réutiliser les packages dans différents notebooks, il est recommandé de les publier dans un environnement. Une autre méthode consiste à se connecter à votre référentiel privé. Pour plus d’informations, consultez la documentation relative à la protection d’accès sortant de l’espace de travail pour les charges de travail d’ingénierie des données
Scénario : Devez-vous activer WS OAP dans les environnements de développement ?
Envisagez de ne pas activer WS OAP dans les espaces de travail de développement ou inférieurs, car il a un impact sur le processus de développement. Une fois que les définitions de Notebook ou de travail Spark (SJD) sont testées avec des bibliothèques publiques, testez le même Notebook avec des bibliothèques personnalisées. Après les révisions de code appropriées, déployez dans des environnements plus élevés, puis activez WS OAP. Si vous souhaitez protéger même l’environnement de développement, vous pouvez activer le protocole OAP WS, mais cela peut entraver le processus de développement. Les pools de démarrage ne sont pas disponibles lorsque vous activez le protocole OAP WS.
Accès à Azure Key Vault (AKV) à partir de Notebook
Scénario : vous êtes ingénieur données et vous souhaitez vous connecter à plusieurs sources de données à l’aide d’informations d’identification sécurisées à partir de Notebooks Spark.
Stockez les informations d’identification de manière sécurisée dans Azure Key Vault (AKV). Ne conservez pas un coffre de clés unique pour stocker tous les secrets. Utilisez plutôt plusieurs coffres de clés basés sur des projets/domaines si possible.
Accès à Azure Key Vault (AKV) à partir de Notebook
Réseau: Nous vous recommandons de protéger votre AKV avec des règles de pare-feu pour autoriser l’accès uniquement à partir de réseaux connus. Toutefois, vous autorisez les adresses IP de Fabric Spark dans vos règles de pare-feu. Pour vous connecter en toute sécurité à des AKV protégés depuis des notebooks Fabric Spark, nous vous recommandons de créer un point de terminaison privé managé vers AKV. Un AKV ne peut prendre en charge que jusqu’à 64 points de terminaison privés (limites, quotas et contraintes d’abonnement Azure).
Authentification: Le système exécute Fabric Spark Notebooks et SJDs dans le cadre de l’utilisateur qui envoie les travaux/Notebooks. Pour accéder à AKV, l’utilisateur soumis doit disposer d’un accès suffisant pour récupérer le secret (« Agent des secrets Key Vault »). Reportez-vous aux bonnes pratiques AKV : Accordez l’autorisation aux applications d’accéder à un coffre de clés Azure à l’aide d’Azure RBAC.
- Vous pouvez utiliser notebookutils (précédemment appelé mssparkutils) pour accéder à AKV à l’aide des informations d’identification de l’utilisateur exécutant le notebook/SJD :
notebookutils.credentials.getSecret('<AKV URL>', 'Secret Name')En production, nous vous déconseillons de fournir à l’utilisateur l’accès aux AKVs dans l’environnement prod. Utilisez plutôt des comptes de service pour accéder à votre coffre de clés (KV). Envoyez les notebooks/travaux à l’aide du compte de service.
Dans certains cas, le compte de service qui soumet le travail a accès à lire des secrets depuis AKV.
Dans certains cas, ce compte de service est généralement un compte DevOps qui pourrait ne pas avoir accès pour lire les secrets depuis l'Azure Key Vault (AKV). Dans de tels cas, le générateur d'informations d'identification est utile pour accéder à l'Azure Key Vault en utilisant un autre Nom de Principal de Service (SPN).
Voici l’exemple d’extrait de code Scala :
val clientSecretCredential: ClientSecretCredential = new ClientSecretCredentialBuilder()
.clientId("<client id here>")
.clientSecret("<client secret here>")
.tenantId("<tenant id here>")
.build()
val secretClient: SecretClient = new SecretClientBuilder()
.vaultUrl("<vault url here>")
.credential(clientSecretCredential)
.buildClient()
val secretName = "<your value>"
val retrievedSecret = secretClient.getSecret(secretName)
println(s"Retrieved secret: ${retrievedSecret.getValue}")
Note
Ne codez pas en dur les secrets ou les mots de passe en texte brut dans votre code. Utilisez toujours un coffre sécurisé (comme Azure Key Vault) pour stocker et récupérer vos secrets.