Cette page a été traduite par l'API Cloud Translation.

Points à noter concernant la sécurité

Cette page présente les considérations de sécurité concernant 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.

Points à prendre en compte concernant la sécurité du 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 , de 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 cloud privé virtuel. L'accès aux données 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.

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

NFS utilise différents ports pour communiquer entre le client et un serveur. Pour assurer une communication appropriée et des montages de volumes réussis, vous devez activer les ports sur vos pare-feu.

NetApp Volumes fait office de serveur NFS et expose les ports réseau requis pour NFS. Assurez-vous que vos clients NFS sont autorisés à communiquer avec les ports NetApp Volumes suivants :

111 TCP/UDP portmapper
635 TCP/UDP mountd
2049 TCP/UDP nfsd
4045 TCP/UDP nlockmgr (pour NFSv3 uniquement)
4046 TCP/UDP status (pour NFSv3 uniquement)
3260 TCP iSCSI

Les adresses IP des NetApp Volumes sont automatiquement attribuées à partir de la plage CIDR que vous avez attribuée au service lors de l'appairage réseau. Pour en savoir plus, consultez Choisir un CIDR.

Utilisation du verrouillage consultatif avec NFSv3

Si vous utilisez des verrous consultatifs avec NFSv3, vous devez exécuter le daemon rpc.statd sur votre client pour prendre en charge Network Lock Manager, qui est une fonctionnalité qui fonctionne en coopération avec NFS pour fournir un verrouillage de fichier et d'enregistrement consultatif de style System V sur le réseau. Votre client NFS doit ouvrir un port d'entrée pour rpc.statd afin de recevoir les rappels Network Lock Manager. Dans la plupart des distributions Linux, rpc.statd démarre lorsque vous installez le premier partage NFS. Il utilise un port aléatoire que vous pouvez identifier à l'aide de la commande rpcinfo -p. Pour que rpc.statd soit plus compatible avec les pare-feu, configurez-le pour qu'il utilise un port statique.

Pour définir des ports statiques pour rpc.statd, consultez les ressources suivantes :

Si vous n'utilisez pas les verrous consultatifs NFSv3 ni le gestionnaire de verrous réseau, nous vous recommandons de monter vos partages NFSv3 avec l'option de montage nolock.

NFSv4.1 implémente la fonction de verrouillage au sein du protocole NFSv4.1 lui-même, qui s'exécute sur la connexion TCP initiée par le client au serveur NFSv4.1 sur le port 2049. Le client n'a pas besoin d'ouvrir les ports de pare-feu pour le trafic entrant.

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

SMB utilise différents ports pour communiquer entre le client et un serveur. Pour assurer une communication appropriée, vous devez activer les ports sur vos pare-feu.

NetApp Volumes agit en tant que serveur SMB et expose les ports réseau requis par SMB. Assurez-vous que votre client SMB est autorisé à communiquer avec les ports NetApp Volumes suivants :

445 TCP SMB2/3
135 TCP msrpc et 40001 TCP SMB CA : utilisés uniquement pour les partages SMB 3.x à disponibilité continue. Ces ports ne sont pas requis pour les partages non disponibles en continu.

Le service expose le port 139/TCP, mais ne l'utilise pas.

Vos clients PME n'ont pas besoin d'exposer les ports d'entrée pour que SMB fonctionne.

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 pour 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

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
```

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

Pour l'accès iSCSI, NetApp Volumes utilise des ports réseau spécifiques pour permettre la communication entre les initiateurs (clients) et les cibles (volumes de stockage). Pour que la connectivité soit correcte et que l'accès aux volumes de stockage par blocs soit possible, vous devez configurer vos pare-feu pour autoriser les ports nécessaires.

Assurez-vous que vos initiateurs iSCSI peuvent communiquer avec le port NetApp Volumes suivant :

3260 TCP : port cible iSCSI

Contrôles d'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 de 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 d'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 d'utiliser 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 LCA 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 et 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 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 à certaines données d'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é pour le 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 au sein du 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.