Considerações sobre segurança

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

Considerações sobre segurança para rede

Google Cloud NetApp Volumes oferecem 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 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 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), como Server Message Block (SMB) e 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 dos 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 configurando 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 o 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, ative 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)

• 3260 TCP iSCSI

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 bloqueio de arquivo e registro consultivo no estilo System V 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 o rpc.statd mais compatível com firewalls, 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 usar bloqueios consultivos do NFSv3 ou o Network Lock Manager, recomendamos que você monte seus 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

Observação: os servidores DNS do Active Directory também funcionam como controladores de domínio, o que exige a aplicação de dois conjuntos de regras.

Anexar tag de firewall aos servidores do Active Directory

Use as instruções a seguir para anexar a tag de firewall aos seus 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

Regras de firewall para acesso a volumes iSCSI

Para acesso iSCSI, o NetApp Volumes usa portas de rede específicas para permitir a comunicação entre iniciadores (clientes) e destinos (volumes de armazenamento). Para ter conectividade adequada e acesso aos volumes de armazenamento em blocos, configure os firewalls para permitir as portas necessárias.

Verifique se os iniciadores iSCSI podem se comunicar com a seguinte porta do NetApp Volumes:

• 3260 TCP: porta de destino iSCSI

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.

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. Para mais informações sobre regras de exportação, consulte Controle de acesso a volumes usando políticas de exportação.

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 ou a CLI do Windows:

Console do Windows

1. Clique com o botão direito do mouse no ícone Iniciar do Windows e selecione Gerenciamento do computador.

2. Depois que o console Gerenciamento do computador for aberto, clique em Ação > Conectar a outro computador.

3. Na caixa de diálogo Selecionar computador, insira o nome netbios do compartilhamento SMB e clique em OK.

4. Depois de se conectar ao compartilhamento de arquivos, acesse Ferramentas do sistema > Pastas compartilhadas > Compartilhamentos para pesquisar seu compartilhamento.

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

1. Abra uma linha de comando do Windows.

2. Conecte-se ao compartilhamento de arquivos.

   fsmgmt.msc /computer=<netbios_name_of_share>

3. Depois de se conectar ao compartilhamento de arquivos, acesse Ferramentas do sistema > Pastas compartilhadas > Compartilhamentos para pesquisar seu compartilhamento.

4. 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 a volumes para o protocolo iSCSI

O acesso aos volumes iSCSI da NetApp é gerenciado usando grupos de hosts, que são objetos regionais que contêm um ou mais IQNs iniciadores 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. Essa relação concede acesso do volume iSCSI aos clientes iSCSI (iniciadores) dentro desse grupo de hosts, o que permite que eles descubram a LUN e consumam o recurso de armazenamento. Somente os iniciadores que são membros do grupo host podem visualizar e se conectar ao volume iSCSI atribuído.

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 nem se conectar à LUN.

• Escopo regional: os grupos de hosts são objetos regionais, com configuração e associação limitadas a uma região específica no ambienteGoogle Cloud .

• 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 montar 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 dele é responsável por gerenciar permissões do sistema de arquivos e controles de acesso. Por exemplo, hosts Windows usam permissões e ACLs do NTFS, enquanto 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 NetApp Volumes.

Estilo de segurança do volume

NetApp Volumes oferecem 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 do protocolo escolhido:

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ões 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 verificação de permissão. 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 volume no estilo UNIX, o root:root tem a propriedade do inode raiz e permissões de 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 de 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, 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 procurar 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 realiza 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 retorna 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 para 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 criptografia específica do protocolo para aumentar a 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 em Google Cloud regiões para oferecer proteção de dados. Como o tráfego reside no Google Cloud, a infraestrutura de rede do Google protege o processo de transferência, 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 compatíveis com 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 do Google e é criptografado usando o 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 volumes

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 qualquer firewall entre a interface lógica (LIF) intercluster do sistema ONTAP e o endereço IP de migração do NetApp Volumes permite essas portas.

A seguir

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