Este artigo, baseado no meu Curso Pluralsight, Manutenção e solução de problemas do sistema Linux, pretende fazer você pensar sobre o que será necessário para a construção de um protocolo eficaz.

Tudo começa com o plano de continuidade de negocios (BCP). Esse é um plano formal que visa definir os procedimentos que uma organização usaria para garantir a sobrevivência em caso de emergência. Os BCPs geralmente incluem sub-planos para garantir a segurança imediata de funcionários e clientes, trabalham para restaurar operações críticas previamente designadas o mais rápido possível e, eventualmente, para restaurar operações normais completas. Além disso, um BCP eficaz também incluirá dois subplanos específicos das operações de TI: o protocolo de gerenciamento de incidentes e o plano de recuperação de desastres.

o recuperação de desastres plano (DRP) visa proteger a infraestrutura de TI de uma organização em caso de desastre. Seus principais objetivos são minimizar os danos e restaurar a funcionalidade o mais rápido possível. A razão pela qual chamamos isso de "plano" é porque simplesmente não funciona sem uma preparação prévia séria. A proteção da infraestrutura, a detecção de ameaças e os protocolos corretivos são partes críticas do plano.

A Plano de Gerenciamento de Incidentes (IMP) destina-se a lidar com a ameaça específica de ataques cibernéticos contra a infraestrutura de TI. Seus objetivos são minimizar os danos e remover a ameaça. Como você pode facilmente perceber, haverá alguma sobreposição entre seu DRP e IMP. Mas o foco principal da recuperação de desastres é recuperar a infraestrutura, enquanto o gerenciamento de incidentes está muito mais alinhado com o mundo da segurança de TI.

No restante deste breve artigo, veremos o que é necessário para criar planos de gerenciamento de incidentes e recuperação de desastres e como garantir que seu plano seja sólido e, quando executado, realmente funcione.

Desenvolvendo um Protocolo de Gerenciamento de Incidentes

Como o gerenciamento de incidentes será sua primeira resposta a problemas, começaremos por aí. A primeira indicação de que há problemas pode vir de um usuário que percebe que algo não está certo com o sistema ou, se você fez um trabalho particularmente bom na configuração de sua infraestrutura, ele também pode aparecer na forma de um alerta automático acionado por software de monitoramento.

Quando esse alerta chegar, será o trabalho do técnico ou administrador de plantão decidir como será tratado e quem terá que lidar com isso. O escalonamento pode ocorrer por meio de uma ligação telefônica direta ou por email, um ticket enviado por meio de uma ferramenta de colaboração como Jira ou usando uma ferramenta SIEM (Security Information and Event Management) criada para esse fim.

Mais uma vez, porém, quanto mais automação inteligente você criar no processo, mais rápido e mais eficiente será. Quem acabar com a responsabilidade final coordenará os esforços para diagnosticar e resolver definitivamente o problema. Idealmente, quando necessário, essa coordenação incluirá administradores, desenvolvedores e outras partes interessadas importantes para garantir que você tenha todos os recursos necessários para solucionar o problema.

Quando tudo terminar, depois de confirmar que o problema foi resolvido, você desejará encerrar o incidente, avaliando o que deu errado e o que deu certo, como sua resposta poderia ter sido melhor e como você pode refazer as coisas para reduzir o problema. risco de repetição do incidente.

Mas o que tudo isso tem a ver com administração de TI? Bem, os gerentes de TI responsáveis ​​devem poder criar resiliência em sua infraestrutura. Isso significará gastar muito tempo ajustando seus sistemas de monitoramento de software para que eles capturem e alertem você sobre problemas reais ao emitir alertas para o mínimo possível de falsos positivos. E provavelmente também envolverá a automação inteligente dos sistemas de registro e detecção de intrusões e, geralmente, uma boa idéia de como as coisas devem parecer.

Desenvolvendo um plano de recuperação de desastres

O planejamento de recuperação de desastre exige que você:

  • Defina exatamente o que significa recuperação
  • Identifique os recursos que a recuperação exigirá
  • Converta essas observações em um formato de plano formal
  • Comunique o plano aos jogadores que um dia terão de executá-lo

O que recuperação significar? É quando sua infra-estrutura pobre e atingida retorna à forma que estava no momento anterior ao desastre. O que você precisa para voltar a esse ponto pode ser definido estabelecendo um Objetivo do tempo de recuperação (RTO) e Objetivo do ponto de recuperação (RPO) que atenda às necessidades da sua organização.

UMA Objetivo do tempo de recuperação representa o número máximo de minutos, horas ou dias em que sua organização pode sobreviver a uma interrupção do serviço de TI. Portanto, seu plano de recuperação precisará incorporar esse prazo final em seus protocolos.

É claro que isso significa que você precisará ter membros da equipe disponíveis para entrar no escritório, mesmo nas primeiras horas da noite, com rapidez suficiente para fazer a diferença. Mas isso também significa, digamos, que se o seu RTO for de seis horas, mas a restauração de dados críticos de seus backups levaria um período mínimo de oito horas apenas para lidar com a transferência, você precisará repensar esses números antes de assinar o plano .

UMA Objetivo do ponto de recuperação é a quantidade de dados de transação que sua organização pode perder durante uma interrupção e sobreviver. Para ilustrar, um site de comércio eletrônico que normalmente processa 25 transações a cada minuto pode, talvez, dar ao luxo de emitir desculpas e reembolsar 30 minutos em clientes irritados, perguntando-se por que seus cartões de crédito foram faturados, mas seus trens elétricos não foram entregues. Reembolsar mais de 30 minutos, no entanto, pode esgotar suas reservas financeiras a ponto de você não ser mais viável.

De qualquer forma, calcular RTOs e RPOs precisos e confiáveis ​​é como você define os limites dentro dos quais seu plano de recuperação terá que operar. Ou, em outras palavras, você terá definido o que significa recuperação.

Agora que tal Recursos? Com isso quero dizer os backups de dados e, quando necessário, o equipamento físico necessário para recuperar o aplicativo. Para fazer esse trabalho, você terá que decidir sobre um sistema de backup de infraestrutura. Se você optar por ir com incremental ou diferencial; no local ou fora do local; e tipos de mídia únicos ou múltiplos, você precisará mapear exatamente como será a recuperação e se ela atenderá ou não aos seus limites de RTO e RPO.

É claro que não pode haver coisas realmente ruins que podem tornar esses planos totalmente inúteis. E se o seu servidor local apenas queimar? E se for perdido por algum tipo de agitação política ou por uma ampla interrupção do poder? Mesmo que você tenha mantido conscientemente backups de dados atualizados fora do local, que benefícios eles farão se seu hardware não existir mais?

Pensar em todos esses horrores pode tornar a preparação de um protocolo de backup baseado em nuvem usando plataformas como AWS e Azure muito atraente. As grandes nuvens públicas têm recursos para distribuir sua infraestrutura amplamente o suficiente para que seja praticamente impossível que tudo ocorra.

Assim, você poderia, por exemplo, manter um armazenamento de dados replicado de maneira confiável em uma plataforma de nuvem pública que espelha sua implantação principal. Você também pode criar um modelo de infraestrutura que possa ser carregado com seus dados de backup e, em seguida, iniciado sob demanda para assumir o controle no caso de uma interrupção. Como nada é mantido em execução até que seja realmente necessário, pode levar alguns minutos para acelerar esse processo.

Um design de recuperação em espera quente pode manter seus dados em execução 24/7 em um número mínimo de servidores virtuais. Em caso de emergência, você pode pressionar o botão e o dimensionamento automático da plataforma acionará todas as instâncias necessárias. Você pode definir o dimensionamento para ativar quando acionado por um alerta do seu sistema principal. A nuvem pública apresenta infinitas possibilidades, mas todas exigem planejamento e preparação.

Um desastre sólido plano de recuperacao deve ser eficaz comunicada muito antes da hora da crise. Na prática, isso significa que tudo será redigido, impresso e distribuído a cada um dos principais envolvidos na execução do plano. Isso não quer dizer que termina aí: é claro que esses jogadores realmente leram a coisa e, idealmente, se envolverão em simulações realistas até estarem confiantes de que podem fazê-la funcionar sob pressão.

O que se passa neste livro?

  • Uma enumeração de todas as coisas que podem dar errado e derrubar seu sistema
  • Um inventário exatamente do que você está executando em sua sala de servidores e o que seria necessário para substituí-lo
  • As informações necessárias para acessar e restaurar os dados de backup
  • Uma lista de contatos atualizada das pessoas que serão responsáveis ​​por todos os aspectos do plano
  • A sequência exata das tarefas e eventos que comporão a recuperação

São muitos detalhes. Mas é apenas uma gota no balde quando comparado com a quantidade total de preparação e o trabalho árduo e simples que é necessário para criar um plano de recuperação no mundo real.

Mas, por enquanto, o principal argumento deste módulo é simplesmente manter tudo isso em mente. Por quê? Como na próxima vez que você se sentar para configurar um pacote de monitoramento ou uma estrutura de administração, pense em protocolos de gerenciamento de incidentes e planos de recuperação de desastre e se perguntará como deve incluí-los em sua configuração.