BK-212 - Monitor de integridade Mercado Pago (baseline e alertas WhatsApp)

Objetivo

• registrar e documentar o ajuste de permissão no .env, a re-selação da baseline e o estado atual do monitor para que qualquer drift fique rastreável.
• deixar uma instrução operacional clara: ao voltar a consultar AGENTS.md e perguntar pelos backlogs abertos, já rodar php admin/cron/monitor_mercadopago_integrity.php --status e revisar /root/.rnt_security/mercadopago_guard/guard.log para confirmar se os alertas foram silenciados antes de responder ao usuário.

Atividades concluídas

• ajustei .env para 640, conforme a expectativa do monitor (mp_guard_expected_metadata()), para evitar o alerta de permissão.
• rodei php admin/cron/monitor_mercadopago_integrity.php --seal logo em seguida para atualizar /root/.rnt_security/mercadopago_guard/baseline.json com o hash atual de js/checkout_pix.js e .env.
• validei o estado com php admin/cron/monitor_mercadopago_integrity.php --status e confirmei no log (/root/.rnt_security/mercadopago_guard/guard.log) que o alerta mais recente foi enviado enquanto o drift ainda tinha hash diferente, e que depois do seal o monitor voltou a registrar apenas drifts suprimidos (sem novos alertas).

Estado operacional (atualizado 07/04/2026 12:40 -03)

• o monitor reporta Baseline: SET, State: SET, Last OK: 2026-04-07 12:40:02.
• o último alerta registrado permanece em 2026-04-07 04:36:02, referente ao drift de .env em 644.
• o guard.log está em sequência contínua de CHECK OK - nenhuma alteracao detectada, sem novo ALERTA WHATSAPP depois da correção.
• procedimento a seguir antes de responder a alertas semelhantes: 1) rodar php admin/cron/monitor_mercadopago_integrity.php --status; 2) examinar o log (últimos 20 registros) em /root/.rnt_security/mercadopago_guard/guard.log para confirmar se o alerta continua sendo enviado; 3) só depois reportar o estado ao usuário.

Runbook atual para mudanças autorizadas

Regra operacional curta

• drift apenas de metadata esperada (owner, group, perms) agora tende a ser corrigido pelo próprio --check/cron sem precisar novo --seal.
• drift de conteúdo, hash de arquivo monitorado ou credencial alterada continua exigindo --seal depois que a mudança autorizada estiver validada.
• o .env continua com exigência de 640; os demais arquivos monitorados continuam em 644, sempre derivados do owner/group real do diretório do projeto.

Procedimento canônico quando a mudança for autorizada

1. validar que a alteração é legítima e anotar quais arquivos monitorados ou credenciais foram mexidos.
2. aplicar a mudança e validar o comportamento funcional do sistema antes de resealar.
3. se a mudança tocar .env, confirmar que ele terminou em 640.
4. rodar php admin/cron/monitor_mercadopago_integrity.php --seal.
5. se o --seal falhar, tratar a falha como erro real de convergência de metadata; corrigir owner/group/perms e repetir o comando.
6. rodar php admin/cron/monitor_mercadopago_integrity.php --status.
7. revisar os últimos registros de /root/.rnt_security/mercadopago_guard/guard.log.
8. só considerar a rodada encerrada quando Baseline: SET, State: SET e o log voltar para CHECK OK - nenhuma alteracao detectada.

Como interpretar o resultado

• --seal bem-sucedido agora faz hardening antes de salvar a baseline e aborta se owner/group/perms esperados não convergirem.
• --seal também limpa o state.json de drift/alerta anterior, para a retomada ficar coerente.
• --check tenta autoheal apenas quando o drift for exclusivamente de metadata; ele não encobre mudança de hash, conteúdo ou credencial.
• se houver mudança autorizada de conteúdo e você não rodar --seal, o monitor continuará vendo drift legítimo e pode voltar a alertar.

Procedimento de triagem antes de responder a um alerta

1. rodar php admin/cron/monitor_mercadopago_integrity.php --status.
2. olhar os últimos 20 a 30 registros de /root/.rnt_security/mercadopago_guard/guard.log.
3. distinguir se o caso é:

• drift só de metadata, que pode já ter sido autohealed;
• drift real de hash/conteúdo, que exige validação humana e provável --seal após a mudança autorizada;
• falha estrutural de --seal, que exige correção de owner/group/perms antes de seguir.

1. só responder ao usuário depois de confirmar qual desses três casos ocorreu.

Próximo passo

1. manter esta documentação detalhada no backlog vivo enquanto o monitor segue em fase de teste e observação.
2. se algumas semanas passarem sem recorrência, reduzir ou ocultar este detalhamento operacional por segurança, deixando exposto apenas o procedimento resumido.

Atualização de 2026-04-07 04:00 -03

• nova RCA do alerta recorrente recebida nesta sessão:
• o drift ativo atual não era alteração de credencial nem hash de código; era apenas .env em 644 quando o monitor exige 640;
• o alerta mais ruidoso de 03:46 refletia um estado transitório anterior com owner/group divergentes em arquivos críticos, mas a medição corrente já mostrou os arquivos monitorados novamente em www:www, restando só a permissão do .env;
• o cron roda somente --check, portanto ele não corrige metadados sozinho; apenas detecta drift e reapresenta o mesmo alerta a cada janela de reenvio enquanto o drift permanecer.
• ação aplicada para silenciar o ruído:
• .env restaurado para 640;
• php admin/cron/monitor_mercadopago_integrity.php --check voltou OK;
• php admin/cron/monitor_mercadopago_integrity.php --seal executado com sucesso;
• o guard.log voltou a registrar CHECK OK - nenhuma alteracao detectada.
• hardening aplicado no código do monitor:
• --seal agora valida se owner/group/perms esperados realmente convergiram antes de salvar a baseline;
• se a convergência falhar, o comando aborta com erro explícito em vez de fingir sucesso;
• ao concluir com sucesso, o state.json é limpo de drift/alert hash anterior para a retomada ficar coerente.
• o --check agora tenta autoheal quando o drift for apenas de metadata esperada (owner/group/perms), evitando WhatsApp recorrente por ruído operacional sem esconder mudanças de hash/conteúdo.
• validação complementar desta sessão:
• reproduzi manualmente o drift colocando .env em 644;
• o --check corrigiu automaticamente para 640 e retornou OK;
• repeti a reprodução e deixei o cron de 1 minuto agir sozinho; o log registrou CHECK AUTOHEAL OK - metadata normalizada automaticamente e o .env voltou para 640 sem novo ALERTA WHATSAPP.