Continuidade & Resiliência • Artigo
Reduzir o risco em cloud e terceiros: quanto tempo demora a repor serviços?
⏱️ Leitura estimada: 4 minutos
Dependências de hyperscalers, falhas sistémicas e concentração de terceiros estão a mudar a exigência: reduzir o risco em cloud e terceiros exige provar capacidade de continuidade, recuperação e resposta com evidência.
Porque é que reduzir o risco em cloud e terceiros é agora prioritário?
- Dependências de hyperscalers: a falha de 12/jun/2025 afetou múltiplas aplicações populares e expôs o impacto transversal de um único ponto de falha na identidade/serviços partilhados. status.cloud.google.com
- Impactos na produtividade derivados de SPOF’s: em julho, os utilizadores do Outlook/M365 ficaram horas sem e-mail/calendário até serem aplicadas as medidas corretivas necessárias de configuração. Um lembrete de que para “trabalhar” as organizações dependem de” serviços SaaS críticos”, tais como, aplicações simples e supostamente identificadas como “não críticas” numa avaliação de impacto comum. AP News
- Falhas na infraestrutura e serviços de suporte, fora do controlo da organização, e não nas TI da organização. O efeito sistémico do evento disruptivo desafiou a resiliência do ecossistema onde vivem muitas organizações: o apagão ibérico foi classificado pela ERSE como ICS 3 – Blackout (o nível mais grave da ENTSO-E), e mostrou que energia/telecom são dependências operacionais diretas. Muitas organizações sentiram o impacto real de um evento disruptivo que afetou em cascata todo o seu ecossistema. erse.pt
- Concentração de terceiros tecnológicos: supervisores europeus têm alertado para o risco de concentração no uso de prestadores terceiros de TI. Quando muitas entidades dependem dos mesmos fornecedores, uma falha técnica, um incidente cibernético ou uma indisponibilidade prolongada pode produzir efeitos em cadeia. Este tema é especialmente relevante no setor financeiro, onde o DORA reforça a gestão do risco TIC, o reporte de incidentes, os testes de resiliência e a governação de terceiros. Atentos a este facto, os reguladores e supervisores europeus vêm destacar a necessidade de reforçar as medidas de gestão do risco, cibersegurança e controlo a implementar por estas partes, de modo a reduzir os riscos de concentração e contágio de todo o ecossistema de serviços dependentes. Destacam-se das diretivas europeias transpostas para legislação nacional como o NIS 2 e a CER, e os regulamentos setoriais “lex specialis” como por exemplo, o DORA, para o setor financeiro e prestadores de serviços TI, que já se aplica desde 17 jan 2025. ESMA, ou extensões e regras especificas, como no setor a aviação a Diretiva NIS 2 (lex generalis) + Regras EASA Part IS (lex specialis) – onde se incluem Regras/Regulamentos EASA (aplicação direta ou via regulamentos de execução).
“Continuity-by-design”, não é apenas um dossier!
1) Multi-região, seguida de multi-cloud
Arranca com redundância na mesma cloud: zonas/regiões distintas, failover testado e dados “imutáveis”, Write Once Read Many (WORM), para suportar a recuperação. Passa a multi-cloud onde o impacto justifica (identidade, faturação, front-ends).
2) Identidade com break-glass
Se IAM cai, tudo cai. Define contas break-glass fora do SSO, dupla custódia de chaves e procedimento de ativação/revogação ensaiado.
3) SaaS “egress-ready”
Para cada SaaS crítico, responde: Como exporto os dados? Em quanto tempo? Consigo operar em serviços mínimos sem a plataforma? Mantém extratos/espelhos do que for vital para o cliente.
4) Observabilidade que não morre com o incidente
Registos, alertas e status fora do prestador afetado (monitorização externa, runbooks e contactos offline).
5) Planos de degradação funcional
Define serviços mínimos viáveis (o que manténs quando perdes 30–50% da capacidade) — e treina o feature toggle sob pressão.
6) Contratos que realmente ajudam
Exige RTO/RPO, notificação antecipada, direito de auditoria e testes conjuntos; mede tempo de resposta e qualidade das evidências.
7) Exercícios recorrentes e mensuráveis
A ENISA recomenda testar BC/DR regularmente (table-tops, simulações, hot sites, digital twins) com registo de lições e revisões. ENISA
“Provas” que acalmam reguladores e clientes
- DORA (financeiro): evidências de gestão de risco TIC, testes de resiliência e modelos de governo de terceiros (relatórios, atas, métricas). EIOPA
- Concentração de serviços e dependências em terceiros: demonstra que conhece quem o pode parar (3.º e 4.º nível), sabe quem (de facto, é crítico) e como reduzir essa exposição. ESMA
- Comunicação: playbooks prontos (clientes, media, supervisores) com tempos-objetivo e porta-vozes treinados.
Checklist 60 minutos (quando tudo pára)
- Ative os runbook e bridge de crise (comunicação out-of-band).
- Confirme o âmbito (o que caiu / o que funciona) e ative o modo degradado.
- Decida em 15 min: failover automático/manual, bloqueio de mudanças e mensagem inicial a clientes.
- Registe tudo (tempos, decisões, evidências).
- Atualize status de hora a hora até estabilizar.
Métricas que o Board entende
- RTO/RPO por serviço (objetivo – metas vs. obtido no último teste)
- MTTR por cenário (média e p95)
- Percentagem de backups restaurados nos últimos 90 dias
- Cobertura EDR/SIEM e % de runbooks testados com sucesso
- Mapa de dependências (3.º/4.º nível) e tempo até 1.ª comunicação a clientes
Perguntas que deves fazer ao teu fornecedor esta semana (após verificares o teu contrato)
- Qual é o RTO/RPO contratual e o observado em testes reais?
- Como exportar dados em cenário de emergência e em quanto tempo?
- Que alternativas existem se o SSO/IAM falhar?
- Se / Como se pode testar em conjunto um cenário de falha regional/serviço? Quando?
- Que evidências são entregues após o incidente?
Plano de 100 dias (novo ângulo, sem repetir o que já tem)
0–30 dias — Fotografia de risco de concentração
Mapeie serviços críticos ↔ regiões/fornecedores ↔ pontos únicos de falha (inclui energia/telecom). Marque quick wins (break-glass, status page externa). erse.pt
31–60 dias — Ensaiar e medir
Table-top “perda de IAM/cloud” + teste de restore cronometrado; prepara dashboards (RTO/RPO, MTTR, comunicação). status.cloud.google.com
61–100 dias — Provar e melhorar
Teste técnico (perda de GCP/Azure/M365) + revisão contratual de SaaS críticos (export, notificação, right to audit) + after-action review. AP News
Leituras úteis (2025)
- Status do incidente GCP (12/jun/2025) e análises independentes. status.cloud.google.com
- Outage Microsoft 365/Outlook (jul/2025) — correção de configuração e restauro progressivo. AP News
- Apagão ibérico classificado ICS 3 – Blackout (ERSE). erse.pt
- Concentração de terceiros em TI preocupa supervisores europeus (JC ESAs). ESMA
- ENISA: testar BC/DR regularmente e documentar lições. ENISA
Cursos Behaviour recomendados
- ISO 22301 Lead Implementer — BIA, RTO/RPO, runbooks e exercícios
- ISO 22301 Lead Auditor — medir eficácia e preparar auditorias
- NIS 2 Compliance Lead Manager — governação, reporte e gestão de risco de terceiros
- DORA Compliance Lead Manager — resiliência operacional digital (financeiro)
Tem uma dúvida de formação relacionada com este tema?
Se procura perceber em que curso, área ou percurso Behaviour este conteúdo pode ser trabalhado, consulte a página Formação por Necessidades.
Autor: Behaviour
Publicado em: 24 de novembro de 2025
Não é autorizada a cópia ou reprodução deste artigo.