Points à noter concernant la sécurité

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

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

Google Cloud NetApp Volumes fournit un framework d'architecture 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 les autorisations IAM protègent cette couche. Pour en savoir plus sur la sécurité au niveau du projet, consultez la section 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 VPC. L'accès aux données de NetApp Volumes n'est possible que via votre VPC, sauf si vous utilisez explicitement une solution tierce pour remplacer le routage d'appairage 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 au protocole.

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

Les règles de pare-feu protègent le VPC Google Cloud . 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 l'installation correcte des volumes, vous devez activer les ports sur vos pare-feu.

NetApp Volumes agit en tant que 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 la section 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, une fonctionnalité qui fonctionne en coopération avec le NFS pour fournir un style System V de verrouillage de fichiers et d'enregistrement consultatifs sur le réseau. Votre client NFS doit ouvrir un port d'entrée pour que rpc.statd reçoive les rappels du Gestionnaire de verrouillage réseau. 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 de verrous consultatifs NFSv3 ni de gestionnaire de verrouillage réseau, nous vous recommandons d'installer vos partages NFSv3 avec l'option d'installation nolock.

NFSv4.1 implémente la fonction de verrouillage dans le 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 disponibles en permanence. Ces ports ne sont pas nécessaires pour les partages non disponibles en continu.

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

Les adresses IP de 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 la section 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

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

  • DNS 53 TCP

  • DNS 53 UDP

  • LDAP 389 TCP

  • LDAP 389 UDP

  • LDAP (GC) 3268 TCP

  • SAM/LSA 445 TCP

  • SAM/LSA 445 UDP

  • Secure LDAP 636 TCP

  • Secure LDAP 3269 TCP

  • W32Time 123 UDP

  • AD Web Svc 9389 TCP

  • Kerberos 464 TCP

  • Kerberos 464 UDP

  • Kerberos 88 TCP

  • Kerberos 88 UDP

Associer un tag de pare-feu à des serveurs Active Directory

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

  1. Associez le tag de pare-feu à vos serveurs Active Directory:

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

    Remplacez les informations suivantes:

    • NETAPP_VOLUMES_CIDR: le CIDR NetApp Volumes

    • VPC_NAME: nom du VPC

  2. Associez la balise suivante à 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 les protocoles NFS avec une seule stratégie d'exportation avec 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 une virgule 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 NFS:

NFS sans Kerberos

Toutes les versions NFS sans Kerberos utilisent la variante de sécurité AUTH_SYS. Dans ce mode, vous devez gérer étroitement les règles d'exportation pour n'autoriser que les clients de confiance qui peuvent garantir l'intégrité des ID utilisateur et de groupe.

Par mesure de sécurité, les serveurs NFS mappent automatiquement les appels NFS avec UID=0 (root) sur UID=65535 (anonyme), qui dispose d'autorisations limitées sur le système de fichiers. Lors de la création du volume, vous pouvez activer l'option d'accès racine pour contrôler ce comportement. Si vous activez l'accès root, l'ID utilisateur 0 reste 0. Nous vous recommandons de créer une règle d'exportation dédiée qui active l'accès racine pour vos hôtes administrateur connus et de désactiver l'accès racine pour tous les autres clients.

NFSv4.1 avec Kerberos

NFSv4.1 avec Kerberos utilise des règles d'exportation et une authentification supplémentaire à l'aide de Kerberos pour accéder aux volumes. Vous pouvez configurer des règles d'exportation à appliquer pour les éléments suivants:

  • Kerberos uniquement (krb5)

  • Signature Kerberos (krb5i)

  • Confidentialité Kerberos (krb5p)

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

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

Les volumes sont créés avec les autorisations de 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

  1. Effectuez un clic droit sur l'icône Démarrer de Windows, puis sélectionnez Gestion des ordinateurs.

  2. Une fois la console Computer Management (Gestion de l'ordinateur) ouverte, cliquez sur Action > Connect to another computer (Se connecter à un autre ordinateur).

  3. Dans la boîte de dialogue Select Computer (Sélectionner un ordinateur), saisissez le nom NetBIOS de votre partage SMB, puis cliquez sur OK.

  4. Une fois connecté au partage de fichiers, accédez à System Tools (Outils système) > Shared Folders (Dossiers partagés) > Shares (Partages) pour rechercher votre partage.

  5. Double-cliquez sur Nom du partage, puis sélectionnez l'onglet Autorisations de partage pour contrôler les autorisations du partage.

CLI Windows

  1. Ouvrez une ligne de commande Windows.

  2. Connectez-vous au partage de fichiers.

    fsmgmt.msc /computer=<netbios_name_of_share>

  3. Une fois connecté au partage de fichiers, accédez à System Tools (Outils système) > Shared Folders (Dossiers partagés) > Shares (Partages) pour rechercher votre partage.

  4. Double-cliquez sur Nom du partage, puis sélectionnez l'onglet Autorisations de partage pour contrôler les autorisations du partage.

Contrôle des accès aux fichiers

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

Style de sécurité du volume

NetApp Volumes propose deux styles de sécurité pour les volumes, UNIX et NTFS, afin de prendre en charge les 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 protocoles duals, 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 la vérification des autorisations. Il en va de même pour les volumes qui utilisent à la fois les types de protocoles NFSv3 et NFSv4.1. Vous pouvez définir et modifier des 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 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 lors de l'accès au volume après le montage. Pour activer l'accès au volume pour les utilisateurs non racine, un utilisateur racine doit modifier la propriété de l'inode racine à l'aide de chown et modifier les autorisations de fichier à 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'autorisations NTFS. Chaque fichier et répertoire possède une ACL 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. Pour configurer un volume, définissez le style de sécurité du volume sur des 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 agit en tant qu'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

En fonction du protocole utilisé par le client (NFS ou SMB) et du style de sécurité du volume (UNIX ou NTFS), les NetApp Volumes peuvent vérifier directement les autorisations d'accès de l'utilisateur ou nécessiter de mapper d'abord 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é Identité de sécurité au nom d'utilisateur à l'ID utilisateur
PME NTFS Identifiant de sécurité N/A

Lorsqu'un mappage est nécessaire, NetApp Volumes s'appuie sur les données stockées dans Active Directory LDAP. Pour en savoir plus, consultez la section Cas d'utilisation d'Active Directory.

Schéma de mappage utilisateur multiprotocole: accès SMB à un volume UNIX

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

Le client Windows envoie un appel SMB au volume. L'appel SMB contient l'identité de l'utilisateur en tant qu'identifiant de sécurité. L'identifiant de sécurité n'est pas comparable aux autorisations de fichier de l'ID utilisateur et de l'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 tant que 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 par rapport à l'ID utilisateur et à l'ID de groupe de propriété du fichier à l'aide de l'ID utilisateur et de l'ID de groupe renvoyés.

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

L'ingénieur Amal L. doit accéder à certaines données sur un volume à partir d'un client Linux à l'aide de NFS. Étant donné que 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 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, puis vérifie 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 peuvent répliquer des volumes dans les régions Google Cloud pour assurer la protection des données. Étant donné que le trafic réside dans le Google Cloud, le processus de transfert est sécurisé, car il utilise l'infrastructure réseau de Google, qui a un accès 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 sécurisée de Google à l'aide d'un chiffrement standard TLS 1.2 conforme à la norme FIPS 140-2. De plus, les archives de sauvegarde stockent ces sauvegardes à l'aide d'une clé de chiffrement appartenant à Google et gérée par Google pour renforcer la sécurité.

Étape suivante

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