Entender a criptografia de dados no Azure NetApp Files

O Azure NetApp Files criptografa dados por meio de dois métodos diferentes:

Criptografia em repouso: os dados são criptografados no local usando padrões compatíveis com FIPS 140-2.
Criptografia em trânsito: os dados são criptografados em trânsito ou na transmissão, pois são transferidos entre o cliente e o servidor.

Entenda a criptografia em repouso

Os dados inativos no Azure NetApp Files podem ser criptografados de duas maneiras:

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

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

Entender a criptografia de dados em trânsito

Além de proteger dados inativos, o Azure NetApp Files pode proteger dados quando estiver em trânsito entre pontos de extremidade. O método de criptografia usado depende do protocolo ou do recurso. O DNS não é criptografado em trânsito nos arquivos do Azure NetApp. Continue lendo para saber mais sobre criptografia SMB e NFS, LDAP e replicação de dados no Azure NetApp Files.

Criptografia SMB

Os clientes SMB do Windows que usam a versão do protocolo SMB3.x dão suporte nativo à criptografia SMB. A criptografia SMB é realizada de ponta a ponta e criptografa toda a 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 do Azure NetApp Files, 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 as práticas recomendadas de desempenho do SMB para o Azure NetApp Files.

Exigir criptografia para conexões SMB

O Azure NetApp Files fornece uma opção para impor a criptografia em todas as conexões SMB. A imposição de criptografia impede a comunicação SMB não criptografada e utiliza o SMB3 e versões posteriores para conexões SMB. A criptografia é executada usando a criptografia AES e criptografa todos os pacotes SMB. Para que esse recurso funcione corretamente, os clientes SMB devem dar suporte à criptografia SMB. Se o cliente SMB não der suporte à criptografia e ao 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.

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

Proteção UNC

Em 2015, a Microsoft introduziu a proteção UNC (MS15-011 e MS15-014) para abordar vulnerabilidades de caminho de rede remoto que poderiam permitir a execução remota de código entre compartilhamentos SMB. Para obter mais informações, consulte MS15-011 & MS15-014: Reforço da Política de Grupo.

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 (criptografia total de pacotes SMB) habilitada/desabilitada para evitar detecção de tráfego.

O Azure NetApp Files dá suporte a todas as três formas de endurecimento UNC.

NFS Kerberos

O Azure NetApp Files também fornece 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 dá 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 (krb5i) – Autenticação inicial e verificação de integridade; requer uma troca de tíquetes/login de usuário Kerberos para acessar a exportação NFS e adiciona verificações de integridade a cada pacote NFS para evitar ataques intermediários (MITM).
Kerberos 5p (krb5p) – Autenticação inicial, verificação de integridade e privacidade; requer uma troca de tíquetes Kerberos/entrada do usuário para acessar a exportação do 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 sobre o 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, krb5 tem um desempenho melhor do que krb5i, krb5i tem um desempenho melhor do que krb5p, o AES-128 tem um desempenho melhor que o AES-256 e assim por diante. Para obter mais informações sobre o efeito de desempenho do NFS Kerberos no Azure NetApp Files, consulte o impacto de desempenho do Kerberos em volumes do NFSv4.1 do Azure NetApp Files.

Observação

O NFS Kerberos só tem suporte com o NFSv4.1 no Azure NetApp Files.

Na imagem a seguir, Kerberos 5 (krb5) é usado; somente a solicitação de autenticação inicial (a aquisição de entrada/tíquete) é criptografada. Todo o outro tráfego NFS chega em texto sem formatação.

Ao usar 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; krb5p) fornece criptografia de ponta a ponta de todo o tráfego NFS, conforme mostrado na imagem de rastreamento de tráfego usando um encapsulamento 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

No Azure NetApp Files, 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 no acesso para evitar a detecção de pacotes e ataques intermediários (espionagem ou representação entre pontos de extremidade de comunicação). Além disso, o tráfego de replicação é criptografado usando 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 associação do LDAP é transmitido em texto não cifrado, o que significa que qualquer pessoa com acesso para farejar pacotes de rede pode obter informações do servidor LDAP, como nomes de usuário, IDs numéricas, associações de grupo etc. Essas informações podem ser usadas para personificar usuários, enviar e-mails para ataques de phishing etc.

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

Assinatura LDAP

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

O Windows Active Directory também permite que você use a assinatura e criptografia de pacotes LDAP (criptografia de ponta a ponta de pacotes LDAP). O Azure NetApp Files não dá suporte a esse recurso.

Associação de canal LDAP

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

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

O Azure NetApp Files, por padrão, dá suporte à associação de canal LDAP de forma oportunista, o que significa que a associação de canal LDAP é usada quando o cliente dá suporte a ela. Se não suportar/enviar associação de canal, a comunicação ainda será permitida e a vinculação de canal não será imposta.

LDAP via SSL (porta 636)

O tráfego LDAP no Azure NetApp Files passa pela porta 389 em todos os casos. Essa porta não pode ser modificada. Não há suporte para LDAP sobre SSL (LDAPS) e é considerado herdado pela maioria dos fornecedores de servidor LDAP (RFC 1777 foi publicado em 1995). Se você quiser usar a criptografia LDAP com o Azure NetApp Files, use LDAP no TLS.

LDAP sobre StartTLS

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

O LDAP sobre StartTLS usa a porta 389 para a conexão LDAP. Depois que a conexão LDAP inicial for feita, uma OID StartTLS será trocada e os certificados serão comparados; em seguida, todo o tráfego LDAP é criptografado usando TLS. A captura de pacote mostrada abaixo mostra a associação LDAP, o handshake StartTLS e o tráfego LDAP criptografado por TLS subsequente.

Há duas diferenças principais entre LDAPS e StartTLS:

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. 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. Para fins de segurança, a maioria dos administradores LDAP não permite isso. 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 o SSL autoassinado e a autoridade de certificação.
Impedir consultas LDAP e associações que não usam StartTLS. Por padrão, o Active Directory desabilita associações anônimas.

Conexão de segurança do Active Directory

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