Considerações sobre segurança

Nesta página, você encontra uma visão geral das considerações de segurança para o Google Cloud NetApp Volumes. Essas considerações incluem proteção de rede, controle de acesso e criptografia de dados.

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 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 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 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 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 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 o 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 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 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 o 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 seu 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 do host é responsável por gerenciar permissões do sistema de arquivos e controles de acesso. Por exemplo, hosts Windows usam permissões e ACLs 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 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 vale para volumes que usam os dois tipos de protocolo. É 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 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 da identidade do usuário para a 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

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

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 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, a infraestrutura de rede do Google 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 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 fica na infraestrutura de rede do Google e é criptografado usando o padrão TLS 1.2 em conformidade com o FIPS 140-2. Os backup vaults podem armazenar esses backups usando Google-managed encryption key por padrão ou uma chave de criptografia gerenciada pelo cliente (CMEK) para maior 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 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 os volumes da NetApp com um perímetro de serviço.