Resiliência operacional · Gestão de risco de TIC · Serviços financeiros
O Digital Operational Resilience Act (DORA), Regulamento (UE) 2022/2554, aplica-se às entidades financeiras da União Europeia desde 17 de janeiro de 2025. Entre seus objetivos centrais está o requisito de que as empresas detectem incidentes de TIC (tecnologia da informação e comunicação) prontamente e mantenham a disponibilidade dos serviços que suportam funções críticas ou importantes.
Atingir esse objetivo requer monitoramento que reflita a disponibilidade real dos serviços voltados para clientes, e não apenas a saúde interna dos sistemas por trás deles. Ferramentas internas de observabilidade reportam sobre a infraestrutura a partir da rede corporativa. Elas não confirmam se um serviço é acessível e funcional na posição de um usuário externo. O monitoramento sintético externo responde a isso executando transações roteirizadas contra serviços em produção a partir de locais fora da rede, em uma programação definida.
Este artigo identifica as obrigações específicas do DORA que afetam monitoramento contínuo e detecção, e explica como o monitoramento sintético externo, e a plataforma Dotcom-Monitor em particular, abordam cada uma delas.
Obrigações de Detecção e Disponibilidade do DORA
O DORA é baseado em resultados e não prescritivo quanto às ferramentas. Não exige um produto específico de monitoramento nem frequência de checagem. Estabelece obrigações para detecção, disponibilidade e supervisão, e o monitoramento é o controle operacional pelo qual várias dessas obrigações são cumpridas. Quatro disposições são as mais relevantes.
Artigo 9 (Proteção e Prevenção) exige que as entidades financeiras monitorem e controlem continuamente a segurança e o funcionamento dos sistemas e ferramentas de TIC. A obrigação é contínua, o que exclui verificações periódicas ou manuais como controle suficiente por si só.
Artigo 10 (Detecção) requer mecanismos para detectar prontamente atividades anômalas, incluindo problemas de desempenho da rede de TIC e incidentes relacionados à TIC, além de identificar potenciais pontos únicos de falha material. O parágrafo 10(2) do artigo exige ainda que os mecanismos de detecção possibilitem múltiplas camadas de controle, definam limiares de alerta e incluam alertas automáticos para a equipe responsável pela resposta a incidentes.
“As entidades financeiras deverão dispor de mecanismos que detectem prontamente atividades anômalas, incluindo problemas de desempenho da rede de TIC e incidentes relacionados à TIC.”
DORA, Artigo 10 (Detecção)
Artigos 17 e 19 (Gestão e Comunicação de Incidentes) exigem um processo documentado para gestão de incidentes ligados à TIC e, para incidentes classificados como graves, notificação à autoridade competente dentro do prazo definido pelo regulador, medido em horas e não em dias. A rapidez dessa notificação depende diretamente da velocidade da detecção.
Artigo 28 (Risco de Terceiros de TIC) exige que as entidades gerenciem e monitorem o risco decorrente dos provedores terceirizados de serviços de TIC. Quando um provedor suporta uma função crítica ou importante, sua disponibilidade é de responsabilidade da entidade monitorar.
Dessas disposições, cinco capacidades de monitoramento são requeridas: monitoramento contínuo, detecção imediata de incidentes, validação de disponibilidade, supervisão de TIC terceirizada e aviso prévio de degradação do serviço. As seções abaixo tratam de cada uma em sequência.
O Papel da Verificação Externa
Ferramentas internas, incluindo gerenciamento de desempenho de aplicação (APM), métricas de servidor e análise de logs, observam os sistemas de dentro da rede. Elas reportam com precisão o estado da infraestrutura, mas não detectam uma categoria de falhas que ocorrem entre o usuário e os servidores. Estas incluem:
- Alterações de DNS que resolvem incorretamente para usuários em uma região ou rede específicas.
- Certificados TLS expirados ou mal configurados que são rejeitados pelos clientes.
- Falhas no roteamento de CDN ou ISP no caminho para o data center.
- Scripts ou APIs de terceiros que travam e impedem o carregamento completo da página.
- Balanceadores de carga que retornam uma resposta válida para uma verificação de saúde, mas falham em uma transação completa do usuário.
Em cada uma dessas condições, o monitoramento interno reporta operação normal enquanto o serviço está indisponível para os usuários. O monitoramento sintético externo executa a transação do usuário fora da rede, registrando portanto a falha no ponto em que ela afeta os usuários.
A verificação externa também possui valor probatório para conformidade. Um registro de disponibilidade tem mais credibilidade para um examinador quando a medição é originada fora do sistema medido. Dados independentes e carimbados de tempo apoiam as obrigações de auditoria e relatório que acompanham os requisitos de detecção do DORA.
Mapeamento dos Requisitos do DORA para as Capacidades do Dotcom-Monitor
As subseções seguintes apresentam cada requisito e a capacidade correspondente que o atende. Dotcom-Monitor é uma plataforma de monitoramento sintético que realiza verificações de fora da rede, o que está alinhado com as obrigações de detecção e disponibilidade apresentadas acima.
Monitoramento Contínuo (Artigo 9)
Requisito. Monitorar e controlar continuamente o funcionamento dos sistemas de TIC que suportam serviços voltados para clientes.
Como é atendido. Verificações sintéticas programadas rodam em intervalos definidos, com frequência de até um minuto, proporcionando cobertura ininterrupta dos serviços monitorados. O monitoramento de aplicações web carrega o serviço em um navegador real e mede o resultado renderizado, em vez de confirmar apenas que um servidor responde. Isso fornece um registro contínuo se o serviço funciona como o usuário o encontraria.
Detecção Imediata de Atividades Anômalas (Artigo 10)
Requisito. Detectar prontamente atividades anômalas, incluindo problemas de desempenho da rede e incidentes e identificar pontos únicos de falha material.
Como é atendido. Uma transação sintética que falha, ou que excede um limite definido de tempo de resposta, identifica a condição no ciclo da verificação em que ocorre, independentemente de relatos dos usuários. Roteirizar jornadas completas com o gravador EveryStep estende a detecção além da disponibilidade da página para processos em múltiplas etapas, como autenticação, pagamento e abertura de conta, onde um único passo falho constitui um incidente.
Limiares de Alerta e Alertas Automáticos (Artigo 10(2))
Requisito. Definir limiares de alerta e fornecer alertas automáticos para a equipe responsável pela resposta a incidentes.
Como é atendido. Alertas configuráveis em alertas disparam em condições definidas, incluindo tempo de resposta acima do limite, resposta de erro ou falha em uma etapa da transação. Os alertas são automaticamente encaminhados para email, SMS ou ferramentas integradas de gerenciamento de incidentes, direcionando a notificação para os responsáveis designados e não para uma fila compartilhada. Alertas baseados em degradação, não apenas em interrupção total, suportam as múltiplas camadas de controle que o Artigo 10(2) exige.
Validação de Disponibilidade e Evidência para Auditoria
Requisito. Demonstrar que os serviços que suportam funções críticas ou importantes permaneceram disponíveis, com registros adequados para auditoria e revisão pós-incidente.
Como é atendido. Os relatórios de uptime e SLA fornecem histórico de disponibilidade carimbado com data e hora para cada serviço monitorado. Como a medição se origina fora da rede, o registro resultante constitui evidência independente de disponibilidade e do timing e duração de qualquer interrupção. Esses registros suportam tanto revisão interna quanto pedidos de examinadores. Metas relacionadas à disponibilidade são discutidas nos recursos de monitoramento de uptime da plataforma.
Supervisão de TIC de Terceiros (Artigo 28)
Requisito. Monitorar a disponibilidade e o desempenho dos provedores terceirizados de TIC que suportam funções críticas ou importantes.
Como é atendido. O monitoramento de API verifica os endpoints REST, SOAP e GraphQL dos quais uma aplicação depende, incluindo aqueles operados por terceiros. Para aplicações hospedadas usadas em operações, o monitoramento SaaS acompanha diretamente a disponibilidade do provedor, dando à entidade visibilidade independente da dependência em vez de depender do próprio status reportado pelo provedor.
Aviso Prévio e Comunicação de Incidentes (Artigos 10, 17, 19)
Requisito. Fornecer aviso antecipado de degradação do serviço e detectar incidentes graves a tempo de cumprir prazos para reporte.
Como é atendido. Como as verificações são contínuas e externas à rede, a degradação e interrupção são detectadas próximas ao ponto de ocorrência, diminuindo o intervalo entre início do incidente e detecção. Esse intervalo é relevante para os Artigos 17 e 19, onde o prazo para notificação de um incidente grave é medido em horas. Detecção mais precoce aumenta o tempo disponível para classificar, responder e reportar o incidente. A mesma capacidade suporta a detecção antecipada de interrupções e é explorada mais profundamente no contexto do monitoramento sintético em serviços financeiros.
Cobertura de Sistemas Internos
Requisito. Monitorar aplicações internas que suportam funções críticas ou importantes, além dos serviços públicos.
Como é atendido. Serviços públicos são verificados a partir da rede global de monitoramento. Aplicativos internos atrás do firewall são verificados por agentes privados implementados no ambiente da entidade, aplicando as mesmas verificações para sistemas internos e externos a partir de uma plataforma única.
Resumo Requisito para Capacidade
A tabela consolida o mapeamento apresentado acima.
| Disposição do DORA | Requisito | Capacidade do Dotcom-Monitor |
|---|---|---|
| Artigo 9 | Monitoramento contínuo de sistemas de TIC | Verificações agendadas em navegador real em intervalos de até um minuto |
| Artigo 10(1) | Detecção imediata de atividades anômalas | Transações sintéticas que sinalizam falhas e rompimento de limiares por ciclo |
| Artigo 10(2) | Limiares de alerta e alertas automáticos | Alertas configuráveis para responsáveis designados em erro ou degradação |
| Artigos 17, 19 | Detecção oportuna de incidentes para reporte | Detecção contínua externa que reduz o tempo para conhecimento |
| Artigo 28 | Supervisão de terceiros de TIC | Monitoramento de API e SaaS de dependências externas |
| Auditoria e revisão | Evidência de disponibilidade | Relatórios carimbados de uptime e SLA a partir de fora da rede |
Ilustrações de Lacunas de Detecção
Duas condições de falha demonstram por que a verificação externa é necessária. Ambas são indetectáveis somente pelo monitoramento interno.
Configuração incorreta regional de DNS. Uma alteração no DNS resolve incorretamente para um único provedor de internet. Métricas do lado do servidor permanecem nominais, pois as requisições afetadas não alcançam a infraestrutura. Uma verificação externa executada na região afetada registra a falha em seu próximo ciclo e emite um alerta, indicando a localização afetada.
Latência na autenticação de terceiros. Um provedor externo de identidade permanece disponível mas responde lentamente, adicionando vários segundos a cada autenticação. Nenhum erro interno é gerado. Uma transação sintética que completa o login mede o tempo elevado de resposta, ultrapassa seu limite configurado e identifica a dependência como fonte. Esta é a visibilidade que o Artigo 28 exige para provedores terceiros.
Configuração Recomendada de Monitoramento
A configuração abaixo estabelece uma linha de base de monitoramento alinhada às obrigações de detecção e disponibilidade acima. Prioriza caminhos críticos em vez de cobertura exaustiva.
Passo 1: Identifique funções críticas ou importantes. Enumere os serviços voltados para clientes cuja falha exigiria um relatório de incidente, como autenticação, pagamentos, transferências, abertura de contas e acesso a extratos. Estes definem a prioridade do monitoramento.
Passo 2: Roteirize jornadas completas do usuário. Para cada função, grave o fluxo completo do usuário com o gravador EveryStep, concluindo em um passo que confirme que o serviço desempenhou sua função, como uma transferência concluída ou uma visualização de conta carregada. Uma verificação limitada à página inicial não detectará falha em uma etapa posterior.
Passo 3: Monitore a partir de locais relevantes. Selecione locais de monitoramento que correspondam à geografia dos clientes da entidade na rede global de monitoramento, para que falhas regionais sejam detectadas.
Passo 4: Monitore dependências de terceiros. Configure verificações separadas para as APIs de terceiros e aplicações hospedadas das quais funções críticas dependem, para que a origem da falha possa ser atribuída à entidade ou ao provedor.
Passo 5: Defina limiares e roteamento de alertas. Estabeleça limiares de alerta para tempo de resposta e condições de erro, e direcione os alertas para os responsáveis designados e sistemas de gerenciamento de incidentes. Configure alertas para degradação, assim como para interrupção completa.
Passo 6: Mantenha registros de disponibilidade. Habilite relatórios de uptime e SLA desde o início, para que o histórico de disponibilidade acumule automaticamente e esteja disponível para auditoria e revisão pós-incidente.
Passo 7: Amplie a cobertura para sistemas internos. Implemente agentes privados para aplicações internas que suportam funções críticas, para que esses sistemas recebam verificações contínuas equivalentes.
Escopo e Limitações
O monitoramento sintético externo é um controle dentro de um programa DORA e não satisfaz, por si só, a regulamentação na totalidade. Ele fornece validação de disponibilidade e detecção pronta. Não oferece governança de risco de TIC, classificação e procedimentos de comunicação de incidentes, testes de penetração liderados por ameaças, backup e recuperação, ou os acordos contratuais com terceiros exigidos pelo DORA. Essas obrigações são atendidas por outros controles no programa de resiliência da entidade.
O monitoramento sintético também verifica apenas as transações roteirizadas. Uma jornada de usuário não configurada não é monitorada, então a cobertura deve ser mantida conforme os serviços mudam. Dentro deste escopo definido, o monitoramento sintético externo fornece evidências de detecção e disponibilidade que poucos outros controles produzem.
Conclusão
O DORA requer que entidades financeiras detectem incidentes de TIC prontamente e mantenham, e evidenciem, a disponibilidade dos serviços que suportam funções críticas ou importantes. O monitoramento interno reporta o estado da infraestrutura e não detecta falhas que ocorrem entre o usuário e os servidores. O monitoramento sintético externo verifica a transação completa do usuário continuamente, de fora da rede e em regiões relevantes, incluindo dependências de terceiros, e mantém registros carimbados do resultado.
Essas capacidades correspondem diretamente à obrigação de monitoramento contínuo do Artigo 9, às obrigações de detecção e alertas do Artigo 10, à celeridade exigida pelos Artigos 17 e 19, e à supervisão de terceiros do Artigo 28. O monitoramento sintético externo não constitui conformidade com o DORA por si só, mas é um meio direto e evidenciado de atender aos requisitos de detecção e disponibilidade que a regulamentação estabelece.
