Muitas PME que utilizam o Microsoft 365 configuraram o serviço uma vez, no momento da migração, e raramente voltaram a rever essas definições. Não é negligência: é o resultado natural de uma equipa pequena com muitas prioridades. O problema é que as definições iniciais raramente acompanham o crescimento da empresa.
Esta checklist reúne quinze verificações que qualquer organização com Microsoft 365 pode fazer ao seu próprio ambiente. Não são instruções para aplicar diretamente em produção, mas pontos de análise: em cada um, a pergunta é «como está isto configurado hoje?» e «faz sentido para a nossa realidade?».
Algumas verificações são simples e resolvem-se numa tarde. Outras exigem planeamento e uma fase de testes. Assinalámos a prioridade de cada uma para ajudar a definir a ordem de trabalho.
- Comece pelas contas administrativas e pela autenticação multifator: é aí que o retorno é maior.
- As predefinições de segurança e o Acesso Condicional são modelos alternativos. A transição entre os dois deve ser planeada com cuidado.
- Toda a alteração de autenticação deve ser validada com um grupo piloto e com contas de emergência já criadas.
- Uma configuração correta hoje pode deixar de o ser à medida que a empresa, os serviços e as ameaças evoluem. A revisão periódica faz parte do controlo.
Identidade e acesso
1. Contas administrativas separadas das contas de utilização diária
Um administrador que usa a mesma conta para ler email, navegar na Internet e gerir o tenant — o ambiente Microsoft 365 da organização — expõe permissões elevadas a todo o risco do dia a dia. A prática recomendada é manter uma conta de utilizador normal para o trabalho corrente e uma conta administrativa distinta, sem caixa de correio nem licenças desnecessárias, usada apenas quando é preciso administrar.
Verifique quantas contas com funções administrativas existem e se alguma delas é também a conta de trabalho de alguém.
2. Autenticação multifator em todas as contas
A autenticação multifator reduz de forma significativa o impacto de credenciais comprometidas, sobretudo em ataques de recolha de palavras-passe. Não elimina todos os ataques: existem técnicas de intermediação que capturam sessões já autenticadas, e a fadiga de notificações continua a ser explorada. Ainda assim, é o controlo isolado com melhor relação entre esforço e proteção.
Confirme que a cobertura abrange todas as contas humanas com início de sessão interativo, incluindo administradores externos e prestadores de serviços.
Contas utilizadas por aplicações, scripts ou automações devem ser analisadas separadamente. Sempre que possível, substitua contas de utilizador partilhadas por identidades geridas ou service principals, com permissões mínimas e um ciclo de vida controlado. Quando uma aplicação antiga obrigar à utilização de uma conta de utilizador, restrinja o início de sessão interativo sempre que tecnicamente possível, proteja as credenciais e monitorize a sua utilização. Uma identidade gerida não é um utilizador que responde a pedidos de autenticação multifator.
A Microsoft recomenda utilizar primeiro identidades geridas, depois service principals, e apenas em último recurso contas de utilizador como contas de serviço.
3. Predefinições de segurança ou Acesso Condicional — não os dois
Este é um dos pontos onde há mais confusão, por isso vale a pena separar os três conceitos.
As predefinições de segurança (Security Defaults) são um conjunto fixo de proteções que se ativa ou desativa por completo. Exigem o registo de MFA a todos os utilizadores, obrigam determinadas funções administrativas a realizar MFA em cada início de sessão, e solicitam MFA aos restantes utilizadores quando a Microsoft considera necessário, com base em fatores como localização, dispositivo, função e tarefa. Bloqueiam também a autenticação legada. Não são personalizáveis e não requerem licenças pagas.
O Acesso Condicional é o mecanismo baseado em políticas, incluído no Microsoft Entra ID P1 — e, portanto, no Microsoft 365 Business Premium. Permite definir regras por utilizador, grupo, aplicação, localização, plataforma e estado do dispositivo, com modo de relatório para testar antes de aplicar.
A MFA por utilizador é o método antigo, em que o estado de MFA é definido conta a conta. Continua a funcionar, mas a Microsoft desaconselha-o e recomenda o Acesso Condicional.
São modelos alternativos de aplicação de controlos de acesso, não camadas que se somam. Uma organização que decida substituir as predefinições por políticas de Acesso Condicional tem de as desativar.
As políticas devem ser criadas primeiro em modo de relatório: nesse estado são avaliadas a cada início de sessão e o resultado fica nos registos, mas os controlos não são aplicados. Só depois de confirmar nos registos que a cobertura é equivalente, e com as contas de emergência já criadas e testadas, se desativam as predefinições e se passam as políticas a ativas.
Desativar as predefinições antes de existirem políticas validadas pode criar uma janela sem os controlos de autenticação esperados.
4. Contas de emergência configuradas e testadas
Uma política de Acesso Condicional mal desenhada pode bloquear todos os administradores em simultâneo. As contas de emergência existem precisamente para esse cenário: são contas administrativas que ficam fora do âmbito das políticas que poderiam causar o bloqueio.
É importante perceber que uma conta de emergência não deve replicar a configuração das contas administrativas normais — se estivesse sujeita às mesmas políticas e dependesse dos mesmos mecanismos, falharia no momento em que fosse necessária. Deve, ainda assim, estar fortemente protegida: credenciais longas e guardadas em local seguro com acesso restrito, um método de autenticação que não dependa do dispositivo pessoal de um administrador, monitorização de qualquer utilização e teste periódico documentado.
A Microsoft recomenda manter pelo menos duas contas de emergência, criadas diretamente no Entra ID no domínio onmicrosoft.com, sem dependência de sincronização com o local nem de um fornecedor de identidade externo. Devem usar autenticação resistente a phishing — chaves de segurança FIDO2, guardadas em locais separados — diferente da usada pelas contas administrativas normais. A sua utilização deve gerar alerta, e o funcionamento deve ser validado pelo menos a cada 90 dias, e também sempre que houver mudanças na equipa de TI ou na subscrição.
Quanto ao momento da exclusão, a Microsoft esclarece que políticas em modo de relatório não bloqueiam o acesso e, por isso, não exigem que estas contas sejam excluídas durante a fase de análise. A exclusão é necessária antes de a política passar a ativa. Na prática, o mais seguro é excluí-las logo no momento em que cada política é criada — assim não depende de alguém se lembrar mais tarde, no passo em que o erro custa o acesso ao tenant.
5. Autenticação legada e SMTP AUTH
A autenticação básica já foi removida da maioria dos protocolos do Exchange Online — POP, IMAP, EWS, ActiveSync, PowerShell remoto e Autodiscover, entre outros. Ainda assim, podem existir exceções, aplicações antigas, autenticação SMTP e outros fluxos que não utilizam autenticação moderna.
O SMTP AUTH é o caso que continua em aberto, e a Microsoft já reviu o calendário mais do que uma vez. Na versão atual, o comportamento mantém-se inalterado até ao final de 2026; a partir daí passa a estar desativado por omissão nos tenants existentes, ainda com possibilidade de reativação pelo administrador, e indisponível por omissão nos tenants novos. A data de remoção definitiva será anunciada mais tarde.
Analise os registos de início de sessão para identificar qualquer utilização remanescente e planeie a migração para OAuth, Microsoft Graph, conectores ou outros métodos modernos antes de aplicar bloqueios adicionais. É aí que aparecem as impressoras multifunções que enviam digitalizações por email, as aplicações de faturação, os sistemas de alarme e o equipamento que ninguém associava a correio eletrónico.
Bloquear sem inventariar interrompe processos e gera pressão para reverter tudo — e a reversão costuma ser total, não seletiva.
6. Revisão de administradores e funções atribuídas
As funções administrativas tendem a acumular-se. Um consultor que ajudou na migração, um colaborador que mudou de departamento, um fornecedor cujo contrato terminou — todos podem manter acessos que já não se justificam.
Reveja a lista de contas com funções privilegiadas e aplique o princípio do menor privilégio. Muitas tarefas correntes não exigem Administrador Global. Atribua a função mais limitada que permita executar a tarefa necessária e reveja periodicamente se essa atribuição continua justificada.
7. Processo de entrada e saída de colaboradores
A saída de um colaborador é o momento em que mais falhas ocorrem. Sem um processo escrito, é comum a conta ficar ativa semanas depois, com sessões válidas em dispositivos pessoais e acesso a ficheiros partilhados.
Um procedimento mínimo cobre: bloqueio do início de sessão, revogação das sessões ativas, remoção das licenças na altura certa, decisão sobre o destino da caixa de correio e dos ficheiros no OneDrive, e remoção do acesso a grupos, equipas e sites do SharePoint.
Dispositivos
8. Dispositivos empresariais geridos e conformes
Se a empresa fornece computadores, deve saber quais são, em que estado se encontram e se cumprem os requisitos mínimos definidos. Com o Intune, isso traduz-se em inscrição dos equipamentos e políticas de conformidade que verifiquem encriptação de disco, atualizações do sistema, proteção antimalware ativa e bloqueio de ecrã.
Sem gestão, a resposta à pergunta «este portátil está encriptado?» depende da memória de alguém.
Um detalhe que engana: um computador pode aparecer no Entra ID sem estar sob gestão. Registado e associado não são o mesmo estado, e as políticas de conformidade só se aplicam a dispositivos efetivamente inscritos. Vale a pena confirmar o estado de inscrição de um equipamento concreto antes de assumir que a política está a produzir efeito.
9. Dispositivos pessoais com acesso a dados da empresa
Telemóveis pessoais com o Outlook e o Teams instalados são um caso muito comum. A gestão ao nível da aplicação permite proteger os dados corporativos — exigir PIN para abrir a aplicação, impedir a cópia de conteúdo para aplicações pessoais, permitir a remoção seletiva dos dados da empresa — sem gerir o dispositivo pessoal do colaborador.
Defina qual é a posição da empresa sobre este ponto e certifique-se de que está comunicada.
10. Proteção de endpoints com visibilidade central
Antivírus instalados individualmente, sem consola comum, dão pouca informação útil. Uma solução de proteção de endpoints gerida centralmente — o Microsoft Defender for Business, no caso do Business Premium — permite ver o estado de todo o parque, detetar incidentes e responder.
Confirme que todos os equipamentos estão efetivamente integrados na consola, e não apenas licenciados. A licença atribuída não integra o dispositivo — é um passo distinto, e enquanto não correr o portal mostra a organização sem dispositivos. Ninguém repara, porque nada falha visivelmente.
Dados e email
11. Definições de partilha externa
A partilha no SharePoint e no OneDrive é frequentemente deixada nas definições iniciais. Verifique se é possível criar ligações acessíveis a qualquer pessoa sem autenticação, se essas ligações expiram, e que permissões são atribuídas por omissão.
O objetivo não é bloquear a partilha externa — muitas empresas dependem dela — mas garantir que corresponde a uma decisão consciente.
12. Encaminhamento automático de email
O encaminhamento automático para endereços externos é um dos primeiros mecanismos usados após o compromisso de uma caixa de correio: permite manter acesso à correspondência mesmo depois de a palavra-passe ser alterada.
No Microsoft 365, a opção predefinida de encaminhamento automático externo — Automatic — System-controlled — está atualmente configurada para bloquear este comportamento. Ainda assim, confirme se existem políticas personalizadas, exceções por utilizador, configurações de domínios remotos ou regras de fluxo de correio que o voltem a permitir.
Existe também um relatório de mensagens encaminhadas automaticamente, útil como ponto de validação: mostra quem está a encaminhar para destinatários externos. Verifique quem criou cada regra e se é legítima.
13. SPF, DKIM e DMARC configurados
Estes três registos de DNS determinam se outros servidores de correio conseguem distinguir mensagens legítimas do seu domínio de mensagens falsificadas. Sem eles, é mais fácil alguém enviar email em nome da empresa, e é mais provável que o correio legítimo seja classificado como indesejado.
No Microsoft 365, o DKIM não fica ativo por omissão nos domínios personalizados — requer publicação de dois registos CNAME e ativação no portal. Confirme o estado dos três mecanismos, incluindo os subdomínios e os serviços externos que enviam email em nome da empresa.
14. Auditoria, alertas e registos
Quando algo corre mal, a diferença entre uma investigação de duas horas e uma de duas semanas está nos registos disponíveis.
Confirme primeiro que a auditoria está efetivamente ativa. Este ponto merece atenção especial numa PME: ao contrário das organizações com licenciamento Enterprise, nos planos Microsoft 365 Business Basic, Standard e Premium a auditoria não vem ativada por predefinição — tem de ser ligada manualmente.
Depois de ativada, os registos do Audit (Standard) são conservados por 180 dias, valor que pode variar com o licenciamento atribuído e com políticas de retenção definidas. Valide também quem os pode pesquisar e que alertas existem para atividades críticas: atribuição de funções administrativas, criação de regras de encaminhamento, ou utilização de contas de emergência.
Uma nota importante sobre este ponto: o Microsoft 365 mantém histórico de versões, reciclagem e retenção, mas isso não constitui um sistema de cópias de segurança tradicional com pontos de restauro de longo prazo. Se a organização tem requisitos de retenção prolongada ou de recuperação de cenários específicos, essa necessidade deve ser avaliada separadamente.
15. Testes e revisão periódica
Nenhuma configuração se mantém adequada indefinidamente. Novos serviços são contratados, colaboradores mudam de funções, a Microsoft altera predefinições e introduz funcionalidades.
Defina uma frequência de revisão — trimestral ou semestral, consoante a dimensão — e registe as decisões tomadas. Recomenda-se também que qualquer alteração significativa passe primeiro por um grupo piloto e, no caso do Acesso Condicional, pelo modo de relatório, que mostra o efeito que a política teria sem a aplicar de facto.
Resumo das verificações
| Verificação | Risco reduzido | Prioridade |
|---|---|---|
| 1. Contas administrativas separadas | Comprometimento de conta com permissões elevadas através da utilização diária | Crítica |
| 2. Autenticação multifator em todas as contas | Acesso com credenciais roubadas ou reutilizadas | Crítica |
| 3. Predefinições de segurança ou Acesso Condicional | Acessos sem verificação adicional e políticas em conflito | Crítica |
| 4. Contas de emergência | Perda total de acesso administrativo ao tenant | Crítica |
| 5. Autenticação legada e SMTP AUTH | Contorno da autenticação multifator por protocolos antigos | Crítica |
| 6. Revisão de administradores e funções | Acumulação de privilégios desnecessários ao longo do tempo | Alta |
| 7. Entrada e saída de colaboradores | Acesso mantido por quem já saiu da organização | Alta |
| 8. Dispositivos empresariais geridos | Equipamentos desatualizados ou sem encriptação de disco | Alta |
| 9. Dispositivos pessoais | Dados da empresa sem proteção em equipamentos não geridos | Alta |
| 10. Proteção de endpoints | Malware sem deteção nem visibilidade centralizada | Alta |
| 11. Partilha externa | Exposição involuntária de ficheiros a destinatários não previstos | Alta |
| 12. Encaminhamento automático de email | Extração continuada de correspondência após comprometimento | Alta |
| 13. SPF, DKIM e DMARC | Falsificação do domínio e entrega deficiente do correio legítimo | Alta |
| 14. Auditoria, alertas e registos | Incapacidade de investigar e de detetar atempadamente | Alta |
| 15. Testes e revisão periódica | Degradação silenciosa da configuração ao longo do tempo | Média |
Como usar esta checklist
Percorra os quinze pontos e registe, para cada um, o estado atual: conforme, parcialmente conforme ou por rever. Não é necessário resolver tudo de uma vez. Uma organização que trate bem os cinco pontos críticos fica em situação melhor do que uma que aplique quinze medidas de forma superficial.
Sempre que uma alteração envolva autenticação ou acesso, siga a mesma sequência: criar e testar as contas de emergência, excluí-las das políticas no momento em que cada uma é criada, colocar a política em modo de relatório durante tempo suficiente para apanhar quem só se autentica uma vez por semana, ler os registos de início de sessão na vista de modo de relatório, e só então passar a ativa. Documente cada decisão, incluindo o motivo.
- Inventariar as contas com funções administrativas e separar as contas de administração das de uso diário
- Confirmar a cobertura de MFA em todas as contas humanas, e tratar as contas de automação separadamente
- Decidir entre predefinições de segurança e Acesso Condicional, e garantir que apenas um está em vigor
- Criar, proteger e testar pelo menos duas contas de emergência
- Identificar utilizações remanescentes de autenticação legada e de SMTP AUTH nos registos de início de sessão
- Rever as funções atribuídas e aplicar o menor privilégio
- Escrever o procedimento de entrada e saída de colaboradores
- Inscrever e verificar a conformidade dos dispositivos empresariais
- Definir a política para dispositivos pessoais com acesso a dados da empresa
- Confirmar que todos os endpoints estão integrados na consola de proteção
- Rever as definições de partilha externa no SharePoint e no OneDrive
- Verificar as regras de encaminhamento automático de email existentes
- Validar o estado do SPF, do DKIM e do DMARC em todos os domínios
- Confirmar a auditoria ativa e configurar alertas para eventos relevantes
- Marcar em agenda a próxima revisão e registar as decisões tomadas
Conclusão
Cada uma destas verificações pode ser analisada separadamente, embora algumas exijam mais planeamento, testes e conhecimento técnico do que outras. A maior dificuldade está em aplicá-las de forma consistente e manter o resultado ao longo do tempo, sobretudo em organizações onde a gestão do Microsoft 365 é uma tarefa acumulada com outras responsabilidades.
Uma sugestão prática: em vez de tentar resolver os quinze pontos numa semana, trate de dois por mês e registe o que fez. Ao fim de oito meses, a organização terá percorrido a lista inteira, com documentação e com alterações testadas — um resultado bastante mais sólido do que uma revisão intensiva feita uma única vez.
Convém, por fim, resistir à ideia de que existe uma configuração universalmente correta. As recomendações da Microsoft são um bom ponto de partida, mas a configuração adequada depende da dimensão da empresa, do tipo de dados que trata, dos equipamentos que utiliza e da capacidade que tem para manter o que implementa.
Fontes oficiais
- Security best practices for Microsoft 365 Business Premium
- Security defaults in Microsoft Entra ID
- Features and licenses for Microsoft Entra multifactor authentication
- Microsoft 365 for business security overview
- Guia de implementação do Microsoft Defender for Office 365
- Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline
- Turn auditing on or off in Microsoft Purview
- Deprecation of Basic authentication in Exchange Online
- Control automatic external email forwarding in Microsoft 365
- Governing Microsoft Entra service accounts
- Manage emergency access admin accounts in Microsoft Entra ID
- Conditional Access report-only mode
- Preset security policies in EOP and Microsoft Defender for Office 365
- Configurar o DKIM para assinar mensagens no Microsoft 365
Última validação técnica: 26 de julho de 2026. As funcionalidades de segurança do Microsoft 365 e do Microsoft Entra ID são atualizadas com frequência. Confirme o comportamento atual na documentação oficial antes de aplicar alterações.
