O planejamento de continuidade para autenticação de e-mail começa com o impacto nos negócios e não com uma promessa genérica de alta disponibilidade. Identifique os fluxos que devem continuar, as evidências que a organização pode perder e as pessoas que podem restaurar cada dependência. O gerenciamento de relatórios e autenticação pode precisar de objetivos de recuperação diferentes do envio transacional.
Defina objetivos por função
Use uma análise de impacto nos negócios para distinguir um boletim informativo atrasado de uma mensagem de recuperação de conta com falha. NIST SP 800-34 Rev. fornece uma estrutura geral para planejamento de contingência, estratégias de recuperação, testes e manutenção. Ele não prescreve tempos de recuperação específicos para e-mail. A empresa deve escolher esses objetivos com base no impacto e na viabilidade.
Defina o objetivo do tempo de recuperação como a indisponibilidade máxima aceitável para o recurso ou função especificada antes que seu impacto nos negócios se torne inaceitável. Defina o objetivo do ponto de recuperação como o ponto antes da interrupção até o qual os dados devem ser recuperáveis, refletindo a perda de dados tolerada. Indique o início do relógio, o escopo e o estado degradado aceitável. Um RPO de relatório não descreve o tempo de inatividade da entrega; um alvo de recuperação DNS não garante que todo cache recursivo tenha convergido.
Preservar entradas de recuperação independentes
Mantenha cópias aprovadas dos registros da política, seletor mapeamentos, propriedade de serviços, histórico de configuração e exportações de relatórios fora da interface de gerenciamento indisponível. Separe a configuração pública das credenciais e use um processo de segredos aprovado para qualquer acesso de recuperação. Verifique se os operadores de backup autorizados podem recuperar as instruções sem depender da mesma identidade ou caminho de conta com falha.
Mapeie dependências entre hospedagem DNS , assinatura, retransmissões, coleta de relatórios e acesso de administrador. Um painel alternativo na mesma conta pode falhar com o original. Um remetente alternativo só será útil se o aplicativo puder usá-lo e sua identidade tiver sido configurada e testada. Não compare ter um contrato de fornecedor com um caminho de failover executável.
Calcule o exemplo em vez de inventar um SLA
Uma planilha de continuidade hipotética pressupõe uma meta de recuperação de relatórios de quatro horas e uma meta de perda de dados de uma hora. Uma interrupção começa às 12h UTC; a última exportação recuperável é às 11h30 e o serviço é restaurado às 14h. A duração da recuperação calculada manualmente é de duas horas e a exposição à idade de exportação é de trinta minutos, dentro dos objetivos numéricos assumidos, se a exportação for o único insumo recuperável e a função aceitável declarada for realmente restaurada. Um segundo caso é restaurado às 17h de uma exportação às 10h, dando cinco horas de duração de recuperação e duas horas de exposição na idade de exportação. Esses números excedem ambas as metas assumidas, a menos que outros dados recuperáveis alterem a avaliação da perda de dados.
Estes são cálculos de carimbo de data/hora feitos à mão sobre eventos fictícios, testes não executados, desempenho medido do provedor ou metas universais recomendadas. Substitua os tempos pelos registros de exercícios observados. Avaliar se os insumos brutos que chegaram durante a lacuna foram retidos em outro lugar e podem ser reproduzidos. Se puderem, o intervalo real de dados perdidos poderá ser diferente da idade da última exportação do painel. Registre a base em vez de relatar um número atraente sem a sua população.
Exercite e mantenha o plano
Execute primeiro um exercício de mesa e depois um exercício técnico autorizado em um ambiente seguro. Inclui perda do operador principal, acesso de gerenciamento indisponível e atraso no feed de relatórios. Registre quem toma a decisão de recuperação, quais informações estão faltando e o que o operador de backup pode realmente executar. Verifique os resultados das mensagens e relate a continuidade separadamente.
Revise o plano após alterações de fornecedor, domínio, aplicativo ou equipe. Mantenha os proprietários das exceções e as datas de reteste. Fechar um exercício somente após os defeitos terem ações e prazos; uma discussão bem-sucedida não é prova de restauração técnica. Comunique a capacidade de recuperação suportada e seus limites para o negócio. Não apresente planilha local como garantia de nível de serviço.