Migrar para Microsoft Defender para Office 365 – Fase 2: Configuração

• Aplica-se a:

  ✅ Microsoft Defender for Office 365 Plan 2

Fase 1: preparação	Fase 2: configuração	Fase 3: integração
	Está aqui!

Bem-vindo à Fase 2: Configurara migração para Microsoft Defender para Office 365! Esta fase de migração inclui os seguintes passos:

1. Criar grupos de distribuição para utilizadores piloto
2. Configurar as definições de mensagens comunicadas pelo utilizador
3. Manter ou criar a regra de fluxo de correio SCL=-1
4. Configurar a Filtragem Avançada para Conectores
5. Criar políticas de proteção piloto

Passo 1: criar grupos de distribuição para utilizadores piloto

Os grupos de distribuição são necessários no Microsoft 365 para os seguintes aspetos da migração:

• Exceções para a regra de fluxo de correio SCL=-1: pretende que os utilizadores piloto obtenham o efeito completo da proteção Defender para Office 365, pelo que precisa de Defender para Office 365 para analisar as respetivas mensagens recebidas. Obtém este resultado ao definir os utilizadores piloto nos grupos de distribuição adequados no Microsoft 365 e ao configurar estes grupos como exceções à regra de fluxo de correio SCL=-1.

  Tal como descrevemos no Passo 2: (Opcional) Isentar os utilizadores piloto da filtragem pelo seu serviço de proteção existente, deve considerar isentar estes mesmos utilizadores-piloto da análise pelo serviço de proteção existente. Eliminar a possibilidade de filtragem pelo seu serviço de proteção existente e depender exclusivamente de Defender para Office 365 é a melhor e mais próxima representação do que vai acontecer após a conclusão da migração.

• Teste de funcionalidades específicas de proteção Defender para Office 365: mesmo para os utilizadores piloto, não quer ativar tudo ao mesmo tempo. Utilizar uma abordagem faseada para as funcionalidades de proteção que estão em vigor para os utilizadores piloto facilita a resolução de problemas e o ajuste. Com esta abordagem em mente, recomendamos os seguintes grupos de distribuição:

  • Um grupo piloto de Anexos Seguros: por exemplo, MDOPilot_SafeAttachments
  • Um grupo piloto de Ligações Seguras: por exemplo, MDOPilot_SafeLinks
  • Um grupo piloto para definições de política anti-spam e anti-phishing Standard: por exemplo, MDOPilot_SpamPhish_Standard
  • Um grupo piloto para definições estritas de política anti-spam e anti-phishing: por exemplo, MDOPilot_SpamPhish_Strict

Para maior clareza, utilizamos estes nomes de grupo específicos ao longo deste artigo, mas pode utilizar a sua própria convenção de nomenclatura.

Quando estiver pronto para começar a testar, adicione estes grupos como exceções à regra de fluxo de correio SCL=-1. À medida que cria políticas para as várias funcionalidades de proteção no Defender para Office 365, utilize estes grupos como condições que definem a quem a política se aplica.

Notas:

• Os termos Standard e Strict provêm das nossas definições de segurança recomendadas, que também são utilizadas em políticas de segurança predefinidas. Idealmente, dir-lhe-emos para definir os seus utilizadores piloto nas políticas de segurança predefinidas Padrão e Estrita, mas não podemos fazê-lo. Porquê? Uma vez que não pode personalizar as definições em políticas de segurança predefinidas (em particular, ações executadas em mensagens). Durante os testes de migração, quer ver o que Defender para Office 365 faria às mensagens, verificar se é esse o resultado pretendido e, possivelmente, ajustar as configurações da política para permitir ou impedir esses resultados.

  Por isso, em vez de utilizar políticas de segurança predefinidas, irá criar manualmente políticas personalizadas com definições semelhantes às, mas em alguns casos são diferentes das definições das políticas de segurança predefinidas Padrão e Estrita.

• Se quiser experimentar definições que diferem significativamente dos nossos valores recomendados Padrão ou Estrito, deve considerar criar e utilizar grupos de distribuição adicionais e específicos para os utilizadores piloto nesses cenários. Pode utilizar o Analisador de Configuração para ver a segurança das suas definições. Para obter instruções, veja Analisador de configuração para políticas de proteção na EOP e Microsoft Defender para Office 365.

  Para a maioria das organizações, a melhor abordagem é começar com políticas que se alinham estreitamente com as nossas definições Padrão recomendadas. Depois de tantas observações e comentários como pode fazer no período de tempo disponível, pode passar para definições mais agressivas mais tarde. A proteção de representação e a entrega na pasta de Email de Lixo vs. entrega em quarentena podem exigir personalização.

  Se utilizar políticas personalizadas, certifique-se de que são aplicadas antes das políticas que contêm as nossas definições recomendadas para a migração. Se um utilizador for identificado em várias políticas do mesmo tipo (por exemplo, anti-phishing), apenas uma política desse tipo é aplicada ao utilizador (com base no valor de prioridade da política). Para obter mais informações, consulte Ordem e precedência da proteção de e-mail.

Passo 2: Configurar as definições de mensagens comunicadas pelo utilizador

A capacidade de os utilizadores reportarem falsos positivos ou falsos negativos de Defender para Office 365 é uma parte importante da migração.

Pode especificar uma caixa de correio Exchange Online para receber mensagens que os utilizadores comunicam como maliciosas ou não maliciosas. Para obter instruções, consulte Definições comunicadas pelo utilizador. Esta caixa de correio pode receber cópias de mensagens que os seus utilizadores submeteram à Microsoft ou a caixa de correio pode intercetar mensagens sem as comunicar à Microsoft (a sua equipa de segurança pode analisar e submeter as mensagens manualmente). No entanto, a abordagem de intercepção não permite que o serviço ajuste e aprenda automaticamente.

Também deve confirmar que todos os utilizadores no piloto têm uma forma suportada de comunicar mensagens que receberam um veredicto incorreto de Defender para Office 365. Estas opções incluem:

• O botão Relatório incorporado no Outlook
• Os suplementos Mensagem de Relatório e Phishing de Relatórios
• Ferramentas de relatórios de terceiros suportadas, conforme descrito aqui.

Não subestimes a importância deste passo. Os dados das mensagens comunicadas pelo utilizador dar-lhe-ão o ciclo de comentários de que precisa para verificar uma boa e consistente experiência de utilizador final antes e depois da migração. Este feedback ajuda-o a tomar decisões de configuração de políticas informadas e a fornecer relatórios com suporte de dados para a gestão de que a migração correu sem problemas.

Em vez de depender de dados baseados na experiência de toda a organização, mais do que uma migração resultou em especulação emocional com base numa única experiência de utilizador negativa. Além disso, se estiver a executar simulações de phishing, pode utilizar o feedback dos seus utilizadores para o informar quando virem algo de risco que possa exigir investigação.

Passo 3: Manter ou criar a regra de fluxo de correio SCL=-1

Uma vez que o seu e-mail de entrada é encaminhado através de outro serviço de proteção que se encontra à frente do Microsoft 365, é provável que já tenha uma regra de fluxo de correio (também conhecida como regra de transporte) no Exchange Online que define o nível de confiança de spam (SCL) de todos os e-mails recebidos para o valor -1 (ignorar a filtragem de spam). A maioria dos serviços de proteção de terceiros incentiva esta regra de fluxo de correio SCL=-1 para clientes do Microsoft 365 que pretendam utilizar os seus serviços.

Se estiver a utilizar outro mecanismo para substituir a pilha de filtragem da Microsoft (por exemplo, uma lista de permissões de IP), recomendamos que mude para uma regra de fluxo de correio SCL=-1 , desde que todos os e-mails de entrada no Microsoft 365 sejam provenientes do serviço de proteção de terceiros (sem fluxos de correio diretamente da Internet para o Microsoft 365).

A regra de fluxo de correio SCL=-1 é importante durante a migração pelos seguintes motivos:

• Pode utilizar o Explorador de Ameaças (Explorador) para ver que funcionalidades na pilha da Microsoft teriam agido nas mensagens sem afetar os resultados do seu serviço de proteção existente.

• Pode ajustar gradualmente quem está protegido pela pilha de filtragem do Microsoft 365 ao configurar exceções à regra de fluxo de correio SCL=-1. As exceções são os membros dos grupos de distribuição piloto que recomendamos mais adiante neste artigo.

  Antes ou durante a transferência do seu registo MX para o Microsoft 365, desativa esta regra para ativar a proteção completa da pilha de proteção do Microsoft 365 para todos os destinatários na sua organização.

Para obter mais informações, consulte Utilizar regras de fluxo de correio para definir o nível de confiança de spam (SCL) nas mensagens no Exchange Online.

Notas:

• Se planear permitir que o correio na Internet flua através do seu serviço de proteção existente e diretamente para o Microsoft 365 ao mesmo tempo, precisa de restringir a regra de fluxo de correio SCL=-1 (correio que ignora a filtragem de spam) para o correio que passou apenas pelo seu serviço de proteção existente. Não quer que o correio da Internet não filtrado seja enviado em caixas de correio de utilizadores no Microsoft 365.

  Para identificar corretamente o correio que já foi analisado pelo serviço de proteção existente, pode adicionar uma condição à regra de fluxo de correio SCL=-1. Por exemplo:

  • Para serviços de proteção baseados na cloud: pode utilizar um valor de cabeçalho e cabeçalho exclusivo para a sua organização. As mensagens que têm o cabeçalho não são analisadas pelo Microsoft 365. As mensagens sem o cabeçalho são analisadas pelo Microsoft 365
  • Para dispositivos ou serviços de proteção no local: pode utilizar endereços IP de origem. As mensagens dos endereços IP de origem não são analisadas pelo Microsoft 365. As mensagens que não são provenientes dos endereços IP de origem são analisadas pelo Microsoft 365.

• Não dependa exclusivamente de registos MX para controlar se o correio é filtrado. Os remetentes podem facilmente ignorar o registo MX e enviar e-mails diretamente para o Microsoft 365.

Passo 4: Configurar a Filtragem Avançada para Conectores

A primeira coisa a fazer é configurar a Filtragem Avançada para Conectores (também conhecido como ignorar listagem) no conector utilizado para o fluxo de correio do seu serviço de proteção existente para o Microsoft 365. Pode utilizar o relatório Mensagens de entrada para ajudar a identificar o conector.

A Filtragem Avançada para Conectores é necessária por Defender para Office 365 para ver de onde são realmente provenientes as mensagens da Internet. A Filtragem Melhorada para Conectores melhora consideravelmente a precisão da pilha de filtragem da Microsoft (especialmente as capacidades de spoof intelligence e pós-falha no Explorador de Ameaças e na Resposta de & de Investigação Automatizada (AIR).

Para ativar corretamente a Filtragem Avançada para Conectores, tem de adicionar os endereços IP públicos de **todos** serviços de terceiros e/ou anfitriões do sistema de e-mail no local que encaminham correio de entrada para o Microsoft 365.

Para confirmar que a Filtragem Avançada dos Conectores está a funcionar, verifique se as mensagens recebidas contêm um ou ambos os cabeçalhos seguintes:

• X-MS-Exchange-SkipListedInternetSender
• X-MS-Exchange-ExternalOriginalInternetSender

Passo 5: Criar políticas de proteção piloto

Ao criar políticas de produção, mesmo que não sejam aplicadas a todos os utilizadores, pode testar funcionalidades pós-falha, como o Explorador de Ameaças, e testar a integração de Defender para Office 365 nos processos da sua equipa de resposta de segurança.

Importante

As políticas podem ser confinadas a utilizadores, grupos ou domínios. Não recomendamos a combinação dos três numa política, uma vez que apenas os utilizadores que correspondem aos três serão abrangidos pelo âmbito da política. Para políticas piloto, recomendamos a utilização de grupos ou utilizadores. Para políticas de produção, recomendamos a utilização de domínios. É extremamente importante compreender que apenas o domínio de e-mail principal do utilizador determina se o utilizador se enquadra no âmbito da política. Por isso, se mudar o registo MX para o domínio secundário de um utilizador, certifique-se de que o domínio primário também está abrangido por uma política.

Criar políticas piloto de Anexos Seguros

Os Anexos Seguros são a funcionalidade de Defender para Office 365 mais fácil de ativar e testar antes de mudar o registo MX. Os Anexos Seguros têm as seguintes vantagens:

• Configuração mínima.
• Hipóteses extremamente baixas de falsos positivos.
• Comportamento semelhante à proteção antimalware, que está sempre ativada e não é afetada pela regra de fluxo de correio SCL=-1.

Para obter as definições recomendadas, veja Definições de política anexos seguros recomendados. As recomendações Padrão e Estrita são as mesmas. Para criar a política, veja Configurar políticas de Anexos Seguros. Certifique-se de que utiliza o grupo MDOPilot_SafeAttachments como condição da política (a quem se aplica a política).

Nota

A política de segurança predefinida de proteção incorporada fornece proteção de Anexos Seguros a todos os destinatários que não estão definidos em nenhuma política de Anexos Seguros. Para obter mais informações, veja Preset security policies in EOP and Microsoft Defender para Office 365 (Políticas de segurança predefinidas na EOP e Microsoft Defender para Office 365).

Criar políticas piloto de Ligações Seguras

Nota

Não suportamos a moldagem ou reescrita de ligações já encapsuladas ou reescritas. Se o seu serviço de proteção atual já encapsular ou reescrever ligações em mensagens de e-mail, terá de desativar esta funcionalidade para os seus utilizadores piloto. Uma forma de garantir que isto não acontece é excluir o domínio de URL do outro serviço na política ligações seguras.

As probabilidades de falsos positivos nas Ligações Seguras também são bastante baixas, mas deve considerar testar a funcionalidade num número menor de utilizadores piloto do que os Anexos Seguros. Uma vez que a funcionalidade afeta a experiência do utilizador, deve considerar um plano para educar os utilizadores.

Para obter as definições recomendadas, veja Definições de política de Ligações Seguras. As recomendações Padrão e Estrita são as mesmas. Para criar a política, veja Configurar políticas de Ligações Seguras. Certifique-se de que utiliza o grupo MDOPilot_SafeLinks como condição da política (a quem se aplica a política).

Nota

A política de segurança predefinida de proteção incorporada fornece proteção de Ligações Seguras a todos os destinatários que não estão definidos em nenhuma política de Ligações Seguras. Para obter mais informações, veja Preset security policies in EOP and Microsoft Defender para Office 365 (Políticas de segurança predefinidas na EOP e Microsoft Defender para Office 365).

Criar políticas antisspam piloto

Crie duas políticas antisspam para utilizadores piloto:

• Uma política que utiliza as definições Padrão. Utilize o grupo MDOPilot_SpamPhish_Standard como condição da política (a quem se aplica a política).
• Uma política que utiliza as definições Estritas. Utilize o grupo MDOPilot_SpamPhish_Strict como condição da política (a quem se aplica a política). Esta política deve ter uma prioridade mais alta (número mais baixo) do que a política com as definições Padrão.

Para as definições Padrão e Estrita recomendadas, veja Definições de política antiss spam recomendadas. Para criar as políticas, veja Configurar políticas antisspam.

Criar políticas piloto anti-phishing

Crie duas políticas anti-phishing para utilizadores piloto:

• Uma política que utiliza as definições Padrão, exceto para ações de deteção de representação, conforme descrito abaixo. Utilize o grupo MDOPilot_SpamPhish_Standard como condição da política (a quem se aplica a política).
• Uma política que utiliza as definições Estritas, exceto para ações de deteção de representação, conforme descrito abaixo. Utilize o grupo MDOPilot_SpamPhish_Strict como condição da política (a quem se aplica a política). Esta política deve ter uma prioridade mais alta (número mais baixo) do que a política com as definições Padrão.

Para deteções de spoof, a ação Padrão recomendada é Mover a mensagem para as pastas de Email de Lixo dos destinatários e a ação Estrita recomendada é Colocar a mensagem em quarentena. Utilize as informações de spoof intelligence para observar os resultados. As substituições são explicadas na secção seguinte. Para obter mais informações, veja Informações de inteligência de spoof na EOP.

Para deteções de representação, ignore as ações Padrão e Estrita recomendadas para as políticas piloto. Em vez disso, utilize o valor Não aplicar nenhuma ação para as seguintes definições:

• Se for detetada uma mensagem como representação do utilizador
• Se a mensagem for detetada como domínio representado
• Se as informações da caixa de correio detetarem um utilizador representado

Utilize as informações de representação para observar os resultados. Para obter mais informações, veja Informações de representação no Defender para Office 365.

Ajuste a proteção contra spoofing (ajuste as permissões e os blocos) e ative cada ação de proteção de representação para colocar em quarentena ou mover as mensagens para a pasta Email de Lixo (com base nas recomendações Padrão ou Estrita). Observe os resultados e ajuste as respetivas definições conforme necessário.

Para mais informações, consulte os seguintes artigos:

• Proteção anti-spoofing
• Definições de representação em políticas anti-phishing
• Configure políticas anti-phishing no Defender para Office 365.

Passo seguinte

Parabéns! Concluiu a fase de Configuração da migração para Microsoft Defender para Office 365!

• Avance para a Fase 3: Integrar.