Práticas recomendadas para todas as arquiteturas de isolamento
A seguir estão as considerações de design para todas as configurações de isolamento. Ao longo deste conteúdo, são muitos os links. Nós vinculamos ao conteúdo, em vez de duplicá-lo aqui, para que você sempre tenha acesso às informações mais atualizadas.
Para obter orientações gerais sobre como configurar locatários do Microsoft Entra (isolados ou não), consulte o guia de implantação de recursos do Microsoft Entra.
Nota
Para todos os inquilinos isolados, sugerimos que use uma marca clara e diferenciada para ajudar a evitar o erro humano de trabalhar no inquilino errado.
Princípios de segurança de isolamento
Ao projetar ambientes isolados, é importante considerar os seguintes princípios:
Usar apenas autenticação moderna - Os aplicativos implantados em ambientes isolados devem usar a autenticação moderna baseada em declarações (por exemplo, SAML, * Auth, OAuth2 e OpenID Connect) para usar recursos como federação, colaboração B2B do Microsoft Entra, delegação e a estrutura de consentimento. Dessa forma, os aplicativos herdados que dependem de métodos de autenticação herdados, como o NT LAN Manager (NTLM), não serão levados adiante em ambientes isolados.
Impor autenticação forte - A autenticação forte deve ser sempre usada ao acessar os serviços e a infraestrutura do ambiente isolado. Sempre que possível, a autenticação sem senha, como o Windows for Business Hello ou uma chave de segurança FIDO2, deve ser usada.
Implante estações de trabalho seguras As - estações de trabalho seguras fornecem o mecanismo para garantir que a plataforma e a identidade que ela representa sejam devidamente atestadas e protegidas contra exploração. Duas outras abordagens a considerar são:
Use o Windows 365 Cloud PCs (Cloud PC) com a API do Microsoft Graph.
Use Acesso Condicional e filtro para dispositivos como uma condição.
Elimine 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 relações de confiança do Ative 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 à superfície protegendo as identidades subjacentes e a infraestrutura de serviços contra a exposição. Habilite o acesso somente por meio de autenticação moderna para serviços e acesso remoto seguro (também protegido por autenticação moderna) para a infraestrutura.
Atribuições de função no nível do diretório - Evite ou reduza o número de atribuições de função no nível do diretório (Administrador de usuário no escopo do diretório em vez do escopo da AU) ou funções de diretório específicas do serviço com ações do plano de controle (Administrador de conhecimento com permissões para gerenciar associações a grupos de segurança).
Além das orientações no guia de operações gerais do Microsoft Entra, também recomendamos as seguintes considerações para ambientes isolados.
Aprovisionamento de identidade humana
Contas privilegiadas
Provisionar contas no ambiente isolado para pessoal administrativo e equipes de TI que operam o ambiente. Isso permite 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 de não produção podem potencialmente utilizar a colaboração B2B do Microsoft Entra para integrar contas privilegiadas aos locatários que não são de produção usando a mesma postura e controles de segurança projetados para acesso privilegiado em seu ambiente de produção.
Contas somente na nuvem são a maneira mais simples de provisionar identidades humanas em um locatário do Microsoft Entra e são uma boa opção para ambientes de campo verde. No entanto, se houver uma infraestrutura local existente que corresponda ao ambiente isolado (por exemplo, floresta do Ative Directory de pré-produção ou gerenciamento), você poderá considerar a sincronização de identidades a partir daí. Isso é especialmente verdadeiro se a infraestrutura local descrita aqui for usada para soluções IaaS que exigem acesso ao servidor para gerenciar o plano de dados da solução. Para obter mais informações sobre esse cenário, consulte Protegendo o Microsoft 365 contra ataques locais. A sincronização a partir de ambientes locais isolados também pode ser necessária se houver requisitos específicos de conformidade regulamentar, como autenticação somente de cartão inteligente.
Nota
Não há controles técnicos para fazer prova de identidade para contas B2B do Microsoft Entra. As identidades externas provisionadas com o Microsoft Entra B2B são inicializadas com um único fator. A atenuação é que a organização tenha um processo para comprovar as identidades necessárias antes de um convite B2B ser emitido 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.
Terceirização de funções de alto risco
Para mitigar ameaças internas, é possível terceirizar o acesso às funções de Administrador Global e Administrador de Função Privilegiada para ser provedor de serviços gerenciados usando a colaboração B2B do Azure ou delegando acesso por meio de um parceiro CSP ou farol. Esse acesso pode ser controlado pela equipe interna por meio de fluxos de aprovação no Azure Privileged Identity Management (PIM). Esta abordagem pode reduzir significativamente as ameaças internas. Essa é uma abordagem que você pode usar 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 permanentemente atribuídas à função de 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 "quebra de vidro" em que as contas normais não podem ser usadas ou todos os outros administradores são bloqueados acidentalmente. Essas contas devem ser criadas seguindo as recomendações da conta 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. Verifique a lista de serviços que dão suporte a identidades gerenciadas ao projetar suas soluções do Azure.
Se as identidades gerenciadas não forem suportadas ou não forem possíveis, considere provisionar objetos de entidade de serviço.
Contas de serviço híbridas
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 ingressados no 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 têm a capacidade de entrar interativamente, o que significa que, em cenários de nuvem, elas não podem atender a requisitos de credenciais fortes, como autenticação multifator. Nesse cenário, não use uma conta de serviço que tenha sido sincronizada localmente, mas use uma identidade gerenciada \ entidade de serviço. Para entidade de serviço (SP), use um certificado como credencial ou proteja a controladora com acesso condicional.
Se houver restrições técnicas que não tornem isso possível e a mesma conta tiver que ser usada tanto para o local quanto para 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 recurso
Uma solução empresarial pode ser composta por vários recursos do Azure e o seu acesso deve ser gerido e gerido como uma unidade lógica de atribuição - um grupo de recursos. Nesse cenário, os grupos de segurança do Microsoft Entra podem ser criados e associados às permissões e à atribuição de função adequadas em todos os recursos da solução, de modo que adicionar ou remover usuários desses grupos resulte em permitir ou negar acesso a toda a solução.
Recomendamos que você use o licenciamento baseado em grupo e grupos de segurança para serviços da Microsoft que dependem de um usuário que tenha uma atribuição de estação de licença como pré-requisito antes de fornecer acesso (por exemplo, Dynamics 365, Power BI).
Os grupos nativos da nuvem do Microsoft Entra podem ser governados nativamente a partir 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 oferece suporte à atribuição direta de usuários a serviços SaaS de terceiros (por exemplo, Salesforce, Service Now) e aplicativos locais para logon único e provisionamento de identidade. As atribuições diretas a recursos podem ser governadas nativamente a partir da nuvem quando combinadas 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 Ative Directory locais. Para esses casos, considere o ciclo de sincronização com o Microsoft Entra ID ao projetar processos SLA.
Gestão da autenticação
Esta seção descreve as verificações a serem executadas e as ações a serem tomadas para o gerenciamento de credenciais e as políticas de acesso com base na postura de segurança da sua organização.
Gestão de credenciais
Credenciais fortes
Todas as identidades humanas (contas locais e identidades externas provisionadas por meio de colaboração B2B) no ambiente isolado devem ser provisionadas com credenciais de autenticação forte, como autenticação multifator ou uma chave FIDO. Ambientes com uma infraestrutura local subjacente com autenticação forte, como autenticação de cartão inteligente, podem continuar usando a autenticação de cartão inteligente na nuvem.
Credenciais sem senha
Uma solução sem senha é a melhor solução para garantir o método mais conveniente e seguro de autenticação. Credenciais sem senha, como chaves de segurança FIDO e Windows Hello for Business , são recomendadas para identidades humanas com funções privilegiadas.
Proteção por palavra-passe
Se o ambiente estiver sincronizado a partir de uma floresta do Ative Directory local, você deverá implantar 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 em nuvem para bloquear agentes mal-intencionados que estão tentando adivinhar as senhas de seus usuários ou usar métodos de força bruta para entrar.
Gestão de palavras-passe personalizada
Os usuários que precisam alterar ou redefinir suas senhas são uma das maiores fontes de volume e custo de chamadas de suporte técnico. Além do custo, alterar a senha como ferramenta para mitigar um risco do usuário é um passo fundamental para melhorar a postura de segurança da sua organização. No mínimo, implante o Gerenciamento de Senhas de Autoatendimento para contas humanas e de teste com senhas para desviar chamadas de suporte técnico.
Senhas de identidades externas
Ao usar a colaboração B2B do Microsoft Entra, um processo de convite e resgate permite que usuários externos, como parceiros, desenvolvedores e subcontratados, usem suas próprias credenciais para acessar os recursos da sua empresa. Isso reduz a necessidade de introduzir mais senhas nos locatários isolados.
Nota
Alguns aplicativos, infraestrutura ou fluxos de trabalho podem exigir uma credencial local. Avalie caso a caso.
Credenciais das entidades de serviço
Para cenários em que as entidades de serviço são necessárias, use credenciais de certificado para entidades de serviço ou Acesso Condicional para identidades de carga de trabalho. Se necessário, use segredos de cliente como uma exceção à política organizacional.
Em ambos os casos, o Azure Key Vault pode ser usado com identidades gerenciadas do Azure, para que o ambiente de tempo de execução (por exemplo, uma 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
Nas seções a seguir estão recomendações para soluções do Azure. Para obter orientações gerais sobre políticas de Acesso Condicional para ambientes individuais, consulte as Práticas recomendadas 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 da API de Gerenciamento de Serviços do Windows Azure para impor a postura de segurança de identidade ao acessar o Gerenciador de Recursos do Azure. Isso deve incluir controles em MFA e controles baseados em dispositivos para permitir o acesso somente por meio de estações de trabalho seguras (mais sobre isso na seção Funções privilegiadas em Governança de identidade). Além disso, use o 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 reflitam 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 o uso do Acesso Condicional para restringir identidades de carga de trabalho. Crie uma política para limitar ou controlar melhor o acesso com base na localização ou em outras circunstâncias relevantes.
Desafios de autenticação
As identidades externas provisionadas com o Microsoft Entra B2B podem precisar reprovisionar credenciais de autenticação multifator no locatário do recurso. Isso pode 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 único fator. Com essa abordagem, a mitigação de risco é que a organização tenha um processo para comprovar o perfil de risco do usuário e da credencial antes de um convite B2B ser emitido. Além disso, defina Acesso Condicional ao processo de registro conforme descrito anteriormente.
Use as configurações de acesso entre locatários de identidades externas para gerenciar como elas colaboram com outras organizações do Microsoft Entra e outras nuvens do Microsoft Azure por meio da colaboração B2B e da conexão direta B2B.
Para configuração e controle de dispositivos específicos, você pode usar filtros de dispositivo em políticas de Acesso Condicional para direcionar ou excluir dispositivos específicos. Isso permite que você restrinja o acesso às ferramentas de gerenciamento do Azure a partir de uma estação de trabalho de administração segura (SAW) designada. Outras abordagens que você pode adotar incluem o uso da Área de Trabalho Virtual do Azure, do Azure Bastion ou do Cloud PC.
As aplicações de gestão de faturação, como o portal EA do Azure ou as contas de faturação MCA, não são representadas como aplicações na nuvem para segmentação de Acesso Condicional. Como controle de compensação, defina contas de administração separadas e direcione políticas de Acesso Condicional para essas contas usando uma condição "Todos os Aplicativos".
Identity Governance
Papéis privilegiados
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 realizar operações privilegiadas em ambientes isolados. O RBAC (controle de acesso baseado em função) do Azure integra-se ao Microsoft Entra Privileged Identity Management (PIM). O PIM fornece ativação just-in-time determinada por portas 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 pessoas com um papel privilegiado para mitigar os riscos de continuidade de 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 privilégios mínimos.
Limitar o acesso privilegiado - Crie grupos somente na nuvem e atribuíveis por função para privilégios altos 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 de acordo com sua função na organização.
As funções personalizadas do RBAC do Azure permitem projetar funções menos privilegiadas com base nas necessidades organizacionais. Recomendamos que as definições de funções personalizadas sejam criadas ou revisadas por equipes de segurança especializadas e reduzam os riscos de privilégios excessivos não intencionais. A criação de funções personalizadas pode ser auditada por meio da Política do Azure.
Para atenuar o uso acidental de funções que não se destinam a uso mais amplo na organização, use a Política do Azure para definir explicitamente quais definições de função podem ser usadas para atribuir acesso. Saiba mais com este exemplo do GitHub.
Acesso privilegiado a partir de estações de trabalho seguras - Todo o acesso privilegiado deve ocorrer a partir de dispositivos seguros e bloqueados . Separar essas tarefas e contas confidenciais de estações de trabalho e dispositivos de uso diário protege contas privilegiadas contra ataques de phishing, vulnerabilidades de aplicativos e sistemas operacionais, vários ataques de falsificação de identidade e ataques de roubo de credenciais, como registro de pressionamento de teclas, Pass-the-Hash e Pass-The-Ticket.
Algumas abordagens que você pode usar para usar dispositivos seguros como parte de sua história de acesso privilegiado incluem o uso de políticas de Acesso Condicional para direcionar ou excluir dispositivos específicos, usando a Área de Trabalho Virtual do Azure, o Azure Bastion ou o Cloud PC ou a criação de estações de trabalho gerenciadas pelo Azure ou estações de trabalho de acesso privilegiado.
Guardrails de processo de função privilegiada - As organizações devem definir processos e guarda-corpos técnicos para garantir que operações privilegiadas possam ser executadas sempre que necessário, cumprindo os requisitos regulamentares. Exemplos de critérios de guarda-corpos:
Qualificação de seres humanos com funções privilegiadas (por exemplo, funcionário/vendedor a tempo inteiro, nível de autorização, cidadania)
Incompatibilidade explícita de funções (também conhecida como separação de funções). Os exemplos incluem equipes com funções de diretório do Microsoft Entra que 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 preferidas para quais funções.
O monitoramento de atribuições do IAM fora do Microsoft Entra PIM não é automatizado por meio das Políticas do Azure. A atenuação é não conceder funções de Proprietário da Assinatura ou Administrador de Acesso de 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 aos recursos
Atestado - As identidades que ocupam papéis privilegiados devem ser revistas periodicamente para manter a filiação atualizada e justificada. As revisões de acesso do Microsoft Entra integram-se com funções RBAC do Azure, associações de grupo e identidades externas B2B do Microsoft Entra.
Ciclo de vida - As operações privilegiadas podem exigir acesso a vários recursos, como aplicativos de linha de negócios, aplicativos SaaS e grupos de recursos e assinaturas do Azure. O Microsoft Entra Entitlement Management permite definir pacotes de acesso que representam um recurso definido que é atribuído aos usuários como uma unidade, estabelecer um período de validade, fluxos de trabalho de aprovação e assim por diante.
Gerenciamento do ciclo de vida do locatário e da assinatura
Ciclo de vida do locatário
Recomendamos implementar um processo para solicitar um novo locatário corporativo do Microsoft Entra. O processo deve ter em conta:
Justificação empresarial para a sua criação. Criar um novo locatário do Microsoft Entra aumentará significativamente a complexidade, por isso é fundamental verificar se um novo locatário é necessário.
A nuvem do Azure na qual ele deve ser criado (por exemplo, Comercial, Governo e assim por diante).
Quer se trate de produção ou não produção
Requisitos de residência de dados de diretório
Quem irá geri-lo
Formação e compreensão dos requisitos comuns de segurança.
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 faturamento, monitoramento e assim por diante.
A revisão regular dos locatários do Microsoft Entra no plano de faturamento precisa ser implementada para detetar e descobrir a criação de locatários fora do processo controlado. Consulte a seção Inventário e visibilidade deste documento para obter mais detalhes.
A criação de locatários do Azure AD B2C pode ser controlada usando a Política do Azure. A política é executada quando uma assinatura do Azure é 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 é registada no registo de auditoria. O onboarding para o avião de faturamento é um controle de compensação no portão. Em vez disso, tal deve ser complementado com monitorização e alertas.
Ciclo de vida da subscrição
Abaixo estão algumas considerações ao projetar um processo de ciclo de vida de assinatura governado:
Defina uma taxonomia de aplicativos e soluções que exigem recursos do Azure. Todas as equipas que solicitem subscrições devem fornecer o seu "identificador de produto" quando solicitam subscrições. Esta taxonomia de informação determinará:
Locatário do Microsoft Entra para provisionar a assinatura
Conta EA do Azure a ser usada para a criação de assinaturas
Convenção de nomenclatura
Atribuição de grupo de gestão
Outros aspetos, como marcação, carregamento cruzado, uso de visualização do produto e assim por diante.
Não permita a criação de assinaturas ad-hoc através dos portais ou por outros meios. Em vez disso, considere gerenciar assinaturas programaticamente usando o Azure Resource Manager e extraindo relatórios de consumo e cobrança programaticamente. Isso pode ajudar a limitar o provisionamento de assinatura para usuários autorizados e aplicar suas metas de política e taxonomia. Orientações sobre como seguir os princípios do AZOps podem ser usadas para ajudar a criar uma solução prática.
Quando uma assinatura for provisionada, crie grupos de nuvem do Microsoft Entra para manter as funções padrão do Azure Resource Manager necessárias para as equipes de aplicativos, como Colaborador, Leitor e funções personalizadas aprovadas. Isso permite que você gerencie 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 do Azure RBAC usando o Microsoft Entra PIM com os controles correspondentes, como política de ativação, revisões de acesso, aprovadores e assim por diante.
Em seguida, delegue o gerenciamento dos grupos aos proprietários da solução.
Como guardrail, não atribua proprietários de produtos a funções de Administrador de Acesso de Usuário ou Proprietário para evitar a atribuição direta inadvertida de funções fora do Microsoft Entra PIM, ou potencialmente alterar a assinatura para um locatário diferente.
Para clientes que optam por habilitar o gerenciamento de assinatura entre locatários em locatários que não são de produção por meio do Azure Lighthouse, certifique-se de que as mesmas políticas de acesso da conta privilegiada de produção (por exemplo, acesso privilegiado somente de estações de trabalho seguras) sejam aplicadas ao autenticar para gerenciar assinaturas.
Se sua organização tiver arquiteturas de referência pré-aprovadas, o provisionamento de assinatura poderá ser integrado com ferramentas de implantação de recursos, como Azure Blueprints ou Terraform.
Dada a afinidade do 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 de acordo.
Funções EA e MCA
O portal do Contrato do Azure Enterprise (Azure EA) não se integra com o Azure RBAC ou o Acesso Condicional. A atenuação para isso é usar contas de administração dedicadas que podem ser direcionadas 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 Microsoft Customer Agreement (MCA) 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 oferecem suporte ao PIM. Para aumentar a segurança, recomendamos usar a colaboração do Microsoft Entra B2B para integrar as equipes de engenharia que gerenciam o CIAM (Customer Identity Access Management) do seu locatário do Azure, atribuí-las a funções privilegiadas do Azure AD B2C e aplicar políticas de Acesso Condicional a essas contas de administração dedicadas.
As funções privilegiadas de locatário do Azure AD B2C não são integradas às revisões de acesso do Microsoft Entra. A atenuação é criar contas dedicadas no locatário do Microsoft Entra da organização, adicionar essas contas a um grupo e realizar revisões regulares de acesso nesse grupo.
Seguindo as diretrizes de acesso de emergência para o Microsoft Entra ID acima, considere criar contas de acesso de emergência equivalentes, além dos administradores externos descritos acima.
Recomendamos que a propriedade lógica da assinatura subjacente do Microsoft Entra do locatário B2C se alinhe com as equipes de engenharia do CIAM, da mesma forma que o restante das assinaturas do Azure são usadas para as soluções B2C.
Operações
A seguir estão considerações operacionais adicionais para o Microsoft Entra ID, específicas para vários ambientes isolados. Consulte o Azure Cloud Adoption Framework, o benchmark de segurança na nuvem da Microsoft e o guia de Operações do Microsoft Entra para obter orientações detalhadas para operar ambientes individuais.
Funções e responsabilidades entre ambientes
Arquitetura SecOps em toda a empresa - Os membros das equipes de operações e segurança de todos os ambientes da organização devem definir conjuntamente o seguinte:
Princípios para definir 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 faturamento (portal EA / MCA), postura operacional e abordagem de delegação.
Processo de criação de inquilinos.
Taxonomia de aplicações empresariais.
Processo de provisionamento de assinatura do Azure.
Limites de autonomia de isolamento e administração e avaliação de riscos entre equipes e ambientes.
Configuração de linha de base comum e controlos de segurança (técnicos e compensatórios) e linhas de base operacionais a utilizar 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 acordada em vários ambientes.
Segregação de tarefas entre ambientes.
Gestão comum da cadeia de abastecimento 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 criar o locatário seguindo procedimentos padronizados definidos pela arquitetura SecOps em toda a empresa. O que está incluído:
Provisionamento de licença subjacente (por exemplo, Microsoft 365).
Integração ao plano de faturação empresarial (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 de pilha de segurança por arquitetura de segurança cibernética acordada, incluindo configurações de diagnóstico, integração SIEM, integração CASB, integração 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 privilegiadas iniciais.
Provisionamento de 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 trabalhar em vários ambientes. Essas ferramentas devem ser consideradas críticas para a infraestrutura e devem ser arquitetadas, projetadas, implementadas e gerenciadas como tal. Como resultado, arquitetos de todos os ambientes devem ser envolvidos sempre que ferramentas entre ambientes precisarem ser definidas.
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 eles a função interna de Administrador de Acesso de Usuário no grupo de gerenciamento raiz.
Nota
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.
Habilitando o acesso de leitura para descobrir recursos - Os 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 de recursos no ambiente, o Azure Resource Graph pode ser usado para consultar recursos no ambiente.
Registos e monitorização
Gerenciamento central de logs de segurança - Ingerir logs de cada ambiente de forma centralizada, seguindo práticas recomendadas consistentes em todos os ambientes (por exemplo, configurações de diagnóstico, retenção de logs, ingestão de SIEM e assim por diante). 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 e assim por diante.
Informações detalhadas sobre o uso de processos e ferramentas automatizados ou manuais para monitorar logs como parte de suas 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 quais dados (se houver) podem sair de um determinado ambiente. Se o monitoramento centralizado entre ambientes não for possível, as equipes devem ter procedimentos operacionais para correlacionar atividades de identidades entre ambientes para fins de auditoria e perícia, como tentativas de movimento lateral entre ambientes. Recomenda-se que o objeto identifica identidades humanas pertencentes à mesma pessoa seja detetável, 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 início de sessão
Registos de auditoria
Eventos de risco
O Microsoft Entra ID fornece integração do 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 diagrama a seguir mostra as diferentes fontes de dados que precisam ser incorporadas como parte da estratégia de monitoramento:
Os locatários do Azure AD B2C podem ser integrados ao Azure Monitor. Recomendamos o monitoramento do 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 podem habilitar o monitoramento entre locatários se os logs forem coletados pelo Azure Monitor. Os espaços de trabalho do Log Analytics correspondentes 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, consulte Monitorar recursos delegados em escala - Azure Lighthouse.
Logs de segurança do sistema operacional de infraestrutura híbrida
Todos os logs do sistema operacional da infraestrutura de identidade híbrida devem ser arquivados e cuidadosamente monitorados como um sistema de nível 0, dadas as implicações da área de superfície. O que está incluído:
Servidores AD FS e Proxy de Aplicativo Web
Microsoft Entra Connect
Agentes de proxy de aplicativo
Agentes de write-back de senha
Máquinas de gateway de proteção por 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 log - Todos os ambientes devem ter uma estratégia, design e implementação coesos de retenção de armazenamento de log para facilitar um conjunto de ferramentas consistente (por exemplo, sistemas SIEM, como o Azure Sentinel), consultas comuns, investigação e playbooks forenses. A Política do Azure pode ser usada para definir configurações de diagnóstico.
Monitoramento e revisão de logs - As tarefas operacionais em torno do monitoramento de identidade devem ser consistentes e ter proprietários em cada ambiente. Conforme descrito acima, esforce-se para consolidar essas responsabilidades em todos os ambientes, na medida permitida pela conformidade regulatória e pelos requisitos de isolamento.
Os seguintes cenários devem ser explicitamente monitorizados 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 da rede para evitar deteções barulhentas em sinais baseados em localização. A Proteção de ID do Microsoft Entra é integrada nativamente com a Central de Segurança do Azure. É recomendável que qualquer investigação de deteção de risco inclua todos os ambientes em que a identidade é provisionada (por exemplo, se uma identidade humana tiver uma deteção de risco ativa no locatário corporativo, a equipe que opera o locatário voltado para o cliente também deve investigar a atividade da conta correspondente nesse ambiente).
Alertas de análise comportamental de entidade de usuário (UEBA) - A UEBA deve ser usada para obter informações perspicazes com base na deteção de anomalias. O Microsoft Microsoft 365 Defender for Cloud Apps fornece UEBA na nuvem. Os clientes podem integrar o UEBA local a partir do Microsoft 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 criados para investigações. Este acompanhamento deve incluir:
Inícios de sessão
Gestão de credenciais
Quaisquer atualizações sobre associações de grupo
Atribuições de Aplicação
Contas de gestão de faturação - Dada a sensibilidade das contas com funções de gestão de faturação no Azure EA ou MCA e os seus privilégios significativos, recomenda-se monitorizar e alertar:
Inicie sessão em tentativas por contas com funções de faturação.
Qualquer tentativa de autenticação em aplicativos diferentes do Portal EA.
Qualquer tentativa de autenticação em aplicativos diferentes do Gerenciamento de Recursos do Azure se estiver usando contas dedicadas para tarefas de cobrança MCA.
Atribuição a recursos do Azure usando contas dedicadas para tarefas de cobrança MCA.
Atividade de função privilegiada - Configure e revise alertas de segurança gerados pelo Microsoft Entra PIM. Se o bloqueio de atribuições diretas do RBAC não for totalmente aplicável com controles técnicos (por exemplo, a função de proprietário deve ser concedida às equipes de produto para fazer 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 moderna do Azure em vez das funções clássicas . Como resultado, os seguintes eventos devem ser monitorados:
- Atribuição a funções clássicas ao nível da subscrição
Configurações em todo o locatário - Qualquer serviço de configuração em todo o locatário deve gerar alertas no sistema.
Atualizando domínios personalizados
Atualização da identidade visual
Lista de permissões/bloqueios do Microsoft Entra B2B
Provedores de identidade permitidos pelo Microsoft Entra B2B (IDPs SAML por meio de federação direta ou logins sociais)
Alterações nas Políticas de Acesso Condicional
Objetos de aplicação e de principal de serviço
Novas entidades de Aplicativos/Serviços que podem exigir políticas de Acesso Condicional
Atividade de Consentimento de Aplicação
Atividade do grupo de gerenciamento - Os seguintes Aspetos de Identidade dos grupos de gerenciamento devem ser monitorados:
Atribuições de funções do RBAC no MG
Políticas do Azure aplicadas no MG
Assinaturas movidas entre MGs
Quaisquer alterações nas políticas de segurança para o MG raiz
Funções personalizadas
Atualizações das definições de função personalizada
Novas funções personalizadas criadas
Regras personalizadas de separação de funções - Se as suas organizações estabeleceram regras de separação de funções, utilize pacotes de acesso incompatíveis com o Microsoft Entra Entitlement Management para impor a separação de funções e crie alertas ou configure revisões periódicas para detetar violações por parte dos administradores.
Outras considerações de monitoramento - as assinaturas do Azure que contêm recursos usados para o Gerenciamento de Logs devem ser consideradas como infraestrutura crítica (Nível 0) e bloqueadas para a equipe de Operações de Segurança do ambiente correspondente. Considere o uso de ferramentas como a Política do Azure 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 do Microsoft Entra para evitar a reimplantação de várias instâncias em cada locatário e evitar ineficiências operacionais. A implementação deve incluir lógica de autorização para garantir que o isolamento entre usuários e dados seja preservado.
Adicione alertas e deteções para monitorar qualquer automação entre ambientes (por exemplo, provisionamento de identidade) e limites de limite para segurança contra falhas. Por exemplo, você pode querer um alerta se o desprovisionamento de contas de usuário atingir um nível específico, pois pode indicar um bug ou erro operacional que pode ter um amplo impacto.
Qualquer automação que orquestra tarefas entre ambientes deve ser operada como um sistema altamente privilegiado. Este sistema deve ser alojado no ambiente de segurança mais elevado e extraído 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 da identidade para remover identidades de todos os ambientes para um funcionário demitido.
Ferramentas de gerenciamento de serviços de TI - As organizações que usam sistemas de Gerenciamento de Serviços de TI (ITSM), como o ServiceNow, devem definir as configurações de ativação da função PIM do Microsoft Entra para solicitar um número de tíquete como parte das finalidades de ativação.
Da mesma forma, o Azure Monitor pode ser integrado com sistemas ITSM por meio do IT Service Management Connector.
Práticas operacionais - Minimizar as atividades operacionais que exigem acesso direto ao ambiente para as identidades humanas. Em vez disso, modele-os como Pipelines do Azure que executam operações comuns (por exemplo, adicionar capacidade a uma solução PaaS, executar diagnósticos e assim por diante) e modelar o acesso direto às interfaces do Azure Resource Manager para cenários de "quebra de vidro".
Desafios das operações
A atividade de monitoramento da entidade de serviço é limitada para alguns cenários
Os alertas do Microsoft Entra PIM não têm uma API. A mitigação é ter uma revisão regular desses alertas PIM.
O Portal 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 faturamento. 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 entre ambientes, pois não podem ser multilocatários ou multinuvem.
Não há cobertura total de API no Microsoft Online Services para alcançar totalmente a infraestrutura como código. A mitigação é usar APIs tanto quanto possível e usar portais para o restante. Esta iniciativa de código aberto para ajudá-lo a determinar uma abordagem que possa funcionar para o seu ambiente.
Não há capacidade programática para descobrir locatários de recursos que tenham acesso de assinatura delegado a identidades em um locatário de gerenciamento. Por exemplo, se um endereço de email permitiu que um grupo de segurança no locatário contoso.com gerenciasse assinaturas no locatário fabrikam.com, os administradores no contoso.com não têm uma API para descobrir que essa delegação ocorreu.
O monitoramento específico da atividade da conta (por exemplo, conta de vidro quebrado, conta de gerenciamento de faturamento) não é fornecido imediatamente. A mitigação é para que os clientes criem suas próprias regras de alerta.
O monitoramento de configuração em todo o locatário não é fornecido imediatamente. A mitigação é para que os clientes criem suas próprias regras de alerta.
Próximos passos
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários