Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Points à noter concernant la sécurité

Cette page présente les considérations de sécurité pour Google Cloud NetApp Volumes. Ces considérations incluent la protection du réseau, le contrôle des accès et le chiffrement des données.

Considérations de sécurité pour la mise en réseau

Google Cloud NetApp Volumes fournit un framework architectural protégé avec les couches de sécurité isolées suivantes :

Sécurité au niveau du projet : couche de sécurité administrative utilisée par les administrateurs pour gérer les ressources NetApp Volumes telles que les pools de stockage ou les volumes à l'aide de la console Google Cloud , du Google Cloud SDK ou des API. Les rôles et autorisations IAM protègent cette couche. Pour en savoir plus sur la sécurité au niveau du projet, consultez Configurer les autorisations IAM.
Sécurité au niveau du réseau : couche réseau utilisée pour accéder aux volumes de données avec les protocoles de stockage en réseau (NAS) (Server Message Block (SMB) et Network File System (NFS)).

Vous pouvez accéder aux données des volumes à l'aide de protocoles NAS via un réseau de cloud privé virtuel (VPC). L'accès aux données des NetApp Volumes n'est possible que via votre VPC, sauf si vous utilisez explicitement une solution tierce pour remplacer le routage de l'appairage de VPC vers vos VPC.

Dans le VPC, vous pouvez limiter davantage l'accès à l'aide de pare-feu et en configurant des mécanismes de contrôle des accès spécifiques aux protocoles.

Règles de pare-feu pour l'accès aux volumes

Les règles de pare-feu protègent le Google Cloud VPC. Pour autoriser l'accès des clients à NetApp Volumes, vous devez autoriser un trafic réseau spécifique.

Pour en savoir plus sur les règles de pare-feu pour l'accès aux volumes NFS, SMB et iSCSI, consultez les sections suivantes :

Règles de pare-feu pour l'accès à Active Directory

NetApp Volumes a besoin d'accéder aux ports suivants sur les serveurs DNS configurés dans votre stratégie Active Directory pour identifier les contrôleurs de domaine Active Directory. NetApp Volumes utilise des recherches DNS pour la découverte des contrôleurs de domaine Active Directory.

ICMPV4
DNS 53 TCP
DNS 53 UDP

Ouvrez les ports suivants sur tous vos contrôleurs de domaine Active Directory pour le trafic provenant de la plage CIDR de NetApp Volumes :

ICMPV4
LDAP 389 TCP
SMB over IP 445 TCP
Secure LDAP 636 TCP
Kerberos 464 TCP
Kerberos 464 UDP
Kerberos 88 TCP
Kerberos 88 UDP

Pour spécifier une plage source pour vos pare-feu, utilisez la plage CIDR complète que vous avez fournie lors de la configuration de l'accès privé aux services. Pour en savoir plus, consultez Configurer l'accès aux services privés.

Associer un tag de pare-feu aux serveurs Active Directory

Suivez les instructions ci-dessous pour associer le tag de pare-feu à vos serveurs Active Directory.

Associez la règle de pare-feu à vos serveurs DNS Active Directory :

gcloud compute firewall-rules create netappvolumes-to-dns \
  --allow=icmp,TCP:53,UDP:53 \
  --direction=ingress \
  --target-tags=allow-netappvolumes-to-dns \
  --source-ranges=NETAPP_VOLUMES_CIDR \
  --network=VPC_NAME

Associez la règle de pare-feu à vos contrôleurs de domaine Active Directory :

gcloud compute firewall-rules create netappvolumes-to-activedirectory \
  --allow=icmp,TCP:88,UDP:88,TCP:389,TCP:445,TCP:464,UDP:464,TCP:636 \
  --direction=ingress \
  --target-tags=allow-netappvolumes-to-activedirectory \
  --source-ranges=NETAPP_VOLUMES_CIDR \
  --network=VPC_NAME

Remplacez les informations suivantes :

NETAPP_VOLUMES_CIDR : CIDR NetApp Volumes
VPC_NAME : nom du VPC.

Associez le tag suivant à vos serveurs DNS :
```
allow-netappvolumes-to-dns
```
Associez le tag suivant à vos contrôleurs de domaine :
```
allow-netappvolumes-to-activedirectory
```

Contrôles des accès aux volumes pour les protocoles NFS

NetApp Volumes protège l'accès par protocoles NFS avec une seule règle d'exportation comportant jusqu'à 20 règles d'exportation. Les règles d'exportation sont des listes d'adresses IPv4 et de CIDR IPv4 séparées par des virgules, qui spécifient les clients autorisés à monter des volumes. NetApp Volumes évalue les règles d'exportation dans l'ordre séquentiel et s'arrête après la première correspondance. Pour obtenir les meilleurs résultats, nous vous recommandons de classer les règles d'exportation de la plus spécifique à la plus générique. Pour en savoir plus sur les règles d'exportation, consultez Contrôle de l'contrôle des accès à l'aide de règles d'exportation.

Contrôles d'accès aux volumes pour le protocole SMB

SMB utilise des autorisations au niveau du partage pour protéger l'accès aux volumes et exige une authentification auprès d'Active Directory. Ces autorisations vous permettent de contrôler qui a accès aux partages sur le réseau.

Les volumes sont créés avec des autorisations au niveau du partage Tout le monde et Contrôle total. Vous pouvez modifier les autorisations au niveau du partage à l'aide de la console Windows ou de la CLI Windows.

Suivez les instructions ci-dessous pour modifier les autorisations au niveau du partage SMB à l'aide de la console Windows ou de la CLI Windows :

Console Windows

Effectuez un clic droit sur l'icône Démarrer de Windows, puis sélectionnez Gestion de l'ordinateur.
Une fois la console Gestion de l'ordinateur ouverte, cliquez sur Action > Se connecter à un autre ordinateur.
Dans la boîte de dialogue Sélectionner un ordinateur, saisissez le nom NetBIOS de votre partage SMB, puis cliquez sur OK.
Une fois connecté au partage de fichiers, accédez à Outils système > Dossiers partagés > Partages pour rechercher votre partage.
Double-cliquez sur Nom du partage, puis sélectionnez l'onglet Autorisations de partage pour contrôler les autorisations du partage.

CLI Windows

Ouvrez une ligne de commande Windows.

Connectez-vous au partage de fichiers.

fsmgmt.msc /computer=<netbios_name_of_share>

Une fois connecté au partage de fichiers, accédez à Outils système > Dossiers partagés > Partages pour rechercher votre partage.
Double-cliquez sur Nom du partage, puis sélectionnez l'onglet Autorisations de partage pour contrôler les autorisations du partage.

Contrôles des accès aux volumes pour le protocole iSCSI

L'accès à iSCSI NetApp Volumes est géré à l'aide de groupes d'hôtes, qui sont des objets régionaux contenant un ou plusieurs IQN d'initiateur iSCSI. Un initiateur iSCSI est généralement un système client ou un serveur qui se connecte à des cibles de stockage sur un réseau à l'aide du protocole iSCSI.

Lorsqu'un volume iSCSI est créé, il est associé à un groupe d'hôtes. Cette relation accorde l'accès au volume iSCSI aux clients iSCSI (initiateurs) de ce groupe d'hôtes, ce qui leur permet de découvrir le LUN et de consommer la ressource de stockage. Seuls les initiateurs membres du groupe hôte peuvent afficher le volume iSCSI attribué et s'y connecter.

Voici les principales caractéristiques des groupes d'hôtes et de l'accès iSCSI :

Contrôle de la visibilité : les groupes d'hôtes limitent les clients iSCSI qui peuvent afficher et accéder à des volumes spécifiques. Si un initiateur ne fait pas partie d'un groupe hôte, il ne peut pas découvrir ni se connecter au LUN.
Champ d'application régional : les groupes d'hôtes sont des objets régionaux dont la configuration et les membres sont limités à une région spécifique de votre environnementGoogle Cloud .
Sécurité côté client : alors que les groupes d'hôtes contrôlent la visibilité des volumes, l'administrateur du client iSCSI est responsable de l'implémentation des contrôles d'accès au niveau de l'utilisateur sur le système client. Cela inclut la gestion des utilisateurs autorisés à installer le volume iSCSI et à accéder au système de fichiers créé sur celui-ci.

Autorisations du système de fichiers basées sur l'hôte

Une fois qu'une LUN est mappée à un hôte, le système d'exploitation de l'hôte est responsable de la gestion des autorisations du système de fichiers et des contrôles d'accès. Par exemple, les hôtes Windows utilisent les autorisations et les LCA NTFS, tandis que les hôtes Linux et UNIX utilisent les autorisations de fichier UNIX standards et, éventuellement, les LCA pour protéger les fichiers et les répertoires.

Cette approche de sécurité à deux niveaux permet de s'assurer que seuls les hôtes autorisés peuvent accéder au stockage au niveau des blocs, tandis que le système d'exploitation hôte gère la sécurité au niveau des fichiers conformément aux règles de l'organisation.

Contrôle des accès aux fichiers

Les sections suivantes fournissent des informations sur le contrôle des accès au niveau des fichiers NetApp Volumes.

Style de sécurité du volume

NetApp Volumes propose deux styles de sécurité pour les volumes, UNIX et NTFS, afin de s'adapter aux différents ensembles d'autorisations des plates-formes Linux et Windows.

UNIX : les volumes configurés avec le style de sécurité UNIX utilisent des bits de mode UNIX et des LCA NFSv4 pour contrôler l'accès aux fichiers.
NTFS : les volumes configurés avec le style de sécurité NTFS utilisent des ACL NTFS pour contrôler l'accès aux fichiers.

Le style de sécurité du volume dépend du protocole choisi pour le volume :

Type de protocole	Style de sécurité du volume
NFSv3	UNIX
NFSv4.1	UNIX
Les deux (NFSv3 et NFSv4.1)	UNIX
PME	NTFS
Double (SMB et NFSv3)	UNIX ou NTFS
Double (SMB et NFSv4.1)	UNIX ou NTFS

Pour les doubles protocoles, vous ne pouvez choisir le style de sécurité que lors de la création du volume.

Contrôle des accès au niveau des fichiers NFS pour les volumes de type UNIX

Une fois qu'un client a installé un volume, NetApp Volumes vérifie les autorisations d'accès aux fichiers et aux répertoires à l'aide du modèle d'autorisation UNIX standard appelé bits de mode. Vous pouvez définir et modifier les autorisations à l'aide de chmod.

Les volumes NFSv4.1 peuvent également utiliser des listes de contrôle des accès (LCA) NFSv4. Si un fichier ou un répertoire comporte à la fois des bits de mode et une LCA NFSv4, la LCA est utilisée pour vérifier les autorisations. Il en va de même pour les volumes qui utilisent les types de protocoles NFSv3 et NFSv4.1. Vous pouvez définir et modifier les ACL NFSv4 à l'aide de nfs4_getfacl et nfs4_setfacl.

Lorsque vous créez un volume de type UNIX, root:root est propriétaire de l'inode racine et dispose des autorisations 0770. En raison de ce paramètre de propriété et d'autorisation, un utilisateur non racine reçoit une erreur permission denied lorsqu'il accède au volume après le montage. Pour permettre aux utilisateurs non racine d'accéder au volume, un utilisateur racine doit modifier la propriété de l'inode racine à l'aide de chown et modifier les autorisations d'accès aux fichiers à l'aide de chmod.

Contrôle des accès aux fichiers SMB pour les volumes de type NTFS

Pour les volumes de type NTFS, nous vous recommandons d'utiliser un modèle d'autorisation NTFS. Chaque fichier et répertoire possède une liste de contrôle d'accès NTFS que vous pouvez modifier à l'aide de l'Explorateur de fichiers, de l'outil de ligne de commande icacls ou de PowerShell. Dans le modèle d'autorisation NTFS, les nouveaux fichiers et dossiers héritent des autorisations de leur dossier parent.

Mappage des utilisateurs multiprotocole

Pour les volumes à double protocole, les clients peuvent utiliser NFS et SMB pour accéder aux mêmes données. Un volume est configuré en définissant son style de sécurité sur les autorisations UNIX ou NTFS.

Lorsque vous créez un volume SMB et NFS à double protocole, nous vous recommandons vivement qu'Active Directory contienne un utilisateur par défaut. L'utilisateur par défaut est utilisé lorsqu'un client NFS envoie un appel NFS avec un ID utilisateur qui n'est pas disponible dans Active Directory. NetApp Volumes tente ensuite de rechercher un utilisateur appelé pcuser, qui sert d'utilisateur UNIX par défaut. Si cet utilisateur n'est pas trouvé, l'accès à l'appel NFS est refusé.

Nous vous recommandons de créer un utilisateur par défaut dans Active Directory avec les attributs suivants :

uid = pcuser
uidnumber = 65534
cn = pcuser
gidNumber = 65534
objectClass = user

Selon le protocole utilisé par le client (NFS ou SMB) et le style de sécurité du volume (UNIX ou NTFS), NetApp Volumes peut vérifier directement les autorisations d'accès de l'utilisateur ou nécessite d'abord de mapper l'utilisateur à l'identité de l'autre plate-forme.

Protocole d'accès	Style de sécurité	Identité utilisée par le protocole	Mappage obligatoire
NFSv3	UNIX	ID utilisateur et ID de groupe	N/A
NFSv3	NTFS	ID utilisateur et ID de groupe	ID utilisateur vers nom d'utilisateur vers identifiant de sécurité
PME	UNIX	Identifiant de sécurité	Identifiant de sécurité vers nom d'utilisateur vers ID utilisateur
PME	NTFS	Identifiant de sécurité	N/A

Lorsque le mappage est requis, NetApp Volumes s'appuie sur les données stockées dans Active Directory LDAP. Pour en savoir plus, consultez Cas d'utilisation d'Active Directory.

Scénario de mappage d'utilisateur multiprotocole : accès SMB à un volume UNIX

Scientifique Charlie E. (charliee) souhaite accéder à un volume NetApp Volumes à l'aide de SMB depuis un client Windows. Étant donné que le volume contient des résultats générés par une machine fournis par un cluster de calcul Linux, il est configuré pour stocker les autorisations UNIX.

Le client Windows envoie un appel SMB au volume. L'appel SMB contient l'identité de l'utilisateur sous forme d'identificateur de sécurité. L'identifiant de sécurité n'est pas comparable aux autorisations de fichier d'ID utilisateur et d'ID de groupe, et nécessite un mappage.

Pour effectuer le mappage requis, NetApp Volumes procède comme suit :

NetApp Volumes demande à Active Directory de résoudre l'identifiant de sécurité en nom d'utilisateur, par exemple, S-1-5-21-2761044393-2226150802-3019316526-1224 en charliee.
NetApp Volumes demande à Active Directory de renvoyer l'ID utilisateur et l'ID de groupe pour charliee.
NetApp Volumes vérifie l'accès en fonction de l'ID utilisateur et de l'ID de groupe du propriétaire du fichier à l'aide de l'ID utilisateur et de l'ID de groupe renvoyés.

Scénario de mappage d'utilisateurs multiprotocole : accès NFS à un volume NTFS

L'ingénieur Amal L. doit accéder à des données sur un volume à partir d'un client Linux à l'aide de NFS. Comme le volume est principalement utilisé pour stocker des données Windows, il est configuré avec le style de sécurité NTFS.

Le client Linux envoie un appel NFS à NetApp Volumes. L'appel NFS contient des identifiants d'ID utilisateur et d'ID de groupe qui ne peuvent pas être mis en correspondance avec un identifiant de sécurité sans mappage.

Pour effectuer le mappage requis, NetApp Volumes demande à Active Directory le nom d'utilisateur de l'ID utilisateur et de renvoyer l'identifiant de sécurité du nom d'utilisateur. Il vérifie ensuite l'accès par rapport à l'identifiant de sécurité du propriétaire du fichier consulté à l'aide de l'identifiant de sécurité renvoyé.

Chiffrement des données en transit

Le chiffrement en transit protège les données contre l'interception sur un réseau. Le trafic pour la réplication de volumes, la sauvegarde intégrée et la migration de volumes est chiffré par défaut à l'aide de TLS 1.2. Pour le trafic NFS et SMB, vous pouvez configurer des paramètres de chiffrement spécifiques au protocole pour une protection renforcée.

NFS

Pour les volumes NFS, utilisez NFSv4.1 avec le chiffrement Kerberos krb5p activé pour une sécurité maximale.

PME

Pour les volumes SMB, activez le chiffrement AES dans votre stratégie Active Directory et le chiffrement SMB sur votre volume pour une sécurité maximale.

Réplication de volume

NetApp Volumes peut répliquer des volumes dans plusieurs régions Google Cloud pour assurer la protection des données. Étant donné que le trafic réside dans Google Cloud, l'infrastructure réseau de Google protège le processus de transfert, dont l'accès est limité pour empêcher toute interception non autorisée. De plus, le trafic de réplication est chiffré à l'aide des normes TLS 1.2 conformes à la norme FIPS 140-2.

Sauvegarde intégrée

Une sauvegarde intégrée crée des sauvegardes de NetApp Volumes dans le service. Le trafic de sauvegarde reste dans l'infrastructure réseau de Google et est chiffré à l'aide de la norme TLS 1.2 conforme à la norme FIPS 140-2. Les coffres de sauvegarde peuvent stocker ces sauvegardes à l'aide de Google-managed encryption key par défaut ou d'une clé de chiffrement gérée par le client (CMEK) pour plus de sécurité.

Migration de volume

La migration de volumes envoie des données depuis le système ONTAP ou Cloud Volumes ONTAP source vers NetApp Volumes. La communication entre le système source et NetApp Volumes est chiffrée à l'aide des normes TLS 1.2 conformes à FIPS 140-2.

NetApp Volumes lance la migration et utilise les protocoles et ports suivants :

ICMP
10000/TCP
11104/TCP
11105/TCP

Assurez-vous que tout pare-feu entre l'interface logique intercluster (LIF) de votre système ONTAP et l'adresse IP de migration de NetApp Volumes autorise ces ports.

Étapes suivantes

Sécurisez les volumes NetApp avec un périmètre de service.