Considerações sobre segurança

Nesta página, fornecemos uma visão geral das considerações de segurança Google Cloud NetApp Volumes.

Considerações sobre segurança para rede

O Google Cloud NetApp Volumes oferece um framework arquitetônico seguro 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 ou volumes de armazenamento, usando o console Google Cloud , o SDK Google Cloud ou APIs. As permissões e os papéis do IAM protegem essa camada. Para mais informações sobre 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), como o Server Message Block (SMB) e o Network File System (NFS).

  É possível acessar dados em volumes usando protocolos NAS por uma rede de nuvem privada virtual. Todo o acesso a dados nos NetApp Volumes só é possível pela sua VPC, a menos que você use explicitamente uma solução de terceiros para substituir o roteamento de peering da 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 a Google Cloud VPC. Para permitir o acesso de clientes ao NetApp Volumes, é necessário permitir um tráfego de rede específico.

Regras de firewall para acesso a volumes NFS

O NFS usa várias portas para se comunicar entre o cliente e um servidor. Para garantir a comunicação adequada e a montagem de volume bem-sucedida, é necessário ativar portas nos firewalls.

O NetApp Volumes atua como um servidor NFS e expõe as portas de rede necessárias para o NFS. Verifique se os clientes NFS têm permissão para se comunicar com as seguintes portas do NetApp Volumes:

• 111 TCP/UDP portmapper

• 635 TCP/UDP mountd

• 2049 TCP/UDP nfsd

• 4045 TCP/UDP nlockmgr (somente para NFSv3)

• 4046 TCP/UDP status (somente para NFSv3)

Os endereços IP dos NetApp Volumes são atribuídos automaticamente do intervalo CIDR atribuído ao serviço durante o peering de rede. Para mais informações, consulte Escolher um CIDR.

Uso de bloqueio consultivo com NFSv3

Se você usar bloqueios consultivos com o NFSv3, execute o daemon rpc.statd no cliente para oferecer suporte ao Network Lock Manager, que é um recurso que funciona em cooperação com o NFS para fornecer um estilo System V de bloqueio de arquivo e registro consultivo na rede. O cliente NFS precisa abrir uma porta de entrada para rpc.statd receber callbacks do Network Lock Manager. Na maioria das distribuições Linux, o rpc.statd é iniciado quando você monta o primeiro compartilhamento NFS. Ele usa uma porta aleatória que pode ser identificada com o comando rpcinfo -p. Para tornar rpc.statd mais compatível com firewall, configure-o para usar uma porta estática.

Para definir portas estáticas para rpc.statd, consulte os seguintes recursos:

• Debian/Ubuntu

• SuSE

• RedHat

Se você não usa bloqueios consultivos do NFSv3 ou o Network Lock Manager, recomendamos montar os compartilhamentos do NFSv3 com a opção de montagem nolock.

O NFSv4.1 implementa a função de bloqueio no próprio protocolo NFSv4.1, que é executado na conexão TCP iniciada pelo cliente com o servidor NFSv4.1 na porta 2049. O cliente não precisa abrir portas de firewall para o tráfego de entrada.

Regras de firewall para acesso a volumes SMB

O SMB usa várias portas para se comunicar entre o cliente e um servidor. Para garantir a comunicação adequada, é necessário ativar as portas nos firewalls.

NetApp Volumes funcionam como um servidor SMB e expõem as portas de rede necessárias para o SMB. Verifique se o cliente SMB tem permissão para se comunicar com as seguintes portas do NetApp Volumes:

• 445 TCP SMB2/3

• 135 TCP msrpc e 40001 TCP SMB CA: usados apenas para compartilhamentos SMB 3.x disponíveis continuamente. Essas portas não são necessárias para compartilhamentos não disponíveis continuamente.

O serviço expõe, mas não usa, a porta 139/TCP.

Os endereços IP dos NetApp Volumes são atribuídos automaticamente do intervalo CIDR atribuído ao serviço durante o peering de rede. Para mais informações, consulte Escolher um CIDR.

Seus clientes de PMEs não precisam expor portas de entrada para que o SMB funcione.

Regras de firewall para acesso ao Active Directory

O NetApp Volumes precisa de acesso às seguintes portas nos servidores DNS configurados na sua 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 tráfego originado do intervalo CIDR para 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

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.

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

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

3. Anexe a seguinte tag aos seus servidores DNS:

   allow-netappvolumes-to-dns

4. Anexe a seguinte tag aos controladores de domínio:

   allow-netappvolumes-to-activedirectory

Controles de acesso a volumes para protocolos NFS

O NetApp Volumes protege o acesso por protocolos NFS com uma única política de exportação com até 20 regras. 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 montar 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 ter os melhores resultados.

Use as guias a seguir para analisar as políticas com base nas versões do NFS:

Controles de acesso a volumes para o protocolo SMB

O SMB usa permissões no nível do compartilhamento para proteger o acesso ao volume e exigir autenticação no Active Directory. Com elas, você controla quem tem acesso aos compartilhamentos na rede.

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

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

Controle de acesso a arquivos

As seções a seguir fornecem detalhes sobre o controle de acesso no nível do arquivo 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 do NFSv4 para controlar o acesso a arquivos.

• NTFS: volumes configurados com o estilo de segurança NTFS usam ACLs do NTFS para controlar o acesso aos arquivos.

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

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 monta um volume, o NetApp Volumes verifica as permissões de acesso a arquivos e diretórios usando o modelo padrão de permissão do UNIX chamado 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) do NFSv4. Se um arquivo ou diretório tiver bits de modo e uma ACL do NFSv4, a ACL será usada para verificar permissões. O mesmo se aplica a volumes que usam os dois tipos de protocolo NFSv3 e NFSv4.1. É possível definir e modificar ACLs do NFSv4 usando nfs4_getfacl e nfs4_setfacl.

Quando você cria 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 montagem. 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 do arquivo usando chmod.

Controle de acesso a arquivos SMB para volumes no estilo NTFS

Para volumes no estilo NTFS, recomendamos usar um modelo de permissão NTFS. Cada arquivo e diretório tem uma ACL do 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, os novos arquivos e pastas herdam permissões da pasta principal.

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 dele como permissões UNIX ou NTFS.

Ao criar um volume SMB e NFS de protocolo duplo, recomendamos que o Active Directory tenha 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. Em seguida, 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 obrigatório
NFSv3	UNIX	ID do usuário e ID do grupo	N/A
NFSv3	NTFS	ID do usuário e ID do grupo	ID do 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 e ID do 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 com vários protocolos: acesso SMB a um volume UNIX

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, ele é configurado para armazenar permissões UNIX.

O cliente Windows envia uma chamada SMB ao 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 executa as seguintes etapas:

1. O NetApp Volumes pede ao Active Directory para resolver o identificador de segurança em um nome de usuário, por exemplo, S-1-5-21-2761044393-2226150802-3019316526-1224 para charliee.

2. O NetApp Volumes pede ao Active Directory para retornar o ID do usuário e do grupo de charliee.

3. O NetApp Volumes verifica o acesso com base no ID do usuário proprietário e no ID do grupo do arquivo usando o ID do usuário e o ID do grupo retornados.

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

A engenheira 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 do usuário e o identificador de segurança do nome de usuário. Em seguida, ele verifica o acesso com o identificador de segurança do proprietário do arquivo acessado usando o identificador de segurança retornado.

Criptografia em trânsito

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 ter segurança máxima.

Replicação de volume

O NetApp Volumes pode replicar volumes em Google Cloud regiões para oferecer proteção de dados. Como o tráfego reside no Google Cloud, o processo de transferência é seguro porque usa a infraestrutura de rede do Google, que tem acesso limitado para evitar interceptações não autorizadas. Além disso, o tráfego de replicação é criptografado usando padrões TLS 1.2 em conformidade com o FIPS 140-2.

Backup integrado

Um backup integrado cria backups de NetApp Volumes no serviço. O tráfego de backup permanece na infraestrutura de rede segura do Google usando criptografia padrão TLS 1.2 em conformidade com o FIPS 140-2. Além disso, os backup vaults armazenam esses backups usando Google-owned and Google-managed encryption key para aumentar a segurança.

Migração de volume

A migração de volumes envia dados do sistema de origem ONTAP ou Cloud Volumes ONTAP 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 o 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 os volumes da NetApp com um perímetro de serviço.