Points à noter concernant la sécurité

Cette page présente les considérations de sécurité concernant Google Cloud NetApp Volumes.

Points à prendre en compte concernant la sécurité du réseau

Google Cloud NetApp Volumes fournit un framework architectural sécurisé 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 des 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, Network-Attached Storage) (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)

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 :

• Debian/Ubuntu

• SuSE

• RedHat

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.

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.

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

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.

1. 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

2. 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.

3. Associez le tag suivant à vos serveurs DNS :

   allow-netappvolumes-to-dns

4. 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 de meilleurs résultats, nous vous recommandons de classer les règles d'exportation de la plus spécifique à la plus générique.

Utilisez les onglets suivants pour examiner les règles en fonction des versions de NFS :

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 :

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 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 la forme d'un 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 :

1. 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.

2. NetApp Volumes demande à Active Directory de renvoyer l'ID utilisateur et l'ID de groupe pour charliee.

3. 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 à 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é 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

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 Google Cloud régions pour assurer la protection des données. Comme le trafic réside dans Google Cloud, le processus de transfert est sécurisé, car il utilise l'infrastructure réseau de Google, 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 des NetApp Volumes dans le service. Le trafic de sauvegarde reste dans l'infrastructure réseau sécurisée de Google, qui utilise le chiffrement standard TLS 1.2 conforme à la norme FIPS 140-2. De plus, les coffres de sauvegarde stockent ces sauvegardes à l'aide de Google-owned and Google-managed encryption key pour une sécurité renforcée.

Migration de volume

La migration de volumes envoie des données du 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.