Tópico 3.9 — Continuidade de negócios e recuperação de desastres

Na saúde e nos cuidados, uma grande indisponibilidade de sistema é um evento de segurança do paciente antes de ser um problema de TI; por isso a sua capacidade de continuar prestando cuidados enquanto um sistema está fora do ar — e de recuperá-lo por completo e depressa — é uma capacidade clínica e de confiança pública central, e não uma nota técnica de rodapé.

Por que isso importa na saúde e nos cuidados#

O cuidado não para quando a tecnologia para. Quando um prontuário eletrônico do paciente, uma plataforma de prescrição eletrônica ou um sistema de resultados laboratoriais falha em todo um hospital, os clínicos não podem pausar o tratamento enquanto os engenheiros trabalham. Precisam continuar atendendo pacientes, prescrevendo medicamentos e tomando decisões — muitas vezes sem os alertas de alergia, as verificações de dose e o histórico anterior que o sistema que falhou normalmente fornece. É por isso que uma indisponibilidade não se mede apenas em horas de parada e créditos de serviço; mede-se em diagnósticos atrasados, interações perdidas, operações canceladas e no risco adicional carregado por cada clínico que trabalha às cegas. A continuidade de negócios é a disciplina de garantir que, quando o pior acontecer, o cuidado permaneça o mais seguro possível.

O que está em jogo é nacional e bem documentado. O ataque de ransomware WannaCry de 2017 afetou cerca de um terço dos hospitais do NHS na Inglaterra, forçou o cancelamento de milhares de consultas e operações, desviou ambulâncias e trancou a equipe fora dos próprios dispositivos — incluindo alguns equipamentos de imagem e patologia — de que precisava para tratar as pessoas. Custou ao NHS cerca de £ 92 milhões e, mais importante, mostrou que um ciberataque à infraestrutura de saúde cai como uma crise clínica, e não meramente um incidente de segurança de dados. Desde então, a resiliência saiu da sala de servidores e foi para a mesa do conselho, e com razão.

Este tópico estende a disciplina operacional do Tópico 3.8 — Gestão de serviços e operação em produção, mas desloca o foco da operação cotidiana para a grande interrupção: o incêndio, a inundação, o ciberataque, o colapso de um fornecedor ou a pane regional que ameaça derrubar um serviço crítico por horas ou dias. Liga-se estreitamente ao Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança (porque a recuperação de ransomware é hoje um cenário central de continuidade), ao Tópico 4.0 — Arquitetura técnica, nuvem e sistemas legados (porque a resiliência é projetada, e não acrescentada) e ao Tópico 6.4 — Governança e garantia (porque alguém precisa ser dono do plano, testá-lo e responder por ele). Se isso for bem feito, a interrupção vira um dia ruim; se for mal feito, vira um inquérito público.

Conceitos centrais#

Continuidade de negócios e recuperação de desastres. O planejamento de continuidade de negócios (BCP) é a capacidade de continuar entregando produtos ou serviços — no seu caso, cuidado seguro — em níveis aceitáveis predefinidos durante e após um incidente disruptivo. A recuperação de desastres de TI (DR) é o subconjunto técnico mais estreito, voltado a restaurar os sistemas, dados e infraestrutura que sustentam esses serviços. A continuidade de negócios é a promessa mais ampla ("os pacientes continuam sendo tratados"); a recuperação de desastres é um dos meios ("o sistema de resultados volta em quatro horas"). Vocês precisam de ambas e não devem confundir um servidor restaurado com um serviço restaurado.

Gestão de continuidade de negócios e análise de impacto nos negócios. A gestão de continuidade de negócios (BCM) é o processo contínuo de gestão — e não um documento pontual — que identifica ameaças e constrói resiliência organizacional. Sua base é a análise de impacto nos negócios (BIA): uma avaliação estruturada de cada serviço que pergunta com que rapidez a sua perda causa dano inaceitável, de que ele depende e quanto tempo atrás vocês podem se permitir perder dados. A BIA é onde o julgamento clínico entra na engenharia: os clínicos, e não apenas os tecnólogos, precisam definir o que significa "inaceitável" para um sistema de maternidade versus uma intranet da equipe.

Objetivo de tempo de recuperação e objetivo de ponto de recuperação. Dois números ancoram todo plano de recuperação. O objetivo de tempo de recuperação (RTO) é o tempo máximo aceitável para restaurar um serviço após uma falha. O objetivo de ponto de recuperação (RPO) é a quantidade máxima aceitável de perda de dados, expressa em tempo — um RPO de quinze minutos significa que vocês toleram perder, no máximo, os últimos quinze minutos de registros. Para um sistema clínico crítico, podem ser minutos; para um data warehouse de relatórios, podem ser dias. Defini-los com honestidade, por serviço, é a decisão de continuidade mais útil que vocês tomarão.

Backups e restaurações testadas. Um backup é uma cópia de dados guardada em outro lugar para que o original possa ser restaurado após uma perda. A linha de base do setor é a regra 3-2-1: três cópias, em dois tipos de mídia, com uma guardada fora do local (e, na era do ransomware, uma imutável ou offline). De modo crucial, um backup que você nunca restaurou é uma esperança, não um controle. O ransomware rotineiramente criptografa backups alcançáveis pela rede, e restaurações não testadas rotineiramente falham no dia. A disciplina não é "fazemos backup?", mas "quando foi a última vez que restauramos com sucesso, de ponta a ponta, e quanto tempo levou?".

Alta disponibilidade, redundância e failover. A alta disponibilidade (HA) é uma propriedade de projeto que mantém um sistema funcionando apesar da falha de componentes, geralmente medida em "noves" de disponibilidade. É obtida por meio da redundância — a duplicação deliberada de componentes críticos — e do failover, a troca automática para um componente ou local em espera quando o principal falha. A alta disponibilidade reduz a frequência das indisponibilidades; a recuperação de desastres trata das que passam. São complementares, e não alternativas, e confundi-las deixa lacunas perigosas.

Pontos únicos de falha e dependências críticas. Um ponto único de falha (SPOF) é qualquer componente cuja falha para todo o serviço — um enlace de rede, um serviço de autenticação, um fornecedor, um banco de dados ou uma pessoa que sozinha sabe como algo funciona. Mapear os SPOFs e as dependências críticas (os serviços a montante e os terceiros dos quais o seu serviço silenciosamente depende) é o coração analítico da resiliência. Na TI de saúde moderna, as dependências raramente são locais: um serviço de login único, uma conexão com a espinha dorsal nacional ou uma região de nuvem pode derrubar muitos sistemas de uma vez.

Procedimentos clínicos de contingência e de continuidade de negócios. A saúde e os cuidados têm um controle distintivo que a TI genérica não tem: o procedimento clínico de contingência, um recurso seguro e ensaiado — em geral, papel — para prestar cuidados quando um sistema digital está indisponível, mais o processo de reentrada para reconciliar esse registro em papel de volta ao sistema quando ele retorna. É a continuidade de negócios tornada concreta à beira do leito, e onde os planos de continuidade mais frequentemente encontram a realidade.

Ransomware e recuperação cibernética. O ransomware criptografa os seus dados e exige pagamento, e tornou-se a ameaça de continuidade definidora para os sistemas de saúde. O ataque de ransomware WannaCry de 2017 é o caso de referência: é por isso que a recuperação cibernética — isolar, reconstruir a partir de backups limpos e validar a integridade antes de reconectar — é hoje um cenário de primeira ordem em todo plano sério.

A norma de continuidade. A ISO 22301 é a norma internacional para sistemas de gestão de continuidade de negócios. Oferece uma estrutura reconhecida — contexto, liderança, planejamento, apoio, operação, avaliação, melhoria — para construir e auditar a capacidade de continuidade, e é uma espinha dorsal útil, busque-se ou não a certificação formal.

Boas práticas#

1. Comece por uma análise de impacto nos negócios de propriedade dos clínicos, e não só da TI. Classifique cada serviço pelo dano clínico causado quando ele falha e pela rapidez com que esse dano se torna intolerável e atribua a cada um um RTO e um RPO específicos. Faça isso com os clínicos e gestores operacionais que arcam com as consequências, porque "por quanto tempo podemos operar sem isto com segurança?" é uma pergunta de cuidado, e não de infraestrutura. O resultado é uma lista priorizada que diz onde gastar primeiro o seu finito orçamento de resiliência.

2. Projete a resiliência de forma proporcional à criticidade. Ajuste a engenharia ao impacto: os sistemas críticos para a missão (pronto-socorro, administração de pacientes, prescrição eletrônica) justificam alta disponibilidade, redundância geográfica e failover automático; os de menor criticidade podem aceitar recuperação mais longa e backups mais simples. Resista tanto à subengenharia de sistemas críticos quanto ao excesso de requinte em sistemas triviais. Arquitetura e continuidade precisam ser projetadas em conjunto (ver Tópico 4.0 — Arquitetura técnica, nuvem e sistemas legados), porque não se acrescenta resiliência a um projeto frágil depois do fato.

3. Cace pontos únicos de falha e dependências ocultas. Mapeie sistematicamente as dependências de cada serviço crítico — rede, autenticação, DNS, conexões nacionais, energia, refrigeração, fornecedores-chave e pessoas-chave — e identifique onde uma falha se propaga em cascata. Preste especial atenção a serviços compartilhados, como o login único ou um motor de integração comum, cuja falha derruba muitos sistemas ao mesmo tempo. Uma dependência que você não mapeou é uma dependência que você descobrirá durante a indisponibilidade.

4. Faça backups para sobreviver ao ransomware e prove as restaurações testando-as. Siga a regra 3-2-1 e mantenha ao menos uma cópia de backup imutável ou fisicamente offline, para que um atacante que alcance sua rede não consiga criptografar sua última linha de defesa. Depois, teste as restaurações em cronograma, cronometrando-as frente ao seu RTO e validando a integridade dos dados frente ao seu RPO — uma restauração que leva dois dias frente a um objetivo de quatro horas é um controle falho que vocês apenas ainda não perceberam. Trate a "última restauração completa bem-sucedida" como uma métrica que você reporta, e não uma tarefa que você presume.

5. Escreva, dê recursos e ensaie os procedimentos clínicos de contingência. Para cada sistema clínico crítico, mantenha um recurso testado em papel (ou offline) que permita à equipe continuar prestando cuidados seguros durante uma indisponibilidade, mais um processo claro para reinserir esses dados depois, sem perda nem duplicação. Guarde os formulários de contingência onde possam ser alcançados quando a rede e as impressoras também estiverem fora do ar. Ensaie-os com a equipe da linha de frente, porque um procedimento que vive apenas numa pasta não será encontrado, entendido nem confiável às 3 da manhã durante uma crise.

6. Mantenha um plano de recuperação de desastres com failover de local real. Documente, para cada sistema crítico, exatamente como ele se recupera: o que roda onde, em que ordem, quem decide invocá-lo e como se volta depois (failback). Onde o impacto justifica, opere um local de recuperação ou uma região de nuvem genuinamente separados e prove que consegue passar para eles — a ordem de recuperação importa, porque os sistemas têm dependências que ditam a sequência. Um local de DR não testado é uma suposição cara.

7. Exercite o plano; um plano nunca testado é um plano que falha. Conduza exercícios regulares ao longo de um espectro: percursos de mesa de cenários, testes técnicos de failover e simulações ocasionais plenas ao vivo, incluindo o recurso clínico. Os exercícios expõem as lacunas — a lista de contatos desatualizada, a etapa de recuperação que exige uma senha que ninguém tem, a suposição de que a equipe conhece o processo em papel — enquanto é seguro encontrá-las. Registre as lições, corrija-as e retestes; um exercício sem acompanhamento é teatro.

8. Estenda a continuidade aos seus fornecedores e à nuvem. Sua resiliência é tão forte quanto os terceiros de que seus serviços críticos dependem; portanto, faça da continuidade uma questão contratual e de garantia: exija que os fornecedores evidenciem seus próprios RTO/RPO, testes de DR e recuperação cibernética e entenda o modelo de responsabilidade compartilhada do seu provedor de nuvem — zonas de disponibilidade e regiões protegem contra algumas falhas, mas não contra uma configuração errada ou um comprometimento de conta de que você é responsável. Planeje a falha do próprio fornecedor, incluindo o cenário em que um fornecedor-chave é o atingido por ransomware (ver Tópico 6.3 — Aquisições e contratações).

9. Adote uma norma reconhecida e ponha a continuidade sob governança. Use a ISO 22301 como espinha dorsal estruturada e as orientações do NHS e nacionais como camada setorial e dê a um executivo nomeado a responsabilidade pela continuidade de negócios, reportando ao conselho. A continuidade de que ninguém é dono, que ninguém financia ou revisa decai em silêncio até que o incidente a revele. Ligue-a ao seu arcabouço de garantia (ver Tópico 6.4 — Governança e garantia) para que os planos sejam mantidos, testados e melhorados como rotina, e não redescobertos numa crise.

Perguntas para discutir com a sua equipe#

1. Para cada um dos nossos sistemas clínicos críticos, que RTO e RPO de fato acordamos com os clínicos — e conseguimos cumpri-los hoje? Esta pergunta traz a distância entre aspiração e capacidade à luz do dia. Muitas organizações nunca definiram objetivos explícitos de recuperação, ou os definiram na TI sem contribuição clínica, de modo que a indisponibilidade "aceitável" é apenas o que a arquitetura atual por acaso entrega. Debatam onde a necessidade clínica (minutos para um sistema de emergência) colide com o que os seus backups e a DR podem de fato alcançar (talvez um dia), porque essa distância é risco clínico não gerido que vocês carregam, nomeiem-no ou não. Olhem de forma concreta a sua última recuperação real ou testada: quanto tempo levou, quantos dados vocês teriam perdido e quem aprovou que isso é seguro? Uma boa resposta, honesta, nomeia números específicos por sistema, admite onde ainda não consegue cumpri-los e transforma cada distância numa ação financiada, e não num silêncio confortável.

2. Se um ransomware criptografasse nossos sistemas centrais e nossos backups esta noite, como manteríamos os pacientes seguros amanhã — e quanto tempo até estarmos totalmente recuperados? Este é o cenário que atingiu sistemas de saúde reais; por isso merece um percurso concreto e sem concessões, e não tranquilização. Explorem honestamente as duas metades: a continuidade clínica imediata (os procedimentos de contingência são ensaiados, providos de recursos e confiáveis o bastante para tocar um hospital inteiro em papel por dias?) e a recuperação técnica (os backups são imutáveis e offline, vocês testaram a reconstrução a partir de cópias limpas e conhecem a ordem de recuperação?). Tragam à tona as dependências incômodas — se o login único, o motor de integração ou um fornecedor-chave estiver fora do ar, quanto mais cai junto? Considerem quem declara o incidente grave, quem fala com a equipe, os pacientes e a mídia e quem decide que um sistema é seguro para reconectar. Uma resposta forte descreve um plano ensaiado, com papéis nomeados e restaurações testadas; uma fraca supõe que os backups estão bem e que o processo em papel simplesmente funcionará.

3. Quando foi a última vez que testamos de ponta a ponta os nossos planos de continuidade e de recuperação de desastres, e o que aprendemos? O propósito aqui é distinguir uma capacidade viva de um documento de prateleira. Um plano que não foi exercitado é um plano não testado, e planos não testados rotineiramente falham no contato com a realidade — a lista de contatos está desatualizada, a etapa de recuperação exige credenciais que ninguém tem, os formulários de contingência estão guardados no sistema que está fora do ar. Discutam o espectro de exercícios que vocês de fato realizam: cenários de mesa, testes técnicos de failover e simulações plenas que incluam o recurso clínico da linha de frente, e não apenas a restauração do servidor. Sondem se as lições de incidentes e exercícios passados foram de fato corrigidas e retestadas, ou registradas e esquecidas. Uma boa resposta mostra um calendário regular de exercícios, evidência de lacunas encontradas e fechadas e honestidade sobre quais partes do plano continuam não comprovadas.

4. Quais das nossas dependências críticas não controlamos — e qual é o nosso plano para o dia em que uma delas falhar? A TI de saúde moderna raramente falha sozinha; falha pelos serviços e fornecedores que estão por baixo dela. Levem a equipe além dos sistemas que vocês possuem até os dos quais apenas dependem: a conexão com a espinha dorsal nacional, o provedor de login único, a região de nuvem, o motor de integração, o data center terceirizado, o parceiro de serviços gerenciados que detém as chaves da recuperação. Para cada um, perguntem o que acontece com o cuidado se ele desaparecer por um dia, se o contrato obriga o terceiro a um objetivo de recuperação compatível com a necessidade clínica de vocês e se vocês já viram evidência do teste de DR deles, e não um parágrafo tranquilizador numa proposta. A verdade incômoda é que vocês podem carregar risco residual nunca precificado, porque a falha está no parque de outra pessoa. Uma resposta honesta nomeia as dependências externas específicas de cada serviço crítico, declara quais são garantidas por contrato e quais são simplesmente confiadas e identifica um recurso — ainda que manual — para as dependências que vocês não conseguem tornar resilientes.

5. Quando um incidente grave acontece, quem decide o quê, quem comunica a quem, e todos conhecem seu papel antes do dia? A continuidade tem tanto a ver com comando e comunicação quanto com backups, e é aqui que os planos ensaiados e o caos improvisado divergem. Percorram a coreografia humana: quem tem autoridade para declarar um incidente grave e invocar o plano, quem conduz a resposta operacional, quem decide que um sistema é seguro para reconectar e quem fala com a equipe, os pacientes, a imprensa, os reguladores e — num ciberataque — as autoridades policiais. Considerem a falha das próprias ferramentas durante o incidente, porque a indisponibilidade pode derrubar o e-mail, o diretório telefônico ou a intranet que vocês normalmente usariam para coordenar. Tragam à tona a tensão entre andar depressa e andar com segurança e o que está em jogo reputacionalmente ao errar a mensagem pública. Uma resposta forte aponta uma estrutura testada de comando de incidente, com papéis nomeados e com substitutos, canais de comunicação fora de banda e modelos de mensagem pré-acordados; uma fraca supõe que as pessoas certas simplesmente se reunirão e saberão o que fazer.

6. Como financiamos, assumimos e mantemos viva a continuidade quando nada deu errado por dois anos? A resiliência decai em silêncio no intervalo entre incidentes, e esta pergunta confronta a disciplina organizacional que a impede de apodrecer. A continuidade compete por dinheiro e atenção com prioridades clínicas e digitais visíveis e urgentes, e a organização imatura e sortuda é idêntica à madura até o dia em que deixa de ser. Debatam quem é de fato dono da continuidade em nível executivo, se ela tem uma linha financiada em vez de boa vontade emprestada e como os planos, os mapas de dependência e as listas de contatos são mantidos atuais à medida que os sistemas e as pessoas mudam. Perguntem o que o conselho de fato vê — garantia testada e lacunas honestas, ou uma classificação verde e um documento arquivado. Uma boa resposta descreve responsabilidade nomeada, um orçamento recorrente e um calendário de exercícios e um ritmo de governança que trata a continuidade mantida e testada como rotina, e não como algo redescoberto na próxima crise.

Na prática: um exemplo de saúde e cuidados#

O Meadowvale NHS Foundation Trust opera um hospital de agudos de 600 leitos. Numa manhã de terça-feira, a equipe chega e encontra o prontuário eletrônico do paciente (EPR), a patologia e a radiologia trancados por um bilhete de resgate; os atacantes haviam entrado dez dias antes por uma conta de acesso remoto de um fornecedor. O diretor de informação declara um incidente grave em menos de uma hora, e o plano de continuidade de negócios do hospital é ativado.

Como o hospital havia feito sua análise de impacto nos negócios, sabia que o EPR e a patologia eram seus sistemas de maior criticidade, com objetivos de recuperação acordados, e seus procedimentos de contingência haviam sido ensaiados no outono anterior. As enfermarias passam a fichas de medicação em papel e formulários de observação pré-impressos — guardados deliberadamente em armários físicos em cada enfermaria, e não numa unidade de rede compartilhada —, e o pronto-socorro volta à sua via em papel. As operações eletivas da semana são adiadas e comunicadas aos pacientes; as ambulâncias são desviadas dos períodos de maior movimento. O cuidado continua, degradado mas seguro, porque a equipe havia praticado trabalhar assim.

A recuperação é mais difícil do que a restauração. A equipe de segurança isola a rede para conter a propagação e depois reconstrói os sistemas críticos a partir de backups imutáveis mantidos offline — cópias que os atacantes não conseguiram alcançar. Esses backups haviam sido testados trimestralmente por restauração; assim, a equipe sabia que o processo funcionava e aproximadamente quanto tempo levava; o EPR volta dentro do seu RTO de oito horas, embora a patologia, com dependências mais complexas, leve dois dias. O RPO de quinze minutos significa que apenas uma curta janela de dados foi perdida, e a equipe reconcilia os registros em papel de volta ao sistema por um processo controlado de reentrada, conferindo duas vezes medicamentos e resultados.

Na reunião de balanço, o hospital encontra lacunas reais: o login único era um ponto único de falha que atrasou o acesso dos clínicos durante a recuperação, e o acesso remoto do fornecedor não havia sido coberto pela garantia de continuidade do próprio hospital. Ambos vão para o registro de riscos do conselho, com responsáveis e datas, e o próximo exercício completo é agendado. Foi uma semana ruim — mas não uma catástrofe, porque o plano existia, tinha recursos e havia sido testado.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital raramente tem um data center sobrando; assim, sua estratégia de continuidade se apoia quase inteiramente na resiliência nativa da nuvem e em backups disciplinados. Usem serviços gerenciados com alta disponibilidade embutida entre zonas de disponibilidade, automatizem backups com cópias imutáveis, fora da conta, para sobreviver tanto ao ransomware quanto a uma conta de nuvem comprometida, e ensaiem de fato uma restauração em um ambiente limpo. Seus clientes — hospitais do NHS e sistemas de cuidados integrados — exigirão cada vez mais evidência de RTO, RPO e testes de DR por meio de arcabouços como o DTAC e a garantia de fornecedores; trate, portanto, a continuidade como um ativo de venda, e não como custo indireto. O risco existencial de um pequeno fornecedor é que um único incidente, ou o fundador que sozinho entende a implantação, vire o seu ponto único de falha.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso, uma agência de cuidados domiciliares ou uma clínica de unidade única — carrega o mesmo dever de manter os pacientes seguros durante uma indisponibilidade que um grande hospital, mas com pacientes reais, caixa apertado e, muitas vezes, nenhuma equipe de TI dedicada. A continuidade aqui é deliberadamente pragmática: saibam quais um ou dois sistemas (o prontuário clínico, o sistema de dispensação ou de eMAR) interromperiam o cuidado seguro se falhassem, insistam que o fornecedor do sistema evidencie seus próprios backups, RTO e RPO e mantenham um pacote simples e impresso de contingência — fichas de medicação em papel, telefones-chave, listas recentes de pacientes — onde a equipe possa alcançá-lo quando as telas estiverem apagadas. Como um único gerente de consultório ou um contratado de TI isolado é com frequência a única pessoa que entende a configuração, escrevam as etapas de recuperação e garantam que uma segunda pessoa consiga segui-las. Ransomware e uma linha de banda larga quebrada são as ameaças cotidianas; assim, uma cópia de backup offline ou imutável e uma forma alternativa de trabalhar importam mais do que qualquer elaborado local de DR que vocês não podem pagar nem operar.

Grande organização#

Um grande hospital do NHS, um sistema de cuidados integrados ou um grande fornecedor de tecnologia em saúde carrega um parque extenso e interdependente em que o problema mais difícil é mapear as dependências e os serviços compartilhados, e não qualquer sistema isolado. Invistam num programa formal de BCM alinhado à ISO 22301, num mapa de dependências mantido, em locais ou regiões de DR para os sistemas críticos e num calendário contínuo de exercícios que inclua o recurso clínico. A escala significa que os SPOFs costumam ser serviços compartilhados — identidade, motores de integração, núcleos de rede — cuja falha se propaga em cascata por dezenas de sistemas. A governança é a restrição vinculante: com muitas equipes e fornecedores, a continuidade só se sustenta se um executivo nomeado for dono dela e o conselho revisar a garantia testada, e não planos em papel.

Governo#

Um órgão nacional — NHS England, um departamento de saúde descentralizado ou a UKHSA — precisa pensar a resiliência em escala populacional e sistêmica, onde a falha de um serviço nacional ou de um fornecedor amplamente usado é, em si, um evento de continuidade para todo o setor. Definam padrões e expectativas (objetivos de recuperação, recuperação cibernética, exercícios obrigatórios), financiem capacidades protetoras compartilhadas e coordenem a resposta setorial a incidentes graves, como uma campanha nacional de ransomware. A resposta ao WannaCry remodelou a política nacional justamente porque o impacto atravessou centenas de organizações de uma só vez, expondo fraquezas comuns. A responsabilização aqui é pública e parlamentar; assim, a transparência sobre os riscos conhecidos e o relato honesto da prontidão importam tanto quanto os próprios controles técnicos.

Modos de falha comuns#

• Backups que nunca foram restaurados. Confundir "fazemos backup toda noite" com "conseguimos recuperar". As restaurações não testadas rotineiramente falham ou estouram o RTO; meçam e reportem restaurações bem-sucedidas de ponta a ponta, e não a conclusão do backup.
• Backups alcançáveis pelo ransomware. Manter todos os backups online e conectados à rede, de modo que um atacante os criptografa junto com a produção. Mantenham ao menos uma cópia imutável ou offline.
• DR que protege servidores, e não serviços. Restaurar um banco de dados, mas não as dependências, integrações e acessos que fazem dele um serviço clínico utilizável. Recuperem e testem serviços inteiros, na ordem de dependência.
• Procedimentos de contingência que só existem em papel sobre papel. Planos de recurso nunca ensaiados, guardados no sistema que falha ou desconhecidos da equipe da linha de frente. Ensaiem-nos onde o cuidado de fato acontece.
• Dependências não mapeadas e SPOFs compartilhados. Descobrir durante a indisponibilidade que o login único, o DNS ou um fornecedor sustentavam tudo. Mapeiem as dependências antes, e não durante, o incidente.
• Um plano escrito para o auditor, nunca exercitado. A continuidade como documento de conformidade que decai sem teste até o dia em que é necessário. Um plano nunca testado é um plano que falha.
• Ignorar a continuidade de fornecedores e da nuvem. Supor que os terceiros são resilientes sem evidência e esquecer o modelo de responsabilidade compartilhada. Façam da continuidade algo contratual e assegurado.

Modelo de maturidade#

Lista de verificação#

• Uma análise de impacto nos negócios, de propriedade conjunta com os clínicos, classifica cada serviço e define um RTO e um RPO explícitos para cada sistema crítico.
• Os sistemas críticos têm alta disponibilidade e redundância proporcionais à sua criticidade clínica.
• Os pontos únicos de falha e as dependências críticas (incluindo serviços compartilhados e fornecedores) estão mapeados e mitigados.
• Os backups seguem a regra 3-2-1, com ao menos uma cópia imutável ou offline que o ransomware não alcança.
• As restaurações são testadas em cronograma e cronometradas frente ao RTO/RPO, com a "última restauração bem-sucedida" reportada como métrica.
• Todo sistema clínico crítico tem um procedimento de contingência ensaiado e um processo controlado de reentrada de dados.
• Um plano de recuperação de desastres define as etapas de recuperação, a ordem, a autoridade de decisão e o failback, e o local/região de DR é testado.
• Um cenário de recuperação cibernética (isolar, reconstruir a partir de backups limpos, validar, reconectar) está documentado e exercitado.
• A continuidade de fornecedores e da nuvem é exigida por contrato, evidenciada e assegurada, incluindo o modelo de responsabilidade compartilhada.
• A continuidade está alinhada à ISO 22301, é de responsabilidade de um executivo nomeado, é exercitada num calendário e reportada ao conselho.

Fontes-chave#

• NHS England — Business Continuity Management Toolkit e o Emergency Preparedness, Resilience and Response (EPRR) Framework e Core Standards.
• National Cyber Security Centre (NCSC) — orientações sobre backups offline/imutáveis, mitigação de ransomware e resposta a incidentes.
• ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements (International Organization for Standardization).
• ISO/IEC 27031 — Guidelines for information and communication technology readiness for business continuity.
• Business Continuity Institute (BCI) — Good Practice Guidelines.
• National Audit Office — Investigation: WannaCry cyber attack and the NHS (2017) e a revisão de lições aprendidas do Department of Health.
• NHS England / Data Security and Protection Toolkit (DSPT) — padrões de segurança de dados, incluindo continuidade de negócios e resposta a incidentes.
• GOV.UK Service Manual — orientações de resiliência, monitoramento e recuperação para serviços em produção.

Referências#

1. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
2. IT disaster recovery — Wikipedia — https://en.wikipedia.org/wiki/IT_disaster_recovery
3. ISO 22301 — Wikipedia — https://en.wikipedia.org/wiki/ISO_22301
4. Backup — Wikipedia — https://en.wikipedia.org/wiki/Backup
5. High availability — Wikipedia — https://en.wikipedia.org/wiki/High_availability
6. Redundancy (engineering) — Wikipedia — https://en.wikipedia.org/wiki/Redundancy_(engineering)
7. Failover — Wikipedia — https://en.wikipedia.org/wiki/Failover
8. Single point of failure — Wikipedia — https://en.wikipedia.org/wiki/Single_point_of_failure
9. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
10. WannaCry ransomware attack — Wikipedia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
11. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — International Organization for Standardization — https://www.iso.org/standard/75106.html
12. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
13. Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
14. Offline backups in an online world — National Cyber Security Centre — https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/