Práticas recomendadas para o planejamento e a implantação seguros do AD FS
Este tópico fornece as informações de práticas recomendadas para ajudar você a planejar e avaliar a segurança ao projetar a implantação do AD FS (Serviços de Federação do Active Directory). Este tópico é um ponto de partida para as considerações de análise e avaliação que afetam a segurança geral do seu uso do AD FS. As informações contidas neste tópico visam complementar e estender o planejamento de segurança existente e outras práticas recomendadas de design.
Principais práticas recomendadas de segurança do AD FS
As principais práticas recomendadas a seguir são comuns a todas as instalações do AD FS, onde você deseja aprimorar ou estender a segurança do design ou da implantação:
Proteger o AD FS como um sistema "Nível 0"
Como o AD FS é fundamentalmente um sistema de autenticação, ele deve ser tratado como um sistema de "Nível 0", como outros sistemas de identidade em sua rede. Para obter mais informações, confira Modelo da camada administrativa do Active Directory.
Use o Assistente de Configuração de Segurança para aplicar as práticas recomendadas de segurança específicas do AD FS aos servidores de federação e computadores de proxy do servidor de federação
O SCW (Assistente de Configuração de Segurança) é uma ferramenta fornecida pré-instalada em todos os computadores com Windows Server 2008, Windows Server 2008 R2 e Windows Server 2012. Você pode usá-lo para aplicar as práticas recomendadas de segurança que podem ajudar a reduzir a superfície de ataques de um servidor com base nas funções do servidor instalado.
Ao instalar o AD FS, o programa de configuração cria arquivos de extensão de função que podem ser usados com o SCW para criar uma política de segurança que aplicará a função de servidor específica do AD FS (seja servidor de federação ou proxy do servidor de federação) escolhida durante a instalação.
Cada arquivo de extensão de função instalado representa o tipo de função e subfunção para as quais o computador foi configurado. Os seguintes arquivos de extensão de função são instalados no diretório C:WindowsADFSScw:
Farm.xml
SQLFarm.xml
StandAlone.xml
Proxy.xml (Este arquivo estará presente somente se você configurou o computador na função de proxy de servidor de federação.)
Para aplicar as extensões de função do AD FS no SCW, execute as etapas a seguir na ordem indicada:
Instale o AD FS e escolha a função de servidor apropriada para o computador em questão. Para obter mais informações, consulte Instalar o serviço de função do Proxy do Serviço de Federação no Guia de Implantação do AD FS.
Registre o arquivo de extensão de função apropriado usando a ferramenta de linha de comando Scwcmd. Confira a tabela abaixo para ver mais detalhes sobre como usar esta ferramenta na função para qual o computador foi configurado.
Para verificar se o comando foi concluído com êxito, examine o arquivo SCWRegister_log.xml, que encontra-se no diretório WindowssecurityMsscwLogs.
Você deve executar todas essas etapas em cada servidor de federação ou computador de proxy do servidor de federação aos quais deseja aplicar políticas de segurança do AD FS com o SCW.
A tabela a seguir explica como registrar a extensão de função de SCW apropriada com base na função do servidor AD FS escolhida no computador onde o AD FS foi instalado.
Função do servidor AD FS Banco de dados de configuração do AD FS usado Digite o comando a seguir em um prompt de comando: Servidor de federação autônomo Banco de Dados Interno do Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwStandAlone.xml"Servidor de federação ingressado em farm Banco de Dados Interno do Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwFarm.xml"Servidor de federação ingressado em farm SQL Server scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwSQLFarm.xml"Proxy do servidor de federação N/D scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwProxy.xml"Para saber mais sobre os bancos de dados que podem ser usados com o AD FS, confira A função do banco de dados de configuração do AD FS.
Use a detecção de reprodução de token em situações em que a segurança é uma questão muito importante, por exemplo, ao usar quiosques. A detecção de reprodução de token é um recurso do AD FS que garante que qualquer tentativa de reproduzir uma solicitação de token efetuada no Serviço de federação é detectada e a solicitação é descartada. A detecção de reprodução de token é habilitada por padrão. Ela funciona tanto no perfil passivo do Web Services Federation quanto no perfil de WebSSO SAML (Security Assertion Markup Language) ao garantir que o mesmo token nunca seja usado mais de uma vez.
Quando o Serviço de federação é iniciado, ele começa a criar um cache com quaisquer solicitações de token executadas. Com o passar do tempo, as solicitações de token seguintes são adicionadas ao cache, multiplicando a capacidade de detectar qualquer tentativa de reproduzir uma solicitação de token para o serviço de federação. Se você desabilitar a detecção de reprodução de token e posteriormente decidir reativá-la, lembre-se de que o serviço de federação ainda aceitará tokens pelo período que possa ter sido usado anteriormente, até que o cache de reprodução tenha tido tempo suficiente para reconstruir seu conteúdo. Para saber mais, confira A função do banco de dados de configuração de AD FS.
Use criptografia de token, especialmente se usar resolução de artefato de SAML de suporte.
A criptografia de tokens é altamente recomendada para aumentar a segurança e proteção contra possíveis ataques MITM (man-in-the-middle) que podem ameaçar sua implantação do AD FS. Usar criptografia de uso pode representar um ligeiro impacto no resultado geral, porém este geralmente não é notado em muitas implantações, e os benefícios oferecidos por uma segurança mais elevada ultrapassam e muito qualquer custo em termos de desempenho do sistema.
Para habilitar a criptografia de token, primeiramente adicione um certificado de criptografia à sua terceira parte confiável. Você pode configurar um certificado de criptografia ao criar um objeto de confiança de terceira parte confiável ou posteriormente. Para adicionar um certificado de criptografia posteriormente a objeto de confiança de terceira parte confiável existente, você pode definir um certificado para uso na guia Criptografia nas propriedades de relação de confiança usando o snap-in do AD FS. Para especificar um certificado para uma relação de confiança existente usando os cmdlets do AD FS, use o parâmetro EncryptionCertificate dos cmdlets Set-ClaimsProviderTrust ou Set-RelyingPartyTrust. Para definir um certificado para ser usado pelo Serviço de federação ao descriptografar tokens, use o cmdlet Set-ADFSCertificate e especifique "
Token-Encryption" para o parâmetro CertificateType. É possível habilitar e desativar a criptografia para um objeto de confiança de terceira parte confiável usando o parâmetro EncryptClaims do cmdlet Set-RelyingPartyTrust.Utilize proteção estendida para autenticação
Para ajudar a proteger suas implantações, você pode definir e usar a proteção estendida para o recurso de autenticação com o AD FS. Esta configuração especifica o nível da proteção estendida para autenticação compatível com o servidor de federação.
A proteção estendida para autenticação ajuda a proteger contra ataques intermediários (MITM), nos quais um invasor intercepta as credenciais do cliente e encaminha-a para um servidor. A proteção contra tais ataques é possível por causa de um CBT (Token de Ligação de Canal), que poderá ser pedido, permitido ou não pedido pelo servidor quando este estabelecer comunicações com clientes.
Para habilitar o recurso de proteção estendida, use o parâmetro ExtendedProtectionTokenCheck no cmdlet Set-ADFSProperties. Os possíveis valores desta configuração e o nível de segurança fornecido por esses valores são descritos na tabela a seguir.
Valor de Parâmetro Nível de segurança Configuração de proteção Exigir O servidor está totalmente protegido. A proteção estendida é imposta e sempre necessária. Allow O servidor está parcialmente protegido. A proteção estendida é imposta nos casos em que os sistemas envolvidos foram atualizados para dar suporte a ela. Nenhum O servidor está vulnerável. A proteção estendida não é imposta. Se você usar registro em log e rastreamento, certifique-se de manter a privacidade de informações confidenciais.
O AD FS não expõe ou rastreia, por padrão, PII (informações de identificação pessoal) diretamente como parte do Serviço de Federação ou das operações normais. Quando o log de eventos e o log de rastreamento de depuração estão habilitados no AD FS, contudo, dependendo da política de declaração configurada, alguns tipos de declarações e seus valores associados podem conter PII, que por sua vez pode ser registrado no evento ou nos logs de rastreamento do AD FS.
Por isso, é altamente recomendável impor o controle de acesso na configuração do AD FS e nos arquivos de log. Se você não desejar que esse tipo de informação fique visível, desabilite o logon ou filtre quaisquer dados confidenciais ou PII presentes nos logs antes de compartilhá-los.
As dicas a seguir podem ajudar a evitar que o conteúdo do arquivo de log seja exposto indesejadamente:
Certifique-se que os arquivos de log de eventos e de log de rastreamento do AD FS estejam protegidos pelas ACL (listas de controle de acesso) que limitam o acesso a somente os administradores confiáveis que precisam acessá-los.
Não copie ou arquive logs usando extensões de arquivo ou caminhos que podem ser facilmente expostos com uma solicitação da web. Por exemplo, a extensão de nome de arquivo .xml não é uma opção segura. Você pode conferir o guia de administração de ISS (Serviços de Informações da Internet) para ver uma lista das extensões que podem ser usadas.
Se você revisar o caminho para o arquivo de log, lembre-se de especificar um caminho absoluto para o local do arquivo de log, que deverá estar fora da raiz virtual do host da web (vroot) para evitar que seja acessado por terceiros usando um navegador da web.
Bloqueio flexível de extranet do AD FS e proteção de bloqueio inteligente de extranet do AD FS
No caso de um ataque na forma de solicitações de autenticação com senhas inválidas que vêm por meio do Proxy de Aplicativo Web, o bloqueio de extranet do AD FS permite que você proteja seus usuários contra um bloqueio de conta do AD FS. Além de proteger os usuários de um bloqueio de conta do AD FS, o bloqueio de extranet do AD FS também protege contra ataques de adivinhação de senha de força bruta.
Para o bloqueio flexível de extranet do AD FS no Windows Server 2012 R2, consulte Proteção de bloqueio flexível de extranet do AD FS.
Para o bloqueio inteligente de extranet do AD FS no Windows Server 2016, consulte Proteção de bloqueio inteligente de extranet do AD FS.
Práticas recomendadas de segurança do AD FS específicas para SQL Server
As práticas recomendadas de segurança a seguir são específicas para o uso do Microsoft SQL Server® ou WID (Banco de Dados Interno do Windows) quando essas tecnologias de banco de dados são usadas para gerenciar dados no design e na implantação do AD FS.
Observação
Essas recomendações visam ampliar, e não substituir, o guia de segurança de produto do SQL Server. Para obter mais informações sobre como planejar uma instalação segura do SQL Server, confira Considerações sobre segurança para uma instalação do SQL Server (https://go.microsoft.com/fwlink/?LinkID=139831).
Sempre implante o SQL Server atrás de um firewall em um ambiente de rede fisicamente seguro.
Uma instalação do SQL Server nunca deverá estar diretamente exposta à Internet. Somente computadores internos ao seu datacenter podem acessar a instalação do SQL Server compatível com o AD FS. Para obter mais informações, consulte Lista de verificação das práticas recomendadas de segurança (https://go.microsoft.com/fwlink/?LinkID=189229).
Execute o SQL Server em uma conta de serviço em vez de usar contas de serviço padrão integradas do sistema.
Por padrão, o SQL Server geralmente é instalado e configurado para usar uma das contas integradas do sistema com suporte, tal como as contas LocalSystem ou NetworkService. Para melhorar a segurança da instalação do SQL Server para o AD FS, se possível, use uma conta de serviço separada para acessar o serviço do SQL Server e habilite a autenticação Kerberos registrando o SPN (nome de entidade de segurança) desta conta na implantação do Active Directory. Isso habilita a autenticação mútua entre o cliente e o servidor. Sem registrar o SPN de uma conta de serviço separada, o SQL Server usará NTLM para autenticação do Windows, na qual somente o cliente é autenticado.
Minimize a área da superfície do SQL Server.
Habilite somente os terminais do SQL Server necessários. Por padrão, o SQL Server fornece um único ponto de extremidade TCP integrado que não pode ser removido. Para o AD FS, você deve habilitar o ponto de extremidade TCP para autenticação Kerberos. Para analisar os terminais de TCP atuais para ver se portas TCP definidas pelo usuário adicionais foram adicionados a uma instalação do SQL, use a instrução de consulta "SELECT * FROM sys.tcp_endpoints" em uma sessão Transact-SQL (T-SQL). Para saber mais sobre a configuração de ponto de extremidade do SQL Server, confira Como: configurar o mecanismo de banco de dados para escutar diversas portas TCP (https://go.microsoft.com/fwlink/?LinkID=189231).
Evite usar autenticação baseada no SQL.
Para evitar transferir senhas como texto simples pela rede ou armazenar senhas nas definições de configuração, use a autenticação do Windows somente com sua instalação do SQL Server. A autenticação do SQL Server é um modo de autenticação legado. Não é recomendado armazenar credenciais de logon em linguagem SQL (ou seja, nomes de usuário e senhas do SQL) ao usar a autenticação do SQL Server. Para obter mais informações, consulte Modos de autenticação (https://go.microsoft.com/fwlink/?LinkID=189232).
Avalie com cautela a necessidade de usar segurança de canal adicional na instalação do SQL.
Mesmo com a autenticação do Kerberos em vigor, o SSPI (interface SSPI) do SQL Server não oferece segurança no nível do canal. Contudo, para instalações nas quais o servidor encontra-se em uma rede protegida com segurança por firewall, pode não ser necessário criptografar as comunicações do SQL.
Embora a criptografia seja uma ferramenta valiosa para ajudar a garantir a segurança, não deve ser considerada em todos os dados ou conexões. Quando você estiver decidindo se a criptografia deve ser implementada, considere como os usuários acessarão os dados. Se os usuários acessarem dados por uma rede pública, a criptografia de dados poderá ser necessária para aumentar a segurança. Contudo, se todos os acessos dos dados SQL do AD FS estiverem em uma configuração de intranet segura, talvez não seja necessário usar criptografia. Qualquer uso de criptografia deve também incluir uma estratégia de manutenção de senhas, chaves e certificados.
Se houver alguma preocupação que os dados do SQL podem ser vistos ou violados na sua rede, use o IPsec ou o SSL para ajudar a proteger as conexões do SQL. Contudo, talvez isso afete negativamente o desempenho do SQL Server, o que pode impactar ou limitar o desempenho do AD FS em algumas situações. Por exemplo, o desempenho do AD FS na emissão de tokens pode decair quando pesquisas de atributos de um repositório de atributos do SQL forem cruciais para emissão de tokens. Você pode eliminar a ameaça de violação do SQL com mais eficiência se possuir uma forte configuração de perímetro de segurança. Por exemplo, uma solução melhor para proteger sua instalação do SQL Server seria garantir que esta esteja inacessível a usuários e computadores da Internet, e que esteja acessível somente a usuários ou computadores no ambiente do seu datacenter.
Para obter mais informações, consulte Criptografar conexões com o SQL Server ou Criptografia do SQL Server.
Configure o acesso designado com segurança usando procedimentos armazenados para realizar todas as pesquisas de SQL efetuadas pelo AD FS de dados armazenados no SQL.
Para fornecer um melhor serviço e isolamento dos dados, você pode criar procedimentos armazenados para todos os comandos de pesquisa de armazenamento de atributo. Você pode criar uma função de banco de dados que receberá permissão para executar os procedimentos armazenados. Atribua a identidade do serviço do Windows do AD FS a esta função de banco de dados. O serviço do Windows do AD FS não deve executar nenhuma outra instrução de SQL, exceto os procedimentos armazenados apropriados que são usados para pesquisa de atributos. Bloquear o acesso ao banco de dados do SQL Server desta maneira reduz o risco de um ataque de elevação de privilégio.