Falha do fornecedor de cloud ao abrigo da NIS 2
O seu fornecedor estar em baixo é o teste do seu plano de continuidade, não uma isenção dele.
O que esta página é
Um grande fornecedor de cloud cai. A produção para. A pergunta na sala é se as obrigações NIS 2 ficam com o fornecedor ou com a sua entidade. A resposta da diretiva é que ambas as camadas carregam as suas próprias obrigações e uma não dispensa a outra. Os seus deveres ao abrigo do Artigo 21(2)(c) NIS 2 de manter a continuidade do negócio, os backups e a recuperação, e ao abrigo do Artigo 23 de reportar incidentes significativos, aplicam-se à sua entidade independentemente do que o seu fornecedor faça no seu próprio relógio.
Esta página é escrita para um responsável de TI ou um gerente numa empresa de 50 a 250 pessoas que corre a maior parte da sua produção num hyperscaler ou numa cloud regional. Não é aconselhamento jurídico. É a mecânica de qual cláusula se aplica a quem quando a página de estado do fornecedor fica vermelha.
A frase mais útil: uma falha de cloud é o teste ao vivo do seu plano de recuperação do Artigo 21(2)(c). Se o plano funcionar, não ocorreu nenhum incidente significativo na sua entidade. Se o plano não funcionar, o Artigo 23 começa a correr no seu relógio, não no do fornecedor.
Diretiva (UE) 2022/2555 (NIS 2)
Artigo 21(2)(c): políticas e procedimentos relativos à continuidade das atividades, como a gestão de cópias de segurança e a recuperação após desastre, e a gestão de crises. Artigo 21(2)(d): segurança da cadeia de fornecimento, incluindo aspetos relacionados com a segurança das relações entre cada entidade e os seus fornecedores ou prestadores de serviços diretos.
O Artigo 21(2)(c) coloca a obrigação de continuidade, backup e recuperação na entidade. A diretiva não permite que essa obrigação seja delegada num fornecedor de cloud através de um contrato. O Artigo 21(2)(d) é o pilar do risco de fornecedor: é-lhe exigido avaliar e gerir a segurança dos seus fornecedores diretos, o que inclui cláusulas contratuais de notificação para falhas e incidentes no fornecedor. O Artigo 23 fixa depois a cascata de reporte com o aviso prévio de 24 horas, a notificação de incidente de 72 horas, uma atualização intermédia a pedido, e um relatório final no prazo de um mês.
Regulamento de Execução (UE) 2024/2690 da Comissão
Artigo 7.º: No que diz respeito aos prestadores de serviços de computação em nuvem, considera-se que um incidente é significativo nos termos do artigo 3.º, n.º 1, alínea g), se preencher um ou mais dos seguintes critérios: a) Um serviço de computação em nuvem prestado fica completamente indisponível durante mais de 30 minutos; b) A disponibilidade de um serviço de computação em nuvem de um prestador fica limitada, por um período superior a uma hora, para mais de 5 % dos utilizadores do serviço de computação em nuvem na União ou para mais de um milhão de utilizadores do serviço de computação em nuvem na União, consoante o que for menor; […]
O CIR quantifica o que conta como significativo para as 11 categorias de infraestrutura digital e serviços digitais que cobre, o que inclui os fornecedores de serviços de computação em nuvem ao abrigo do Anexo I setor 8 da NIS 2. Os artigos 3.º e 7.º do CIR fixam os limiares para os prestadores de serviços de computação em nuvem. Para entidades fora do âmbito do CIR, o teste de significância do Artigo 23(3) é o que se aplica e uma falha em cascata que para a produção quase sempre o cumpre.
BSIG (Alemanha)
§30 BSIG: medidas técnicas e organizativas adequadas ao risco. §32 BSIG: notificação de incidentes significativos à BSI através do Meldeportal em bsi.bund.de. §31 BSIG: deveres de segurança da cadeia de fornecimento para a entidade.
O BSIG é o exemplo da transposição alemã. Os Países Baixos (Cyberbeveiligingswet) e a Áustria (NISG 2024) têm os seus. A cascata de 24 / 72 horas / intermédio / um mês é de nível de diretiva e idêntica em todos os Estados-Membros. Um fornecedor de cloud que seja ele próprio uma entidade NIS 2 na UE tem o seu próprio dever de reporte do §32 BSIG ou do equivalente nacional. Esse dever não extingue o seu.
Avalie face ao seu plano do Artigo 21(2)(c)
Abra o plano de continuidade do negócio e de recuperação após desastre e execute-o. A pergunta não é se o fornecedor está em baixo. A pergunta é se os seus serviços podem continuar a operar ao abrigo do plano que escreveu. Failover para uma região secundária, mudar para um fluxo de trabalho offline documentado, ou restaurar a partir de um backup mantido fora do fornecedor afetado. O Artigo 21(2)(c) NIS 2 coloca o dever de continuidade na sua entidade. Se a falha expuser que não havia plano, essa é a primeira constatação, não a falha.
Acione o seu processo de fornecedor do Artigo 21(2)(d)
O Artigo 21(2)(d) NIS 2 exige que faça a gestão da segurança dos seus fornecedores diretos. Na prática, isso significa três coisas numa falha: abrir o contrato e ler as cláusulas de notificação e de SLA, registar a referência de incidente do fornecedor e qualquer cronologia que ele publique, e captar a evidência no seu registo de auditoria. Se o contrato não exigir notificação pelo fornecedor de incidentes que o afetem, essa é a segunda constatação, separada da própria falha.
Reporte se a sua entidade tiver um incidente significativo
O teste do Artigo 23(3) é aplicado à sua entidade, não ao fornecedor. Se a falha causar uma perturbação operacional grave dos seus serviços, perdas financeiras a si, ou danos consideráveis a outros que de si dependem, então o Artigo 23 NIS 2 começa a correr no seu relógio. Aviso prévio ao CSIRT nacional ou à autoridade competente no prazo de 24 horas após tomar conhecimento, notificação de incidente no prazo de 72 horas, relatório intermédio a pedido, relatório final no prazo de um mês. Na Alemanha isto passa pelo BSI Meldeportal ao abrigo do §32 BSIG. O relatório do próprio fornecedor ao abrigo do seu próprio estatuto NIS 2 é separado e não reporta por si.
A continuidade é dever da entidade, não do fornecedor
O Artigo 21(2)(c) NIS 2 coloca o dever de continuidade, backup e recuperação na entidade. Um contrato com um hyperscaler que promete uma meta de disponibilidade de 99,99 por cento não é um plano de continuidade no sentido da diretiva. O plano tem de descrever o que a sua entidade faz quando o fornecedor está indisponível. O auditor, no próximo ano, testa se tal plano existe e se foi exercitado, não se o SLA foi cumprido.
Os backups têm de ser recuperáveis, não apenas existir
A posição da BSI é que a existência de um backup não é o teste. A restaurabilidade nas condições de um incidente real é. Um backup mantido na mesma região de cloud que o sistema de produção, face ao mesmo fornecedor de identidade, não é um backup no sentido do Artigo 21(2)(c) quando é a região ou a camada de identidade que falha. A obrigação de backup recuperável exige separação ao longo do domínio de falha que está a tentar sobreviver.
BSI Meldeportal (Alemanha), CSIRT nacional (outros Estados-Membros)
Se a falha causar um incidente significativo na sua entidade ao abrigo do Artigo 23(3), o relatório passa pelo seu canal nacional. Na Alemanha é o BSI Meldeportal ao abrigo do §32 BSIG. Nos Países Baixos o National Cyber Security Centre, na Áustria o GovCERT. O relatório é seu para apresentar, mesmo que a causa raiz esteja com o fornecedor. A página de estado de um fornecedor não é uma apresentação.
Fornecedor de cloud como entidade NIS 2, Anexo I setor 8
Um fornecedor de serviços de computação em nuvem estabelecido na UE é uma entidade essencial ou importante ao abrigo do Anexo I setor 8 da NIS 2 (infraestrutura digital). Deve o seu próprio reporte do Artigo 23 no seu próprio relógio à sua própria autoridade competente ou CSIRT. O CIR 2024/2690 especifica os limiares de significância para os fornecedores de infraestrutura digital. O relatório do fornecedor não é o seu relatório. Um fornecedor fora da UE está fora do âmbito da diretiva, caso em que a gestão de risco de fornecedor do Artigo 21(2)(d) é o seu único ponto de controlo sobre ele.
ENISA e a rede de CSIRT
As falhas transfronteiriças de grandes fornecedores de cloud são coordenadas através da rede de CSIRT coordenada pela ENISA ao abrigo do Artigo 15 NIS 2. A ENISA publica conhecimento situacional em todos os Estados-Membros. Para uma entidade individual, isto é material de referência e não um canal de reporte. O canal de reporte é nacional. A ENISA é onde lê o que está a acontecer ao nível da UE quando o fornecedor está em baixo em vários países.
A cloud é problema do fornecedor. A NIS 2 fica com eles.
O Artigo 21(2)(c) NIS 2 coloca a obrigação de continuidade, backup e recuperação na sua entidade. O Artigo 21(2)(d) coloca a obrigação de risco de fornecedor na sua entidade. O fornecedor tem os seus próprios deveres ao abrigo da diretiva se for um fornecedor de cloud estabelecido na UE ao abrigo do Anexo I setor 8, mas esses deveres correm em paralelo com os seus e não os dispensam. A auditoria, no próximo ano, testa o seu plano, não o SLA do fornecedor.
Esperar pelo relatório de SLA pós-incidente do fornecedor antes de apresentar ou rever.
O Artigo 23(4) NIS 2 exige o aviso prévio no prazo de 24 horas após tomar conhecimento de um incidente significativo na sua entidade. O relatório do fornecedor pode levar semanas. Se a falha causou uma perturbação operacional grave na sua entidade, o relógio de 24 horas corre contra si, tenha ou não o fornecedor emitido alguma coisa. Esperar pelo relatório de SLA é a razão única mais comum pela qual as entidades falham o prazo em casos de falha de cloud.
O fornecedor voltou, tudo funciona de novo, o incidente está fechado.
O Artigo 21(2)(c) NIS 2 espera que o plano de continuidade e recuperação seja exercitado e melhorado. Uma falha de cloud é um exercício ao vivo desse plano, e a análise pós-incidente é o que alimenta a iteração seguinte. O auditor vai perguntar o que mudou no plano de recuperação após a última falha. Se nada mudou e a mesma lacuna continua lá, isso é uma constatação. Um regresso à operação normal não é um incidente fechado no sentido da diretiva.
Uma empresa de logística com 110 pessoas na Renânia do Norte-Vestfália, classificada como wichtige Einrichtung ao abrigo da NIS 2 porque o setor e o número de trabalhadores a colocam em âmbito. Terça-feira 09:14: a região central da UE do hyperscaler degrada-se e o sistema de gestão de transportes, o fornecedor de identidade e o armazenamento de ficheiros partilhado da empresa ficam todos inacessíveis. 09:20: o responsável de TI abre o plano de continuidade, muda o despacho para o fluxo de trabalho offline documentado em portáteis locais, e informa o gerente. 09:35: órgão de gestão informado, decisão registada no registo de auditoria de tratar isto como um evento de continuidade ao abrigo do Artigo 21(2)(c) e de monitorizar face ao teste de significância do Artigo 23(3). A página de estado do fornecedor é capturada em imagem e anexada ao registo do incidente.
11:50: a falha já dura mais de duas horas e está agora a afetar os compromissos de entrega a clientes. O teste do Artigo 23(3) é reavaliado: a perturbação operacional grave dos serviços está cumprida. O aviso prévio de 24 horas é apresentado através do BSI Meldeportal ao abrigo do §32 BSIG, citando a referência de incidente do fornecedor e o impacto próprio da empresa. 14:30: o fornecedor recupera a região. A empresa faz a análise pós-incidente na manhã seguinte. Constatação: o fornecedor de identidade secundário estava no papel mas nunca tinha sido exercitado, pelo que o failover demorou 40 minutos mais do que o plano assumia. Duas alterações escritas entram no plano: exercício mensal do fornecedor de identidade secundário, e uma adenda contratual com o fornecedor de cloud para exigir a notificação de incidentes regionais no prazo de 30 minutos. O relatório intermédio e o relatório final de um mês ao abrigo do Artigo 23 são apresentados a partir do registo de auditoria, não de memória.
- Diretiva (UE) 2022/2555 (NIS 2): Artigo 21(2)(c) (continuidade das atividades, backup, recuperação, gestão de crises), Artigo 21(2)(d) (segurança da cadeia de fornecimento), Artigo 23 (cascata de reporte) e Artigo 23(3) (teste de significância). Anexo I setor 8 (infraestrutura digital, incluindo fornecedores de serviços de computação em nuvem). EUR-Lex.
- Regulamento de Execução (UE) 2024/2690 da Comissão: requisitos técnicos e metodológicos e limiares de significância para fornecedores de infraestrutura digital e de serviços digitais, incluindo fornecedores de cloud. Artigos 3.º e 7.º. EUR-Lex.
- BSIG (Alemanha): §30 (medidas de gestão de risco), §31 (segurança da cadeia de fornecimento), §32 (BSI Meldeportal). Gesetze im Internet.
- BSI: pacotes informativos NIS 2 sobre continuidade, backups recuperáveis e a posição de que a existência de um backup não é o teste. bsi.bund.de.
- ENISA: coordenação da rede de CSIRT ao abrigo do Artigo 15 NIS 2 para incidentes transfronteiriços. enisa.europa.eu.
Na prática
Onde isto aparece no percurso guiado
O percurso guiado transforma isto em passos que preenche, com a lei explicada ao lado de cada um. Abra um passo para ver o seu ecrã, preenchido para uma empresa fictícia.
O percurso em si está em alemão e em inglês.
Business Continuity
Write the business continuity plan
How you keep working when something fails, and who decides then.
Business Continuity
Record your backups
How often you back up, and when a restore last worked.
Supply Chain Security
Record what you have agreed with your suppliers
For each supplier: what does the contract say about security?
Tem de tratar da NIS2?
Acompanhamos passo a passo. Preenche, nós explicamos cada ponto em palavras simples e, no fim, a direção assina.
