Skip to main content
NetApp Solutions
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Architecture de Google Cloud NetApp volumes

Contributeurs

À l'instar des autres services natifs Google Cloud tels que CloudSQL, Google Cloud VMware Engine (GCVE) et filestore, Google Cloud NetApp volumes utilise "Google PSA" pour fournir le service. Dans PSA, les services sont construits dans le cadre d'un projet de producteur de services, qui utilise "Peering de réseau VPC" pour se connecter au consommateur de services. Le producteur de services est fourni et exploité par NetApp. Le consommateur de service est un VPC dans un projet client qui héberge les clients qui souhaitent accéder aux partages de fichiers Google Cloud NetApp volumes.

La figure suivante, référencée dans la "section architecture" documentation de Google Cloud NetApp volumes, présente une vue générale.

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

La partie au-dessus de la ligne pointillée montre le plan de contrôle du service, qui contrôle le cycle de vie du volume. La partie sous la ligne pointillée montre le plan de données. La zone bleue gauche représente le VPC (Service Consumer) de l'utilisateur, la zone bleue droite est le producteur de services fourni par NetApp. Les deux sont connectés via le peering VPC.

Modèle de location

Dans Google Cloud NetApp volumes, les projets individuels sont considérés comme des locataires uniques. Cela signifie que la manipulation des volumes et des copies Snapshot, etc., est effectuée sur la base de chaque projet. En d'autres termes, tous les volumes sont détenus par le projet dans lequel ils ont été créés, et seul ce projet peut gérer et accéder aux données qui leur sont propres par défaut. Cette vue est considérée comme le plan de contrôle du service.

VPC partagés

Dans la vue du plan de données, Google Cloud NetApp volumes peut se connecter à un VPC partagé. Vous pouvez créer des volumes dans le projet d'hébergement ou dans l'un des projets de service connectés au VPC partagé. Tous les projets (hôte ou service) connectés à ce VPC partagé peuvent atteindre les volumes au niveau de la couche réseau (TCP/IP). Étant donné que tous les clients disposant d'une connectivité réseau sur le VPC partagé peuvent accéder aux données via les protocoles NAS, vous devez utiliser le contrôle d'accès sur chacun des volumes (listes de contrôle d'accès (ACL) d'utilisateur/de groupe, ainsi que les noms d'hôte/adresses IP pour les exportations NFS) pour contrôler qui peut accéder aux données.

Vous pouvez connecter Google Cloud NetApp volumes à cinq VPC par projet client. Sur le plan de contrôle, le projet vous permet de gérer tous les volumes créés, quel que soit le VPC auquel ils sont connectés. Sur le plan de données, les VPC sont isolés les uns des autres et chaque volume ne peut être connecté qu'à un VPC.

L'accès aux volumes individuels est contrôlé par des mécanismes de contrôle d'accès spécifiques à un protocole (NFS/SMB).

En d'autres termes, sur la couche réseau, tous les projets connectés au VPC partagé peuvent voir le volume, tandis que, du point de vue de la gestion, le plan de contrôle ne permet au projet propriétaire de voir le volume que.

Contrôles du service VPC

Les contrôles du service VPC établissent un périmètre de contrôle d'accès autour des services Google Cloud reliés à Internet et accessibles dans le monde entier. Ces services permettent le contrôle d'accès par le biais d'identités utilisateur, mais ne peuvent pas limiter les demandes d'emplacement réseau. Les contrôles de service VPC comblent ce fossé en introduisant des capacités permettant de limiter l'accès aux réseaux définis.

Le plan de données de Google Cloud NetApp volumes n'est pas connecté à Internet externe, mais à des VPC privés avec des limites de réseau (périmètres) bien définies. Sur ce réseau, chaque volume utilise un contrôle d'accès spécifique au protocole. Toute connectivité réseau externe est créée de manière explicite par les administrateurs de projet Google Cloud. Le plan de contrôle, cependant, ne fournit pas les mêmes protections que le plan de données et peut être accessible par n'importe qui à partir de n'importe quel endroit avec des informations d'identification valides ( "Jetons JWT").

En résumé, le plan de données de Google Cloud NetApp volumes fournit la fonctionnalité de contrôle d'accès au réseau, sans prendre en charge les contrôles de service de VPC et sans utiliser explicitement les contrôles de service de VPC.

Considérations relatives à la détection et à la détection des paquets

Les captures de paquets peuvent être utiles pour résoudre des problèmes réseau ou d'autres problèmes (autorisations NAS, connectivité LDAP, etc.), mais peuvent également être utilisées de manière malveillante pour obtenir des informations sur les adresses IP réseau, les adresses MAC, les noms d'utilisateurs et de groupes, ainsi que le niveau de sécurité utilisé sur les noeuds finaux. En raison de la configuration de la mise en réseau Google Cloud, des VPC et des règles de pare-feu, l'accès non autorisé aux paquets réseau devrait être difficile à obtenir sans identifiants de connexion utilisateur ou "Jetons JWT" dans les instances cloud. Les captures de paquets ne sont possibles que sur les terminaux (tels que les machines virtuelles) et uniquement sur les terminaux internes au VPC, à moins qu'un VPC partagé et/ou un tunnel/IP de réseau externe ne soit utilisé pour permettre explicitement le trafic externe vers les terminaux. Il n'y a pas de moyen de sniff trafic en dehors des clients.

Lorsque des VPC partagés sont utilisés, le chiffrement à la volée avec NFS Kerberos et/ou "Chiffrement SMB" peut masquer une grande partie des informations glanées par les traces. Cependant, certains trafics sont toujours envoyés en texte clair, tels que "DNS" et "Requêtes LDAP". La figure suivante montre une capture de paquet à partir d'une requête LDAP en texte clair provenant de Google Cloud NetApp volumes et les informations d'identification potentielles exposées. Pour l'instant, les requêtes LDAP dans Google Cloud NetApp volumes ne prennent pas en charge le chiffrement ou LDAP sur SSL. Les volumes NetApp-Performance prennent en charge la signature LDAP, si Active Directory en fait la demande. NetApp volumes-SW ne prend pas en charge la signature LDAP.

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Remarque UnixUserPassword est interrogé par LDAP et n'est pas envoyé en texte clair, mais plutôt dans un hash salé. Par défaut, Windows LDAP ne renseigne pas les champs unixUserPassword. Ce champ est uniquement obligatoire si vous devez utiliser Windows LDAP pour les connexions interactives via LDAP aux clients. Google Cloud NetApp volumes ne prend pas en charge les connexions LDAP interactives avec les instances.

La figure suivante montre une capture de paquets d'une conversation Kerberos NFS à côté d'une capture de NFS sur AUTH_SYS. Notez que les informations disponibles dans une trace diffèrent entre les deux et que l'activation du cryptage à la volée offre une sécurité globale accrue pour le trafic NAS.

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Figure montrant la boîte de dialogue entrée/sortie ou représentant le contenu écrit

Interfaces réseau des VM

Une astuce peut tenter d'ajouter une nouvelle carte d'interface réseau (NIC) à une machine virtuelle dans "mode promiscueux" (Mise en miroir des ports) ou activez le mode promiscuous sur une carte réseau existante afin de sniiser tout le trafic. Dans Google Cloud, l'ajout d'une nouvelle carte réseau nécessite l'arrêt complet d'une machine virtuelle, ce qui génère des alertes, ce qui rend les pirates informatiques inaperçus.

De plus, les cartes réseau ne peuvent pas être configurées en mode promiscuous et déclencheront des alertes dans Google Cloud.