Melhores práticas para todas as arquiteturas de isolamento
A seguir estão considerações de design para todas as configurações de isolamento. Este conteúdo inclui muitos links. Vinculamos ao conteúdo, em vez de duplicá-lo aqui, para que você sempre tenha acesso às informações mais atualizadas.
Para obter diretrizes gerais sobre como configurar Microsoft Entra locatários (isolados ou não), consulte o guia de implantação de recursos do Microsoft Entra.
Observação
Para todos os locatários isolados, sugerimos que você use uma identidade visual clara e diferenciada para ajudar a evitar o erro humano de trabalhar no locatário incorreto.
Princípios de segurança de isolamento
Ao criar ambientes isolados, é importante considerar os seguintes princípios:
Usar apenas a autenticação moderna – os aplicativos implantados em ambientes isolados devem usar a autenticação moderna baseada em declarações (por exemplo, SAML, * Auth, OAuth2, and OpenID Connect) para usar recursos como federação, colaboração do Microsoft Entra B2B, delegação e a estrutura de consentimento. Dessa forma, os aplicativos herdados que têm dependência de métodos de autenticação herdados, como o NTLM (NTLM), não serão encaminhados em ambientes isolados.
Impor autenticação forte – a autenticação forte sempre deve ser usada ao acessar os serviços de ambiente isolados e a infraestrutura. Sempre que possível, autenticação sem senha como Windows for Business Hello ou chaves de segurança FIDO2 deve ser usada.
Implantar estações de trabalho seguras - Estações de trabalho seguras fornecem o mecanismo para garantir que a plataforma e a identidade que a plataforma representa sejam devidamente atestadas e protegidas contra exploração. Duas outras abordagens a serem consideradas são:
Usar computadores Windows 365 Cloud (PC na nuvem) com a API do Microsoft Graph.
Usar Acesso Condicional e filtrar para dispositivos como uma condição.
Eliminar mecanismos de confiança herdados – diretórios e serviços isolados não devem estabelecer relações de confiança com outros ambientes por meio de mecanismos herdados, como confianças do Active Directory. Todas as relações de confiança entre ambientes devem ser estabelecidas com construções modernas, como federação e identidade baseada em declarações.
Isolar serviços – minimize a área de ataque de superfície protegendo identidades subjacentes e a infraestrutura de serviço contra exposição. Habilite o acesso somente por meio da autenticação moderna para serviços e acesso remoto seguro (também protegido pela autenticação moderna) para a infraestrutura.
Atribuições de função no nível do diretório – evite ou reduza números de atribuições de função no nível do diretório (Administrador de Usuário no escopo do diretório em vez de escopo de UA) ou funções de diretório específicas do serviço com ações do painel de controle (Administração de conhecimento com permissões para gerenciar associações de grupo de segurança).
Além das diretrizes no guia de Operações gerais do Microsoft Entra, também recomendamos as considerações a seguir para ambientes isolados.
Provisionamento de identidade humana
Contas com privilégios
Provisione contas no ambiente isolado para equipes administrativas e de TI que estarão operando o ambiente. Isso permitirá que você adicione políticas de segurança mais fortes, como controle de acesso baseado em dispositivo para estações de trabalho seguras. Conforme discutido nas seções anteriores, os ambientes não relacionados à produção podem utilizar colaboração B2B do Microsoft Entra para integrar contas privilegiadas aos locatários não produtivos usando a mesma postura e os mesmos controles de segurança projetados para acesso privilegiado em seu ambiente de produção.
As contas somente na nuvem são o modo mais simples de provisionar identidades humanas em um locatário do Microsoft Entra e são uma boa opção para ambientes greenfield. No entanto, se houver uma infraestrutura local que corresponda ao ambiente isolado (por exemplo, floresta do Active Directory de pré-produção ou gerenciamento), você poderá considerar a sincronização de identidades com base nela. Isso é especialmente verdadeiro se a infraestrutura local descrita acima também for usada para soluções de IaaS que exigem acesso do servidor para gerenciar o plano de dados da solução. Para mais informações, confira Proteger o Microsoft 365 de ataques locais. A sincronização de ambientes locais isolados também poderá ser necessária se houver requisitos de conformidade regulatória específicos, como autenticação somente de cartão inteligente.
Observação
Não há controles técnicos para verificar a identidade para contas B2B do Microsoft Entra. As identidades externas provisionadas com B2B do Microsoft Entra são inicializadas com fator único. A mitigação é que a organização tenha um processo para comprovar as identidades necessárias antes da emissão de um convite B2B e revisões regulares de acesso de identidades externas para gerenciar o ciclo de vida. Considere habilitar uma política de Acesso Condicional para controlar o registro de MFA.
Como terceirizar funções de alto risco
Para atenuar as ameaças internas, é possível terceirizar o acesso às funções administrador global e administrador de funções com privilégios para serem gerenciadas por um provedor de serviços com a colaboração B2B do Azure ou a delegação do acesso por meio de um parceiro CSP ou do Lighthouse. Esse acesso pode ser fortemente controlado por funcionários internos por meio de fluxos de aprovação no Azure Privileged Identity Management (PIM). Essa abordagem pode reduzir consideravelmente as ameaças internas. Você pode usar essa abordagem para atender às demandas de conformidade para clientes que têm preocupações.
Provisionamento de identidade não humana
Contas de acesso de emergência
A Microsoft recomenda que as organizações tenham duas contas de acesso de emergência somente na nuvem atribuídas permanentemente à função Administrador Global. Essas contas são altamente privilegiadas e não são atribuídas a indivíduos específicos. As contas são limitadas a cenários de emergência ou de "acesso de emergência" em que as contas normais não podem ser usadas ou em que todos os outros administradores estão acidentalmente bloqueados. Essas contas devem ser criadas de acordo com as recomendações para as contas de acesso de emergência.
Identidades gerenciadas do Azure
Use Identidades gerenciadas do Azure para recursos do Azure que exigem uma identidade de serviço. Confira a lista de serviços compatíveis com identidades gerenciadas ao criar suas soluções do Azure.
Se não houver suporte para identidades gerenciadas ou elas não forem possíveis, considere provisionar objetos da entidade de serviço.
Contas de serviço híbrido
Algumas soluções híbridas podem exigir acesso a recursos locais e na nuvem. Um exemplo de caso de uso seria um aplicativo que usa uma conta de serviço no AD DS para acesso a servidores locais conectados ao domínio e também tem uma conta no Microsoft Entra ID, pois requer acesso ao Microsoft Online Services.
As contas de serviço locais normalmente não podem entrar interativamente, o que significa que, em cenários de nuvem, elas não conseguem cumprir requisitos de credencial fortes, como a autenticação multifator. Nesse cenário, não use uma conta de serviço sincronizada localmente, mas uma identidade gerenciada\entidade de serviço. Para a SP (entidade de serviço), use um certificado como credencial ou proteja a SP com acesso condicional.
Se houver restrições técnicas que não possibilitem isso e a mesma conta precisar ser usada para o local e a nuvem, implemente controles de compensação, como Acesso Condicional, para bloquear a conta híbrida proveniente de um local de rede específico.
Atribuição de recursos
Uma solução corporativa pode ser composta por vários recursos do Azure e seu acesso deve ser gerenciado e regido como uma unidade lógica de atribuição, um grupo de recursos. Nesse cenário, grupos de segurança do Microsoft Entra podem ser criados e associados às permissões adequadas e à atribuição de função em todos os recursos de solução, de modo que adicionar ou remover usuários desses grupos resulta em permitir ou negar acesso a toda a solução.
Recomendamos que você use grupos de segurança e licenciamento baseado em grupo para serviços da Microsoft que dependem de o usuário ter uma atribuição de assento de licença como um pré-requisito antes de fornecer acesso (por exemplo, o Dynamics 365 e o Power BI).
Os grupos nativos de nuvem do Microsoft Entra podem ser controlados nativamente da nuvem quando combinados com revisões de acesso do Microsoft Entra e gerenciamento de direitos do Microsoft Entra.
O Microsoft Entra ID também dá suporte à atribuição direta do usuário para serviços SaaS de terceiros (por exemplo, Salesforce, Service Now) e aplicativos locais para o provisionamento de identidade e logon único. As atribuições diretas a recursos podem ser controlados nativamente da nuvem quando combinados com revisões de acesso do Microsoft Entra e gerenciamento de direitos do Microsoft Entra. A atribuição direta pode ser uma boa opção para a atribuição voltada para o usuário final.
Alguns cenários podem exigir a concessão de acesso a recursos locais por meio de grupos de segurança do Active Directory local. Para esses casos, considere o ciclo de sincronização como o Microsoft Entra ID ao criar processos de SLA.
Gerenciamento de autenticação
Esta seção descreve as verificações a serem executadas e as ações a serem executadas para políticas de acesso e gerenciamento de credenciais com base na postura de segurança da sua organização.
Gerenciamento de credenciais
Credenciais fortes
Todas as identidades humanas (contas locais e identidades externas provisionadas por meio da colaboração B2B) no ambiente isolado devem ser provisionadas com credenciais de autenticação fortes, como autenticação multifator ou uma chave FIDO. Ambientes com uma infraestrutura local subjacente com autenticação forte, como autenticação com cartão inteligente, podem continuar usando a autenticação com cartão inteligente na nuvem.
Credenciais sem senha
Uma solução sem senha é a melhor alternativa para garantir o método de autenticação mais conveniente e seguro. Credenciais sem senha, como chaves de segurança FIDO e Windows Hello para Empresas, são recomendadas para identidades humanas com funções privilegiadas.
Proteção por senha
Se o ambiente for sincronizado de uma floresta Active Directory local, implanta a Proteção por senha do Microsoft Entra para eliminar senhas fracas em sua organização. O Bloqueio inteligente do Microsoft Entra também deve ser usado em ambientes híbridos ou somente na nuvem para bloquear pessoas mal-intencionadas que estão tentando adivinhar as senhas dos usuários ou usar métodos de força bruta para entrar.
Gerenciamento de senhas de autoatendimento
O grande volume e custo de chamadas para o suporte técnico vêm dos usuários que precisam alterar ou redefinir as senhas deles. Além do custo, alterar a senha como uma ferramenta para mitigar um risco do usuário é uma etapa fundamental para melhorar a postura de segurança de sua organização. No mínimo, implante o Gerenciamento de Senhas por Autoatendimento para contas humanas e de teste com senhas para desviar as chamadas ao suporte técnico.
Senhas de identidades externas
Usando a colaboração B2B do Microsoft Entra, um processo de convite e resgate permite que usuários externos, como parceiros, desenvolvedores e subcontratados, usem credenciais próprias para acessar os recursos da sua empresa. Isso reduz a necessidade de introduzir mais senhas nos locatários isolados.
Observação
Alguns aplicativos, infraestrutura ou fluxos de trabalho podem exigir uma credencial local. Avalie isso caso a caso.
Credenciais de entidades de serviço
Para cenários que exigem entidades de serviço, use as credenciais de certificado para entidades de serviço ou acesso condicional para identidades de carga de trabalho. Se necessário, use os segredos do cliente como uma exceção à política organizacional.
Nos dois casos, o Azure Key Vault pode ser usado com as identidades gerenciadas do Azure, para que o ambiente de runtime (por exemplo, a função do Azure) possa recuperar a credencial do cofre de chaves.
Verifique este exemplo para criar entidades de serviço com certificado autoassinado para autenticação de entidades de serviço com credenciais de certificado.
Políticas de acesso
As recomendações para soluções do Azure estão nas seções a seguir. Para diretrizes gerais sobre políticas de Acesso Condicional para ambientes individuais, confira Melhores práticas de acesso condicional, Guia de Operações do Microsoft Entra e Acesso condicional para Confiança Zero:
Defina Políticas de Acesso Condicional para o aplicativo de nuvem API de Gerenciamento de Serviços do Windows Azure para impor a postura de segurança de identidade ao acessar o Azure Resource Manager. Isso deve incluir controles em MFA e controles baseados em dispositivo para habilitar o acesso somente por meio de estações de trabalho seguras (mais sobre isso na seção Funções Privilegiadas sob Governança de Identidade). Além disso, use Acesso Condicional para filtrar dispositivos.
Todos os aplicativos integrados a ambientes isolados devem ter políticas explícitas de acesso condicional aplicadas como parte do processo de integração.
Defina políticas de acesso condicional para registro de informações de segurança que refletem uma raiz segura do processo de confiança local (por exemplo, para estações de trabalho em locais físicos, identificáveis por endereços IP, que os funcionários devem visitar pessoalmente para verificação).
Considere usar o acesso condicional para restringir identidades de carga de trabalho. Crie uma política para limitar ou controlar melhor o acesso com base no local ou em outras circunstâncias relevantes.
Desafios de autenticação
Identidades externas provisionadas com o B2B do Microsoft Entra talvez precisem reprovisionar credenciais de autenticação multifator no locatário do recurso. Isso poderá ser necessário se uma política de acesso entre locatários não tiver sido configurada com o locatário do recurso. Isso significa que a integração ao sistema é inicializada com um só fator. Com essa abordagem, a mitigação de risco é que a organização tenha um processo para comprovar o usuário e o perfil de risco de credencial antes da emissão de um convite B2B. Além disso, defina o acesso condicional para o processo de registro, conforme descrito anteriormente.
Use configurações de acesso entre locatários de Identidades Externas para gerenciar a colaboração com outras organizações do Microsoft Entra e outras nuvens do Microsoft Azure por meio da colaboração B2B e da conexão direta de B2B.
Para configuração e controle de dispositivo específicos, use filtros de dispositivo em políticas de acesso condicional para focar ou excluir dispositivos específicos. Isso permite restringir o acesso às ferramentas de gerenciamento do Azure de uma SAW (estação de trabalho de administrador seguro) designada. Outras abordagens que você pode adotar incluem usar Área de Trabalho Virtual do Azure, Azure Bastion ou PC na nuvem.
Aplicativos de gerenciamento do orçamento, como o portal do Azure EA ou contas de cobrança MCA, não são representados como aplicativos de nuvem para direcionamento de acesso condicional. Como um controle compensatório, defina contas de administração separadas e direcione políticas de acesso condicional para essas contas usando uma condição "Todos os Aplicativos".
Governança de Identidade
Funções com privilégio
Abaixo estão alguns princípios de governança de identidade a serem considerados em todas as configurações de locatário para isolamento.
Sem acesso permanente – nenhuma identidade humana deve ter acesso permanente para executar operações privilegiadas em ambientes isolados. O RBAC (controle de acesso baseado em função) do Azure se integra ao Microsoft Entra PIM (Privileged Identity Management). O PIM fornece ativação just-in-time determinada por portões de segurança, como autenticação multifator, fluxo de trabalho de aprovação e duração limitada.
Número de administradores – as organizações devem definir o número mínimo e máximo de seres humanos que mantêm uma função privilegiada para atenuar os riscos de continuidade dos negócios. Com poucas funções privilegiadas, pode não haver cobertura de fuso horário suficiente. Reduza os riscos de segurança tendo o menor número possível de administradores seguindo o princípio de menor privilégio.
Limitar o acesso privilegiado – crie grupos somente na nuvem e atribuíveis a funções para privilégios de alto privilégio ou confidenciais. Isso oferece proteção dos usuários atribuídos e do objeto de grupo.
Acesso menos privilegiado – as identidades só devem receber as permissões necessárias para executar as operações privilegiadas conforme a respectiva função na organização.
As funções personalizadas do RBAC do Azure permitem criar funções menos privilegiadas com base nas necessidades organizacionais. Recomendamos que equipes de segurança especializadas criem ou analisem as definições de funções personalizadas para reduzir os riscos de privilégios excessivos inadvertidos. É possível auditar a criação de funções personalizadas por meio do Azure Policy.
Para atenuar o uso acidental de funções que não se destinam a um uso mais amplo na organização, use o Azure Policy para definir explicitamente quais definições de função podem ser usadas para atribuir acesso. Saiba mais neste Exemplo do GitHub.
Acesso privilegiado de estações de trabalho seguras – todo o acesso privilegiado deve ocorrer por meio de dispositivos seguros e bloqueados. Separar essas tarefas e contas confidenciais das estações de trabalho de uso diário e dispositivos protege contas privilegiadas contra ataques de phishing, aplicativo e vulnerabilidades do SO, vários ataques de representação e ataques de roubo de credenciais, como o registro em log de teclas pressionadas, Pass-the-Hash e Pass-The-Ticket.
Algumas abordagens que você pode adotar para usar dispositivos seguros como parte de sua história de acesso privilegiado incluem o uso de políticas de Acesso Condicional para focar ou excluir dispositivos específicos, usar a Área de Trabalho Virtual do Azure, o Azure Bastion ou o PC na nuvem ou criar estações de trabalho gerenciadas pelo Azure ou estações de trabalho de acesso privilegiado.
Proteções de processo de função com privilégios – as organizações devem definir processos e proteções técnicos para garantir que operações privilegiadas possam ser executadas sempre que necessário enquanto estão em conformidade com os requisitos regulatórios. Exemplos de critérios de proteções incluem:
Qualificação de humanos com funções privilegiadas (por exemplo, fornecedor/funcionário em tempo integral, nível de liberação, cidadania)
Incompatibilidade explícita de funções (também conhecida como separação de tarefas). Exemplos incluem equipes com funções de diretório do Microsoft Entra não devem ser responsáveis pelo gerenciamento de funções privilegiadas do Azure Resource Manager e assim por diante.
Se as atribuições diretas de usuários ou grupos são preferenciais para qualquer função.
O monitoramento de atribuições de IAM fora do Microsoft Entra PIM não é automatizado por meio de Políticas do Azure. A mitigação é não conceder funções de Proprietário de Assinatura ou Administrador de Acesso do Usuário às equipes de engenharia. Em vez disso, crie grupos atribuídos a funções menos privilegiadas, como Colaborador e delegue o gerenciamento desses grupos às equipes de engenharia.
Acesso a recursos
Atestado – as identidades que detêm funções privilegiadas devem ser analisadas periodicamente para manter a associação atual e justificada. As Revisões de Acesso do Microsoft Entra se integram a funções do RBAC do Azure, associações de grupo e identidades externas do Microsoft Entra B2B.
Ciclo de vida – operações com privilégios podem exigir acesso a vários recursos, como aplicativos de linha de negócios, aplicativos SaaS e assinaturas e grupos de recursos do Azure. O Gerenciamento de Direitos do Microsoft Entra permite definir pacotes de acesso que representam um recurso definido atribuído aos usuários como uma unidade, estabelecer um período de validade, fluxos de trabalho de aprovação etc.
Gerenciamento do ciclo de vida de assinatura e locatário
Ciclo de vida do locatário
Recomendamos implementar um processo para solicitar um novo locatário corporativo do Microsoft Entra. O processo deve considerar:
Justificativa comercial para criá-lo. A criação de um novo locatário do Microsoft Entra aumentará significativamente a complexidade, portanto, é fundamental verificar se um novo locatário é necessário.
A nuvem do Azure na qual ela deve ser criada (por exemplo, Comercial, Governamental e assim por diante).
Se ele é de produção ou não
Requisitos de residência de dados de diretório
Quem vai gerenciá-lo
Treinamento e compreensão dos requisitos de segurança comuns.
Após a aprovação, o locatário do Microsoft Entra será criado, configurado com os controles de linha de base necessários e integrado no plano de cobrança, monitoramento e assim por diante.
A análise regular dos locatários do Microsoft Entra no plano de cobrança precisa ser implementada para detectar e descobrir a criação de locatários fora do processo controlado. Confira a seção Inventário e Visibilidade deste documento para mais detalhes.
A criação de locatário do Azure AD B2C pode ser controlada usando o Azure Policy. A política é executada quando uma assinatura do Azure está associada ao locatário B2C (um pré-requisito para cobrança). Os clientes podem limitar a criação de locatários do Azure AD B2C a grupos de gerenciamento específicos.
Não há controles técnicos para subordinar a criação de locatários a uma organização. No entanto, a atividade é registrada no log de auditoria. A integração ao plano de cobrança é um controle compensador no portão. Isso precisa ser complementado com monitoramento e alertas.
Ciclo de vida da assinatura
Abaixo estão algumas considerações ao criar um processo de ciclo de vida de assinatura regido:
Defina uma taxonomia de aplicativos e soluções que exigem recursos do Azure. Todas as equipes que solicitam assinaturas devem fornecer um "identificador de produto" ao solicitar assinaturas. Essa taxonomia de informações determinará:
O locatário do Microsoft Entra para provisionar a assinatura
A conta do Azure EA a ser usada para criação de assinatura
Convenção de nomenclatura
Atribuição de grupo de gerenciamento
Outros aspectos, como marcação, cobrança cruzada, uso de exibição de produto e assim por diante.
Não permita a criação de assinatura ad hoc por portais ou outros meios. Em vez disso, considere gerenciar assinaturas programaticamente usando o Azure Resource Manager e efetuar pull de relatórios de consumo e cobrança de modo programático. Isso pode ajudar a limitar o provisionamento de assinatura a usuários autorizados e impor suas metas de política e taxonomia. As diretrizes sobre como seguir as entidades de segurança do AZOps podem ser usadas para ajudar a criar uma solução prática.
Quando uma assinatura é provisionada, crie grupos de nuvem do Microsoft Entra para manter as funções padrão do Azure Resource Manager exigidas pelas equipes de aplicativos, como colaborador, leitor e funções personalizadas aprovadas. Isso permite gerenciar atribuições de função do RBAC do Azure com acesso privilegiado controlado em escala.
Configure os grupos para se tornarem elegíveis para funções RBAC do Azure usando o Microsoft Entra PIM com os controles correspondentes, como política de ativação, revisões de acesso, aprovadores e assim por diante.
Então delegue o gerenciamento dos grupos aos proprietários da solução.
Como uma proteção, não atribua proprietários de produtos a funções de administrador de acesso do usuário ou proprietário para evitar atribuição direta inadvertida de funções fora do Microsoft Entra PIM ou talvez alterar a assinatura para um locatário completamente diferente.
Para clientes que optarem por habilitar o gerenciamento de assinatura entre locatários em locatários não produtivos por meio do Azure Lighthouse, verifique se as mesmas políticas de acesso da conta com privilégios de produção (por exemplo, acesso privilegiado somente de estações de trabalho protegidas) são impostas ao autenticar para gerenciar assinaturas.
Se a organização tiver arquiteturas de referência pré-aprovadas, o provisionamento de assinatura poderá ser integrado a ferramentas de implantação de recursos, como Azure Blueprints ou Terraform.
Dada a afinidade de locatário com as Assinaturas do Azure, o provisionamento de assinatura deve estar ciente de várias identidades para o mesmo ator humano (funcionário, parceiro, fornecedor e assim por diante) em vários locatários e atribuir acesso adequadamente.
Funções do EA e do MCA
O portal do Azure EA (Contrato Enterprise do Azure) não se integra ao RBAC do Azure nem ao Acesso Condicional. A mitigação para isso é usar contas de administração dedicadas que podem ser focadas com políticas e monitoramento adicional.
O portal do Azure EA Enterprise não fornece um log de auditoria. Para atenuar isso, considere um processo controlado automatizado para provisionar assinaturas com as considerações descritas acima e usar contas EA dedicadas e auditar os logs de autenticação.
As funções do MCA (Contrato de Cliente da Microsoft) não se integram nativamente ao PIM. Para atenuar isso, use contas MCA dedicadas e monitore o uso dessas contas.
Locatários do Azure AD B2C
Em um locatário do Azure AD B2C, as funções internas não dão suporte ao PIM. Para aumentar a segurança, recomendamos usar a colaboração B2B do Microsoft Entra para integrar as equipes de engenharia que gerenciam o CIAM (Gerenciamento de Identidades e Acesso do Cliente) de seu locatário do Azure, atribuí-las às funções privilegiadas do Azure AD B2C e aplicar políticas de Acesso Condicional a essas contas de administração dedicadas.
Funções com privilégios de locatário do Azure AD B2C não são integradas a Revisões de Acesso do Microsoft Entra. A mitigação é criar contas dedicadas no locatário do Microsoft Entra da organização, adicionar essas contas a um grupo e executar revisões de acesso regulares nesse grupo.
Seguindo as diretrizes de acesso de emergência para Microsoft Entra ID acima, considere criar contas de acesso de emergência equivalentes, além dos administradores externos descritos acima.
Recomendamos a propriedade lógica da assinatura do Microsoft Entra subjacente do locatário B2C alinhada com as equipes de engenharia da CIAM, da mesma forma que o restante das assinaturas do Azure são usadas para as soluções B2C.
Operações
Veja a seguir considerações operacionais adicionais para o Microsoft Entra ID, específicas para vários ambientes isolados. Consulte o Azure Cloud Adoption Framework, o Microsoft cloud security benchmark e o Guia de operações do Microsoft Entra para obter orientações detalhadas sobre como operar ambientes individuais.
Funções e responsabilidades entre ambientes
Arquitetura de SecOps em toda a empresa – membros de operações e equipes de segurança de todos os ambientes da organização devem definir conjuntamente o seguinte:
Princípios a serem definidos quando os ambientes precisam ser criados, consolidados ou preteridos.
Princípios para definir a hierarquia do grupo de gerenciamento em cada ambiente.
Postura de segurança do plano de cobrança (portal do EA/MCA), postura operacional e abordagem de delegação.
Processo de criação de locatário.
Taxonomia de aplicativo empresarial.
Processo de provisionamento de assinatura do Azure.
Limites de autonomia de isolamento e administração e avaliação de risco entre equipes e ambientes.
Configuração de linha de base comum e controles de segurança (técnico e compensação) e linhas de base operacionais a serem usadas em todos os ambientes.
Procedimentos operacionais padrão comuns e ferramentas que abrangem vários ambientes (por exemplo, monitoramento, provisionamento).
Delegação de funções em vários ambientes acordada.
Segregação do dever entre ambientes.
Gerenciamento da cadeia de fornecedores comum para estações de trabalho privilegiadas.
Convenções de nomenclatura.
Mecanismos de correlação entre ambientes.
Criação de locatário – uma equipe específica deve deter a criação do locatário seguindo procedimentos padronizados definidos pela arquitetura SecOps de toda a empresa. Isso inclui:
Provisionamento de licença básica (por exemplo, Microsoft 365).
Integração ao plano de cobrança corporativa (por exemplo, Azure EA ou MCA).
Criação da hierarquia do grupo de gerenciamento do Azure.
Configuração de políticas de gerenciamento para vários perímetros, incluindo identidade, proteção de dados, Azure e assim por diante.
Implantação da pilha de segurança de acordo com a arquitetura de segurança cibernética acordada, incluindo configurações de diagnóstico, integração de SIEM, integração de CASB, integração de PIM e assim por diante.
Configuração de funções do Microsoft Entra com base na delegação acordada.
Configuração e distribuição de estações de trabalho com privilégios iniciais.
Provisione contas de acesso de emergência.
Configuração da pilha de provisionamento de identidade.
Arquitetura de ferramentas entre ambientes – algumas ferramentas, como provisionamento de identidade e pipelines de controle do código-fonte, podem precisar funcionar em vários ambientes. Essas ferramentas devem ser consideradas críticas para a infraestrutura e ser arquitetada, projetadas, implementadas e gerenciadas como tal. Como resultado, os arquitetos de todos os ambientes devem estar envolvidos sempre que for preciso definir ferramentas entre ambientes.
Inventário e visibilidade
Descoberta de assinatura do Azure – para cada locatário descoberto, um administrador global do Microsoft Entra pode elevar o acesso para obter visibilidade de todas as assinaturas no ambiente. Essa elevação atribuirá a ele a função interna administrador de acesso do usuário no grupo de gerenciamento raiz.
Observação
Essa ação é altamente privilegiada e pode dar ao administrador acesso a assinaturas que contêm informações extremamente confidenciais se esses dados não tiverem sido devidamente isolados.
Habilitar o acesso de leitura para descobrir recursos – grupos de gerenciamento habilitam a atribuição RBAC em escala em várias assinaturas. Os clientes podem conceder uma função de Leitor a uma equipe de TI centralizada configurando uma atribuição de função no grupo de gerenciamento raiz, que será propagada para todas as assinaturas no ambiente.
Descoberta de recursos – depois de obter acesso de leitura do recurso no ambiente, o Azure Resource Graph pode ser usado para consultar recursos no ambiente.
Log e monitoramento
Gerenciamento de log de segurança central – Ingerir logs de cada ambiente de maneira centralizada, seguindo melhores práticas consistentes entre ambientes (por exemplo, configurações de diagnóstico, retenção de log, ingestão de SIEM etc.). O Azure Monitor pode ser usado para ingerir logs de diferentes fontes, como dispositivos de ponto de extremidade, rede, logs de segurança de sistemas operacionais etc.
Informações detalhadas sobre como usar processos e ferramentas automatizados ou manuais para monitorar logs como parte das operações de segurança estão disponíveis no guia de operações de segurança do Microsoft Entra.
Alguns ambientes podem ter requisitos regulatórios que limitam os dados (se houver) que podem sair de um determinado ambiente. Se o monitoramento centralizado entre ambientes não for possível, as equipes deverão ter procedimentos operacionais para correlacionar atividades de identidades em ambientes para fins de auditoria e perícia, como tentativas de movimento lateral entre ambientes. É recomendável que o objeto identifique identidades humanas pertencentes à mesma pessoa, potencialmente como parte dos sistemas de provisionamento de identidade.
A estratégia de log deve incluir os seguintes logs do Microsoft Entra para cada locatário usado na organização:
Atividade de entrada
Logs de auditoria
Eventos de risco
O Microsoft Entra ID fornece integração com o Azure Monitor para o log de atividades de entrada e logs de auditoria. Os eventos de risco podem ser ingeridos por meio da API do Microsoft Graph.
O seguinte diagrama mostra as diferentes fontes de dados que precisam ser incorporadas como parte da estratégia de monitoramento:
Locatários do Azure AD B2C podem ser integrados ao Azure Monitor. Recomendamos o monitoramento de Azure AD B2C usando os mesmos critérios discutidos acima para o Microsoft Entra ID.
As assinaturas que habilitaram o gerenciamento entre locatários com o Azure Lighthouse poderão habilitar o monitoramento entre locatários se os logs forem coletados pelo Azure Monitor. Os workspaces correspondentes do Log Analytics podem residir no locatário do recurso e podem ser analisados centralmente no locatário de gerenciamento usando pastas de trabalho do Azure Monitor. Para saber mais, confira Monitorar recursos delegados em escala – Azure Lighthouse.
Logs de segurança do SO de infraestrutura híbrida
Todos os logs do SO de infraestrutura de identidade híbrida devem ser arquivados e cuidadosamente monitorados como um sistema de camada 0, devido às implicações da área de superfície. Isso inclui:
Servidores AD FS e Links de Proxy de Aplicativo Web
Microsoft Entra Connect
Agentes do Proxy de Aplicativo
Agentes de write-back de senha
Computadores do gateway de proteção de senha
NPS que tem a extensão RADIUS de autenticação multifator do Microsoft Entra
O Microsoft Entra Connect Health deve ser implantado para monitorar a sincronização de identidade e a federação (quando aplicável) para todos os ambientes.
Retenção de armazenamento de logs – todos os ambientes devem ter uma estratégia de retenção de armazenamento de log coesa, design e implementação para facilitar um conjunto de ferramentas consistente (por exemplo, sistemas SIEM como o Azure Sentinel), consultas comuns, investigação e guias estratégicos forenses. O Azure Policy pode ser usado para configurar configurações de diagnóstico.
Monitoramento e revisão de log – as tarefas operacionais em torno do monitoramento de identidade devem ser consistentes e ter proprietários em cada ambiente. Conforme descrito acima, procure consolidar essas responsabilidades entre ambientes na medida permitida pelos requisitos de conformidade e isolamento regulatórios.
Os seguintes cenários devem ser explicitamente monitorados e investigados:
Atividade suspeita – todos os Eventos de risco do Microsoft Entra devem ser monitorados para atividades suspeitas. Todos os locatários devem definir os locais nomeados de rede para evitar detecções com ruídos em sinais baseados no local. O Microsoft Entra ID Identity Protection é nativamente integrado à Central de Segurança do Azure. É recomendável que qualquer investigação de detecção de risco inclua todos os ambientes em que a identidade é provisionada (por exemplo, se uma identidade humana tiver uma detecção de risco ativa no locatário corporativo, a equipe que opera o locatário voltado para o cliente também deverá investigar a atividade da conta correspondente nesse ambiente).
Alertas de UEBA (análise comportamental de entidade de usuário) – a UEBA deve ser usada para obter informações perspicazes com base na detecção de anomalias. Os aplicativos Microsoft 365 Defender para Nuvem fornecem UEBA na nuvem. Os clientes podem integrar a UEBA local do Microsoft 365 Defender for Identity. O MCAS lê sinais do Microsoft Entra ID Protection.
Atividade de contas de acesso de emergência – qualquer acesso usando contas de acesso de emergência deve ser monitorado e alertas devem ser criados para investigações. Esse monitoramento deve incluir:
Entradas
Gerenciamento de credenciais
Quaisquer atualizações em associações de grupo
Atribuições de aplicativos
Contas de gerenciamento do orçamento – dada a confidencialidade das contas com funções de gerenciamento do orçamento no Azure EA ou MCA e seu privilégio significativo, é recomendável monitorar e alertar:
Tentativas de entrada feitas por contas com funções de cobrança.
Qualquer tentativa de autenticação em aplicativos que não o Portal do EA.
Qualquer tentativa de autenticação em aplicativos que não o Gerenciamento de Recursos do Azure se estiver usando contas dedicadas para tarefas de cobrança MCA.
Atribuição aos recursos do Azure usando contas dedicadas para tarefas de cobrança MCA.
Atividade de função privilegiada – configurar e examinar alertas de segurança gerados pelo Microsoft Entra PIM. Se o bloqueio de atribuições diretas do RBAC não for totalmente impositivo com controles técnicos (por exemplo, a função Proprietário deve ser concedida às equipes de produtos para realizar seu trabalho), monitore a atribuição direta de funções privilegiadas fora do PIM gerando alertas sempre que um usuário for atribuído diretamente para acessar a assinatura com o RBAC do Azure.
Atribuições de função clássicas – as organizações devem usar a infraestrutura de função RBAC do Azure moderna em vez das funções clássicas. Como resultado, os seguintes eventos devem ser monitorados:
- Atribuição a funções clássicas no nível da assinatura
Configurações em todo o locatário – qualquer serviço de configuração em todo o locatário deve gerar alertas no sistema.
Como atualizar domínios personalizados
Como atualizar identidade visual
Lista de permissões/bloqueios do Microsoft Entra B2B
O Microsoft Entra B2B permitia provedores de identidade (IDPs de SAML por federação direta ou logins sociais)
Alterações às políticas de acesso condicional
Objetos de aplicativo e entidade de serviço
Novos aplicativos/entidades de serviço que podem exigir políticas de acesso condicional
Atividade de consentimento do aplicativo
Atividade do grupo de gerenciamento – os seguintes aspectos de identidade dos grupos de gerenciamento devem ser monitorados:
Atribuições de função do RBAC no MG
Azure Policies aplicadas no MG
Assinaturas movidas entre MGs
Qualquer alteração às políticas de segurança para o MG raiz
Funções personalizadas
Atualizações para as definições de função personalizadas
Novas funções personalizadas criadas
Separação personalizada de regras de tarefas – Se suas organizações estabelecerem qualquer separação de regras de tarefas, use pacotes de acesso incompatíveis com o gerenciamento de direitos do Microsoft Entra para impor a separação de tarefas e crie alertas ou configure revisões periódicas para detectar violações por parte dos administradores.
Outras considerações de monitoramento – assinaturas do Azure que contêm recursos usados para o Gerenciamento de Logs devem ser consideradas infraestrutura crítica (Camada 0) e bloqueadas para a equipe de Operações de Segurança do ambiente correspondente. Considere usar ferramentas como Azure Policy para impor controles adicionais a essas assinaturas.
Ferramentas operacionais
Considerações de design de ferramentas entre ambientes:
Sempre que possível, as ferramentas operacionais que serão usadas em vários locatários devem ser projetadas para serem executadas como um aplicativo multilocatário doMicrosoft Entra para evitar a reimplantação de várias instâncias em cada locatário e prevenir ineficiências operacionais. A implementação deve incluir a lógica de autorização para preservar o isolamento entre usuários e dados.
Adicione alertas e detecções para monitorar qualquer automação entre ambientes (por exemplo, provisionamento de identidade) e limites para proteções contra falha. Por exemplo, talvez você queira um alerta se o desprovisionamento de contas de usuário atingir um nível específico, pois isso pode indicar um bug ou erro operacional de amplo impacto.
Qualquer automação que orquestra tarefas entre ambientes deve ser operada como um sistema altamente privilegiado. Esse sistema deve ser hospedado no ambiente de segurança mais alto e retirado de fontes externas se forem necessários dados de outros ambientes. A validação de dados e os limites precisam ser aplicados para manter a integridade do sistema. Uma tarefa comum entre ambientes é o gerenciamento do ciclo de vida de identidades para remover identidades de todos os ambientes para um funcionário demitido.
Ferramentas de gerenciamento de serviços de TI – organizações que usam sistemas ITSM (Gerenciamento de Serviços de TI), como o ServiceNow, devem definir configurações de ativação de função do Microsoft Entra PIM para solicitar um número de tíquete como parte das finalidades de ativação.
Da mesma forma, o Azure Monitor pode ser integrado a sistemas ITSM por meio do Conector de Gerenciamento de Serviços de TI.
Práticas operacionais – minimizar as atividades operacionais que exigem acesso direto ao ambiente a identidades humanas. Em vez disso, modele-os como Azure Pipelines que executam operações comuns (por exemplo, adicione capacidade a uma solução de PaaS, execute diagnósticos e assim por diante) e modele o acesso direto às interfaces do Azure Resource Manager para cenários de "quebra de vidro".
Desafios de operações
A atividade de monitoramento da entidade de serviço é limitada para alguns cenários
Alertas do Microsoft Entra PIM não têm uma API. A mitigação é analisar esses alertas do PIM regularmente.
O Portal do EA do Azure não fornece recursos de monitoramento. A mitigação é ter contas de administração dedicadas e monitorar a atividade da conta.
O MCA não fornece logs de auditoria para tarefas de cobrança. A mitigação é ter contas de administração dedicadas e monitorar a atividade da conta.
Alguns serviços no Azure necessários para operar o ambiente precisam ser reimplantados e reconfigurados em ambientes, pois não podem ser de vários locatários ou de várias nuvens.
Não há cobertura completa de API nos Serviços Online da Microsoft para obter totalmente a infraestrutura como código. A mitigação é usar APIs o máximo possível e usar portais para o restante. Essa iniciativa de software livre ajuda a determinar uma abordagem que pode funcionar para seu ambiente.
Não há nenhuma funcionalidade programática para descobrir locatários de recursos que tenham acesso delegado à assinatura a identidades em um locatário de gerenciamento. Por exemplo, se um endereço de email habilitou um grupo de segurança no locatário contoso.com para gerenciar assinaturas no locatário fabrikam.com, os administradores de contoso.com não têm uma API para descobrir que essa delegação ocorreu.
O monitoramento de atividades de conta específica (por exemplo, conta de quebra de vidro, conta de gerenciamento do orçamento) não é fornecido pronto para uso. A mitigação é para que os clientes criem as próprias regras de alerta.
O monitoramento de configuração em todo o locatário não é fornecido pronto para uso. A mitigação é para que os clientes criem as próprias regras de alerta.
Próximas etapas
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de