Norma
29/10/2020

Instrução Normativa BCB N° 37

Divulga o Manual de Segurança do Open Banking com requisitos mínimos para proteção, detecção e reação em sistemas e APIs.

Resumo

🚨 ATENÇÃO: Esta norma foi REVOGADA pela Instrução Normativa BCB nº 99, de 2021. As informações abaixo são de caráter histórico.

Esta instrução divulgou a primeira versão (1.0) do Manual de Segurança do Open Banking, definindo os requisitos técnicos iniciais para as instituições participantes.

🛡️ Proteção de Dados Públicos: Exigia acesso exclusivo via APIs, uso de criptografia com TLS 1.2 ou superior, segregação de redes e controles de tráfego como firewalls.

🔍 Detecção e Auditoria: Obrigava a manutenção de trilhas de auditoria detalhadas (logs de acesso), sincronização de relógios com fontes confiáveis (NTP) e aplicação de configurações seguras (hardening).

🚦 Reação a Incidentes: Permitida a implementação de bloqueios de acesso às APIs para conter riscos ou ataques cibernéticos em andamento.

📇 Diretório de Participantes: Exigia o cadastro de contatos para incidentes, autenticação de dois fatores (2FA) para acesso restrito e registro de todos os acessos ao diretório.

Atenção: Esta Instrução Normativa foi revogada pela Instrução Normativa BCB nº 99, de 14 de abril de 2021. As informações a seguir possuem caráter histórico e contextual sobre a primeira versão do Manual de Segurança do Open Banking.

Esta norma divulgou a versão 1.0 do Manual de Segurança do Open Banking, estabelecendo os requisitos técnicos mínimos e obrigatórios para as instituições participantes. O manual foi estruturado com base nos pilares de governança, proteção, detecção e reação a incidentes.

Para a fase inicial do Open Banking, que envolvia o compartilhamento de dados públicos (como canais de atendimento e informações de produtos), o manual determinava medidas de segurança para garantir a integridade, qualidade e disponibilidade das informações. Os principais requisitos eram:

Proteção:

• O acesso aos dados deveria ocorrer exclusivamente por meio de APIs.

• Os sistemas e APIs deveriam ser mantidos em redes internas logicamente segregadas.

• Implementação de controles de tráfego (como firewalls e Access Control Lists - ACLs) para permitir apenas a comunicação necessária.

• Criptografia obrigatória na comunicação com as APIs, utilizando o protocolo TLS na versão 1.2 ou superior e cifras que garantissem "perfect forward secrecy" (PFS).

• As funcionalidades "TLS Session Resumption" e "TLS Renegotiation" deveriam ser desabilitadas.

• Repositórios de dados não poderiam ser expostos diretamente à internet.

Detecção:

• Manutenção de trilhas de auditoria detalhadas, registrando no mínimo: endereço IP de origem, porta de comunicação, data, hora, sistema, usuário (se aplicável), objeto e resultado (sucesso ou falha) da ação.

• Sincronização dos relógios de todos os sistemas e APIs com uma fonte de tempo confiável, utilizando o protocolo NTP (Network Time Protocol).

• Implementação de sistemas com padrões de configuração segura (hardening).

• Categorização e priorização de vulnerabilidades encontradas de acordo com uma classificação de risco.

Reação:

• As instituições transmissoras de dados tinham a faculdade de implementar bloqueios de acesso às suas APIs para tratar riscos ou incidentes cibernéticos, de acordo com sua Política de Segurança Cibernética.

Diretório de Participantes:

• As instituições deveriam cadastrar no diretório os contatos de seus representantes para tratamento de incidentes (e-mail, chaves PGP, etc.).

• O acesso a áreas restritas do diretório exigia autenticação com, no mínimo, dois fatores.

• Todos os acessos ao diretório deveriam ser registrados em trilhas de auditoria, contendo data e hora (em UTC), IP de origem, porta, URI acessada, método HTTP e status de retorno.