Entender a criptografia de dados no Azure NetApp Files
O Azure NetApp Files criptografam 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 por fio - à medida que são transferidos entre o cliente e o servidor.
Entenda a criptografia em repouso
Os dados em repouso 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 em nível de hardware na camada de 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 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 Microsoft chaves gerenciadas por plataforma ou chaves gerenciadas pelo cliente.
Compreender a criptografia de dados em trânsito
Além de proteger dados em repouso, o Azure NetApp Files pode proteger dados quando eles estão em trânsito entre pontos de extremidade. O método de criptografia usado depende do protocolo ou 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 oferecem suporte nativo criptografia SMB. A criptografia SMB é conduzida de ponta a ponta e criptografa toda a conversa SMB usando conjuntos 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 Práticas recomendadas de desempenho SMB para Azure NetApp Files.
Exigindo criptografia para conexões SMB
O Azure NetApp Files fornece uma opção para impor criptografia em todas as conexões SMB. A imposição de criptografia não permite a comunicação SMB não criptografada e usa o SMB3 e posterior para conexões SMB. A criptografia é executada usando criptografia AES e criptografa todos os pacotes SMB. Para que esse recurso funcione corretamente, os clientes SMB devem oferecer suporte à criptografia SMB. Se o cliente SMB não oferecer suporte a 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 em nível de compartilhamento SMB
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 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: Protegendo a 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/desativada para evitar a detecção de tráfego.
Os Azure NetApp Files dá suporte a todas as três formas de proteção UNC.
NFS Kerberos
O Azure NetApp Files também fornece a capacidade de criptografar conversas NFSv4.1 por meio da autenticação Kerberos usando conjuntos criptográficos AES-256-GCM/AES-128-GCM e AES-256-CCM/AES-128-CCM.
Com o NFS Kerberos, os 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 (
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/entrada 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 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, AES-128 tem um desempenho melhor do que AES-256 e assim por diante. Para obter mais informações sobre o efeito de desempenho do Kerberos NFS em arquivos do Azure NetApp, consulte Impacto no desempenho do Kerberos nos volumes 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 login/ticket) é criptografada. Todo o outro tráfego NFS chega em texto sem formatação.
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; krb5p) fornece criptografia de ponta a ponta de todo o tráfego NFS, conforme 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
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 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 ligação LDAP passa pelo fio em texto sem formatação, 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 interceptadas 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 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 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 (KDC) Kerberos do Active 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 é perceptível para os usuários finais.
O Windows Active Directory também permite que você use a assinatura e selagem LDAP (criptografia de ponta a ponta de pacotes LDAP). O Azure NetApp Files não oferece suporte a esse recurso.
Associação de canal LDAP
Devido a uma vulnerabilidade de segurança descoberta em controladores de domínio do Active Directory do Windows, uma configuração padrão foi alterada para servidores Windows. Para obter detalhes, consulte 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 oferecer suporte a 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.
O Azure NetApp Files, por padrão, dá suporte à vinculação de canal LDAP de forma oportunista, o que significa que a associação de canal LDAP é usada quando o cliente oferece 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 sobre SSL (porta 636)
O tráfego LDAP no Azure NetApp Files 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 o Azure NetApp Files, use LDAP sobre TLS.
LDAP sobre StartTLS
O 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 preterido.
O 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:
- 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 volte para o LDAP normal. 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 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.
- 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 agendadas de senha do servidor SMB) usam o tipo de criptografia mais alto disponível com suporte nos controladores de domínio. O Azure NetApp Files dão suporte aos seguintes tipos de criptografia para comunicações de controlador de domínio, em ordem de tentativa de autenticação: AES-256, AES-128, RC4-HMAC, DES
Observação
Não é possível desabilitar tipos de autenticação mais fracos no Azure NetApp Files (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 no Azure NetApp Files para a funcionalidade adequada.