Compliance e Infraestrutura

• Política de RTO/RPO
• Definição de Separação de Dados Multi-tenant
• Acordo de Nível de Serviço (SLA)
• Política de controle de acesso
• Política de Segurança da Informação e da Prestação de Serviços
• Gestão e Histórico de Releases
• Plano de Recuperação de Desastres (Disaster Recovery Plan)
• Declaração de Governança de Fornecedores
• Certificações e relatórios independentes
• Declaração Técnica de Infraestrutura AWS
• Comunicado Técnico e Guia de Liberação de Firewall / Whitelist
• Política e Procedimento de Expurgo e Eliminação de Dados (DATA PURGE POLICY)

Política de RTO/RPO

Código do Documento: POL-RTO-RPO-001	Versão: 1.0
Data de Aprovação: Janeiro de 2026	Classificação de Informação: Uso Interno / Clientes
Área Gestora: Segurança da Informação / TI	Aplica-se a: Todos os Serviços, Bancos de Dados e Aplicações

1. Resumo da Infraestrutura

A plataforma SISMETRO utiliza atualmente o motor de banco de dados MySQL 8.4 hospedado na Amazon Web Services (AWS) na região São Paulo (sa-east-1).
A arquitetura foi desenhada para garantir que os dados estejam sempre disponíveis e protegidos contra falhas de hardware ou desastres geográficos.

2. Objetivos de Recuperação (Métricas Principais)

Métrica	Objetivo	Descrição
RTO (Tempo de Recuperação)	1 Hora	Tempo máximo para o sistema voltar a operar após uma falha crítica na instância principal.
RPO (Ponto de Recuperação)	Próximo a Zero	Quantidade máxima de dados que podem ser perdidos. Graças à replicação síncrona, a perda é virtualmente nula.

3. Estratégias de Resiliência Aplicadas

A. Alta Disponibilidade (Multi-AZ)
Diferente de servidores convencionais, o nosso banco de dados opera em modo Multi-AZ (Multi-Availability Zones).

• Replicação Síncrona: Cada dado gravado no banco principal (sa-east-1a) é replicado instantaneamente para uma instância de reserva (standby) em uma zona isolada (sa-east-1c).

• Failover Automático: Se a zona principal sofrer uma interrupção, o AWS RDS detecta a falha e redireciona todo o tráfego para a reserva automaticamente em cerca de 60 segundos, sem necessidade de intervenção manual ou alteração de configurações pelos usuários.

B. Política de Backup e Retenção
Utilizamos o AWS Backup para garantir camadas extras de proteção:

• Snapshots Diários e Horários: Mantemos um histórico rigoroso de snapshots (capturas de estado) criados automaticamente a cada hora.

• Point-in-Time Recovery (PITR): Podemos restaurar o banco de dados para qualquer segundo específico dos últimos 7 dias. Isso protege o cliente não apenas contra falhas técnicas, mas também contra erros humanos (como exclusões acidentais de dados).

C. Performance e Segurança
Armazenamento gp3: Utilizamos volumes SSD de última geração com IOPS provisionados, garantindo que a recuperação e o processamento de dados ocorram na velocidade máxima permitida pela tecnologia atual.

Criptografia: Todos os dados, tanto em repouso quanto nos backups, são criptografados usando chaves AES-256 (AWS KMS).

Definição de Separação de Dados Multi-tenant

Código do Documento: DEF-SEP-MUL-TEN-001	Versão: 1.0
Data de Aprovação: Janeiro de 2026	Classificação de Informação: Uso Interno / Clientes
Área Gestora: Segurança da Informação / TI	Aplica-se a: Todos os Serviços, Bancos de Dados e Aplicações

A arquitetura de isolamento por chaves de identificação (também conhecida como Logical Multi-tenancy ou Row-Level Isolation) é uma estratégia robusta e eficiente para sistemas SaaS que utilizam uma base de dados compartilhada.

1. O Conceito de Isolamento Lógico

Diferente de modelos onde cada cliente tem seu próprio banco de dados (o que elevaria drasticamente o custo de infraestrutura no AWS RDS), o SISMETRO utiliza um Banco de Dados Consolidado.

• A Chave de Identificação: Cada tabela que contém dados sensíveis ou de clientes possui uma coluna identificadora (tenant_id).

• Filtro em Camada de Aplicação: O isolamento ocorre no nível do código (Aplicação). Toda e qualquer consulta ao banco de dados é automaticamente "carimbada" com o ID do cliente logado (tenant_id), garantindo que um Cliente A jamais visualize registros do Cliente B, mesmo estando na mesma tabela física.

2. Vantagens Estratégicas para o Cliente

Ao descrever isso para um fornecedor ou auditoria, os pontos de destaque são:

• Segurança de Dados: O isolamento é garantido por políticas globais no código, o que minimiza o erro humano de esquecer um filtro em uma consulta específica.

• Performance Consistente: Utilizando de instâncias potentes, replicadas e armazenamento extensível, o ganho de escala beneficia todos os clientes. O banco de dados consegue gerenciar índices globais de forma muito mais performática do que centenas de pequenos bancos separados.

• Agilidade em Atualizações: Quando é atualizada a estrutura do banco (migrações), todos os clientes recebem as melhorias de segurança e performance simultaneamente.

3. RELATÓRIO TÉCNICO AWS

Documento Técnico de Isolamento de Dados entre Clientes/Tenants Emitido por: Amazon Q — Conta AWS Sismetro Região: São Paulo — sa-east-1 Data de emissão: 02 de setembro de 2026 Gerado via: Amazon Q Developer — Console AWS 1.  Visão Geral da Arquitetura de Banco de Dados O banco de dados principal do Sismetro é gerenciado pelo serviço Amazon RDS (Relational Database Service), utilizando o engine MySQL 8.4.10, hospedado exclusivamente na região São Paulo (sa-east-1) da Amazon Web Services. Atributo                            Valor Serviço Amazon RDS Engine MySQL 8.4.10 Instância Principal           sismetro  Instância de Leitura         sismetro-read  Alta Disponibilidade       Multi-AZ (sa-east-1a / sa-east-1c) Região                             sa-east-1 (São Paulo, Brasil)   2.  Modelo de Isolamento entre Tenants O Sismetro adota o modelo de banco de dados compartilhado com isolamento lógico por schema/tenant, onde todos os clientes residem na mesma instância RDS, porém com separação lógica garantida pela aplicação. 2.1  Isolamento Lógico — Nível de Aplicação Cada cliente/tenant possui um identificador único na camada de aplicação As queries são sempre filtradas pelo tenant_id, garantindo que um cliente nunca acesse dados de outro A camada de aplicação (ECS/Fargate) é responsável por aplicar o escopo correto em todas as operações de leitura e escrita 2.2  Isolamento de Rede — Nível de Infraestrutura AWS O banco de dados opera dentro de uma VPC (Virtual Private Cloud) dedicada, com as seguintes camadas de proteção de rede: 2.3  Isolamento de Acesso — Credenciais e Autenticação  O acesso ao banco de dados é realizado exclusivamente pelos serviços internos da plataforma (ECS/Fargate) Cada serviço de aplicação utiliza credenciais próprias e controladas Proteção contra exclusão acidental: Deletion Protection habilitado 3.  Proteção e Segurança dos Dados 3.1  Criptografia Mecanismo                                              Status Criptografia em repouso (at rest) ✅ Habilitada — AWS KMS Criptografia em trânsito (in transit) ✅ TLS — Certificado rds-ca- (válido até 07/2027) 3.2  Backup e Recuperação Atributo                                   Configuração Retenção de backups 35 dias Janela de backup 23:12–23:42 UTC Backup target Região sa-east-1 3.3  Monitoramento e Auditoria Recurso                             Configuração Performance Insights ✅ Habilitado Enhanced Monitoring ✅ Habilitado 4.  Alta Disponibilidade e Resiliência Auto Minor Version Upgrade          Habilitado — patches de segurança aplicados automaticamente 5.  Responsabilidade Compartilhada AWS O modelo de segurança do Sismetro segue o Modelo de Responsabilidade Compartilhada da AWS: Responsabilidade                                                      Parte Segurança física dos datacenters AWS Infraestrutura de hardware e rede AWS Disponibilidade e durabilidade do RDS AWS Criptografia da infraestrutura subjacente AWS Configuração de VPC, Security Groups e acesso Sismetro Isolamento lógico de dados entre tenants Sismetro Gestão de credenciais e políticas de acesso Sismetro Conformidade com LGPD e regulamentações   Sismetro   Referência: Modelo de Responsabilidade Compartilhada AWS 📌 Nota de autenticidade: Este documento foi gerado automaticamente pelo Amazon Q Developer com leitura direta da conta AWS Sismetro ( sa-east-1 ), em 02/09/2026, refletindo o estado real da infraestrutura no momento da consulta. Os dados são provenientes das APIs oficiais da AWS e podem ser verificados no Console RDS.

Acordo de Nível de Serviço (SLA)

Código do Documento: DEF-SLA-001	Versão: 1.0
Data de Aprovação: Janeiro de 2026	Classificação de Informação: Uso Interno / Clientes
Área Gestora: Segurança da Informação / TI	Aplica-se a: Plataforma SISMETRO (APIs, Web e Arquitetura AWS)

1. Visão Geral e Objetivos

Este documento define os níveis formais de serviço, disponibilidade, metas de recuperação e responsabilidades de suporte técnico para a infraestrutura e ecossistema de software da plataforma SISMETRO.

O objetivo é garantir a continuidade do negócio, prever mitigação de riscos operacionais e estabelecer clareza sobre métricas chave de disponibilidade (Uptime), Tempo de Recuperação (RTO) e Ponto de Recuperação (RPO).

2. Métricas Globais de Disponibilidade (Uptime)

A infraestrutura core do SISMETRO opera em alta disponibilidade na nuvem Amazon Web Services (AWS). O SLA global de disponibilidade da aplicação é estruturado da seguinte forma:

Nota: Janelas de manutenção programada precedidas de aviso prévio não contabilizam como indisponibilidade não planejada.

3. Continuidades e Tolerância a Desastres (RPO e RTO)

Os procedimentos de tolerância a falhas e planos de mitigação e contingência são apoiados por snapshots automáticos e rotinas do AWS Backup e replicação de dados no MySQL / RDS.

4. Classificação de Incidentes e Matriz de Resposta

Os chamados e incidentes reportados no SISMETRO são categorizados pelo seu nível de severidade e impacto no negócio:

5. Procedimentos de Manutenção e Janelas Programadas

• Manutenções Preventivas / Deployments: Realizados preferencialmente fora do horário de pico comercial (22h às 05h - BRT).

• Notificação Prévia: Comunicados com pelo menos 48 horas de antecedência aos gestores técnicos em caso de impactos previstos superior a 15 minutos.

• Deploy Contínuo (CI/CD): Atualizações transparentes via pipeline GitHub / ECS sem downtime para correções pontuais.

6. Exclusões de Cobertura do SLA

O presente SLA não se aplica a indisponibilidades decorrentes de:

1. Interrupção em provedores locais de internet do cliente ou falhas de hardware e rede local das unidades de atendimento.

2. Integrações com APIs de terceiros que estejam inoperantes fora do controle do SISMETRO.

3. Ações fraudulentas, mau uso deliberado do sistema ou violações de segurança originadas por credenciais comprometidas do próprio cliente.

4. Eventos de Força Maior ou desastres naturais que afetem regiões inteiras de datacenters da AWS.

Política de controle de acesso

1. OBJETIVO

Esta Política estabelece as diretrizes e padrões necessários para garantir a proteção, integridade, confidencialidade e disponibilidade dos ativos de informação da organização. Seu propósito principal é assegurar que o acesso a dados, sistemas, redes e infraestruturas seja concedido estritamente a usuários e serviços devidamente autorizados, prevenindo acessos indevidos, incidentes de segurança e vazamentos de dados.

2. ALCANCE E APLICAÇÃO

As diretrizes contidas neste documento aplicam-se obrigatoriamente a:

• Todos os colaboradores diretos, estagiários, diretores e prestadores de serviços terceirizados;

• Todas as plataformas, sistemas corporativos, bancos de dados, redes e infraestruturas em nuvem ou locais (*on-premises*);

• Serviços e integrações automatizadas (*APIs*, *jobs*, contas de serviço).

3. PRINCÍPIOS FUNDAMENTAIS

O controle de acesso corporativo deve seguir rigorosamente os três princípios abaixo:

4. DIRETRIZES DE AUTENTICAÇÃO E IDENTIDADE

4.1. Credenciais Individuais e Intransferíveis

É expressamente proibido o compartilhamento de logins, senhas, chaves de API ou quaisquer outras credenciais de acesso entre colaboradores. Toda conta deve estar associada a uma identidade individual rastreável.

4.2. Autenticação Multi-Fator (MFA)

A utilização de Autenticação Multi-Fator (MFA) é obrigatória para todos os acessos a sistemas corporativos, plataformas em nuvem, ambientes de desenvolvimento e produção, sem exceções.

4.3. Requisitos de Senhas e Chaves

• As senhas corporativas devem atender aos requisitos mínimos de complexidade e tamanho estabelecidos pela equipe de TI;

• Chaves de acesso a ambientes de produção e APIs devem ser armazenadas em cofres de senhas corporativos e rotacionadas periodicamente.

5. GESTÃO DO CICLO DE VIDA DE ACESSOS

5.1. Concessão de Acesso

A liberação de acessos depende obrigatoriamente de solicitação formal realizada via canal oficial de TI, acompanhada da justificativa operacional e da aprovação expressa da liderança imediata e do responsável pelo recurso/sistema.

5.2. Movimentação e Desligamento

• Mudança de Cargo/Função: A área de Recursos Humanos deve notificar a TI sobre transferências internas para que os acessos anteriores sejam revogados e novos perfis ajustados.

• Desligamento: Em caso de encerramento do vínculo contratual, o bloqueio das contas e revogação das permissões devem ser executados imediatamente após a notificação oficial.

6. MONITORAMENTO, RASTREABILIDADE E AUDITORIA

Todos os sistemas, bancos de dados, aplicações e ativos de rede devem gerar registros de auditoria (*logs*) contendo:

• Identificação do usuário ou serviço;

• Data e hora exata do evento (*timestamp*);

• Tipo de tentativa de acesso (sucesso ou falha);

• Ação executada ou alteração efetuada em privilégios.

7. RESPONSABILIDADES E PENALIDADES

O descumprimento das normas estabelecidas nesta Política de Controle de Acesso sujeita o infrator às sanções disciplinares previstas em contrato de trabalho e no regimento interno da empresa, além de eventuais penalidades cíveis e criminais aplicáveis nos termos da legislação vigente.

Política de Segurança da Informação e da Prestação de Serviços

1. OBJETIVO

Esta Política de Segurança da Informação (PSI) visa estabelecer os requisitos, diretrizes e padrões de segurança aplicáveis à prestação de serviços, manutenção de sistemas e gestão de infraestrutura de tecnologia. O objetivo principal é garantir a proteção contra acessos não autorizados, indisponibilidade, alterações indevidas ou vazamentos de dados, assegurando a conformidade com as melhores práticas do mercado e exigências regulatórias (incluindo LGPD).

2. ALCANCE E ESCOPO

As diretrizes estipuladas nesta norma aplicam-se integralmente a:

• Todos os serviços prestados, mantidos ou operados pela organização;

• Ambientes de produção, homologação e desenvolvimento (nuvem e on-premises);

• Bancos de dados, APIs, micros serviços, integrações e pipelines de implantação;

• Colaboradores, terceiros, fornecedores e prestadores de serviços que tenham acesso aos ambientes operacionais.

3. PILARES DA SEGURANÇA DA INFORMAÇÃO

A prestação e operação dos serviços são regidas por quatro pilares essenciais:

4. DIRETRIZES DE SEGURANÇA APLICÁVEIS AO SERVIÇO

4.1. Controle de Acesso e Gestão de Identidade

• Autenticação Forte: Obrigatoriedade do uso de Autenticação Multi-Fator (MFA) para todas as conexões administrativas e acesso aos ambientes de infraestrutura.

• Princípio do Menor Privilégio: Acesso a servidores, bancos de dados e ferramentas concedido estritamente com base na necessidade funcional (Need-to-Know).

• Contas de Serviço: Credenciais de integrações, APIs e processos automatizados devem utilizar chaves temporárias ou ser mantidas em cofres de segredos (*secret managers*) protegidos.

4.2. Segurança em Redes e Infraestrutura

• Segregação de Ambientes: Isolação lógica rigorosa entre ambientes de Desenvolvimento, Testes/Homologação e Produção.

• Proteção de Perímetro: Uso de firewalls de aplicação (WAF), restrições de redes privadas (VPC/Subnets) e proteção contra ataques de negação de serviço (DDoS).

• Criptografia: Criptografia obrigatória de dados em trânsito (HTTPS/TLS 1.2+) e de dados em repouso (*Data at Rest*) utilizando algoritmos consolidados.

4.3. Desenvolvimento Seguro e Gestão de Mudanças

• Práticas de DevSecOps: Análise estática de código (SAST) e varreduras de vulnerabilidades automatizadas durante a esteira de build e deploy.

• Gestão de Dependências: Revisão e atualização contínua de bibliotecas e pacotes para prevenir vulnerabilidades conhecidas (CVEs).

• Versionamento e Revisão de Código: Nenhuma alteração pode ir para produção sem revisão por pares (*Peer Review*) e validação dos testes automatizados.

5. CONTINUIDADE DE NEGÓCIOS E BACKUP

Para assegurar a resiliência dos serviços, a infraestrutura deve seguir as diretrizes de backup e recuperação estipuladas:

• Rotina de Backups: Realização de backups diários incrementais e snapshots periódicos automatizados.

• Testes de Restauração: Execução regular de simulações de restauração para validar a integridade das cópias de segurança.

• Planos de RPO e RTO: Manutenção de metas de RPO (Objetivo de Ponto de Recuperação) e RTO (Objetivo de Tempo de Recuperação) compatíveis com o Acordo de Nível de Serviço (SLA) estabelecido.

6. GESTÃO DE INCIDENTES DE SEGURANÇA

Em caso de suspeita ou confirmação de incidente de segurança afetando o serviço:

• A equipe técnica deve conter imediatamente a ameaça, isolando os componentes afetados;

• Os registros e evidências devem ser preservados para análise forense e causa-raiz;

• Notificação formal aos gestores e partes interessadas conforme prazos legais e regimentais estabelecidos.

7. CONFORMIDADE E AUDITORIA

Esta política é revisada periodicamente para assegurar sua eficácia e adequação aos avanços tecnológicos e legais. O descumprimento destas diretrizes pode acarretar sanções contratuais e disciplinares cabíveis.

Gestão e Histórico de Releases

Código do Documento: GES-HTR-REL-001	Versão: 1.0
Data de Emissão: Janeiro de 2026	Classificação de Informação: Uso Interno / Clientes / Auditoria
Área Responsável: Engenharia de Software / DevOps	Aplica-se a: Todos os Serviços e Microsserviços

1. OBJETIVO

Esta declaração formal visa comprovar a existência e a aplicação contínua de processos padronizados de gestão de releases, controle de versão e auditoria de alterações no código-fonte dos sistemas e serviços mantidos pela organização.

2. ESTRUTURA E REPOSITÓRIO DE CÓDIGO (GITHUB)

A gestão de versões de todos os serviços da organização é centralizada no provedor GitHub, utilizando repositórios privados e seguros. O controle de mudanças e histórico de lançamentos é rastreado de forma automatizada atrelado à esteira de integração e entrega contínuas (CI/CD).

2.1. Modelo de Ramificação (Branching Strategy)

Os repositórios seguem um fluxo de trabalho estruturado, com ramificações (branches) específicas destinadas à segregação de ambientes e garantia de qualidade:

Branch / Ramo	Ambiente Associado	Finalidade e Critérios de Aprovação
main / master / prod	Produção (Prod)	Código em execução operacional. Alterações entram via Pull Requests (PRs) aprovados após validação em homologação e testes.
staging / stage	Homologação (Stage)	Ambiente pré-produção utilizado para validação final e aprovação do time de produto/cliente.
qa / testing	Qualidade / Testes (QA)	Ambiente dedicado para serviços aplicáveis, onde são executados testes de regressão e garantia de qualidade antes do merge para staging.
feature/* ou fix/*	Desenvolvimento Local	Ramos isolados para implementação de melhorias ou correções específicas, originando Pull Requests para revisão de código.

3. MEIOS DE REGISTRO E RASTREABILIDADE DE HISTÓRICO

O histórico completo de revisões, modificações relevantes e pacotes liberados em produção é mantido através das seguintes ferramentas nativas do GitHub:

• GitHub Releases & Tags: As versões oficiais enviadas para produção são marcadas por meio de Tags e consolidadas na aba Releases do repositório, adotando versionamento semântico (ex.: v2.5.0).

• Commits Auditáveis: Cada commit contém autor, data, hora e mensagem descritiva da alteração realizada no sistema.

• Rastreabilidade por Pull Requests (PRs): Todo envio de código para as branches de qa, stage e prod exige abertura de PR, vinculando a alteração à tarefa correspondente.

• GitHub Actions / CI-CD Logs: Cada alteração aprovada aciona pipelines automatizadas cujos históricos de compilação, testes e deploy permanecem salvos e auditáveis.

Plano de Recuperação de Desastres (Disaster Recovery Plan)

Código do Documento: PLN-DST-RCV-025	Versão: 1.0
Data de Emissão: Janeiro de 2026	Classificação de Informação: Uso Interno / Clientes / Auditoria
Área Responsável: Infraestrutura, Cloud & DevOps	Aplica-se a: Todos os Serviços, Bancos de Dados e Aplicações

1. OBJETIVO

Este documento estabelece a política, os procedimentos e as diretrizes técnicas de Recuperação de Desastres (Disaster Recovery) aplicáveis aos serviços prestados pela organização. Seu propósito é assegurar a restauração das operações em caso de indisponibilidades críticas, falhas catastróficas de infraestrutura, desastres naturais ou incidentes graves de segurança.

2. ESTRATÉGIA DE INFRAESTRUTURA EM NUVEM (AWS)

A arquitetura de hospedagem adota serviços gerenciados nativos da Amazon Web Services (AWS), projetada com redundância e alta disponibilidade por padrão:

• Computação (ECS / Fargate): Contêineres de aplicação implantados de forma distribuída em múltiplas Zonas de Disponibilidade (Multi-AZ), garantindo resiliência contra falhas em data centers individuais.

• Banco de Dados (Amazon RDS / MySQL): Utilização de instâncias Multi-AZ com replicação síncrona automática para um ambiente secundário e criação de snapshots periódicos gerenciados pelo AWS Backup.

• Entrega e Armazenamento (CloudFront & S3): Distribuição global de conteúdo estático via CDN (CloudFront) e armazenamento resiliente de objetos com replicação de dados.

3. MÉTRICAS CHAVE DE CONTINUIDADE (RPO E RTO)

O plano de recuperação fundamenta-se nas seguintes metas de nível de serviço para ambientes críticos de produção sendo as métricas e definições em documento próprio.

4. PROCEDIMENTOS DE BACKUP E RESTAURAÇÃO

4.1. Política de Backup Automatizado

• Snapshots de Banco de Dados: Capturas diárias retidas por 30 dias com habilitação de Point-in-Time Recovery (PITR), permitindo a restauração do banco de dados para qualquer segundo dentro do período de retenção.

• Infraestrutura como Código (IaC): Definições de infraestrutura, redes e contêineres mantidas em repositórios controlados no GitHub, permitindo a reconstrução automatizada do ambiente.

• Criptografia e Proteção: Todos os dados em repouso e backups são criptografados utilizando chaves gerenciadas via AWS KMS.

4.2. Fluxo de Restauração em Caso de Desastre

1. Identificação e Declaração de Incidente: Detecção do evento crítico via monitoramento de disponibilidade e acionamento da equipe de DevOps.

2. Isolamento da Origem: Bloqueio das entradas comprometidas ou redirecionamento de tráfego de rede via DNS/CloudFront.

3. Restauração da Base de Dados: Provisionamento de uma nova instância RDS a partir da réplica limpa ou do snapshot mais recente (PITR).

4. Redeployment dos Serviços: Execução das pipelines de CI/CD para subir os contêineres das aplicações no ECS Fargate apontando para a nova base.

5. Validação e Testes de Fumaça: Verificação da integridade das rotas, serviços de autenticação e persistência de dados antes da liberação.

6. Redirecionamento de Tráfego: Alteração dos registros de DNS para restabelecer o serviço para os usuários finais.

5. TESTES E AUDITORIA PERIÓDICA

A eficácia do Plano de Recuperação de Desastres é validada periodicamente por meio de:

• Simulação de Restauração: Testes semestrais de recuperação da base de dados e reprovisionamento de contêineres em ambiente de homologação (Stage);

• Revisão de Políticas: Atualização anual deste documento ou sempre que houver mudanças relevantes na arquitetura do sistema.

Declaração de Governança de Fornecedores

Código do Documento: DEC-FOR-TER	Versão: 1.0
Data de Emissão: Janeiro de 2026	Classificação de Informação: Uso Interno / Clientes / Auditoria
Área Responsável: Engenharia de Software & DevOps	Aplica-se a: Gestão de Infraestrutura e Serviços em Nuvem

1. OBJETIVO

Este documento apresenta a declaração formal de identificação de terceiros críticos e a estratégia de validação e governança de fornecedores.

2. IDENTIFICAÇÃO DE TERCEIROS CRÍTICOS 

A prestação de serviços utiliza uma estrutura de terceiros que abrange infraestrutura em nuvem, suporte técnico especializado e serviços de desenvolvimento de software terceirizado:

Fornecedor / Terceiro	Papel / Escopo Técnico	Nível de Criticidade	Controles & Certificações de Segurança
AWS (Amazon Web Services) São Paulo	Provedor global de infraestrutura em nuvem (hospedagem ECS/Fargate, bancos de dados RDS MySQL, armazenamento S3, redes e backups).	Alta	Certificações mundiais de conformidade ativa, incluindo ISO/IEC 27001, ISO 27017, ISO 27018, SOC 1/2/3, PCI-DSS e conformidade com LGPD/GDPR.
Nuvme (AWS Partner)	Parceiro especializado para suporte técnico consultivo, arquitetura de infraestrutura e sustentação do ambiente AWS.	Média	Acesso restrito via credenciais temporárias (IAM) sob o princípio do menor privilégio, contrato de confidencialidade (NDA) e canal oficial de chamados.
Desenvolvedores / Consultorias Terceirizadas de Software	Desenvolvimento, manutenção de código-fonte, correção de bugs e evolução das aplicações do ecossistema.	Média/Alta	Contratos com cláusulas estritas de confidencialidade (NDA), acessos nomeados e individuais no GitHub com MFA obrigatório, revisão de código (Code Review) antes do merge para produção e sem acesso direto a dados sensíveis de produção.

3. VALIDAÇÃO E GOVERNANÇA DE FORNECEDORES 

3.1. Validação do Provedor de Infraestrutura (AWS)

Por tratar-se de uma plataforma global de Cloud Computing amplamente consolidada, a validação da AWS fundamenta-se no Modelo de Responsabilidade Compartilhada e na revisão contínua das certificações oficiais emitidas por auditores independentes via portal AWS Artifact (Relatórios SOC 2 Type II e certificações ISO 27001).

3.2. Validação e Gestão de Riscos do Parceiro de Suporte (Nuvme)

A atuação da Nuvme como parceira de suporte de infraestrutura é validada e monitorada através da seguinte estratégia baseada em riscos:

• Credenciamento e Parceria AWS: Validação das certificações técnicas da equipe e do status oficial de AWS Partner Network (APN);

• Controle e Isolamento de Acessos: A Nuvme não possui acesso direto irrevogável ou permanente. Os acessos aos ambientes da AWS ocorrem obrigatoriamente por meio de funções IAM com MFA ativado e registros detalhados via AWS CloudTrail;

• Auditoria e Rastreabilidade: Toda alteração promovida na infraestrutura pela equipe de suporte fica registrada de forma imutável nos logs de auditoria do ambiente;

• Acordo de Nível de Serviço (SLA): Abertura de chamados e atendimento regidos por prazos de resposta vinculados aos níveis de severidade do incidente.

3.3. Validação e Gestão de Riscos de Desenvolvedores Terceirizados

A contratação e atuação dos desenvolvedores terceirizados são validadas e controladas sob rígidos critérios de governança de código e gestão de acessos:

• Validação Contratual e Jurídica: Formalização de contratos de prestação de serviços com cláusulas expressas de confidencialidade (NDA), propriedade intelectual e adequação à LGPD;

• Segregação de Ambientes e Proteção de Dados: Os desenvolvedores terceirizados atuam em ambientes de desenvolvimento/homologação;

• Controle de Versão e Aprovação de Código (Code Review): Os terceiros trabalham através de *Pull Requests* no GitHub. Nenhum código de terceiros é implantado diretamente em produção;

• Gestão de Credenciais e Rastreabilidade: Contas individuais no GitHub com exigência de Autenticação Multi-Fator (MFA). Revogação imediata dos acessos ao término do contrato/alocação.

Certificações e relatórios independentes

1. OBJETIVO

Esta declaração formal visa esclarecer o escopo de certificações e relatórios de auditoria independente aplicáveis ao serviço, garantindo o atendimento técnico.

2. ENQUADRAMENTO DA CONFORMIDADE (PARCIAL)

O enquadramento da conformidade do serviço é classificado formalmente como PARCIAL, fundamentado no Modelo de Responsabilidade Compartilhada em Nuvem (AWS Shared Responsibility Model). Esse modelo delimita com clareza as responsabilidades entre o provedor de infraestrutura de nuvem e a organização prestadora do serviço.

3. CERTIFICAÇÕES VIGENTES DA INFRAESTRUTURA (AWS)

A infraestrutura de nuvem subjacente onde os serviços são hospedados e processados (AWS) possui as seguintes certificações e relatórios de conformidade independentes em vigor:

• ISO/IEC 27001:2013 / 27001:2022: Sistema de Gestão de Segurança da Informação (SGSI);

• ISO/IEC 27017:2015: Código de Prática para Controles de Segurança da Informação para Serviços em Nuvem;

• ISO/IEC 27018:2019: Código de Prática para Proteção de Dados Pessoais Identificáveis (PII) em Nuvens Públicas;

• SOC 1, SOC 2 (Type II) e SOC 3: Relatórios de auditoria independente cobrindo os critérios de Segurança, Disponibilidade, Integridade de Processamento, Confidencialidade e Privacidade;

• PCI-DSS Level 1: Padrão de Segurança de Dados do Setor de Cartões de Pagamento (camada de infraestrutura).

Nota: Cópias formais e vigentes dos certificados e relatórios SOC podem ser fornecidas ou validadas diretamente por meio do portal oficial AWS Artifact.

4. CONTROLES DE SEGURANÇA DA CAMADA DE APLICAÇÃO

Para garantir que a camada sob responsabilidade da organização permaneça alinhada às exigências da ISO 27001 e às boas práticas do mercado, adotam-se os seguintes controles de segurança complementares:

• Gestão de Alterações e Código: Versionamento em repositórios privados no GitHub com ramificações segregadas, aprovação por pares (Peer Review) e esteiras automatizadas de integração e entrega (CI/CD);

• Controle de Acessos e Identidade: Uso obrigatório de Autenticação Multi-Fator (MFA) e políticas do menor privilégio para todos os acessos administrativos;

• Continuidade e Recuperação: Plano formal de Recuperação de Desastres (DRP) com rotinas diárias de backup criptografado em repouso e em trânsito.

Declaração Técnica de Infraestrutura AWS

Código do Documento: DEC-INF-004	Versão: 1.0
Data de Emissão: Janeiro de 2026	Classificação de Informação: Uso Interno / Auditoria
Região AWS: sa-east-1 (São Paulo)	Arquitetura: Hub & Spoke Network (Centralized Ingress & Hub Database)

1. OBJETIVO

Esta declaração técnica fornece a especificação detalhada dos componentes, serviços e arquitetura em nuvem Amazon Web Services (AWS) empregados na sustentação do ambiente operacional e de produção.

2. VISÃO GERAL DA ARQUITETURA (HUB & SPOKE NETWORK)

A infraestrutura é implementada na região de São Paulo (sa-east-1) utilizando a topologia Hub & Spoke Network. Esse modelo isola os ambientes de aplicação em VPCs independentes (Spokes de Prod, Staging e QA), conectadas via VPC Peering a uma rede central compartilhada (Hub VPC) para acesso restrito aos bancos de dados e caches.

3. CATALOGAÇÃO E FUNÇÃO DOS SERVIÇOS AWS

3.1. Camada de Borda, Entrada e Segurança (Edge & Ingress Layer)

Serviço AWS	Componente / Domínio	Função na Arquitetura
Amazon Route 53	DNS Routing Global	Roteamento seguro de DNS e resolução de nomes para os domínios do ecossistema.
Amazon CloudFront (CDN) + Amazon S3	web.smtr.io (Prod) stg.smtr.io (Stage) qa.smtr.io (QA)	Hospedagem estática de Frontends SPA em S3 distribuídos via CDN CloudFront com criptografia HTTPS.
AWS WAF (Web Application Firewall)	Central Ingress Rules Engine	Inspeção de tráfego, proteção contra OWASP Top 10 e bloqueio de requisições maliciosas.
Application Load Balancer (Main ALB)	api.smtr.io | core.smtr.io | doc, status, gestao.smtr.io	Ponto de entrada centralizado para tráfego HTTP/HTTPS com terminação TLS e roteamento para as VPCs.

3.2. Camada de Processamento de Aplicações (Spoke VPCs)

Cada VPC possui Subnets Públicas (com IGW e NAT Gateway) e Subnets Privadas:

Ambiente / VPC	Serviços Principais	Especificação Técnica / Instâncias
VPC: PROD (Produção)	ECS Cluster (Fargate PROD) App ALB (Target Groups Router) NAT Gateway EC2 Legacy App (sismetro.com)	• Tasks autorreguláveis em contêineres sem servidor (Auto-scaled Fargate Tasks). • Saída segura para internet via NAT Gateway. • Instância EC2 t3.small isolada para aplicação legado.
VPC: STAGING (Homologação)	ECS Cluster (Fargate STAGING) App ALB & NAT Gateway	Contêineres Fargate isolados para validação pré-produção.
VPC: QA (Qualidade)	ECS Cluster (Fargate QA) App ALB & NAT Gateway	Ambiente de testes automatizados e validação contínua.

3.3. Camada Central Compartilhada (Hub VPC - Shared Database, Cache & Legacy)

A VPC: DEFAULT (HUB) centraliza os dados operacionais e serviços de backend, conectada às Spokes via VPC Peering:

Categoria	Instância / Recurso	Tipo / Engine	Função Técnica no Ambiente
Relational Databases (RDS)	sismetro (Primary DB)	MySQL Primary (Multi-AZ)	Banco de dados principal de produção em Alta Disponibilidade com failover automático.
	sismetro-read (Read Replica)	MySQL Read Replica (Single-AZ)	Réplica para leitura pesada, relatórios e análises (Analytics Offloading).
ElastiCache	siswebsites	Memcached (Single-AZ)	Gerenciamento de estado de sessão e dados em memória.
	siswebsites-new	Memcached (Single-AZ)	Cache de alta performance para novos microsserviços.
EC2 Computing Legacy	dokku & app	m7i / t3	Hospedagem de plataforma de aplicações e serviços de backend central.
	br2 & homologa	t3	Nós auxiliares e suporte a ambientes de homologação legados.

4. SEGURANÇA E ISOLAMENTO DE REDE

• Segregação Lógica: Ambientes de Produção, Staging e QA operam em redes isoladas sem comunicação direta entre si.

• Subnets Privadas: As tarefas ECS Fargate e bancos RDS operam exclusivamente em subnets privadas, sem IPs públicos diretos.

• Controle de Tráfego: Acesso externo aos bancos de dados é bloqueado, ocorrendo apenas por canais internos protegidos via VPC Peering e inspecionados pelo WAF.

5. COMPROVAÇÂO TÉCNICA EXPEDIDA PELO AMAZON Q

SISMETRO — Infraestrutura AWS Emitido por: Amazon Q — Conta AWS Sismetro  Região: São Paulo (sa-east-1) Data de emissão: 02 de setembro de 2026  Gerado via: Amazon Q Developer — Console AWS   📋 SEÇÃO 2 — Bancos de Dados (Amazon RDS) # Instância Engine Versão Multi-AZ Zona de Disponibilidade Réplica de Leitura Status 1 sismetro MySQL 8.4.10 ✅ Sim sa-east-1a ✅  sismetro-read ✅ Available 2 sismetro-read MySQL 8.4.10 ❌ Não sa-east-1c — (é a réplica de  sismetro ) ✅ Available (Replicating) 3 gestao-app MariaDB 11.8.8 ❌ Não sa-east-1c ❌ Não ✅ Available 4 doc-sismetro-io MySQL 8.4.8 ❌ Não sa-east-1a ❌ Não ✅ Available 5 docs-smtr-io MySQL 8.4.10 ❌ Não sa-east-1b ❌ Não ✅ Available 6 status-sismetro MariaDB 11.8.6 ❌ Não sa-east-1a ❌ Não ✅ Available Total de instâncias RDS: 6  Instâncias com Alta Disponibilidade (Multi-AZ): 1 (sismetro)  Instâncias com Réplica de Leitura: 1 (sismetro-read)  Engines utilizados: MySQL 8.4.x, MariaDB 11.8.x       📋 SEÇÃO 4 — Serviços de Containers (Amazon ECS / AWS Fargate) Visão Geral dos Clusters Cluster Status Tasks em Execução Serviços Ativos Capacity Provider smtro-cluster-prod ✅ ACTIVE 16 24 AWS Fargate smtro-cluster-staging ✅ ACTIVE 9 10 AWS Fargate smtro-cluster-qa ✅ ACTIVE 1 1 AWS Fargate Todos os clusters operam com AWS Fargate (serverless — sem gerenciamento de servidores).   📌 Nota de autenticidade: Este documento foi gerado automaticamente pelo Amazon Q Developer com leitura direta da conta AWS Sismetro (sa-east-1), em 02/09/2026, refletindo o estado real da infraestrutura no momento da consulta. Os dados são provenientes das APIs oficiais da AWS e podem ser verificados no Console AWS.

 

Comunicado Técnico e Guia de Liberação de Firewall / Whitelist

Código do Documento: COM-NET-001	Versão: 1.0
Data de Emissão: Janeiro de 2026	Classificação de Informação: Público / Clientes
Área Emissora: Segurança da Informação & Infraestrutura de Rede	Destinatários: Equipes de TI, Redes e Segurança dos Clientes

1. OBJETIVO

Este documento formal estabelece as especificações técnicas de conectividade necessárias para garantir o acesso ininterrupto, seguro e performático aos serviços do ecossistema SISMETRO. Seu objetivo é orientar os administradores de rede e segurança dos clientes na configuração de regras de liberação (Allowlist / Whitelist) em seus Firewalls, Proxies e filtros de conteúdo (como Fortinet FortiGate, Palo Alto, pfSense, Cisco, SonicWall, Sophos, entre outros).

2. DOMÍNIOS E SUBDOMÍNIOS PARA LIBERAÇÃO (FQDN)

Recomenda-se priorizar a liberação baseada em nomes de domínio (FQDN / Wildcard), uma vez que a infraestrutura opera em nuvem AWS de alta disponibilidade com balanceamento dinâmico de carga.

Domínio / Máscara FQDN	Aplicação / Serviço	Protocolo	Portas
*.sismetro.com	Plataforma Legada e Serviços Legados	HTTPS / HTTP	443 / 80
*.smtr.io	Nova Plataforma, APIs REST, Aplicações Web SPA e Microsserviços	HTTPS / HTTP	443 / 80

2.1. Lista Detalhada de Endereços por Ambiente

• Produção (Aplicação Web & Portal): web.smtr.io, sismetro.com

• APIs e Integrações (Produção): api.smtr.io, get.smtr.io

• Serviços Auxiliares e Documentação: doc.smtr.io, status.smtr.io, exporter.smtr.io

3. ESPECIFICAÇÃO DE REDE E ENDEREÇAMENTO IP

O tráfego de borda é processado pela rede global de entrega de conteúdo (Amazon CloudFront CDN) e pelos balanceadores de carga AWS Application Load Balancers (ALB). Por esse motivo, os endereços IP de destino são dinâmicos e distribuídos mundialmente.

3.1. Lista de IPs para liberação:

18.229.2.58
52.67.75.6
54.207.91.15

Novos *.smtr.io
56.125.117.88
54.233.254.250
54.233.164.85

4. REQUISITOS TÉCNICOS E PORTAS

Certifique-se de que os seguintes requisitos técnicos estejam habilitados na rede corporativa e sejam entregues diretamente, muito importante quando existir o produto SISMETRO LISTENER rodando na infraestrutura do cliente, evitando interrupção da comunicação por reescrita do certificado SSL.

• Porta 443 (TCP): Tráfego criptografado TLS/SSL (Obrigatório).

• Porta 80 (TCP): Redirecionamento automático de HTTP para HTTPS.

• Inspeção Deep Packet / SSL Inspection: Caso a empresa utilize inspeção profunda de pacotes (SSL Interception), é necessário incluir os domínios *.smtr.io e *.sismetro.com na lista de exceções (Bypass) para evitar quebra de cadeias de certificados e falhas de comunicação em rotas de API.

Política e Procedimento de Expurgo e Eliminação de Dados (DATA PURGE POLICY)

Procedimento Operacional Padronizado de Offboarding de Tenants, Churn e Rescisão Contratual

Código do Documento: POL-DAT-001	Versão: 2.1
Data de Emissão: Setembro de 2026	Classificação de Informação: Uso Interno / Governança & LGPD
Área Responsável: Gestão Financeira, Engenharia de Software & DevOps	Aplica-se a: Todos os Tenants, Arquivos S3 e Bancos de Dados da Plataforma Sismetro

1. OBJETIVO

Esta política estabelece as diretrizes formais, os requisitos de segurança e os procedimentos operacionais para o encerramento de contas, cancelamento de serviços e o expurgo definitivo e irreversível de dados operacionais e arquivos (Data Purge) de tenants (unidades) na plataforma SISMETRO, garantindo a conformidade com a LGPD (Lei Geral de Proteção de Dados) e o Marco Civil da Internet.

2. CANAIS E GATILHOS DE ENCERRAMENTO

2.1. Modalidade 1: Cancelamento Voluntário (Churn)

1. Solicitação Inicial: Deve ser iniciada obrigatoriamente pela conta Administrativa do cliente no caminho: Meu Perfil → Conta → Solicitar Cancelamento da Conta.

2. Tratativa Comercial e Contratual: A ação dispara um alerta automático para financeiro@sismetro.com. A equipe de Gestão/Financeiro entra em contato com os representantes legais para análise contratual e tratativas operacionais.

3. Validação por Código (1º Fator - Validade de 24 horas): Na tela administrativa dedicada, a equipe informa o ID da Unidade (Tenant ID). O sistema gera o 1º Código de Confirmação de Cancelamento, enviado ao e-mail do usuário administrativo solicitante. O código possui validade de 24 horas para inicialização do processo.

2.2. Modalidade 2: Rescisão por Inadimplência (Quebra Contratual)

1. Critério Temporal: O atraso de pagamento superior a 4 meses corridos (120 dias) a contar do vencimento caracteriza descontinuidade e quebra de contrato.

2. Inclusão na Fila de Expurgo: A conta entra na fila de exclusão permanente.

3. Validação da Gestão: Na tela administrativa dedicada, a equipe de Gestão/Financeiro insere o Número do Contrato e o ID da Unidade (Tenant ID), gerando as mesmas etapas de validação por códigos de autorização.

3. FLUXO OPERACIONAL DE SINCRONIA E EXPURGO EM ETAPAS

[Solicitação / Inadimplência] 
       │
       ▼
[Código 1: Confirmação de Cancelamento (Expira em 24h)]
       │
       ▼
[Validação de Sincronia / "data-sync"] ──(Obrigatório antes da pré-exclusão)
       │
       ▼
[Pausa de Planos às 00:00h e inativação de APIs]
       │
       ▼ (Janela obrigatória de segurança de 45 dias corridos)
       ▼
[Código 2: Autorização de Expurgo (Gestão/Financeiro)]
       │
       ▼
[Código 3: Confirmação Final de Expurgo (Gestão/Diretoria)]
       │
       ▼
[EXPURGO IRREVERSÍVEL: BANCO DE DADOS OPERACIONAL + ARQUIVOS S3]
       │
       ▼
[RETENÇÃO DO REGISTRO DE AUDITORIA NO TENANT E LOGS ISOLADOS]

Step 1: Sincronização Final de Dados (Pre-exclusão)

• Antes da destruição dos dados, é obrigatório executar a rotina de sincronização final para o banco dedicado de exportação (data-sync), mediante informação do Código de Autorização para Sincronia Final.

Step 2: Pausa Operacional dos Serviços

• Com o código de pré-exclusão validado, a rotina automatizada pausa a abertura de novos planos operacionais e uso de APIs a partir das 00:00 horas do dia seguinte.

Step 3: Janela de Carência e 2º Código de Expurgo

• O sistema aplica uma janela de segurança obrigatória de 45 dias corridos.

• Transcorrido o prazo, o sistema libera o campo para digitação do 2º Código de Autorização de Expurgo, fornecido pela equipe de Gestão/Financeiro.

Step 4: Confirmação Final, Destruição de Dados e Limpeza S3 (3º Código)

• A exclusão é autorizada na tela final mediante a inserção do 3º Código de Confirmação (fornecido pela diretoria/gestão) e preenchimento das informações de encerramento.

• Ação Técnica de Expurgo:

  1. Banco de Dados Operacional (Arquitetura Multi-Tenant): Execução de instrução de exclusão lógica/física (Delete Purge) focada estritamente nas linhas (registros) vinculadas ao Tenant ID em todas as tabelas operacionais do banco de dados.

  2. Arquivos em Storage (Amazon S3): Execução da exclusão paralela e automática de todos os documentos, anexos e mídias vinculados à unidade no bucket do Amazon S3.

4. RASTREABILIDADE (AUDIT TRAIL) E RETENÇÃO LEGAL DE LOGS

4.1. Registro Permanente de Encerramento (Audit Trail)

O cadastro mestre do Tenant ID não é destruído. Ele permanece em estado inativo e retém o histórico de autorização de expurgo (identificação dos responsáveis, datas, horas e os 3 códigos de confirmação utilizados). Caso o cliente retorne no futuro, um novo ID de Unidade será gerado.

4.2. Retenção Isolada de Logs de Acesso

Em cumprimento ao Marco Civil da Internet (Lei nº 12.965/2014, Art. 15) e às boas práticas de governança:

• Os registros e logs de acesso dos usuários à unidade são mantidos em banco/repositório isolado de auditoria sob sigilo.

• Os logs passam por uma rotina automatizada de expurgo definitivo após 5 (cinco) anos contados a partir da data de execução do expurgo operacional da unidade.

5. DECLARAÇÃO DE IRREVERSIBILIDADE

Uma vez concluído o Step 4 com a validação dos três códigos de segurança, o processo de expurgo das tabelas operacionais e arquivos no S3 é definitivo e irreversível, não sendo possível a restauração do ambiente por nenhuma das partes.