Considerações sobre segurança

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

Considerações de segurança para redes

O Google Cloud NetApp Volumes oferece um framework de arquitetura 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 de armazenamento ou volumes usando o console do Google Cloud , o SDK Google Cloud ou as APIs. As permissões e 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) (Server Message Block (SMB) e Network File System (NFS)).

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

    Na VPC, é possível limitar ainda mais o acesso com firewalls e com a 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 VPC do Google Cloud . Para permitir o acesso de clientes aos 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 as 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 de 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 bloqueios de aviso com o NFSv3

Se você usar bloqueios informativos com o NFSv3, será necessário executar o daemon rpc.statd no cliente para oferecer suporte ao Network Lock Manager, que é uma instalação que funciona em conjunto com o NFS para fornecer um estilo System V de bloqueio informativo de arquivos e registros pela rede. O cliente NFS precisa abrir uma porta de entrada para que rpc.statd receba 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 usando o comando rpcinfo -p. Para tornar o rpc.statd mais compatível com o firewall, configure-o para usar uma porta estática.

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

Se você não usa bloqueios de aviso do NFSv3 ou o Gerenciador de bloqueio de rede, 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 ao 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 uma comunicação adequada, ative as portas nos firewalls.

NetApp Volumes atuam 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 contínuos do SMB 3.x. 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.

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

Regras de firewall para acesso ao Active Directory

Abra as portas a seguir em todos os controladores de domínio do Active Directory para tráfego originado do intervalo CIDR para NetApp Volumes:

  • ICMPV4

  • DNS 53 TCP

  • DNS 53 UDP

  • LDAP 389 TCP

  • LDAP 389 UDP

  • LDAP (GC) 3268 TCP

  • SAM/LSA 445 TCP

  • SAM/LSA 445 UDP

  • Secure LDAP 636 TCP

  • Secure LDAP 3269 TCP

  • W32Time 123 UDP

  • AD Web Svc 9389 TCP

  • Kerberos 464 TCP

  • Kerberos 464 UDP

  • Kerberos 88 TCP

  • Kerberos 88 UDP

Anexar tag de firewall a servidores do Active Directory

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

  1. Anexe a tag de firewall aos seus servidores do Active Directory:

    gcloud compute firewall-rules create netappvolumes-to-activedirectory \
  --allow=icmp,TCP:53,UDP:53,TCP:88,UDP:88,UDP:123,TCP:389,UDP:389,TCP:445,UDP:445,TCP:464,UDP:464,TCP:636,TCP:3268,TCP:3269,TCP:9389 \
  --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 dos volumes do NetApp

    • VPC_NAME: o nome da VPC

  2. 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 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 montar volumes. NetApp Volumes avaliam as regras de exportação em ordem sequencial e param 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:

NFS sem Kerberos

Todas as versões do NFS sem Kerberos usam o tipo de segurança AUTH_SYS. Nesse modo, é necessário gerenciar de perto as regras de exportação para permitir apenas clientes confiáveis que possam garantir a integridade do ID do usuário e do grupo.

Como medida de segurança, os servidores NFS mapeiam automaticamente as chamadas NFS com UID=0 (raiz) para UID=65535 (anônimo), que tem permissões limitadas no sistema de arquivos. Durante a criação do volume, é possível ativar a opção de acesso raiz para controlar esse comportamento. Se você ativar o acesso raiz, o ID do usuário 0 vai permanecer 0. Como prática recomendada, crie uma regra de exportação dedicada que permita o acesso raiz para os hosts de administrador conhecidos e desative o acesso raiz para todos os outros clientes.

NFSv4.1 com Kerberos

O NFSv4.1 com Kerberos usa políticas de exportação e autenticação adicional usando Kerberos para acessar volumes. É possível configurar regras de exportação para aplicar o seguinte:

  • Somente Kerberos (krb5)

  • Assinatura do Kerberos (krb5i)

  • Privacidade do Kerberos (krb5p)

Controles de acesso ao volume para o protocolo SMB

O SMB usa permissões no nível de compartilhamento para proteger o acesso ao volume e exigir autenticação no Active Directory. Essas permissões permitem controlar quem tem acesso a compartilhamentos pela 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 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 abrir, clique em Ação > Conectar a outro computador.

  3. Na caixa de diálogo Select Computer, digite o nome netbios da sua compartilhação SMB e clique em OK.

  4. Depois de se conectar ao compartilhamento de arquivos, acesse Ferramentas do sistema > Pastas compartilhadas > Compartilhamentos para procurar o 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 procurar o compartilhamento.

  4. Clique duas vezes em Nome do compartilhamento e selecione a guia Permissões de compartilhamento para controlar as permissões do compartilhamento.

Controle de acesso a arquivos

As seções a seguir fornecem detalhes sobre o controle de acesso de arquivos dos 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 do NTFS para controlar o acesso a 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 do tipo UNIX

Depois que um cliente monta um volume, NetApp Volumes verificam as permissões de acesso a arquivos e diretórios usando o modelo de permissão padrão do UNIX, 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 verificar permissões. O mesmo se aplica a volumes que usam os 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 que 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 do tipo NTFS

Para volumes do tipo 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 File Explorer, a ferramenta de linha de comando icacls ou o PowerShell. No modelo de permissão NTFS, novos arquivos e pastas herdam as permissões da pasta pai.

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 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 à chamada NFS será negado.

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), os NetApp Volumes podem verificar diretamente as permissões de acesso do usuário ou exigir o mapeamento do usuário para a outra identidade da plataforma primeiro.

Protocolo de acesso Estilo de segurança Identidade usada pelo protocolo Mapeamento obrigatório
NFSv3 UNIX ID do usuário e do grupo N/A
NFSv3 NTFS ID do usuário e 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 para ID do usuário
SMB NTFS Identificador de segurança N/A

Quando o mapeamento é necessário, NetApp Volumes dependem dos dados armazenados no Active Directory LDAP. 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. (Charlie) quer acessar um volume do NetApp Volumes usando SMB em um cliente Windows. Como o volume contém resultados gerados pela máquina fornecidos por um cluster de computação Linux, ele é configurado para armazenar permissões do UNIX.

O cliente do 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 requer mapeamento.

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

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

  2. NetApp Volumes solicitam que o Active Directory retorne o ID do usuário e do grupo para charliee.

  3. NetApp Volumes verificam o acesso com base no ID de usuário e ID de grupo de propriedade do arquivo usando o ID de usuário e o ID de 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 NetApp Volumes. A chamada NFS contém identificadores de ID do usuário e de grupo que não podem ser associados a um identificador de segurança sem mapeamento.

Para concluir o mapeamento necessário, os NetApp Volumes solicitam ao Active Directory o nome de usuário do ID do usuário e retornam o identificador de segurança do nome de usuário. Em seguida, eles verificam 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 máxima segurança.

Replicação de volume

NetApp Volumes podem replicar volumes nas regiões do Google Cloud para fornecer proteção de dados. Como o tráfego está 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 os 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 fica na infraestrutura de rede segura do Google usando a criptografia padrão TLS 1.2 compatível com FIPS 140-2. Além disso, os backups armazenam esses backups usando de propriedade e gerenciada pelo Google com o Google Cloud para maior segurança.

A seguir

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