Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo fornece orientações de segurança para o Ficheiros do Azure, incluindo partilhas de ficheiros clássicas criadas com a Microsoft.Storage e partilhas de ficheiros criadas com a Microsoft.FileShares. Abrange os recursos que detêm as suas ações, o acesso dos clientes, a proteção de dados e os controlos operacionais.
Os controlos de segurança dependem do fornecedor de recursos e do protocolo. Para uma comparação das funcionalidades suportadas, veja conceitos de gestão do Ficheiros do Azure.
Isolamento de recursos
Trate a conta de armazenamento como um limite de confiança: Criar partilhas clássicas separadas de ficheiros na mesma conta de armazenamento não isola as regras de rede, a fonte de identidade da SMB ou a configuração da chave de encriptação. Alterações a estas definições ao nível da conta afetam todas as partilhas na conta. Agrupe os recursos partilhados clássicos apenas quando estes puderem partilhar estes controlos. Microsoft. FileShares evita esta fronteira partilhada ao nível da conta ao fornecer configuração independente de rede e segurança para cada partilha.
Proteger sistemas clientes: Um cliente com acesso de escrita pode modificar ou eliminar dados de ficheiros. Mantenha os sistemas operativos dos clientes atualizados e restrinja o acesso administrativo local. Utilize proteção de endpoint adequada ao ambiente do cliente. O isolamento da rede e a encriptação não impedem um cliente autorizado de fazer alterações destrutivas.
Segurança de rede
Acesso de entrada e filtragem de saída
Limitar o acesso de entrada aos clientes que necessitam dele: Ambos os fornecedores de recursos suportam endpoints privados e endpoints de serviço com restrições de rede virtual. O acesso a partilhas de ficheiros do NFS Azure requer um destes caminhos. Os clientes clássicos SMB e FileREST também podem usar endpoints públicos com regras de endereço IP. Para os passos de configuração, veja Configurar endpoints de rede para partilhas de ficheiros Azure.
Desative o acesso público quando não for necessário: Os endpoints públicos podem ser usados de forma segura com controlos de acesso à rede, autenticação e encriptação adequados ao protocolo. Mantenha o acesso público ativado quando as suas cargas de trabalho o exigirem e o seu modelo de segurança o permitir, incluindo para ligações através de endpoints de serviço. Criar um endpoint privado não desativa automaticamente o acesso público. Para partilhas clássicas, reveja quaisquer exceções a serviços ou instâncias de recursos confiáveis que possam permanecer eficazes após o acesso público estar desativado. Para mais informações, veja Restringir o acesso a endpoints públicos.
Ative o acesso a serviços confiáveis apenas quando necessário: Disponível apenas para partilhas de ficheiros clássicas, a definição de serviços confiáveis permite que os serviços Azure suportados contornem as regras de rede da conta de armazenamento. Ative-o apenas quando uma integração precisar deste acesso. Estes serviços devem ainda estar autorizados a aceder aos dados dos seus ficheiros.
Filtragem opcional para tráfego de endpoint de serviço: Quando usa endpoints de serviço para aceder a partilhas de ficheiros clássicas, pode aplicar opcionalmente uma política de endpoint de serviço à sua sub-rede. A política limita as contas de armazenamento a que estes clientes podem aceder através dos endpoints de serviço, onde o tráfego contorna o Azure Firewall e os appliances virtuais de rede. Aplica-se apenas ao tráfego de endpoints de serviço e não filtra tráfego de endpoints privados ou outros caminhos de saída. As regras de rede e os requisitos de autorização do destino continuam a aplicar-se. Microsoft.FileShares atualmente não suporta estas políticas. Clientes numa sub-rede com uma política devem usar um endpoint privado para aceder às partilhas Microsoft.FileShares. Para mais informações, consulte Políticas de ponto final de serviço.
Verifique o suporte ao protocolo antes de usar um perímetro de segurança de rede: Para partilhas clássicas, o suporte ao perímetro difere consoante o protocolo e o método de autenticação. No modo Enforced, um perímetro nega o acesso ao NFS através do endpoint público, incluindo o tráfego do endpoint de serviço. O tráfego dos endpoints privados está fora da imposição do perímetro. Verifique as restrições para Azure Backup e Azure File Sync antes de aplicar um perímetro. Para mais informações, consulte Perímetro de Segurança de Rede para Ficheiros do Azure.
Endurecimento do protocolo SMB
Estas recomendações aplicam-se a partilhas de ficheiros SMB clássicas.
Exigir encriptação do canal SMB: Utilize ligações SMB 3.x encriptadas. O SMB 2.1 não suporta encriptação de canais. O requisito de HTTPS para o FileREST não substitui a configuração de encriptação SMB. Para mais informações, consulte encriptação SMB e definições de segurança.
Restringa versões de protocolo e algoritmos àqueles de que os seus clientes precisam: Use o perfil SMB mais seguro compatível com as suas cargas de trabalho. Verifique o suporte do cliente antes de exigir SMB 3.1.1 ou AES-256-GCM, porque clientes incompatíveis não conseguem estabelecer ligação. A encriptação de canais SMB e a encriptação de bilhetes Kerberos são controlos separados. Para mais informações, consulte as definições de segurança do SMB.
Limitar os métodos de autenticação SMB: Use o Kerberos para acesso baseado em identidade. Se nenhum cliente precisar de autenticação por chave de conta de armazenamento via SMB, remover o NTLMv2 dos métodos de autenticação SMB permitidos após testes. Este controlo aplica-se ao SMB; não desativa o acesso FileREST baseado em chaves.
Manter credenciais AD DS quando aplicável: Para autenticação AD DS, gira a palavra-passe do principal do diretório que representa a conta de armazenamento de acordo com a sua política de diretório. Siga o procedimento de rotação documentado para manter a palavra-passe do diretório e a chave Kerberos da conta de armazenamento sincronizadas. Para mais informações, consulte Atualização da palavra-passe da identidade da conta de armazenamento no AD DS.
Partilhas de ficheiros NFS 4.1
Estas recomendações aplicam-se a partilhas de ficheiros NFS com qualquer um dos fornecedores de recursos. O NFS utiliza autenticação baseada em rede e permissões POSIX, não autenticação baseada na identidade do SMB.
Limitar o acesso a redes de confiança: Permitir apenas as sub-redes e ligações privadas necessárias para a carga de trabalho. O NFS baseia-se nas identidades apresentadas pelo cliente, por isso, controle quais os sistemas e administradores que podem usar essas ligações.
Gerir permissões POSIX e identidades de clientes: Utilize IDs de utilizador e de grupo consistentes entre os clientes. Restringa permissões de ficheiros e diretórios aos utilizadores e grupos que necessitem de acesso. As permissões RBAC do Azure para gerir o recurso Azure não concedem acesso a ficheiros NFS. Para mais informações, consulte autenticação NFS e acesso à rede.
Configure root squash quando compatível com a carga de trabalho: Root squash mapeia pedidos do UID/GID 0 para uma identidade anónima. Não restringe outras identidades nem torna uma partilha apenas de leitura. Para definições e passos de configuração para ambos os fornecedores de recursos, veja Root squashing para partilhas de ficheiros NFS Azure.
Exigir encriptação em trânsito: Ambos os fornecedores de recursos suportam TLS através do auxiliar de montagem AZNFS. O Microsoft.FileShares requer encriptação em trânsito por defeito. As partilhas clássicas têm definições de encriptação NFS ao nível da conta de armazenamento. Para valores predefinidos e links de configuração, veja encriptação NFS.
Gestão de identidade e acesso
Gerenciamento de recursos do Azure
Utilize o privilégio mínimo para acesso de gestão: Conceda permissões RBAC ao Azure no menor escopo necessário para criar, configurar ou eliminar recursos. Para as partilhas clássicas, as permissões ao nível da conta podem afetar todas as partilhas da conta. Pode gerir os recursos Microsoft.FileShares de forma independente. Os papéis de gestão e as permissões de acesso a dados têm propósitos diferentes. Para mais informações, veja Azure plano de controlo e plano de dados.
Limitar o acesso administrativo permanente: Use Microsoft Entra Privileged Identity Management quando apropriado para funções privilegiadas Azure. Exija aprovação e autenticação multifator para ativação administrativa de acordo com a política da sua organização. Para mais informações, consulte Gestão de Identidade Privilegiada.
Autenticação baseada em identidade para partilhas de ficheiros SMB
O acesso baseado em identidade SMB está disponível para partilhas de ficheiros clássicas. Uma chave de conta de armazenamento concede acesso amplo a dados em todas as partilhas da conta e não identifica um utilizador individual.
Use uma origem de identidade suportada pelos seus clientes: O Ficheiros do Azure suporta o AD DS, o Microsoft Entra Domain Services e o Microsoft Entra Kerberos. Os seus requisitos de aplicação cliente e identidade diferem. Para cenários suportados e guias de configuração, consulte Autenticação baseada em identidade para Ficheiros do Azure.
Utilize identidades geridas para cargas de trabalho de aplicações suportadas: As identidades geridas podem fornecer acesso SMB sem distribuir chaves de conta de armazenamento. Verifique os pré-requisitos de computação, cliente e autenticação para a sua implementação. Para mais informações, consulte Aceder a partilhas SMB usando identidades geridas.
Proteger as chaves da conta quando forem necessárias: Restringir a permissão para recuperar ou regenerar chaves. Armazene as chaves necessárias no Azure Key Vault e faça a rotação das mesmas após a exposição ou de acordo com a sua política de credenciais. Planeie a rotação em torno dos clientes e integrações que ainda usam as chaves. Para obter mais informações, veja Gerir as chaves de acesso à conta de armazenamento.
Permissões ao nível de partilha e NTFS
Estas permissões aplicam-se a partilhas de ficheiros SMB clássicas.
Atribuir funções de nível de partilha no âmbito exigido: conceder acesso de leitura, escrita ou administração apenas às identidades que o necessitem. As atribuições de funções ao nível de partilha evitam conceder acesso a partilhas não relacionadas na mesma conta de armazenamento. Para obter mais informações, consulte Atribuir permissões de nível de compartilhamento.
Aplicar permissões de diretórios e ficheiros: Use ACLs do Windows, incluindo no diretório raiz da partilha quando necessário, para controlar o acesso dentro da partilha. Use a herança para manter as permissões geríveis. Tanto as permissões ao nível de partilha como as ACLs do Windows são aplicadas. Para mais informações, consulte Configurar permissões ao nível de diretório e ao nível de ficheiro.
Restringir a administração de permissões: Limitar funções elevadas e direitos de modificação de ACL a identidades responsáveis pela gestão das permissões. Revise tanto as atribuições de funções como as ACLs herdadas quando os requisitos de acesso mudarem.
Acesso FileREST e SAS
O acesso a dados FileREST está disponível para partilhas clássicas. Microsoft.FileShares atualmente não suporta acesso a dados FileREST.
Use OAuth para acesso suportado a dados administrativos: As identidades Microsoft Entra, incluindo identidades geridas, podem aceder a partilhas clássicas através do FileREST. Os papéis privilegiados usados por este método de acesso podem contornar permissões de ficheiros e diretórios, por isso atribua-os apenas quando esse acesso for necessário. Para mais informações, consulte Ficheiros do Azure OAuth over REST.
Limitar as permissões e a vida útil do SAS: Quando uma ferramenta suportada necessitar de uma assinatura de acesso partilhada (SAS), restrinja o seu âmbito, permissões e período de validade, exigindo HTTPS. Proteja o SAS como credencial. Os tokens SAS não são usados para montar shares em SMB ou NFS. Para mais informações, consulte Assinaturas de acesso partilhado.
Exigir HTTPS para FileREST: HTTPS protege os pedidos REST em trânsito. A encriptação do canal SMB e o tunelamento NFS TLS são separados do requisito HTTPS. Para os passos de configuração, consulte Transferência segura obrigatória.
Proteção de dados
Compreenda encriptação em repouso: Ambos os fornecedores de recursos encriptam os dados de ficheiros em repouso com chaves geridas pela Microsoft por defeito. A encriptação em repouso protege os dados armazenados; não impede que clientes autorizados leiam ou alterem ficheiros.
Utilize chaves geridas pelo cliente quando necessário: As partilhas clássicas suportam chaves geridas pelo cliente no Azure Key Vault ou Managed HSM. Microsoft.FileShares atualmente não suporta chaves geridas pelo cliente. Proteja o armazenamento de chaves, planeie a rotação de chaves e compreenda que a perda de acesso às chaves pode tornar os dados indisponíveis. Para mais informações, consulte Chaves geridas pelo cliente para Ficheiros do Azure.
Avalie a encriptação da infraestrutura para implementações clássicas aplicáveis: Contas de armazenamento clássicas podem ter uma camada adicional de encriptação quando exigida pela sua política de conformidade. Esta opção é selecionada na criação da conta e não pode ser alterada posteriormente. Para tipos de conta suportados, consulte Encriptação de infraestrutura.
Utilize bloqueios de recursos para proteger operações de gestão: Um bloqueio CanNotDelete no recurso Azure ou no âmbito principal apropriado pode impedir a eliminação através do Azure Resource Manager. Os bloqueios não impedem os clientes de modificar ou eliminar dados de ficheiros. Para partilhas clássicas, estas também não impedem a eliminação através das APIs do plano de dados FileREST. Para o comportamento do bloqueio e os efeitos operacionais, consulte Bloquear recursos do Azure.
Backup e recuperação
Faça snapshots de partilha de acordo com as necessidades de recuperação: Ambos os fornecedores de recursos suportam snapshots de partilha para recuperação de versões anteriores de ficheiros. Defina um calendário e uma política de retenção que cumpram os seus objetivos de recuperação. Os snapshots de partilha permanecem associados à partilha de origem, por isso não fornecem uma cópia de segurança independente se essa partilha for eliminada permanentemente. Para mais informações, consulte Partilhar instantâneos para Ficheiros do Azure.
Ativar a eliminação suave para partilhas clássicas: A eliminação suave mantém as partilhas eliminadas durante um período configurado. Não recupera ficheiros individuais nem snapshots apagados individualmente. Microsoft.FileShares atualmente não suporta eliminação suave. Para mais informações, consulte Prevenir a eliminação acidental de partilhas de ficheiros do Azure.
Escolha uma solução de backup suportada pelo protocolo: o Azure Backup suporta partilhas SMB clássicas, com opções de backup snapshot e em cofre. Atualmente, não suporta partilhas NFS com nenhum dos provedores de recursos. Para NFS, escolha uma solução de backup que suporte o protocolo e cumpra os seus requisitos de retenção e isolamento. Para obter informações sobre a cobertura do Azure Backup, veja suporte para cópia de segurança da partilha de ficheiros do Azure.
Administração separada de backups e recuperação para teste: Limite quem pode eliminar pontos de recuperação ou alterar a retenção. Teste restaurações de ficheiros, permissões e cargas de trabalho completas. Verifique se a recuperação é possível se as credenciais de produção ou a partilha de origem forem comprometidas.
Planeie a recuperação de falhas de infraestrutura separadamente da recuperação de dados: A redundância melhora a resiliência a falhas de infraestrutura, mas também replica alterações de dados. Não substitui backups para alterações indesejadas ou eliminação. As opções de redundância disponíveis variam consoante o media tier e o fornecedor de recursos. Para obter mais informações, consulte Redundância de arquivos do Azure.
Registo e monitorização
Alterações à gestão de auditoria para ambos os fornecedores de recursos: Use o Azure Activity Log para monitorizar a eliminação de recursos, alterações de configuração e atribuições de funções. Reveja as alterações ao acesso público, regras de rede, requisitos de encriptação e controlos de recuperação. Para obter mais informações, consulte Log de atividades do Azure.
Recolha registos de acesso a dados suportados: Para o acesso clássico SMB e FileREST, utilize registos de recursos de serviços de ficheiros para rever autores das chamadas, métodos de autorização, pedidos falhados e atividades de eliminação. Recolha os registos exigidos pela sua política de retenção no Log Analytics ou noutro destino suportado. Não assumas a mesma cobertura de registo de pedidos para NFS ou Microsoft.FileShares. Para operações e campos suportados, consulte referência de dados de monitorização do Ficheiros do Azure.
Correlacione alertas com registos do cliente e de identidade: Investigue o uso inesperado de chaves, falhas na autenticação, eliminação de partilhas e alterações na configuração de segurança. Utilize os registos do cliente e diretório quando ocorrer uma falha de autenticação antes do pedido chegar ao Ficheiros do Azure. Encaminhe os alertas para a equipa responsável pela carga de trabalho.
Avalie o Defender for Storage para implementações clássicas: O Defender for Storage fornece deteção de ameaças para contas de armazenamento suportadas. Verifique a cobertura de funcionalidades e protocolos para a sua implementação; a proteção da conta não implica que todas as operações de ficheiro sejam analisadas para malware. Para mais informações, consulte Microsoft Defender for Storage.
Conformidade e governança
Aplique políticas que correspondam ao fornecedor de recursos: Use o Azure Policy para auditar ou fazer cumprir os requisitos da sua organização onde o tipo de recurso e as propriedades são suportados. Verifique o âmbito e os efeitos de cada definição. Uma política direcionada para contas de armazenamento Microsoft.Storage não avalia automaticamente recursos Microsoft.FileShares. Para obter mais informações, consulte Definições de Política do Azure.
Propriedade de registos e requisitos de dados: Use etiquetas de recursos para identificar a equipa responsável, o ambiente e a classificação dos dados. Para as partilhas clássicas, os controlos ao nível da conta afetam todas as partilhas na conta. Registe exceções e reveja-as quando a responsabilidade da carga de trabalho mudar.
Valide a conformidade para a implementação: Confirme que o serviço, região, protocolo e funcionalidades de proteção selecionados cumprem os seus requisitos. Use o benchmark de segurança na cloud da Microsoft para organizar revisões de controlo. Para informações sobre certificação, consulte as ofertas de conformidade do Armazenamento do Azure.
Azure File Sync
O Azure File Sync suporta partilhas SMB clássicas. Não suporta NFS nem Microsoft.FileShares. Proteja tanto a partilha na cloud como os endpoints do Windows Server.
Utilize identidades geridas para implementações suportadas do File Sync: Siga a configuração de identidade gerida para o Storage Sync Service e servidores registados para remover a dependência de chaves partilhadas. Para mais informações, consulte Usar identidades geridas com Azure File Sync.
Limitar o acesso administrativo a recursos de sincronização e servidores: Utilizar as funções do Storage Sync necessárias no âmbito apropriado. Proteja as permissões locais de ficheiros e a administração do servidor porque as alterações feitas através de um endpoint de servidor podem ser sincronizadas com a partilha na cloud. Para mais informações, consulte Planear uma implementação do Azure File Sync.