Compreender a encriptação de dados nos ficheiros NetApp do Azure

Os Arquivos NetApp do Azure criptografam dados por meio de dois métodos diferentes:

• Criptografia em repouso: os dados são criptografados in-loco usando padrões compatíveis com FIPS 140-2.
• Criptografia em trânsito: os dados são criptografados em trânsito - ou por fio - à medida que são transferidos entre o cliente e o servidor.

Compreender a encriptação em repouso

Os dados em repouso nos Arquivos NetApp do Azure podem ser criptografados de duas maneiras:

• A criptografia única usa criptografia baseada em software para volumes de Arquivos NetApp do Azure.
• A criptografia dupla adiciona criptografia no nível de hardware na camada do dispositivo de armazenamento físico.

Os Arquivos NetApp do Azure usam CryptoMod padrão para gerar chaves de criptografia AES-256. O CryptoMod está listado na lista de módulos validados CMVP FIPS 140-2, para obter mais informações, consulte FIPS 140-2 Cert #4144. As chaves de criptografia estão associadas aos volumes e podem ser chaves gerenciadas pela plataforma Microsoft ou chaves gerenciadas pelo cliente.

Compreender a criptografia de dados em trânsito

Além de proteger os dados em repouso, os Arquivos NetApp do Azure podem proteger os dados quando eles estão em trânsito entre pontos de extremidade. O método de encriptação utilizado depende do protocolo ou funcionalidade. O DNS não é criptografado em trânsito nos arquivos NetApp do Azure. Continue lendo para saber mais sobre criptografia SMB e NFS, LDAP e replicação de dados nos Arquivos NetApp do Azure.

Encriptação SMB

Os clientes SMB do Windows que usam a versão do protocolo SMB3.x suportam nativamente a criptografia SMB. A criptografia SMB é conduzida de ponta a ponta e criptografa a totalidade da conversa SMB usando pacotes criptográficos AES-256-GCM/AES-128-GCM e AES-256-CCM/AES-128-CCM.

A criptografia SMB não é necessária para volumes de Arquivos NetApp do Azure, mas pode ser usada para segurança extra. A criptografia SMB adiciona uma sobrecarga de desempenho. Para saber mais sobre considerações de desempenho com criptografia SMB, consulte Práticas recomendadas de desempenho SMB para arquivos NetApp do Azure.

Exigindo criptografia para conexões SMB

Os Arquivos NetApp do Azure fornecem uma opção para impor a criptografia em todas as conexões SMB. A imposição de criptografia não permite a comunicação SMB não criptografada e usa SMB3 e posterior para conexões SMB. A encriptação é executada usando encriptação AES e encripta todos os pacotes SMB. Para que esse recurso funcione corretamente, os clientes SMB devem oferecer suporte à criptografia SMB. Se o cliente SMB não suportar criptografia e SMB3, as conexões SMB não serão permitidas. Se essa opção estiver habilitada, todos os compartilhamentos que têm o mesmo endereço IP exigirão criptografia, substituindo assim a configuração da propriedade de compartilhamento SMB para criptografia.

Criptografia de nível de compartilhamento SMB

Como alternativa, a criptografia pode ser definida no nível de compartilhamento individual de um volume de Arquivos NetApp do Azure.

Endurecimento UNC

Em 2015, a Microsoft introduziu a proteção UNC (MS15-011 e MS15-014) para resolver vulnerabilidades de caminho de rede remoto que poderiam permitir a execução remota de código em compartilhamentos SMB. Para obter mais informações, consulte MS15-011 & MS15-014: Hardening Group Policy.

A proteção UNC fornece três opções para proteger caminhos UNC:

• RequireMutualAuthentication – Autenticação de identidade necessária/não necessária para bloquear ataques de falsificação.
• RequireIntegrity – Verificação de integridade necessária/não necessária para bloquear ataques de adulteração.
• RequirePrivacy – Privacidade (encriptação total de pacotes SMB) ativada/desativada para evitar a deteção de tráfego.

Os Arquivos NetApp do Azure dão suporte a todas as três formas de proteção UNC.

NFS Kerberos

Os Arquivos NetApp do Azure também fornecem a capacidade de criptografar conversas NFSv4.1 por meio da autenticação Kerberos usando pacotes criptográficos AES-256-GCM/AES-128-GCM e AES-256-CCM/AES-128-CCM.

Com o NFS Kerberos, o Azure NetApp Files oferece suporte a três tipos de segurança diferentes:

• Kerberos 5 (krb5) – Somente autenticação inicial; requer uma troca de tíquetes/login de usuário Kerberos para acessar a exportação NFS. Os pacotes NFS não são criptografados.
• Kerberos 5i () – Autenticação inicial e verificação de integridade: requer uma troca de tíquetes/entrada de usuário Kerberos para acessar a exportação NFS e adiciona verificações de integridade a cada pacote NFS para evitar ataques man-in-the-middle (krb5iMITM).
• Kerberos 5p (krb5p) – Autenticação inicial, verificação de integridade e privacidade: requer uma troca de tíquetes/login de usuário Kerberos para acessar a exportação NFS, executa verificações de integridade e aplica um wrapper GSS a cada pacote NFS para criptografar seu conteúdo.

Cada nível de criptografia Kerberos tem um efeito no desempenho. À medida que os tipos de criptografia e os tipos de segurança incorporam métodos mais seguros, o efeito de desempenho aumenta. Por exemplo, executa melhor do que , krb5i executa melhor do que , AES-128 executar melhor do que krb5ikrb5pAES-256, krb5 e assim por diante. Para obter mais informações sobre o efeito de desempenho do Kerberos NFS nos Arquivos NetApp do Azure, consulte Impacto no desempenho do Kerberos nos volumes NFSv4.1 dos Arquivos NetApp do Azure.

Nota

O Kerberos NFS só é suportado com NFSv4.1 nos Arquivos NetApp do Azure.

Na imagem a seguir, Kerberos 5 () é usado, apenas a solicitação de autenticação inicial (krb5a aquisição de login/tíquete) é criptografada. Todo o outro tráfego NFS chega em texto simples.

Ao usar o Kerberos 5i (krb5i; verificação de integridade), um rastreamento mostra que os pacotes NFS não são criptografados, mas há um wrapper GSS/Kerberos adicionado ao pacote que exige que o cliente e o servidor garantam a integridade dos dados transferidos usando uma soma de verificação.

Kerberos 5p (privacidade; ) fornece criptografia de ponta a ponta de todo o tráfego NFS, krb5pconforme mostrado na imagem de rastreamento usando um wrapper GSS/Kerberos. Esse método cria a maior sobrecarga de desempenho devido à necessidade de processar a criptografia de cada pacote NFS.

Replicação de dados

Nos Arquivos NetApp do Azure, você pode replicar volumes inteiros entre zonas ou regiões no Azure para fornecer proteção de dados. Como o tráfego de replicação reside na nuvem do Azure, as transferências ocorrem na infraestrutura de rede segura do Azure, que é limitada em acesso para evitar a deteção de pacotes e ataques man-in-the-middle (escuta ou representação entre pontos de extremidade de comunicação). Além disso, o tráfego de replicação é criptografado usando os padrões TLS 1.2 compatíveis com FIPS 140-2. Para obter detalhes, consulte Perguntas frequentes sobre segurança.

Criptografia LDAP

Normalmente, o tráfego de pesquisa e vinculação LDAP passa pelo fio em texto simples, o que significa que qualquer pessoa com acesso a pacotes de rede sniff pode obter informações do servidor LDAP, como nomes de usuário, IDs numéricos, associações de grupo, etc. Essas informações podem ser usadas para falsificar usuários, enviar e-mails para ataques de phishing, etc.

Para proteger as comunicações LDAP de serem intercetadas e lidas, o tráfego LDAP pode aproveitar a criptografia over-the-wire aproveitando AES e TLS 1.2 via assinatura LDAP e LDAP sobre TLS, respectivamente. Para obter detalhes sobre como configurar essas opções, consulte Criar e gerenciar conexões do Ative Directory.

Assinatura LDAP

A assinatura LDAP é específica para conexões em servidores Microsoft Ative Directory que hospedam identidades UNIX para usuários e grupos. Essa funcionalidade permite a verificação de integridade para ligações LDAP SASL (Simple Authentication and Security Layer) a servidores AD que hospedam conexões LDAP. A assinatura não requer a configuração de certificados de segurança porque usa a comunicação GSS-API com os serviços do Centro de Distribuição de Chaves Kerberos (KDC) do Ative Directory. A assinatura LDAP verifica apenas a integridade de um pacote LDAP; ele não criptografa a carga útil do pacote.

A assinatura LDAP também pode ser configurada do lado do servidor Windows por meio da Política de Grupo para ser oportunista com a assinatura LDAP (nenhuma – suporte se solicitado pelo cliente) ou para impor a assinatura LDAP (exigir). A assinatura LDAP pode adicionar alguma sobrecarga de desempenho ao tráfego LDAP que geralmente não é percetível para os usuários finais.

O Windows Ative Directory também permite que você use assinatura e selagem LDAP (criptografia de ponta a ponta de pacotes LDAP). Os Arquivos NetApp do Azure não oferecem suporte a esse recurso.

Vinculação de canal LDAP

Devido a uma vulnerabilidade de segurança descoberta nos controladores de domínio do Windows Ative Directory, uma configuração padrão foi alterada para servidores Windows. Para obter detalhes, consulte o Comunicado de Segurança da Microsoft ADV190023.

Essencialmente, a Microsoft recomenda que os administradores habilitem a assinatura LDAP junto com a vinculação de canal. Se o cliente LDAP suportar tokens de vinculação de canal e assinatura LDAP, a vinculação e a assinatura de canal serão necessárias, e as opções do Registro serão definidas pelo novo patch da Microsoft.

Os Arquivos NetApp do Azure, por padrão, oferecem suporte à vinculação de canal LDAP de forma oportunista, o que significa que a vinculação de canal LDAP é usada quando o cliente a suporta. Se não suportar/enviar vinculação de canal, a comunicação ainda será permitida e a vinculação de canal não será imposta.

LDAP sobre SSL (porta 636)

O tráfego LDAP nos Arquivos NetApp do Azure passa pela porta 389 em todos os casos. Esta porta não pode ser modificada. LDAP sobre SSL (LDAPS) não é suportado e é considerado herdado pela maioria dos fornecedores de servidores LDAP (RFC 1777 foi publicado em 1995). Se você quiser usar a criptografia LDAP com os Arquivos NetApp do Azure, use LDAP sobre TLS.

LDAP sobre StartTLS

LDAP sobre StartTLS foi introduzido com RFC 2830 em 2000 e foi combinado no padrão LDAPv3 com RFC 4511 em 2006. Depois que o StartTLS se tornou um padrão, os fornecedores de LDAP começaram a se referir ao LDAPS como obsoleto.

LDAP sobre StartTLS usa a porta 389 para a conexão LDAP. Após a conexão LDAP inicial ter sido feita, um OID StartTLS é trocado e os certificados são comparados; em seguida, todo o tráfego LDAP é criptografado usando TLS. A captura de pacotes mostrada abaixo mostra a ligação LDAP, o handshake StartTLS e o tráfego LDAP criptografado por TLS subsequente.

Existem duas diferenças principais entre LDAPS e StartTLS:

• O StartTLS faz parte do padrão LDAP; LDAPS não é. Como resultado, o suporte à biblioteca LDAP nos servidores ou clientes LDAP pode variar e a funcionalidade pode ou não funcionar em todos os casos.
• Se a criptografia falhar, o StartTLS permitirá que a configuração retorne ao LDAP regular. O LDAPS não. Como resultado, o StartTLS oferece alguma flexibilidade e resiliência, mas também apresenta riscos de segurança se estiver configurado incorretamente.

Considerações de segurança com LDAP sobre StartTLS

O StartTLS permite que os administradores retornem ao tráfego LDAP regular, se desejarem. Por motivos de segurança, a maioria dos administradores LDAP não o permite. As seguintes recomendações para StartTLS podem ajudar a proteger a comunicação LDAP:

• Verifique se o StartTLS está habilitado e se os certificados estão configurados.
• Para ambientes internos, você pode usar certificados autoassinados, mas para LDAP externo, use uma autoridade de certificação. Para obter mais informações sobre certificados, consulte a Diferença entre SSL autoassinado & Autoridade de certificação.
• Impeça consultas LDAP e ligações que não usam StartTLS. Por padrão, o Ative Directory desabilita associações anônimas.

Conexão de segurança do Ative Directory

As conexões do Ative Directory com os volumes do Azure NetApp Files podem ser configuradas para experimentar primeiro o tipo de criptografia Kerberos mais forte disponível: AES-256. Quando a criptografia AES está habilitada, as comunicações do controlador de domínio (como redefinições agendadas de senha do servidor SMB) usam o tipo de criptografia mais alto disponível suportado nos controladores de domínio. Os Arquivos NetApp do Azure dão suporte aos seguintes tipos de criptografia para comunicações do controlador de domínio, na ordem de tentativa de autenticação: AES-256, AES-128, RC4-HMAC, DES

Nota

Não é possível desabilitar tipos de autenticação mais fracos nos Arquivos NetApp do Azure (como RC4-HMAC e DES). Em vez disso, se desejado, eles devem ser desabilitados do controlador de domínio para que as solicitações de autenticação não tentem usá-los. Se o RC4-HMAC estiver desabilitado nos controladores de domínio, a criptografia AES deverá ser habilitada nos Arquivos NetApp do Azure para funcionalidade adequada.

Próximos passos

• Criptografia dupla dos Arquivos NetApp do Azure em repouso
• Configurar chaves gerenciadas pelo cliente para criptografia de volume dos Arquivos NetApp do Azure
• Compreender as opções de proteção de dados e recuperação de desastres nos Arquivos NetApp do Azure
• Criar e gerir ligações do Active Directory