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

Considerações sobre segurança

Esta página oferece uma visão geral das considerações de segurança do Google Cloud NetApp Volumes. Essas considerações incluem proteção de rede, controle de acesso e criptografia de dados.

Considerações de segurança para redes

O Google Cloud NetApp Volumes oferece um framework arquitetônico protegido com as seguintes camadas de segurança isoladas:

Segurança no nível do projeto: a camada de segurança administrativa que os administradores usam para gerenciar recursos do NetApp Volumes, como pools de armazenamento ou volumes, usando o Google Cloud console, o SDK Google Cloud ou as APIs. Os papéis e permissões do IAM protegem essa camada. Para mais informações sobre a segurança no nível do projeto, consulte Configurar permissões do IAM.
Segurança no nível da rede: a camada de rede usada para acessar volumes de dados com protocolos de armazenamento conectado à rede (NAS, na sigla em inglês) (bloco de mensagens do servidor (SMB) e Network File System (NFS)).

É possível acessar dados em volumes usando protocolos NAS por uma rede de nuvem privada virtual (VPC). Todo o acesso aos dados do NetApp Volumes só é possível pela VPC, a menos que você use explicitamente uma solução de terceiros para substituir o roteamento de peering de VPC para suas VPCs.

Na VPC, é possível limitar ainda mais o acesso com firewalls e pela configuração de mecanismos de controle de acesso específicos do protocolo.

Regras de firewall para acesso a volumes

As regras de firewall protegem Google Cloud a VPC. Para permitir o acesso de clientes ao NetApp Volumes, é necessário permitir tráfego de rede específico.

Para mais informações sobre regras de firewall para acesso a volumes NFS, SMB e iSCSI, consulte as seções a seguir:

Regras de firewall para acesso ao Active Directory

O NetApp Volumes precisa de acesso às seguintes portas nos servidores DNS configurados na política do Active Directory para identificar os controladores de domínio do Active Directory. O NetApp Volumes usa pesquisas de DNS para a descoberta de controladores de domínio do Active Directory.

ICMPV4
DNS 53 TCP
DNS 53 UDP

Abra as seguintes portas em todos os controladores de domínio do Active Directory para o tráfego originário do intervalo CIDR do 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

Para especificar um intervalo de origem para seus firewalls, use o intervalo CIDR completo fornecido ao configurar o acesso a serviços particulares. Para mais informações, consulte Configurar o acesso a serviços particulares.

Anexar tag de firewall aos servidores do Active Directory

Use as instruções a seguir para anexar a tag de firewall aos servidores do Active Directory.

Anexe a regra de firewall aos servidores DNS do 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

Anexe a regra de firewall aos controladores de domínio do 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

Substitua as seguintes informações:

NETAPP_VOLUMES_CIDR: o CIDR do NetApp Volumes
VPC_NAME: o nome da VPC

Anexe a seguinte tag aos servidores DNS:
```
allow-netappvolumes-to-dns
```
Anexe a seguinte tag aos controladores de domínio:
```
allow-netappvolumes-to-activedirectory
```

Controles de acesso de volume para protocolos NFS

O NetApp Volumes protege o acesso por protocolos NFS com uma única política de exportação com até 20 regras de exportação. As regras de exportação são listas separadas por vírgulas de endereços IPv4 e CIDRs IPv4 que especificam quais clientes têm permissão para ativar volumes. O NetApp Volumes avalia as regras de exportação em ordem sequencial e para após a primeira correspondência. Recomendamos ordenar as regras de exportação da mais específica para a mais genérica para melhores resultados. Para mais informações sobre regras de exportação, consulte Controle de acesso de volume usando políticas de exportação.

Controles de acesso de volume para protocolo SMB

O SMB usa permissões no nível de compartilhamento para proteger o acesso ao volume e exige autenticação no Active Directory. Essas permissões permitem controlar quem tem acesso a compartilhamentos na rede.

Os volumes são criados com permissões de compartilhamento Todos e Controle total. É possível modificar as permissões no nível de compartilhamento usando o console do Windows ou a CLI do Windows.

Use as instruções a seguir para modificar as permissões de compartilhamento do SMB usando o console do Windows ou a CLI do Windows:

Console do Windows

Clique com o botão direito do mouse no ícone Iniciar do Windows e selecione Gerenciamento do computador.
Depois que o console Gerenciamento do computador for aberto, clique em Ação > Conectar a outro computador.
Na caixa de diálogo Selecionar computador, insira o nome netbios do compartilhamento SMB e clique em OK.
Depois de se conectar ao compartilhamento de arquivos, acesse Ferramentas do sistema > Pastas compartilhadas > Compartilhamentos para pesquisar o compartilhamento.
Clique duas vezes em Nome do compartilhamento e selecione a guia Permissões de compartilhamento para controlar as permissões do compartilhamento.

CLI do Windows

Abra uma linha de comando do Windows.

Conecte-se ao compartilhamento de arquivos.

fsmgmt.msc /computer=<netbios_name_of_share>

Depois de se conectar ao compartilhamento de arquivos, acesse Ferramentas do sistema > Pastas compartilhadas > Compartilhamentos para pesquisar o compartilhamento.
Clique duas vezes em Nome do compartilhamento e selecione a guia Permissões de compartilhamento para controlar as permissões do compartilhamento.

Controles de acesso de volume para protocolo iSCSI

O acesso aos NetApp Volumes iSCSI é gerenciado usando grupos de hosts, que são objetos regionais que contêm um ou mais IQNs de iniciador iSCSI. Um iniciador iSCSI é normalmente um sistema ou servidor cliente que se conecta a destinos de armazenamento em uma rede usando o protocolo iSCSI.

Quando um volume iSCSI é criado, ele é anexado a um grupo de hosts. Esse relacionamento concede acesso do volume iSCSI aos clientes iSCSI (iniciadores) nesse grupo de hosts, o que permite que eles descubram o LUN e consumam o recurso de armazenamento. Somente os iniciadores que são membros do grupo de hosts podem visualizar e se conectar ao volume iSCSI atribuído.

A seguir, confira as principais características dos grupos de hosts e do acesso iSCSI:

Controle de visibilidade: os grupos de hosts restringem quais clientes iSCSI podem visualizar e acessar volumes específicos. Se um iniciador não fizer parte de um grupo de hosts, ele não poderá descobrir ou se conectar ao LUN.
Escopo regional: os grupos de hosts são objetos regionais, com configuração e participação limitadas a uma região específica no Google Cloud ambiente.
Segurança do lado do cliente: embora os grupos de hosts controlem a visibilidade do volume, o administrador do cliente iSCSI é responsável por implementar controles de acesso no nível do usuário no sistema cliente. Isso inclui gerenciar quem pode ativar o volume iSCSI e quem pode acessar o sistema de arquivos criado nele.

Permissões do sistema de arquivos baseadas em host

Depois que um LUN é mapeado para um host, o sistema operacional do host é responsável por gerenciar as permissões do sistema de arquivos e os controles de acesso. Por exemplo, os hosts do Windows usam permissões e ACLs NTFS, enquanto os hosts Linux e UNIX usam permissões de arquivo UNIX padrão e, opcionalmente, ACLs para proteger arquivos e diretórios.

Essa abordagem de segurança de duas camadas ajuda a garantir que apenas hosts autorizados possam acessar o armazenamento no nível do bloco, enquanto o sistema operacional do host gerencia a segurança no nível do arquivo de acordo com as políticas organizacionais.

Controle de acesso a arquivos

As seções a seguir fornecem detalhes sobre o controle de acesso no nível do arquivo do NetApp Volumes.

Estilo de segurança do volume

O NetApp Volumes oferece dois estilos de segurança para volumes, UNIX e NTFS, para acomodar os diferentes conjuntos de permissões das plataformas Linux e Windows.

UNIX: os volumes configurados com o estilo de segurança UNIX usam bits de modo UNIX e ACLs NFSv4 para controlar o acesso a arquivos.
NTFS: os volumes configurados com o estilo de segurança NTFS usam ACLs NTFS para controlar o acesso a arquivos.

O estilo de segurança do volume depende da escolha do protocolo para o volume:

Tipo de protocolo	Estilo de segurança do volume
NFSv3	UNIX
NFSv4.1	UNIX
Ambos (NFSv3 e NFSv4.1)	UNIX
SMB	NTFS
Duplo (SMB e NFSv3)	UNIX ou NTFS
Duplo (SMB e NFSv4.1)	UNIX ou NTFS

Para protocolos duplos, só é possível escolher o estilo de segurança durante a criação do volume.

Controle de acesso no nível do arquivo NFS para volumes no estilo UNIX

Depois que um cliente ativa um volume, o NetApp Volumes verifica as permissões de acesso a arquivos e diretórios usando o modelo de permissão UNIX padrão chamado de bits de modo. É possível definir e modificar permissões usando chmod.

Os volumes NFSv4.1 também podem usar listas de controle de acesso (ACLs) NFSv4. Se um arquivo ou diretório tiver bits de modo e uma ACL NFSv4, a ACL será usada para a verificação de permissão. O mesmo se aplica a volumes que usam os tipos de protocolo NFSv3 e NFSv4.1. É possível definir e modificar ACLs NFSv4 usando nfs4_getfacl e nfs4_setfacl.

Ao criar um novo volume no estilo UNIX, o root:root tem a propriedade do inode raiz e permissões 0770. Devido a essa configuração de propriedade e permissão, um usuário não raiz recebe um erro permission denied ao acessar o volume após a ativação. Para permitir o acesso ao volume para usuários não raiz, um usuário raiz precisa mudar a propriedade do inode raiz usando chown e modificar as permissões de arquivo usando chmod.

Controle de acesso a arquivos SMB para volumes no estilo NTFS

Para volumes no estilo NTFS, recomendamos o uso de um modelo de permissão NTFS. Cada arquivo e diretório tem uma ACL NTFS que pode ser modificada usando o Explorador de Arquivos, a ferramenta de linha de comando icacls ou o PowerShell. No modelo de permissão NTFS, novos arquivos e pastas herdam permissões da pasta mãe.

Mapeamento de usuários de vários protocolos

Para volumes de protocolo duplo, os clientes podem usar NFS e SMB para acessar os mesmos dados. Um volume é configurado definindo o estilo de segurança do volume para ter permissões UNIX ou NTFS.

Ao criar um volume SMB e NFS de protocolo duplo, recomendamos que o Active Directory contenha um usuário padrão. O usuário padrão é usado quando um cliente NFS envia uma chamada NFS com um ID de usuário que não está disponível no Active Directory. O NetApp Volumes tenta pesquisar um usuário chamado pcuser, que atua como um usuário UNIX padrão. Se esse usuário não for encontrado, o acesso será negado à chamada NFS.

Recomendamos que você crie um usuário padrão no Active Directory com os seguintes atributos:

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

Dependendo do protocolo usado pelo cliente (NFS ou SMB) e do estilo de segurança do volume (UNIX ou NTFS), o NetApp Volumes pode verificar diretamente as permissões de acesso do usuário ou exigir o mapeamento do usuário para a identidade da outra plataforma primeiro.

Protocolo de acesso	Estilo de segurança	Identidade usada pelo protocolo	Mapeamento necessário
NFSv3	UNIX	ID de usuário e ID de grupo	N/A
NFSv3	NTFS	ID de usuário e ID de grupo	ID de usuário para nome de usuário para identificador de segurança
SMB	UNIX	Identificador de segurança	Identificador de segurança para nome de usuário para ID de usuário
SMB	NTFS	Identificador de segurança	N/A

Quando o mapeamento é necessário, o NetApp Volumes depende dos dados armazenados no LDAP do Active Directory. Para mais informações, consulte Casos de uso do Active Directory.

Cenário de mapeamento de usuários de vários protocolos: acesso SMB a um volume UNIX

O cientista Charlie E. (charliee) quer acessar um volume do NetApp Volumes usando SMB de um cliente Windows. Como o volume contém resultados gerados por máquina fornecidos por um cluster de computação Linux, o volume é configurado para armazenar permissões UNIX.

O cliente Windows envia uma chamada SMB para o volume. A chamada SMB contém a identidade do usuário como um identificador de segurança. O identificador de segurança não é comparável às permissões de arquivo de ID de usuário e ID de grupo e exige mapeamento.

Para concluir o mapeamento necessário, o NetApp Volumes segue estas etapas:

O NetApp Volumes pede ao Active Directory para resolver o identificador de segurança para um nome de usuário, por exemplo, S-1-5-21-2761044393-2226150802-3019316526-1224 para charliee.
O NetApp Volumes pede ao Active Directory para retornar o ID de usuário e o ID de grupo de charliee.
O NetApp Volumes verifica o acesso ao ID de usuário e ao ID de grupo do arquivo usando o ID de usuário e o ID de grupo retornados.

Cenário de mapeamento de usuários de vários protocolos: acesso NFS a um volume NTFS

O engenheiro Amal L. precisa acessar alguns dados em um volume de um cliente Linux usando NFS. Como o volume é usado principalmente para armazenar dados do Windows, ele é configurado com o estilo de segurança NTFS.

O cliente Linux envia uma chamada NFS para o NetApp Volumes. A chamada NFS contém identificadores de ID de usuário e ID de grupo que não podem ser correspondidos a um identificador de segurança sem mapeamento.

Para concluir o mapeamento necessário, o NetApp Volumes pede ao Active Directory o nome de usuário do ID de usuário e para retornar o identificador de segurança do nome de usuário. Em seguida, ele verifica o acesso ao identificador de segurança do proprietário do arquivo acessado usando o identificador de segurança retornado.

Criptografia em trânsito

A criptografia em trânsito protege os dados contra interceptação em uma rede. O tráfego de replicação de volume, backup integrado e migração de volume é criptografado por padrão usando TLS 1.2. Para tráfego NFS e SMB, é possível configurar configurações de criptografia específicas do protocolo para maior proteção.

NFS

Para volumes NFS, use o NFSv4.1 com a criptografia Kerberos krb5p ativada para máxima segurança.

SMB

Para volumes SMB, ative codificação AES na política do Active Directory e a criptografia SMB no volume para máxima segurança.

Replicação de volume

O NetApp Volumes pode replicar volumes entre Google Cloud regiões para fornecer proteção de dados. Como o tráfego reside na Google Cloudinfraestrutura de rede do Google, ele protege o processo de transferência, que tem acesso limitado para evitar interceptação não autorizada. Além disso, o tráfego de replicação é criptografado usando padrões TLS 1.2 compatíveis com FIPS 140-2.

Backup integrado

Um backup integrado cria backups do NetApp Volumes no serviço. O tráfego de backup permanece na infraestrutura de rede do Google e é criptografado usando o padrão TLS 1.2 compatível com FIPS 140-2. Os backup vaults podem armazenar esses backups usando Google-managed encryption key por padrão ou chave de criptografia gerenciada pelo cliente (CMEK) para maior segurança.

Migração de volume

A migração de volume envia dados do sistema ONTAP ou Cloud Volumes ONTAP de origem para o NetApp Volumes. A comunicação entre o sistema de origem e o NetApp Volumes é criptografada usando padrões TLS 1.2 compatíveis com FIPS 140-2.

O NetApp Volumes inicia a migração e usa os seguintes protocolos e portas:

ICMP
10000/TCP
11104/TCP
11105/TCP

Verifique se qualquer firewall entre a interface lógica intercluster (LIF) do sistema ONTAP e o endereço IP de migração do NetApp Volumes permite essas portas.

A seguir

Proteja o NetApp Volumes com um perímetro de serviço.