Considerações de segurança

Esta página oferece uma vista geral das considerações de segurança do Google Cloud NetApp Volumes.

Considerações de segurança para trabalhar em rede

O Google Cloud NetApp Volumes oferece uma framework arquitetónica protegida com as seguintes camadas de segurança isoladas:

• Segurança ao nível do projeto: a camada de segurança administrativa que os administradores usam para gerir recursos de volumes NetApp, como volumes ou pools de armazenamento, através da Google Cloud consola, do SDK do Google Cloud ou das APIs. As funções e as autorizações do IAM protegem esta camada. Para mais informações acerca da segurança ao nível do projeto, consulte o artigo Configure as autorizações de IAM.

• Segurança ao nível da rede: a camada de rede usada para aceder a volumes de dados com protocolos de armazenamento associado à rede (NAS) (Server Message Block [SMB] e Network File System [NFS]).

  Pode aceder aos dados nos volumes através de protocolos NAS numa rede de nuvem privada virtual. O acesso a todos os dados dos volumes NetApp só é possível através da sua VPC, a menos que use explicitamente uma solução de terceiros para substituir o encaminhamento de interligação de VPCs para as suas VPCs.

  Na VPC, pode limitar ainda mais o acesso com firewalls e através da configuração de mecanismos de controlo 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 aos volumes NetApp, tem de permitir tráfego de rede específico.

Regras de firewall para acesso a volumes NFS

O NFS usa várias portas para comunicar entre o cliente e um servidor. Para garantir uma comunicação adequada e montagens de volume bem-sucedidas, tem de ativar as portas nas suas firewalls.

Os volumes NetApp atuam como um servidor NFS e expõem as portas de rede necessárias para o NFS. Certifique-se de que os seus clientes NFS têm autorização para comunicar com as seguintes portas de volumes NetApp:

• 111 TCP/UDP portmapper

• 635 TCP/UDP mountd

• 2049 TCP/UDP nfsd

• 4045 TCP/UDP nlockmgr (apenas para NFSv3)

• 4046 TCP/UDP status (apenas para NFSv3)

• 3260 TCP iSCSI

Os endereços IP dos volumes NetApp são atribuídos automaticamente a partir do intervalo CIDR que atribuiu ao serviço durante a interligação de redes. Para mais informações, consulte Escolha um CIDR.

Utilização de bloqueio consultivo com NFSv3

Se usar bloqueios consultivos com o NFSv3, tem de executar o daemon rpc.statd no cliente para suportar o Network Lock Manager, que é uma funcionalidade que funciona em cooperação com o NFS para fornecer um estilo System V de bloqueio de ficheiros e registos na rede. O seu cliente NFS tem de 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 monta a primeira partilha NFS. Usa uma porta aleatória que pode identificar através do 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 o rpc.statd, consulte os seguintes recursos:

• Debian/Ubuntu

• SuSE

• RedHat

Se não usar bloqueios consultivos NFSv3 ou o Network Lock Manager, recomendamos que monte as suas partilhas 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 através da ligação TCP iniciada pelo cliente ao servidor NFSv4.1 na porta 2049. O cliente não precisa de abrir portas de firewall para tráfego de entrada.

Regras de firewall para acesso a volumes SMB

O SMB usa várias portas para comunicar entre o cliente e um servidor. Para garantir uma comunicação adequada, tem de ativar as portas nas suas firewalls.

Os volumes NetApp atuam como um servidor SMB e expõem as portas de rede que o SMB requer. Certifique-se de que o cliente SMB tem autorização para comunicar com as seguintes portas de volumes NetApp:

• 445 TCP SMB2/3

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

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

Os endereços IP dos volumes NetApp são atribuídos automaticamente a partir do intervalo CIDR que atribuiu ao serviço durante a interligação de redes. Para mais informações, consulte o artigo Escolha um CIDR.

Os seus clientes de PME não precisam de expor portas de entrada para o SMB funcionar.

Regras de firewall para acesso ao Active Directory

Os volumes do NetApp precisam de acesso às seguintes portas nos servidores DNS configurados na sua política do Active Directory para identificar controladores de domínio do Active Directory. Os volumes NetApp usam procuras de DNS para a deteção do controlador 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 proveniente do intervalo CIDR para volumes NetApp:

• 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

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

Anexe a etiqueta de firewall aos servidores Active Directory

Use as instruções seguintes para anexar a etiqueta de firewall aos seus servidores 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 dos volumes NetApp

   • VPC_NAME: o nome da VPC

3. Anexe a seguinte etiqueta aos seus servidores DNS:

   allow-netappvolumes-to-dns

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

   allow-netappvolumes-to-activedirectory

Regras de firewall para acesso a volumes iSCSI

Para o acesso iSCSI, os volumes NetApp usam portas de rede específicas para ativar a comunicação entre iniciadores (clientes) e destinos (volumes de armazenamento). Para uma conetividade adequada e um acesso bem-sucedido aos volumes de armazenamento em blocos, tem de configurar as suas firewalls para permitir as portas necessárias.

Certifique-se de que os seus iniciadores iSCSI conseguem comunicar com a seguinte porta de volumes da NetApp:

• 3260 TCP – Porta de destino iSCSI

Os endereços IP dos volumes NetApp são atribuídos automaticamente a partir do intervalo CIDR que atribuiu ao serviço durante a interligação de redes. Para mais informações, consulte Escolha um CIDR.

Controlos de acesso ao volume para protocolos NFS

Os volumes NetApp protegem o acesso através de 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 que clientes têm autorização para montar volumes. O NetApp Volumes avalia as regras de exportação por ordem sequencial e para após a primeira correspondência. Recomendamos que ordene as regras de exportação do mais específico para o mais genérico para obter os melhores resultados. Para mais informações sobre as regras de exportação, consulte o artigo Controlo de acesso em massa através de políticas de exportação.

Controlos de acesso ao volume para o protocolo SMB

O SMB usa autorizações ao nível da partilha para proteger o acesso ao volume e requer a autenticação no Active Directory. Estas autorizações permitem-lhe controlar quem tem acesso a partilhas através da rede.

Os volumes são criados com permissões de nível de partilha Todos e Controlo total. Pode modificar as autorizações ao nível da partilha através da consola do Windows ou da CLI do Windows.

Siga estas instruções para modificar as autorizações ao nível da partilha SMB através da consola do Windows ou da CLI do Windows:

Consola do Windows

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

2. Depois de abrir a consola Gestão do computador, clique em Ação > Ligar a outro computador.

3. Na caixa de diálogo Selecionar computador, introduza o nome NetBIOS da partilha SMB e clique em OK.

4. Depois de estabelecer ligação à partilha de ficheiros, aceda a Ferramentas do sistema > Pastas partilhadas > Partilhas para procurar a sua partilha.

5. Clique duas vezes em Nome da partilha e selecione o separador Permissões de partilha para controlar as permissões da partilha.

CLI do Windows

1. Abra uma linha de comandos do Windows.

2. Ligue-se à partilha de ficheiros.

   fsmgmt.msc /computer=<netbios_name_of_share>

3. Depois de estabelecer ligação à partilha de ficheiros, aceda a Ferramentas do sistema > Pastas partilhadas > Partilhas para procurar a sua partilha.

4. Clique duas vezes em Nome da partilha e selecione o separador Permissões de partilha para controlar as permissões da partilha.

Controlos de acesso ao volume para o protocolo iSCSI

O acesso a volumes iSCSI da NetApp é gerido através de grupos de anfitriões, que são objetos regionais que contêm um ou mais IQNs de iniciadores iSCSI. Um iniciador iSCSI é normalmente um sistema ou um servidor cliente que se liga a destinos de armazenamento através de uma rede com o protocolo iSCSI.

Quando um volume iSCSI é criado, é anexado a um grupo de anfitriões. Esta relação concede acesso ao volume iSCSI aos clientes iSCSI (iniciadores) nesse grupo de anfitriões, o que lhes permite descobrir o LUN e consumir o recurso de armazenamento. Apenas os iniciadores que são membros do grupo anfitrião podem ver e estabelecer ligação ao volume iSCSI atribuído.

Seguem-se as principais caraterísticas dos grupos de anfitriões e do acesso iSCSI:

• Controlo de visibilidade: os grupos de anfitriões restringem os clientes iSCSI que podem ver e aceder a volumes específicos. Se um iniciador não fizer parte de um grupo de anfitriões, não pode descobrir nem estabelecer ligação ao LUN.

• Âmbito regional: os grupos de anfitriões são objetos regionais, com a respetiva configuração e adesão limitadas a uma região específica no seu ambienteGoogle Cloud .

• Segurança por parte do cliente: embora os grupos de anfitriões controlem a visibilidade do volume, o administrador do cliente iSCSI é responsável pela implementação de controlos de acesso ao nível do utilizador no sistema cliente. Isto inclui a gestão de quem pode montar o volume iSCSI e quem pode aceder ao sistema de ficheiros criado no mesmo.

Autorizações do sistema de ficheiros baseadas no anfitrião

Depois de um LUN ser mapeado para um anfitrião, o sistema operativo do anfitrião é responsável por gerir as autorizações do sistema de ficheiros e os controlos de acesso. Por exemplo, os anfitriões do Windows usam autorizações NTFS e ACLs, enquanto os anfitriões do Linux e UNIX usam autorizações de ficheiros UNIX padrão e, opcionalmente, ACLs para proteger ficheiros e diretórios.

Esta abordagem de segurança de duas camadas ajuda a garantir que apenas os anfitriões autorizados podem aceder ao armazenamento ao nível do bloco, enquanto o sistema operativo do anfitrião gere a segurança ao nível do ficheiro de acordo com as políticas organizacionais.

Controlo de acesso a ficheiros

As secções seguintes fornecem detalhes sobre o controlo de acesso ao nível do ficheiro dos volumes NetApp.

Estilo de segurança do volume

Os volumes NetApp oferecem dois estilos de segurança para volumes, UNIX e NTFS, para acomodar os diferentes conjuntos de autorizaçõ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 aos ficheiros.

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

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ó pode escolher o estilo de segurança durante a criação do volume.

Controlo de acesso ao nível do ficheiro NFS para volumes ao estilo UNIX

Depois de um cliente montar um volume com êxito, os volumes NetApp verificam as autorizações de acesso a ficheiros e diretórios através do modelo de autorizações UNIX padrão denominado bits de modo. Pode definir e modificar autorizações através de chmod.

Os volumes NFSv4.1 também podem usar listas de controlo de acesso (ACLs) NFSv4. Se um ficheiro ou um diretório tiver bits de modo e uma ACL NFSv4, a ACL é usada para a verificação de autorizações. O mesmo se aplica a volumes que usam tipos de protocolos NFSv3 e NFSv4.1. Pode definir e modificar ACLs NFSv4 através de nfs4_getfacl e nfs4_setfacl.

Quando cria um novo volume no estilo UNIX, o root:root tem a propriedade do nó i de raiz e as autorizações 0770. Devido a esta definição de propriedade e autorização, um utilizador sem acesso root recebe um erro permission denied ao aceder ao volume após a montagem. Para permitir o acesso ao volume para utilizadores sem acesso root, um utilizador com acesso root tem de alterar a propriedade do inode root através do comando chown e modificar as autorizações de ficheiros através do comando chmod.

Controlo de acesso a ficheiros SMB para volumes no estilo NTFS

Para volumes do tipo NTFS, recomendamos que use um modelo de autorização NTFS. Cada ficheiro e diretório tem uma ACL NTFS que pode modificar através do Explorador de Ficheiros, da ferramenta de linha de comando icacls ou do PowerShell. No modelo de autorizações NTFS, os novos ficheiros e pastas herdam as autorizações da respetiva pasta principal.

Mapeamento de utilizadores multiprotocolo

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

Quando cria um volume SMB e NFS de protocolo duplo, recomendamos vivamente que o Active Directory contenha um utilizador predefinido. O utilizador predefinido é usado quando um cliente NFS envia uma chamada NFS com um ID do utilizador que não está disponível no Active Directory. Em seguida, o NetApp Volumes tenta procurar um utilizador denominado pcuser, que funciona como um utilizador UNIX predefinido. Se esse utilizador não for encontrado, o acesso é recusado à chamada NFS.

Recomendamos que crie um utilizador predefinido no Active Directory com os seguintes atributos:

• uid = pcuser

• uidnumber = 65534

• cn = pcuser

• gidNumber = 65534

• objectClass = user

Consoante o protocolo usado pelo cliente (NFS ou SMB) e o estilo de segurança do volume (UNIX ou NTFS), os volumes NetApp podem verificar diretamente as autorizações de acesso do utilizador ou requerem o mapeamento da identidade do utilizador para a outra plataforma primeiro.

Protocolo de acesso	Estilo de segurança	Identidade usada pelo protocolo	Mapeamento obrigatório
NFSv3	UNIX	ID do utilizador e ID do grupo	N/A
NFSv3	NTFS	ID do utilizador e ID do grupo	User-ID para nome de utilizador para identificador de segurança
SMB	UNIX	Identificador de segurança	Identificador de segurança para nome de utilizador para ID do utilizador
SMB	NTFS	Identificador de segurança	N/A

Quando o mapeamento é necessário, os volumes do NetApp baseiam-se nos dados armazenados no LDAP do Active Directory. Para mais informações, consulte o artigo Exemplos de utilização do Active Directory.

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

Cientista Charlie E. (charliee) quer aceder a um volume do NetApp Volumes através do SMB a partir de um cliente Windows. Uma vez que o volume contém resultados gerados por uma máquina fornecidos por um cluster de computação Linux, o volume está configurado para armazenar autorizações UNIX.

O cliente Windows envia uma chamada SMB para o volume. A chamada SMB contém a identidade do utilizador como um identificador de segurança. O identificador de segurança não é comparável com as autorizações de ficheiros do ID do utilizador e do ID do grupo, e requer mapeamento.

Para concluir o mapeamento necessário, o NetApp Volumes executa os seguintes passos:

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

2. O NetApp Volumes pede ao Active Directory para devolver o ID do utilizador e o ID do grupo para charliee.

3. O NetApp Volumes verifica o acesso em relação ao ID do utilizador proprietário e ao ID do grupo do ficheiro através do ID do utilizador e do ID do grupo devolvidos.

Cenário de mapeamento de utilizadores multiprotocolo: acesso NFS a um volume NTFS

O engenheiro Amal L. precisa de aceder a alguns dados num volume a partir de um cliente Linux usando o NFS. Uma vez que o volume é usado principalmente para armazenar dados do Windows, está configurado com o estilo de segurança NTFS.

O cliente Linux envia uma chamada NFS para os volumes NetApp. A chamada NFS contém identificadores de ID do utilizador e ID do grupo que não podem ser associados a um identificador de segurança sem mapeamento.

Para concluir o mapeamento necessário, o NetApp Volumes pede ao Active Directory o nome de utilizador do ID do utilizador e para devolver o identificador de segurança do nome de utilizador. Em seguida, verifica o acesso em relação ao identificador de segurança do proprietário do ficheiro acedido através do identificador de segurança devolvido.

Encriptação em trânsito

A encriptação em trânsito protege os dados contra a intercetação numa rede. O tráfego para a replicação de volumes, a cópia de segurança integrada e a migração de volumes é encriptado por predefinição através do TLS 1.2. Para o tráfego NFS e SMB, pode configurar definições de encriptação específicas do protocolo para uma proteção adicional.

NFS

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

SMB

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

Replicação de volumes

Os volumes da NetApp podem replicar volumes entre Google Cloud regiões para oferecer proteção de dados. Uma vez que o tráfego reside na Google Cloud, a infraestrutura de rede da Google protege o processo de transferência, que tem acesso limitado para evitar a intercetação não autorizada. Além disso, o tráfego de replicação é encriptado através das normas TLS 1.2 em conformidade com a FIPS 140-2.

Cópia de segurança integrada

Uma cópia de segurança integrada cria cópias de segurança de volumes NetApp no serviço. O tráfego de cópia de segurança permanece na infraestrutura de rede da Google e é encriptado através da norma TLS 1.2 em conformidade com a FIPS 140-2. Além disso, os cofres de cópias de segurança armazenam estas cópias de segurança através da Google-owned and Google-managed encryption key para maior segurança.

Migração de volumes

A migração de volumes envia dados do sistema ONTAP ou Cloud Volumes ONTAP de origem para os volumes NetApp. A comunicação entre o sistema de origem e os volumes NetApp é encriptada através de normas TLS 1.2 em conformidade com a FIPS 140-2.

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

• ICMP

• 10000/TCP

• 11104/TCP

• 11105/TCP

Certifique-se de que qualquer firewall entre a interface lógica (LIF) intercluster do seu sistema ONTAP e o endereço IP de migração dos volumes NetApp permite estas portas.

O que se segue?

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