Planejar uma implantação de Proteção de ID
O Microsoft Entra ID Protection deteta riscos baseados em identidade, relata-os e permite que os administradores investiguem e corrijam esses riscos para manter as organizações seguras e protegidas. Os dados de risco podem ainda ser alimentados em ferramentas como o Acesso Condicional para tomar decisões de acesso ou alimentados com uma ferramenta de gerenciamento de informações e eventos de segurança (SIEM) para análise e investigação adicionais.
Este plano de implantação estende os conceitos introduzidos no plano de implantação do Acesso Condicional.
Pré-requisitos
- Um locatário do Microsoft Entra em funcionamento com o Microsoft Entra ID P2 ou uma licença de avaliação habilitada. Se necessário, crie um gratuitamente.
- Os administradores que interagem com a Proteção de ID devem ter uma ou mais das seguintes atribuições de função, dependendo das tarefas que estão executando. Para seguir o princípio de menor privilégio do Zero Trust, considere o uso do PIM, Gerenciamento Privilegiado de Identidades para ativar atribuições de função privilegiadas just-in-time.
- Ler políticas e configurações de Proteção de ID e Acesso Condicional
- Gerenciar proteção de ID
- Criar ou modificar políticas de Acesso Condicional
- Um usuário de teste que não é um administrador para verificar se as políticas funcionam conforme o esperado antes de implantar para usuários reais. Se você precisar criar um usuário, consulte Guia de início rápido: adicionar novos usuários ao ID do Microsoft Entra.
- Um grupo do qual o utilizador é membro. Se precisar de criar um grupo, consulte Criar um grupo e adicionar membros no Microsoft Entra ID.
Envolva as partes interessadas certas
Quando os projetos de tecnologia falham, normalmente o fazem devido a expectativas incompatíveis sobre afeto, resultados e responsabilidades. Para evitar essas armadilhas, certifique-se de que você está envolvendo as partes interessadas certas e que os papéis das partes interessadas no projeto são bem compreendidos, documentando as partes interessadas, suas contribuições no projeto e responsabilidade.
Comunicar a mudança
A comunicação é fundamental para o sucesso de qualquer nova funcionalidade. Você deve se comunicar proativamente com seus usuários como a experiência deles muda, quando ela muda e como obter suporte se eles tiverem problemas.
Etapa 1: Revisar os relatórios existentes
É importante revisar os relatórios de Proteção de ID antes de implantar políticas de Acesso Condicional baseadas em risco. Esta revisão dá a oportunidade de investigar qualquer comportamento suspeito existente. Você pode optar por descartar o risco ou confirmar esses usuários como seguros se determinar que eles não estão em risco.
- Investigar deteções de riscos
- Remediar riscos e desbloquear utilizadores
- Fazer alterações em massa usando o Microsoft Graph PowerShell
Para maior eficiência, recomendamos permitir que os usuários se auto-corrijam por meio de políticas discutidas na Etapa 3.
Etapa 2: Planejar políticas de risco de Acesso Condicional
A Proteção de ID envia sinais de risco para o Acesso Condicional, para tomar decisões e aplicar políticas organizacionais. Essas políticas podem exigir que os usuários executem autenticação multifator ou alteração segura de senha. Há vários itens que as organizações devem planejar antes de criar suas políticas.
Exclusões de políticas
As políticas de Acesso Condicional são ferramentas poderosas, recomendamos excluir as seguintes contas das suas políticas:
- Acesso de emergência ou contas de quebra-vidro para evitar o bloqueio devido à configuração incorreta da política. No cenário improvável de todos os administradores estarem bloqueados, sua conta administrativa de acesso de emergência pode ser usada para fazer login e tomar medidas para recuperar o acesso.
- Mais informações podem ser encontradas no artigo Gerenciar contas de acesso de emergência no Microsoft Entra ID.
- Contas de serviço e entidades de serviço, como a Conta de Sincronização do Microsoft Entra Connect. As contas de serviço são contas não interativas que não estão vinculadas a nenhum utilizador em particular. Normalmente, são usadas por serviços de back-end que permitem acesso programático a aplicações, mas também são usadas para iniciar sessão em sistemas para fins administrativos. As chamadas feitas por principais de serviço não serão bloqueadas pelas políticas de Acesso Condicional com âmbito definido para os utilizadores. Use o Acesso Condicional para identidades de carga de trabalho para definir políticas direcionadas para principais de serviço.
- Se sua organização tiver essas contas em uso em scripts ou código, considere substituí-las por identidades gerenciadas.
Autenticação multifator
No entanto, para que os usuários se auto-corrijam o risco, eles devem se registrar para a autenticação multifator do Microsoft Entra antes de se tornarem arriscados. Para obter mais informações, consulte o artigo Plan a Microsoft Entra multifactor authentication deployment.
Locais de rede conhecidos
É importante configurar locais nomeados no Acesso Condicional e adicionar seus intervalos de VPN ao Defender for Cloud Apps. As entradas a partir de localizações nomeadas que estão marcadas como fidedignas ou conhecidas melhoram a precisão dos cálculos de risco da Proteção de ID. Esses logins diminuem o risco de um usuário quando eles se autenticam em um local marcado como confiável ou conhecido. Essa prática reduz os falsos positivos para algumas deteções em seu ambiente.
Modo somente relatório
O modo somente relatório é um estado da política de Acesso Condicional que permite que os administradores avaliem o efeito das políticas de Acesso Condicional antes de impô-las em seu ambiente.
Etapa 3: Configurar suas políticas
Política de registo de MFA de Proteção de ID
Use a política de registro de autenticação multifator da Proteção de ID para ajudar a registrar seus usuários na autenticação multifator do Microsoft Entra antes que precisem usá-la. Siga as etapas no artigo Como: Configurar a política de registro de autenticação multifator do Microsoft Entra para habilitar essa política.
Políticas de Acesso Condicional
Risco de login - A maioria dos usuários tem um comportamento normal que pode ser rastreado, quando eles estão fora dessa norma, pode ser arriscado permitir que eles apenas entrem. Você pode querer bloquear esse usuário ou pedir-lhe para executar a autenticação multifator para provar que ele é realmente quem diz ser. Você começa definindo o escopo dessas políticas para um subconjunto de seus usuários.
Risco do usuário - A Microsoft trabalha com pesquisadores, policiais, várias equipes de segurança da Microsoft e outras fontes confiáveis para encontrar pares de nome de usuário e senha vazados. Quando esses usuários vulneráveis são detetados, recomendamos exigir que os usuários executem autenticação multifator e, em seguida, redefina sua senha.
O artigo Configurar e habilitar políticas de risco fornece orientação para criar políticas de Acesso Condicional para lidar com esses riscos.
Passo 4: Monitorização e necessidades operacionais contínuas
Notificações por e-mail
Habilite as notificações para que você possa responder quando um usuário for sinalizado como em risco. Essas notificações permitem que você comece a investigar imediatamente. Você também pode configurar e-mails de resumo semanal, dando-lhe uma visão geral do risco para essa semana.
Monitorizar e investigar
A pasta de trabalho Análise de impacto de políticas de acesso baseadas em risco ajuda os administradores a entender o impacto do usuário antes de criar políticas de acesso condicional baseadas em risco.
A pasta de trabalho de Proteção de ID pode ajudar a monitorar e procurar padrões em seu locatário. Monitore esta pasta de trabalho em busca de tendências e também dos resultados do modo Somente Relatório de Acesso Condicional para ver se há alterações que precisam ser feitas, por exemplo, adições a locais nomeados.
O Microsoft Defender for Cloud Apps fornece uma estrutura de investigação que as organizações podem usar como ponto de partida. Para obter mais informações, consulte o artigo Como investigar alertas de deteção de anomalias.
Você também pode usar as APIs de proteção de ID para exportar informações de risco para outras ferramentas, para que sua equipe de segurança possa monitorar e alertar sobre eventos de risco.
Durante o teste, convém simular algumas ameaças para testar seus processos de investigação.