A Noite de 14 a 15 de Abril: Minha Resposta Pessoal à Desconexão do SMED

ghostjima 25 minutos atrás A Noite de 14 a 15 de Abril: Minha Resposta Pessoal à Desconexão do SMED Complexo 7 minutos 626 Rust * Finanças em TI Segurança da Informação * Visão geral Da caixa de areia Eu soube da desconexão não pelas notícias. De manhã, um conhecido de um pequeno banco me escreveu: “tudo caiu, os passaportes não estão sendo verificados, o online parou”. Naquele momento, eu estava terminando de escrever o tratamento de erros em smev4-rs , uma crate Rust para trabalhar com SMED 4. Coincidência, coincidência. As primeiras horas foram gastas para entender o que estava acontecendo. O Ministério da Digitalização disse que o transporte estava em ordem. As reclamações vieram tanto de quem estava no SMED 3 quanto de quem estava migrando para o SMED 4. Então, o problema não estava na versão do protocolo. Paralelamente, nos chats dos desenvolvedores começou o que eu chamaria de “depuração coletiva em voz alta”. As pessoas postavam os status de seus sistemas, testavam diferentes endpoints, comparavam códigos de resposta. Alguns tinham 403, outros 503 sem corpo, outros tinham solicitações simplesmente penduradas. Isso por si só foi informativo: tal dispersão com uma falha simultânea indicava que o problema não estava na camada de transporte. Quando ficou claro que o Ministério do Interior havia fechado o acesso aos seus dados como operador do GIS, algo estalou na minha cabeça: este é exatamente o cenário para o qual eu estava escrevendo uma clara diferenciação de tipos de erros nas últimas semanas. E não porque eu previa abril. É que quando você se integra com dados estatais por muito tempo, você entende que “SMED está fora do ar” e “o Ministério do Interior fechou o acesso” são situações completamente diferentes com consequências diferentes. O primeiro se conserta sozinho, o segundo não. Logo após esses eventos de abril, escrevi sobre o que especificamente está errado nas integrações típicas e como eu pensei sobre isso no processo de desenvolvimento da minha crate. Por que tudo parou, embora o transporte estivesse funcionando O SMED 4, em comparação com a terceira versão, fez uma coisa boa: introduziu um modelo centralizado de gerenciamento de acesso baseado em funções. Controle detalhado sobre quem e a quais dados tem acesso. Para segurança, isso é correto. Efeito colateral: uma ação administrativa do lado do proprietário dos dados leva ao fato de que todas as mais de 500 organizações conectadas perdem o acesso de forma síncrona. Não é preciso quebrar nada no transporte. Configuração na interface, e pronto. Este não é um bug do SMED 4, é uma consequência de sua arquitetura. E é preciso viver com isso ao projetar a integração. A situação legal sobre a qual poucas pessoas falam Enquanto os eventos se desenrolavam, reli a Regulamentação do Banco Central 444-P. O item 2.2 da regulamentação e a carta explicativa do Banco Central de dezembro de 2023 dizem diretamente: para verificar um passaporte em relação às informações do Ministério do Interior durante a identificação remota, existe apenas uma maneira legal - SMED. Simplesmente não existem outros sistemas abertos com o status legal necessário. ESIA é a identificação do usuário, não a verificação do documento. O site do Ministério do Interior é um serviço de referência, não é adequado para os fins da Lei Federal 115. Os agregadores comerciais não criam uma base legal suficiente. Ou seja, na ausência de SMED, o banco fisicamente não pode cumprir o requisito da lei e, ao mesmo tempo, não tem alternativa legal. Situação ruim. Em 20 de abril, alguns bancos receberam acesso de volta. Eram bancos que conseguiam confirmar a presença de um certificado FSTEC de acordo com os novos requisitos. Em 1º de março de 2026, entrou em vigor a Ordem FSTEC nº 117. Ela expandiu os requisitos de proteção para sistemas que recebem dados de sistemas de informação estatais. Como a base de dados do Ministério do Interior é um sistema de informação estatal, os bancos conectados a ela também devem cumprir os requisitos. O Ministério do Interior usou isso como base para a desconexão. O que especificamente quebra nas integrações Conversei com várias equipes após o incidente. O problema comum é um: qualquer erro de um serviço externo é compactado em um único status. Algo deu errado, escrevemos no log “smev error”, seguimos em frente. Para relatórios regulatórios, isso é uma catástrofe. Porque “403 do Ministério do Interior como resultado de uma decisão administrativa” e “503 porque o agente está sobrecarregado” são eventos fundamentalmente diferentes. Eles têm um caminho de degradação diferente, um significado diferente para conformidade, uma linha diferente no registro de auditoria. Uma das equipes com quem conversei descobriu isso em 15 de abril: eles tiveram um “erro de serviço”, começaram a reiniciar os agentes, incomodar o suporte de seu fornecedor e só depois de algumas horas descobriram que o problema não era deles. Durante todo esse tempo, havia a mesma linha ilegível nos logs. Em smev4-rs , eu resolvi isso por meio de um tipo separado. O classificador aceita o status HTTP e a presença do cabeçalho Retry-After e retorna um enum: let reason = UnavailableReason::from_http_status(403, false); // ProviderAccessDenied — o proprietário fechou o acesso

let reason = UnavailableReason::from_http_status(503, true); // QuotaOrRateLimit — 503 com Retry-After = limite, e não degradação

let reason = UnavailableReason::from_http_status(503, false); // ServiceDegraded — simplesmente ruim No tratamento de erros do cliente, isso se parece com: match xml { Ok(body) => { /* tudo bem */ } Err(SmevError::Unavailable { reason }) => { // aqui caem 403, 423, 429, 503 // reason contém a classe de erro e o status log_incident("provider_unavailable", &reason); route_to_fallback(); } Err(SmevError::Timeout) => { log_incident("transport_timeout", "polling_limit_reached"); route_to_manual_queue(); } Err(SmevError::Payload(msg)) if msg.contains("not found or expired") => { // o ticket expirou — este não é um problema de disponibilidade // este é o gerenciamento de sessão no lado do código de chamada log_incident("ticket_expired", &msg); } Err(e) => { log_incident("unexpected_error", &e.to_string()); } } 404 é tratado separadamente: um ticket expirado é retornado como SmevError::Payload , porque esta é outra classe de problema. SMED 3 e SMED 4 retornam dados diferentes Este é um detalhe sobre o qual eu quase não vi uma explicação normal em lugar nenhum. SMED 3, ao verificar um passaporte (tipo de informação MVDR23), retorna três campos: status, código do motivo da invalidade, data a partir da qual o passaporte se tornou inválido. SMED 4 (vitrine rfp_check) retorna apenas o status. Isso significa que a organização que migrou para SMED 4 e desativou o SMED 3 perdeu dois campos. E os campos são significativos: “o passaporte é inválido porque um novo foi emitido” e “o passaporte é inválido porque está na base de dados de roubados”. Estas são situações muito diferentes com ações diferentes. Sem o código do motivo, a diferença é indistinguível. Eu pensei sobre isso ao projetar o roteador. Ainda não existe no smev4-rs (planejado para o futuro), mas arquitetonicamente é correto manter ambas as versões sob uma única interface: SMED 4 como o canal principal, SMED 3 para dados estendidos conforme necessário. Auditoria de tentativas em caso de falha Uma coisa que o dia 15 de abril revelou com força: muitas organizações não têm um registro de que a tentativa de verificação foi sequer feita. E a Lei Federal 115 não se interessa apenas pelo resultado bem-sucedido. Ao verificar, você precisa provar que o banco tentou cumprir o requisito. Mesmo que o serviço externo não tenha respondido. Isso significa: idealmente, você deve ter um log com um carimbo de data/hora de cada tentativa, um hash da solicitação e o motivo da falha. Não “o sistema caiu às 2:15”, mas “tentativa de verificação às 2:15:43.219, status ProviderAccessDenied, redirecionado para a fila manual”. A diferença é que o segundo é uma prova, o primeiro é apenas um log. Em smev4-rs , existem duas opções com auditoria. Simples, para uma tentativa: let fingerprint = SmevClient::request_fingerprint(canonical_request_bytes);

let (result, audit) = client .poll_response_audited(ticket, fingerprint) .await;

// audit é criado independentemente do resultado // com Unavailable — marcador SMEV_UNAVAILABLE // com Timeout — SMEV_TIMEOUT // em caso de sucesso — hash da resposta

persist_audit_entry(&audit).await?; E para uma série de tentativas em uma sessão, com uma cadeia contínua: let nonce = SmevClient::request_fingerprint(canonical_request_bytes);

let (result1, audit1) = client .poll_response_chained(ticket1, nonce, None) .await;

// o segundo se refere ao primeiro let (result2, audit2) = client .poll_response_chained(ticket2, nonce, Some(&audit1)) .await; Cada registro contém o hash do anterior. Inserir ou remover um registro sem violar a cadeia é impossível. Isso é especialmente importante quando você leva artefatos para verificação. O hash da solicitação é calculado a partir de uma representação canônica sem dados pessoais em sua forma explícita. Isso não é apenas privacy-by-design, mas também prático: armazenar a prova de exatamente o que foi solicitado, sem armazenar os próprios dados. Sobre desduplicação e dinheiro A Resolução do Governo nº 1687 introduziu a tarifação do SMED em novembro de 2025. Além disso, o Ministério do Interior quer uma tarifa separada para seus dados. Os valores específicos ainda estão em processo regulatório, mas a direção é clara. Solicitações duplicadas com qualquer tarifação resultam em custos adicionais. request_fingerprint na crate dá um hash BLAKE3 determinístico dos bytes de entrada. A mesma solicitação, o mesmo hash. Pode ser usado como uma chave de cache: let key = SmevClient::request_fingerprint(canonical_request_bytes);

if let Some(cached) = cache.get(&key, ttl_secs) { return Ok(cached); }

let result = client .poll_response_with_config(ticket, config) .await?;

cache.set(&key, &result, ttl_secs); A lógica é simples: uma solicitação real na verificação inicial, sessões repetidas são retiradas do cache. Isso se pagará rapidamente quando uma tarifa aparecer. Sobre rastreamento O cliente registra através do traço padrão tracing . Se você já tem tracing-subscriber , funciona simplesmente: DEBUG smev4_rs: starting SMEV queue polling ticket="tkt_abc" max_attempts=12 WARN smev4_rs: SMEV provider unavailable ticket="tkt_abc" status=503 reason=ServiceDegraded DEBUG smev4_rs: SMEV queue response ready ticket="tkt_xyz" attempts=3 aviso para indisponibilidade e timeouts. Esses eventos devem acionar alertas, e não apenas cair no fluxo padrão de logs de depuração. Separatamente sobre a certificação FSTEC Após 20 de abril, ficou claro: o certificado FSTEC deixou de ser apenas um pedaço de papel para o serviço de segurança. Tornou-se uma condição para o acesso a uma função crítica. A Ordem nº 117 mudou o modelo: agora este não é um projeto único, mas um processo contínuo com o recálculo de indicadores e prazos rígidos para a eliminação de vulnerabilidades (críticas em 24 horas). Para as equipes que estão acostumadas a atualizar o certificado a cada poucos anos, este é um ritmo operacional diferente. Os bancos que tinham um certificado atualizado receberam acesso de volta em 20 de abril. O restante continua parado. No final A falha de acesso em abril de 2026 não é um evento único. Em 2021, o Ministério do Interior anunciou o fechamento do arquivo offline de passaportes. Em 2023, fechou. Em 2026, fechou temporariamente o acesso SMED. O padrão é o mesmo: a dependência de processos críticos do circuito estatal, que não tem obrigações contratuais de garantir a continuidade para os consumidores. Este é um fato arquitetônico que precisa ser levado em consideração ao projetar. Crate smev4-rs com a implementação sobre a qual escrevi, é publicado em crates.io sob Apache-2.0: smev4-rs . O código-fonte está disponível no GitHub . Se alguém estiver trabalhando com SMED em Rust, dê uma olhada, ficarei feliz com o feedback. Fontes Bancos perderam o acesso ao serviço de verificação de passaportes do Ministério do Interior · Kommersant, 16 de abril de 2026 Bancos perderam o acesso aos dados de passaporte dos clientes através da base de dados do Ministério do Interior · RBC, 16 de abril de 2026 Os maiores bancos recuperaram o acesso à verificação de passaportes de clientes · Kommersant, 20 de abril de 2026 Documentos voltaram à circulação · Kommersant, 20 de abril de 2026 Mensagem de informação FSTEC nº 240/22/1492 · GARANT Ordem FSTEC nº 117 Resolução do Governo nº 1687 444-P e SMED · ConsultorPlus Descrição do serviço SMED 3+4 · Quorum Tags: smed fstec bancos fintech arquitetura 115-fz segurança da informação rust Hubs: Rust Finanças em TI Segurança da Informação 0 0 0 1 Karma @ghostjima Usuário Assinar Habr Carreira Fluxo de Back-end disponível 24 horas por dia, 7 dias por semana, graças ao apoio dos amigos do Habr Habr Cursos para desenvolvedores back-end PUBLICIDADE Prática, Hexlet, SkyPro, cursos do autor — reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo de back-end Comentar Melhores do dia Semelhante Mostrar os melhores de todos os tempos