Protéger les données confidentielles dans Notebooks

Ce document suggère des contrôles et des niveaux de sécurité que vous pouvez utiliser pour protéger les données confidentielles dans Notebooks. Il fait partie d'une solution de plans composée des éléments suivants :

  • Un guide des contrôles que vous mettez en œuvre (ce document).
  • Un dépôt GitHub.

Dans ce document, les données confidentielles font référence à des informations sensibles pour accéder auxquelles un utilisateur de votre entreprise aurait besoin de niveaux de privilèges plus élevés. Ce document est destiné aux équipes qui gèrent Notebooks.

Dans ce document, nous partons du principe que vous avez déjà configuré un ensemble fondamental de contrôles de sécurité pour protéger votre déploiement d'infrastructure cloud. Le plan permet de superposer des contrôles supplémentaires sur ces contrôles de sécurité existants pour protéger les données confidentielles dans les notebooks. Pour en savoir plus sur les bonnes pratiques concernant l'intégration de la sécurité dans vos déploiements Google Cloud, consultez le guide sur les principes de sécurité de Google Cloud.

Présentation

L'application de règles de sécurité et de gouvernance des données pour protéger Notebooks avec des données confidentielles nécessite souvent d'équilibrer les objectifs suivants :

  • Aider à protéger les données utilisées par les instances de notebook en utilisant les mêmes pratiques et contrôles de sécurité et de gouvernance des données que ceux appliqués à l'ensemble de votre entreprise.
  • Garantir que les data scientists de votre entreprise ont accès aux données dont ils ont besoin pour fournir des insights pertinents.

Avant d'autoriser des data scientists de votre entreprise à accéder aux données dans Notebooks, vous devez comprendre les points suivants :

  • Comment les données transitent dans votre environnement.
  • Qui accède aux données.

Voici quelques aspects à considérer pour mieux comprendre :

  • Comment déployer votre hiérarchie de ressources Google Cloud pour isoler vos données.
  • Quels groupes IAM sont autorisés à utiliser les données de BigQuery.
  • Influence de votre stratégie de gouvernance des données sur votre environnement.

Les scripts Terraform dans le dépôt GitHub associé au plan mettent en œuvre les contrôles de sécurité décrits dans le présent document. Le dépôt contient également des exemples de données illustrant les pratiques de gouvernance des données. Pour en savoir plus sur la gouvernance des données dans Google Cloud, consultez la section Qu'est-ce que la gouvernance des données ?

Architecture

Le schéma d'architecture suivant montre la hiérarchie des projets et les ressources, telles que Notebooks et les clés de chiffrement.

Architecture du plan

Le périmètre de cette architecture est appelé la limite de confiance supérieure. Elle permet de protéger les données confidentielles utilisées dans le cloud privé virtuel (VPC). Les data scientists doivent accéder aux données via la limite de confiance supérieure. Pour en savoir plus, consultez la page VPC Service Controls.

La limite de confiance supérieure englobe toutes les ressources cloud qui interagissent avec des données confidentielles, ce qui peut vous aider à gérer vos contrôles de gouvernance des données. Les services tels que Notebooks, BigQuery et Cloud Storage ont le même niveau de confiance dans cette limite.

L'architecture crée également des contrôles de sécurité qui vous aident à effectuer les opérations suivantes :

  • Limiter le risque d'exfiltration de données à un appareil utilisé par les data scientists de votre entreprise.
  • Protéger vos instances de notebook du trafic réseau externe.
  • Limiter l'accès à la VM qui héberge les instances de notebook.

Structure organisationnelle

Resource Manager vous permet de regrouper les ressources de manière logique par projet, dossier et organisation. Le schéma suivant montre une hiérarchie de ressources avec des dossiers représentant différents environnements tels que la production ou le développement.

Hiérarchie des ressources avec les dossiers de production et de développement.

Dans votre dossier de production, vous créez un dossier qui représente votre environnement de confiance.

Vous ajoutez des règles d'administration au dossier de confiance que vous créez. Les sections suivantes décrivent comment les informations sont organisées dans le dossier, les sous-dossiers et les projets.

Dossier de confiance

Le plan vous aide à isoler les données en introduisant un nouveau sous-dossier dans votre dossier de production pour Notebooks et pour toutes les données utilisées par les instances de notebook de BigQuery. Le tableau suivant décrit les relations entre les dossiers au sein de l'organisation et répertorie les dossiers utilisés par ce plan.

Dossier Description
production Contient des projets dont les ressources cloud ont été testées et sont prêtes à être utilisées.
trusted Contient des projets et des ressources pour les instances de notebook contenant des données confidentielles. Ce dossier est un sous-dossier enfant du dossier production.

Projets au sein de l'organisation

Le plan vous aide à isoler certaines parties de votre environnement en utilisant les projets. Comme ces projets ne disposent pas d'un propriétaire de projet, vous devez créer des liaisons IAM explicites pour les groupes IAM appropriés.

Le tableau suivant décrit où créer les projets nécessaires au sein de l'organisation.

Projet Parent folder (Dossier parent) Description
trusted-kms trusted Contient des services qui gèrent la clé de chiffrement qui protège vos données (par exemple, Cloud HSM). Ce projet se trouve dans la limite de confiance supérieure.
trusted-data trusted Contient des services qui gèrent des données confidentielles (par exemple, BigQuery). Ce projet se trouve dans la limite de confiance supérieure.
trusted-analytics trusted Contient les Notebooks utilisés par les data scientists. Ce projet se trouve dans la limite de confiance supérieure.

Comprendre les contrôles de sécurité que vous appliquez

Cette section présente les contrôles de sécurité au sein de Google Cloud qui vous aident à protéger vos instances de notebook. L'approche décrite dans le présent document fait appel à plusieurs couches de contrôle pour sécuriser vos données sensibles. Nous vous recommandons d'adapter ces couches de contrôle en fonction des besoins de votre entreprise.

Configurer des règles d'administration

Le service de règles d'administration permet de configurer des restrictions sur les ressources compatibles de votre organisation Google Cloud. Vous configurez des contraintes qui sont appliquées au dossier trusted, comme décrit dans le tableau suivant. Pour plus d'informations sur les contraintes liées aux règles, consultez la section Contraintes de règles d'administration.

Contrainte de règle Description Valeur recommandée
gcp.resourceLocations (list) Définit les contraintes sur la manière dont les ressources sont déployées dans des régions particulières. Pour des valeurs supplémentaires, reportez-vous aux <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="p0QLUJkJWl022ZPF8XOpExbgk/lxGfezRLhprMa5doZN+cJCz6j1rNnG0f6zRCY5lNvENQyutzDSQoNKf6mWtw1wA7mc7xehzQW0s0VnKKA=" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">groupes de régions valides.</a{:> ["in:us-locations", "in:eu-locations"]
iam.disableServiceAccountCreation (booléen) Lorsque la valeur est true, empêche la création d'un <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="CDx+y1R+QGNLsOA+E2D9d9ou+FEz00PeI85jCLdEq5b4Kv4CQ6p1vl0x3rS9735/" track-metadata-position="body" track-name="internalLink" track-type="solution" }=""> compte de service.</a{:> true
iam.disableServiceAccountKeyCreation (booléen) Lorsque la valeur est true, empêche la création de <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="WFRYDQtmB/86VDs7PZa96dou+FEz00PeI85jCLdEq5bHy+ezA0ewJmDnHN78IEaq/uqVRhG/IldRkC2L0Y9bBQ==" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">clés de compte de service.</a{:> true
iam.automaticIamGrantsForDefaultServiceAccounts (booléen) Lorsque la valeur est true, empêche l'octroi des comptes de service par défaut à n'importe quel rôle IAM dans le projet lors de la création des comptes. true
compute.requireOsLogin (booléen) Lorsque la valeur est true, active OS Login. Pour en savoir plus, consultez <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="Mh2WvN3PzmbL/6M7AMJ+U8xdrud5wj8XJuhclBrl/6o=" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">OS Login.</a{:> true
constraints/compute.restrictProtocolForwardingCreationForTypes (liste) Limite les nouvelles règles de transfert à un usage interne uniquement. ["is:INTERNAL"]
compute.restrictSharedVpcSubnetworks (liste) Définit l'ensemble des sous-réseaux VPC partagés que les ressources éligibles peuvent utiliser. Indiquez le nom du projet contenant votre sous-réseau VPC partagé.

Remplacez le sous-réseau VPC_SUBNET par l'ID de ressource du sous-réseau privé que Notebooks doit utiliser.
["under:projects/VPC_SUBNET"]
compute.vmExternalIpAccess (liste) Définit l'ensemble des instances VM Compute Engine autorisées à utiliser des adresses IP externes. deny all=true
compute.skipDefaultNetworkCreation (booléen) Si la valeur est true, cela signifie que Google Cloud ignore la création du réseau par défaut et des ressources associées lors de la création de ressources Google Cloud. true
compute.disableSerialPortAccess (booléen) Lorsque la valeur est true, empêche l'accès via le port série aux VM Compute Engine. true
compute.disableSerialPortLogging (booléen) Lorsque la valeur est true, empêche la journalisation du port série sur Cloud Logging à partir des VM Compute Engine. true

Pour plus d'informations sur les contrôles supplémentaires des règles, consultez le guide sur les principes de base de sécurité Google Cloud.

Authentification et autorisation

Le plan permet de définir des contrôles IAM et des modèles d'accès que vous pouvez appliquer à Notebooks. Le plan vous aide à définir les modèles d'accès de différentes manières :

  • Utiliser un groupe de data scientists au niveau de confiance supérieur Les identités individuelles ne disposent pas des autorisations nécessaires pour accéder aux données.
  • Définir un rôle IAM personnalisé appelé restrictedDataViewer.
  • Appliquer le principe du moindre privilège pour restreindre l'accès à vos données.

Utilisateurs et groupes

La limite de confiance supérieure comporte deux personnages, tels que les suivants :

  • Le propriétaire des données, chargé de classer les données dans BigQuery.
  • Le data scientist approuvé, qui est autorisé à gérer les données confidentielles.

Vous devez associer ces personas à des groupes. Au lieu d'attribuer le rôle à des personas individuels, vous ajoutez une identité correspondant au persona du groupe.

Le plan vous aide à appliquer le principe du moindre privilège en définissant un mappage de type "un à un" entre les data scientists et leurs instances de notebook, de sorte que seule une identité de data scientist unique puisse accéder à l'instance de notebook. Les data scientists individuels ne disposent pas des autorisations d'éditeur pour une instance de notebook.

Le tableau affiche les informations suivantes :

  • Les personnages que vous attribuez au groupe.
  • Les rôles IAM que vous attribuez au groupe au niveau du projet.
Groupe Description Rôles Projet
data-owner@example.com Les membres sont chargés de classer et de gérer les données dans BigQuery. <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="qZGUxiLwMwSqAayYOaEAYsqqqBP4p/061BE24HsZBYzqnuNSkSxnVKwqYjVml1pv" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">roles/bigquery.dataOwner</a{:> trusted-data
trusted-data-scientist@example.com Les membres sont autorisés à accéder aux données du dossier de confiance. roles/restrictedDataViewer (personnalisé) trusted-data

Comptes de service gérés par l'utilisateur

Vous devez créer un compte de service géré par l'utilisateur que Notebooks utilisera à la place du compte de service Compute Engine par défaut. Les rôles du compte de service pour les instances de notebook sont définis dans le tableau ci-dessous.

Compte de service Description Rôles Projet
sa-p-notebook-compute@trusted-analytics.iam.gserviceaccount.com Un compte de service utilisé par Cloud AI Platform pour le provisionnement des instances de notebook
  • roles/restrictedDataViewer(personnalisé)
  • <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="qZGUxiLwMwSqAayYOaEAYsqqqBP4p/061BE24HsZBYzqnuNSkSxnVKwqYjVml1pv" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">roles/bigquery.jobUser</a{:>
  • <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="F09OE/SDdsh4rSUv6kg1NJzBt276nqedo2zyLe4cxCi9OImFy9Pn6CEbIlOwglwwkXtNx3LSV4gEFf1hFSv84Q==" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">roles/cloudkms.cryptoKeyEncrypterDecrypter</a{:>
  • roles/compute.instanceAdmin
  • roles/notebooks.viewer
trusted-analytics

Le plan vous aide également à configurer le compte de service géré par Google qui représente vos Notebooks en donnant au compte de service géré par Google l'accès aux clés de chiffrement gérées par le client (CMEK) spécifiées. Cette autorisation spécifique à la ressource applique le principe du moindre privilège à la clé utilisée par Notebooks.

Étant donné qu'aucun propriétaire n'est défini pour les projets, les data scientists ne sont pas autorisés à gérer les clés.

Rôles personnalisés

Dans le plan, vous créez un rôle personnalisé roles/restrictedDataViewer en supprimant l'autorisation d'exportation. Le rôle personnalisé est basé sur le rôle BigQuery prédéfini dataViewer, qui permet aux utilisateurs de lire des données depuis la table BigQuery. Vous attribuez ce rôle au groupe trusted-data-scientists@example.com. Le tableau suivant indique les autorisations utilisées par le rôle roles/restrictedDataViewer.

Nom de rôle personnalisé Description Autorisations
roles/restrictedDataViewer Permet aux instances de notebook situées dans la limite de confiance supérieure d'afficher les données sensibles de BigQuery.

Basé sur le roles/bigquery.dataViewer <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="qZGUxiLwMwSqAayYOaEAYsqqqBP4p/061BE24HsZBYzqnuNSkSxnVKwqYjVml1pv" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">role
sans l'exportation. (par exemple, bigquery.models.export).</a{:>
bigquery.datasets.get
bigquery.datasets.getIamPolicy
bigquery.models.getData
bigquery.models.getMetadata
bigquery.models.list
bigquery.routines.get
bigquery.routines.list
bigquery.tables.get
bigquery.tables.getData
bigquery.tables.getIamPolicy
bigquery.tables.list
resourcemanager.projects.get
resourcemanager.projects.list

Moindre privilège

Le plan vous permet d'attribuer des rôles disposant du niveau de privilèges minimum. Par exemple, vous devez configurer un mappage de type "un à un" entre une identité de data scientist unique et une instance de notebook plutôt qu'un mappage partagé avec un compte de service. Le fait de limiter les privilèges vous permet d'empêcher les data scientists d'accéder directement aux instances qui hébergent leur instance de notebook.

Accès privilégié

Les utilisateurs du groupe de data scientists au niveau de confiance supérieur, trusted-data-scientists@example.com, disposent d'un accès privilégié. Ce niveau d'accès signifie que ces utilisateurs disposent d'identités qui leur permettent d'accéder à des données confidentielles. Demandez à votre équipe de gestion des identités de fournir des clés de sécurité matérielles et d'activer la validation en deux étapes pour ces identités de data scientists.

Mise en réseau

Spécifiez un environnement VPC partagé pour vos notebooks, tel que celui défini par les scripts réseau de base de sécurité de Google Cloud.

Le réseau des instances de notebook a les propriétés suivantes :

  • Un VPC partagé utilisant un réseau restreint privé sans adresse IP externe.
  • Règles de pare-feu restrictives.
  • Un périmètre VPC Service Controls qui englobe tous les services et projets avec lesquels Notebooks interagit.
  • Une stratégie Access Context Manager

VPC partagé limité

Configurez Notebooks pour qu'il utilise le VPC partagé que vous spécifiez. Étant donné qu'OS Login est requis, votre VPC partagé minimise l'accès aux instances de notebook. Vous pouvez configurer un accès explicite pour vos data scientists à l'aide d'Identity-Aware Proxy (IAP).

Vous configurez également la connectivité privée aux API et services Google dans votre VPC partagé à l'aide du domaine restricted.googleapis.com. Cette configuration permet aux services de votre environnement de prendre en charge VPC Service Controls.

Pour obtenir un exemple de configuration de VPC partagé restreint, consultez le plan de base de sécurité Scripts Terraform de configuration du réseau.

Périmètre VPC Service Controls

Le plan vous aide à établir la limite de confiance supérieure pour votre environnement approuvé à l'aide de VPC Service Controls.

Les périmètres de service sont un contrôle au niveau de l'organisation qui vous permet de protéger les services Google Cloud dans vos projets en limitant le risque d'exfiltration de données.

Le tableau suivant décrit comment configurer votre périmètre VPC Service Controls.

Attribut Considération Valeur
projects Incluez tous les projets contenant des données accessibles par des data scientists utilisant Notebooks, y compris des clés. ["trusted-kms"
"trusted-data"
"trusted-analytics"]
services Ajoutez d'autres services si nécessaire. ["compute.googleapis.com",
"storage.googleapis.com",
"notebooks.googleapis.com",
"bigquery.googleapis.com",
"datacatalog.googleapis.com",
"dataflow.googleapis.com",
"dlp.googleapis.com",
"cloudkms.googleapis.com",
"secretmanager.googleapis.com",
"cloudasset.googleapis.com",
"cloudfunctions.googleapis.com",
"pubsub.googleapis.com",
"monitoring.googleapis.com",
"logging.googleapis.com"]
access_level Ajoutez des <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="lusaVihyw0i6CzgawuRRYyk10Dou6dGBPtPXPAqkVYhqg3ciWN7dEYftf8SKI5K5" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">règles Access Context Manager qui s'alignent sur vos besoins en sécurité et des <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="ZRmADm/vo/JQ2+/D/vUUr0WE0NcjMCq0U/gbksCiqgf1jsdW/MbrYpK1/gdk16L117PUzYIUuMKSr0A78yDcsQ==" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">règles de vérification de point de terminaison plus détaillées.</a{:></a{:> ACCESS_POLICIES
Pour en savoir plus, consultez la page <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="RD1gsl2tw43oA/PJKkk1nXjCRwUobSSsbtnFJlSTCBLjoLksm7evman24//KLCurKSqCdTDqIF3jaY3PSD/AkaFbN8pCOwuaC/vIQ9/k+Vf+HXbWtslLzKBVhXD8qB/Z" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">Access Context Manager
</a{:>

Access Context Manager

Le plan vous aide à configurer Access Context Manager avec votre périmètre VPC Service Controls. Access Context Manager vous permet de définir un contrôle d'accès précis basé sur des attributs pour les projets et les ressources. Vous utilisez la validation des points de terminaison et configurez la règle pour qu'elle soit conforme aux exigences de gouvernance de votre entreprise concernant l'accès aux données. Collaborez avec votre administrateur pour créer une règle d'accès pour les data scientists de votre entreprise.

Nous vous recommandons d'utiliser les valeurs indiquées dans le tableau suivant pour votre règle d'accès.

Condition Considération Values
ip_subnetworks Utilisez des plages d'adresses IP approuvées par votre entreprise. (liste) Les plages CIDR permettant d'accéder aux ressources du périmètre.
members Ajoutez des utilisateurs disposant de privilèges élevés qui peuvent accéder au périmètre. (liste) Identités privilégiées des data scientists et compte de service Terraform pour le provisionnement.
device_policy.require_screen_lock Le verrouillage de l'écran doit être activé sur les appareils. true
device_policy.require_corp_owned Autoriser uniquement les appareils de l'entreprise à accéder à Notebooks. true
device_policy.allowed_encryption_statuses Autoriser uniquement les data scientists à utiliser des appareils qui chiffrent les données au repos. (liste) ENCRYPTED
regions Gérez les régions depuis lesquelles les data scientists peuvent accéder à leurs instances de notebook.

Limitez-vous au plus petit ensemble de régions dans lequel vous souhaitez que vos data scientists travaillent.
<a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="8N5kFK1nMdX9Lm9PBXn1Gik10Dou6dGBPtPXPAqkVYhCA27lJ8v3AtKljasH4ygRJI82FsX3O5bO4YFtCsDjBg==" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">Codes de région valides
(list) </a{:>

Moindre privilège BigQuery

Le plan montre comment configurer l'accès aux ensembles de données BigQuery utilisés par les data scientists. Dans la configuration que vous définissez, les data scientists doivent disposer d'une instance de notebook pour accéder aux ensembles de données BigQuery.

La configuration que vous définissez vous aide également à ajouter des couches de sécurité aux ensembles de données dans BigQuery de différentes manières :

  • Accorder l'accès au compte de service de l'instance de notebook. Les data scientists doivent disposer d'une instance de notebook pour accéder directement aux ensembles de données BigQuery.
  • Atténuer le risque que les data scientists créent des copies de données qui ne répondent pas aux exigences de gouvernance des données de votre entreprise. Les data scientists qui ont besoin d'interagir directement avec BigQuery doivent être ajoutés au groupe trusted-data-scientists@example.com.

Pour offrir un accès limité à BigQuery pour les data scientists, vous pouvez également utiliser des contrôles d'accès plus précis comme la sécurité au niveau des colonnes. Le propriétaire des données doit collaborer avec les équipes de gouvernance pour créer une taxonomie appropriée. Les propriétaires de données peuvent ensuite utiliser Cloud Data Loss Prevention (Cloud DLP) pour analyser les ensembles de données afin de les classer et de leur ajouter des tags correspondant à la taxonomie.

Gestion des clés

Pour vous aider à protéger vos données, Notebooks utilisent des clés de chiffrement. Les clés sont sauvegardées par un composant Cloud HSM FIPS 140-2 de niveau 3. Les clés que vous créez dans l'environnement contribuent à protéger vos données de différentes manières :

  • Le chiffrement CMEK est activé pour tous les services situés dans la limite de confiance supérieure.
  • La disponibilité des clés peut être configurée par région.
  • La rotation des clés est configurable.
  • L'accès aux clés est limité.

CMEK

Le plan vous aide à utiliser les clés CMEK, qui vous permettent de chiffrer vos données en utilisant une clé que vous contrôlez. Votre environnement utilise la même clé CMEK pour tous les services situés dans la limite de confiance supérieure. L'utilisation des clés CMEK vous permet également de détruire la clé que vous avez utilisée pour protéger vos instances de notebook lorsque celle-ci n'est plus requise.

Disponibilité et rotation des clés

Vous pouvez bénéficier d'une disponibilité plus élevée en créant un trousseau de clés multirégional, ce qui augmente la disponibilité de vos clés.

Dans ce plan, vous créez des clés avec une valeur de rotation automatique. Pour définir la valeur de rotation, suivez les règles de sécurité définies par votre entreprise. Vous pouvez modifier la valeur par défaut pour qu'elle corresponde à votre règle de sécurité ou appliquer une rotation plus rapide des clés si nécessaire.

Le tableau suivant décrit les attributs que vous configurez pour vos clés.

Attribut Considération Values
rotation Correspond à la valeur définie par la règle de rotation de conformité de votre entreprise. 45 jours
location Utilisez un trousseau de clés qui utilise des <a{: l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="Z98fpOVAlHdfgDS3sMyCXJRrt04oQqGzq1Aef2125xKSjPY+/eF9aEsSeoGJf8A6" track-metadata-position="body" track-name="internalLink" track-type="solution" }="">emplacements multirégionaux afin d'améliorer la disponibilité.</a{:> Sélection automatique, basée sur la configuration de votre zone Notebooks.
protection level Utilisez le niveau de protection spécifié par votre entreprise. HSM

Accès à la clé

Le plan vous aide à protéger vos clés en les plaçant dans un module Cloud HSM, dans un dossier distinct de vos ressources de données. Utilisez cette approche pour les raisons suivantes :

  • Les clés de chiffrement sont nécessaires pour qu'une ressource puisse utiliser la clé.
  • Les équipes de gestion des clés doivent être distinctes des propriétaires de données.
  • Des contrôles et une surveillance supplémentaires des clés sont nécessaires. L'utilisation d'un dossier distinct vous permet de gérer les règles des clés indépendamment de vos données.

Contrôles de sécurité pour Notebooks

Les contrôles décrits dans cette section protègent les données utilisées dans Notebooks. Le plan vous aide à configurer les contrôles de sécurité du notebook AI Platform comme suit :

  • Limiter le risque d'exfiltration des données.
  • Limiter l'élévation des privilèges.

Gestion des téléchargements de données

Par défaut, les instances de notebook permettent aux data scientists de télécharger ou d'exporter des données sur leurs machines. Le script de démarrage installé par le plan vous permet d'éviter les actions suivantes :

  • Exportation et téléchargement de données vers les appareils locaux.
  • La possibilité d'imprimer des valeurs de sortie calculées par des instances de notebook.

Le script est créé dans le projet trusted_kms. Le plan vous aide à protéger le bucket qui stocke le script en limitant l'accès et en configurant les clés CMEK. Le fait de séparer les scripts du projet utilisé pour Notebooks permet également de réduire le risque d'ajout de code non approuvé aux scripts de démarrage.

Étant donné que vous configurez Notebooks pour utiliser votre sous-réseau VPC privé limité, vos instances de notebook ne peuvent pas accéder aux réseaux publics. Cette configuration empêche les data scientists d'installer des modules externes, d'accéder à des sources de données externes et d'accéder aux dépôts de code public. Au lieu de ressources externes, nous vous recommandons de configurer un dépôt d'artefacts privé (Artifact Registry par exemple) pour les data scientists de votre entreprise.

Gestion des droits

Le plan vous aide à limiter les autorisations attribuées au groupe trusted-data-scientists@example.com. Par exemple, le groupe ne dispose pas d'un rôle permettant de créer des instantanés de disques persistants car le système de fichiers local de l'instantané peut contenir des instances de notebook contenant des données de votre entreprise.

En outre, pour empêcher aux data scientists d'obtenir un accès privilégié, vous interdisez l'utilisation des commandes sudo à partir de la ligne de commande de l'instance de notebook. Cette action permet d'empêcher aux data scientists de modifier les contrôles installés dans l'instance de notebook, tels que les packages approuvés ou la journalisation.

Sécurité opérationnelle

Outre les contrôles de sécurité que vous établissez avec le plan, vous devez configurer les règles de sécurité opérationnelle suivantes pour garantir la protection continue des données dans les notebooks utilisés par votre entreprise :

  • Configuration de la journalisation et de la surveillance.
  • Règles de gestion des failles.
  • Visibilité des éléments.

Journalisation et surveillance

Une fois la hiérarchie créée, vous devez configurer les contrôles de journalisation et de détection que vous utilisez pour les nouveaux projets. Pour en savoir plus sur la configuration de ces contrôles, consultez les scripts de journalisation du plan de base de sécurité.

Gestion des failles

Les images Deep Learning VM sont régulièrement mises à jour. Nous vous recommandons de mettre à jour les images des instances de notebook existantes en suivant votre planning d'analyse des failles. Vous pouvez vérifier le résultat de l'API isUpgradeable et lancer une mise à niveau en utilisant l'API upgrade.

Visibilité des risques

Nous vous recommandons d'utiliser Security Command Center pour obtenir une visibilité sur les ressources, les failles, les risques et les règles. Security Command Center analyse votre déploiement pour évaluer votre environnement par rapport aux frameworks de conformité pertinents.

Conclusion

Pour mettre en œuvre l'architecture décrite dans ce document, procédez comme suit :

  1. Créez votre dossier et vos projets de confiance en fonction de la section Structure organisationelle.
  2. Configurez les contrôles de journalisation et de surveillance pour ces projets en fonction de votre règle de sécurité. Pour obtenir un exemple, consultez la configuration de journalisation du plan de base de la sécurité.
  3. Créez vos groupes IAM puis ajoutez les identités de vos data scientists approuvés au groupe approprié, comme décrit dans la section Utilisateurs et groupes.
  4. Configurez votre réseau avec un VPC et un sous-réseau restreints partagés, comme décrit dans la section Réseau.
  5. Créez votre règle Access Context Manager, comme décrit dans Access Context Manager.
  6. Clonez le dépôt GitHub pour ce plan.
  7. Créez le fichier de variable d'environnement Terraform à l'aide des entrées requises.
  8. Appliquez les scripts Terraform à votre environnement pour créer les contrôles décrits dans le présent plan.
  9. Vérifiez votre environnement approuvé en fonction de vos exigences en matière de sécurité et de gouvernance des données. Vous pouvez analyser les projets nouvellement créés par rapport aux frameworks de conformité de Security Command Center.
  10. Créez un ensemble de données BigQuery dans le projet trusted-data ou utilisez l'exemple fourni dans le module du dépôt GitHub data.
  11. Collaborez avec un data scientist de votre entreprise pour tester son accès à sa nouvelle instance de notebook.
  12. Dans l'environnement Notebooks, vérifiez que le data scientist peut interagir avec les données de BigQuery comme prévu. Vous pouvez exécuter l'exemple de commande BigQuery dans le dépôt GitHub associé.

Resources