# Compliance e Infraestrutura

Documentação de Continuidade de Negócios e Segurança

# Política de RTO/RPO

<table id="bkmrk-c%C3%B3digo-do-documento%3A" style="width:97.0238%;height:89.3907px;"><colgroup><col style="width:49.6324%;"></col><col style="width:50.3676%;"></col></colgroup><tbody><tr style="height:29.7969px;"><td style="height:29.7969px;">Código do Documento: POL-RTO-RPO-001

</td><td style="height:29.7969px;">Versão: 1.0

</td></tr><tr style="height:29.7969px;"><td style="height:29.7969px;">Data de Aprovação: Janeiro de 2026

</td><td style="height:29.7969px;">Classificação de Informação: Uso Interno / Clientes

</td></tr><tr style="height:29.7969px;"><td style="height:29.7969px;">Área Gestora: Segurança da Informação / TI

</td><td style="height:29.7969px;">Aplica-se a: Todos os Serviços, Bancos de Dados e Aplicações

</td></tr></tbody></table>

#### 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)

<table id="bkmrk-m%C3%A9trica-objetivo-des" style="width:100%;"><thead><tr><td style="width:21.7528%;">**Métrica**</td><td style="width:14.8292%;">**Objetivo**</td><td style="width:63.4067%;">**Descrição**</td></tr></thead><tbody><tr><td style="width:21.7528%;"><span>RTO   
(Tempo de Recuperação)</span></td><td class="align-center" style="width:14.8292%;"><span>1 Hora</span></td><td style="width:63.4067%;"><span>Tempo máximo para o sistema voltar a operar após uma falha crítica na instância principal.</span></td></tr><tr><td style="width:21.7528%;"><span>RPO   
(Ponto de Recuperação)</span></td><td class="align-center" style="width:14.8292%;"><span>Próximo a Zero</span></td><td style="width:63.4067%;"><span>Quantidade máxima de dados que podem ser perdidos. Graças à replicação síncrona, a perda é virtualmente nula.</span></td></tr></tbody></table>

####   


#### 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

<table id="bkmrk-c%C3%B3digo-do-documento%3A" style="width:98.0952%;"><colgroup><col style="width:42.1208%;"></col><col style="width:57.8792%;"></col></colgroup><tbody><tr><td>Código do Documento: DEF-SEP-MUL-TEN-001

</td><td>Versão: 1.0

</td></tr><tr><td>Data de Aprovação: Janeiro de 2026

</td><td>Classificação de Informação: Uso Interno / Clientes

</td></tr><tr><td>Área Gestora: Segurança da Informação / TI

</td><td>Aplica-se a: Todos os Serviços, Bancos de Dados e Aplicações

</td></tr></tbody></table>

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.

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

<table id="bkmrk-c%C3%B3digo-do-documento%3A" style="width:96.9048%;"><tbody><tr><td style="width:46.6237%;">Código do Documento: DEF-SLA-001

</td><td style="width:53.3763%;">Versão: 1.0

</td></tr><tr><td style="width:46.6237%;">Data de Aprovação: Janeiro de 2026

</td><td style="width:53.3763%;">Classificação de Informação: Uso Interno / Clientes

</td></tr><tr><td style="width:46.6237%;">Área Gestora: Segurança da Informação / TI

</td><td style="width:53.3763%;">Aplica-se a: Plataforma SISMETRO (APIs, Web e Arquitetura AWS)

</td></tr></tbody></table>

#### 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:

<div dir="ltr" id="bkmrk-componente-%2F-servi%C3%A7o" style="text-align:left;"><table style="width:97.0238%;"><colgroup><col style="width:53.6841%;"></col><col style="width:20.8859%;"></col><col style="width:25.3071%;"></col></colgroup><tbody><tr><td>**Componente / Serviço**

</td><td>**Meta de SLA (Uptime)**

</td><td>**Janela de Indisponibilidade Máxima Estimada**

</td></tr><tr><td>Infraestrutura AWS (ECS Fargate / RDS / CloudFront)

</td><td class="align-center">99,9%

</td><td class="align-center">~43 minutos/mês

</td></tr><tr><td>Aplicações Web &amp; APIs (Laravel / Angular)

</td><td class="align-center">99,5%

</td><td class="align-center">~3,6 horas/mês

</td></tr><tr><td>Serviços de Terceiros e Integrações (Protheus / Provedores)

</td><td class="align-center">99,0%

</td><td class="align-center">~7,2 horas/mês

</td></tr></tbody></table>

</div>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.

<div dir="ltr" id="bkmrk-m%C3%A9trica-defini%C3%A7%C3%A3o-me" style="text-align:left;"><table style="width:97.0238%;"><colgroup><col style="width:27.0347%;"></col><col style="width:39.5501%;"></col><col style="width:33.2924%;"></col></colgroup><tbody><tr><td>**Métrica**

</td><td>**Definição**

</td><td>**Meta Garantida**

</td></tr><tr><td>RPO (Recovery Point Objective)

</td><td>Quantidade máxima tolerável de perda de dados expressa em tempo.

</td><td>≤ 1 hora (Backups contínuos / Transaction logs &amp; Snapshots)

</td></tr><tr><td>RTO (Recovery Time Objective)

</td><td>Tempo máximo para restauração completa dos serviços após desastre.

</td><td>≤ 2 horas (Ambiente multi-az / Fargate auto-recovery)

</td></tr></tbody></table>

</div>#### 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:

<div dir="ltr" id="bkmrk-n%C3%ADvel-de-severidade-" style="text-align:left;"><table style="width:97.2619%;"><colgroup><col style="width:18.6275%;"></col><col style="width:44.2327%;"></col><col style="width:17.532%;"></col><col style="width:19.6078%;"></col></colgroup><tbody><tr><td>**Nível de Severidade**

</td><td>**Descrição / Critério de Impacto**

</td><td>**Tempo de Primeira Resposta**

</td><td>**Tempo de Resolução / Solução Contorno**

</td></tr><tr><td>P1 - Crítico (Urgent)

</td><td>Sistema totalmente inoperante para todos os usuários ou perda crítica de dados sem solução de contorno.

</td><td class="align-center">Até 15 minutos

</td><td class="align-center">Até 2 horas

</td></tr><tr><td>P2 - Alto (High)

</td><td>Funcionalidade principal afetada (ex: falhas em rotas cruciais de sincronização ou ordens de serviço), com impacto significativo.

</td><td class="align-center">Até 1 hora

</td><td class="align-center">Até 8 horas

</td></tr><tr><td>P3 - Médio (Normal)

</td><td>Problema parcial em funcionalidades secundárias ou degradação leve de performance sem paralisação.

</td><td class="align-center">Até 4 horas

</td><td class="align-center">Até 24 horas

</td></tr><tr><td>P4 - Baixo (Low)

</td><td>Dúvidas técnicas, solicitações de melhorias, bugs estéticos ou pequenos ajustes visuais.

</td><td class="align-center">Até 8 horas (dias úteis)

</td><td class="align-center">A combinar conforme Sprint

</td></tr></tbody></table>

</div>#### 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

<div dir="ltr" id="bkmrk-c%C3%B3digo-do-documento%3A" style="text-align:left;"><table style="width:97.0238%;"><colgroup><col style="width:49.6324%;"></col><col style="width:50.3676%;"></col></colgroup><tbody><tr><td>Código do Documento: POL-CTL-ACS-001

</td><td>Versão: 1.0

</td></tr><tr><td>Data de Aprovação: Janeiro de 2026

</td><td>Classificação de Informação: Uso Interno

</td></tr><tr><td>Área Gestora: Segurança da Informação / TI

</td><td>Aplica-se a: Todos os Colaboradores e Prestadores de Serviço

</td></tr></tbody></table>

</div>#### 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:

<div dir="ltr" id="bkmrk-princ%C3%ADpio-descri%C3%A7%C3%A3o-" style="text-align:left;"><table style="width:97.8571%;"><colgroup><col style="width:44.8759%;"></col><col style="width:55.1261%;"></col></colgroup><thead><tr><th scope="col">Princípio

</th><th scope="col">Descrição Operacional

</th></tr></thead><tbody><tr><td>Menor Privilégio (Least Privilege)

</td><td>Todo usuário ou serviço receberá apenas o nível mínimo de permissões indispensável para a execução regular de suas atribuições.

</td></tr><tr><td>Necessidade de Conhecer (Need-to-Know)

</td><td>A concessão de acesso a informações restritas ou sensíveis fundamenta-se na necessidade técnica ou operacional, e não no nível hierárquico do solicitante.

</td></tr><tr><td>Segregação de Funções (Separation of Duties - SoD)

</td><td>Processos críticos que envolvam riscos operacionais ou financeiros devem exigir a atuação/aprovação de pessoas distintas, evitando a concentração de privilégios.

</td></tr></tbody></table>

</div>
#### 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

<div dir="ltr" id="bkmrk-c%C3%B3digo-do-documento%3A" style="text-align:left;"><table style="width:99.6429%;"><colgroup><col style="width:49.6443%;"></col><col style="width:50.3557%;"></col></colgroup><tbody><tr><td>Código do Documento: PSI-SER-001

</td><td>Versão: 1.0

</td></tr><tr><td>Data de Emissão: Janeiro de 2026

</td><td>Classificação de Informação: Uso Interno / Clientes / Fornecedores

</td></tr><tr><td>Área Responsável: Governança de TI e Segurança da Informação

</td><td>Aplica-se a: Todos os Serviços, Sistemas e Colaboradores

</td></tr></tbody></table>

</div>#### 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:

<div dir="ltr" id="bkmrk-pilar-descri%C3%A7%C3%A3o-t%C3%A9cn" style="text-align:left;"><table style="width:99.4048%;"><colgroup><col style="width:28.0252%;"></col><col style="width:71.9767%;"></col></colgroup><tbody><tr><td>**Pilar**

</td><td>**Descrição Técnica e Operacional**

</td></tr><tr><td>Confidencialidade

</td><td>Garantia de que os dados transacionados e armazenados no serviço estejam acessíveis exclusivamente por sistemas e pessoas formalmente autorizados.

</td></tr><tr><td>Integridade

</td><td>Salvaguarda da exatidão e do estado completo das informações e sistemas, protegendo-os contra modificações não autorizadas ou acidentais.

</td></tr><tr><td>Disponibilidade

</td><td>Garantia de que os serviços e dados permaneçam operacionais e acessíveis para os usuários autorizados sempre que necessário.

</td></tr><tr><td>Rastreabilidade (Auditabilidade)

</td><td>Capacidade de registrar, monitorar e auditar todas as ações, acessos e alterações realizadas no ambiente do serviço.

</td></tr></tbody></table>

</div>#### 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

<table id="bkmrk-%C2%A0-%C2%A0-c%C3%B3digo-do-docume" style="width:99.0476%;"><tbody><tr><td style="width:45.8498%;"><span>Código do Documento: GES-HTR-REL-001</span></td><td style="width:54.1502%;"><span>Versão: 1.0</span></td></tr><tr><td style="width:45.8498%;"><span>Data de Emissão: Janeiro de 2026</span></td><td style="width:54.1502%;"><span>Classificação de Informação: Uso Interno / Clientes / Auditoria</span></td></tr><tr><td style="width:45.8498%;"><span>Área Responsável: Engenharia de Software / DevOps</span></td><td style="width:54.1502%;"><span>Aplica-se a: Todos os Serviços e Microsserviços</span></td></tr></tbody></table>


#### 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:

<table id="bkmrk-branch-%2F-ramo-ambien" style="width:100%;height:252.578px;"><tbody><tr style="height:46.5938px;"><td style="width:10.6124%;height:46.5938px;">**Branch / Ramo**</td><td style="width:18.589%;height:46.5938px;">**Ambiente Associado**</td><td style="width:70.7986%;height:46.5938px;">**Finalidade e Critérios de Aprovação**</td></tr><tr style="height:64.3281px;"><td style="width:10.6124%;height:64.3281px;"><span>`main` / `master` / `prod`</span></td><td style="width:18.589%;height:64.3281px;"><span>Produção (Prod)</span></td><td style="width:70.7986%;height:64.3281px;"><span>Código em execução operacional. Alterações entram via Pull Requests (PRs) aprovados após validação em homologação e testes.</span></td></tr><tr style="height:47.2188px;"><td style="width:10.6124%;height:47.2188px;"><span>`staging` / `stage`</span></td><td style="width:18.589%;height:47.2188px;"><span>Homologação (Stage)</span></td><td style="width:70.7986%;height:47.2188px;"><span>Ambiente pré-produção utilizado para validação final e aprovação do time de produto/cliente.</span></td></tr><tr style="height:47.2188px;"><td style="width:10.6124%;height:47.2188px;"><span>`qa` / `testing`</span></td><td style="width:18.589%;height:47.2188px;"><span>Qualidade / Testes (QA)</span></td><td style="width:70.7986%;height:47.2188px;"><span>Ambiente dedicado para serviços aplicáveis, onde são executados testes de regressão e garantia de qualidade antes do merge para staging.</span></td></tr><tr style="height:47.2188px;"><td style="width:10.6124%;height:47.2188px;"><span>`feature/*` ou `fix/*`</span></td><td style="width:18.589%;height:47.2188px;"><span>Desenvolvimento Local</span></td><td style="width:70.7986%;height:47.2188px;"><span>Ramos isolados para implementação de melhorias ou correções específicas, originando Pull Requests para revisão de código.</span></td></tr></tbody></table>

#### 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 &amp; 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)

<table id="bkmrk-%C2%A0-%C2%A0-c%C3%B3digo-do-docume" style="width:98.2143%;height:119.188px;"><tbody><tr style="height:29.7969px;"><td style="width:44.8322%;height:29.7969px;"><span>Código do Documento: PLN-DST-RCV-025</span></td><td style="width:55.1678%;height:29.7969px;"><span>Versão: 1.0</span></td></tr><tr style="height:29.7969px;"><td style="width:44.8322%;height:29.7969px;"><span>Data de Emissão: Janeiro de 2026</span></td><td style="width:55.1678%;height:29.7969px;"><span>Classificação de Informação: Uso Interno / Clientes / Auditoria</span></td></tr><tr style="height:29.7969px;"><td style="width:44.8322%;height:29.7969px;"><span>Área Responsável: Infraestrutura, Cloud &amp; DevOps</span></td><td style="width:55.1678%;height:29.7969px;"><span>Aplica-se a: Todos os Serviços, Bancos de Dados e Aplicações</span></td></tr></tbody></table>

#### 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 &amp; 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

<table id="bkmrk-%C2%A0-%C2%A0-c%C3%B3digo-do-docume"><tbody><tr><td><span>Código do Documento: DEC-FOR-TER</span></td><td><span>Versão: 1.0</span></td></tr><tr><td><span>Data de Emissão: Janeiro de 2026</span></td><td><span>Classificação de Informação: Uso Interno / Clientes / Auditoria</span></td></tr><tr><td><span>Área Responsável: Engenharia de Software &amp; DevOps</span></td><td><span>Aplica-se a: Gestão de Infraestrutura e Serviços em Nuvem</span></td></tr></tbody></table>

#### 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:

<table id="bkmrk-fornecedor-%2F-terceir" style="width:100%;height:287.156px;"><tbody><tr style="height:46.5938px;"><td style="width:15.6138%;height:46.5938px;">Fornecedor / Terceiro</td><td style="width:32.8963%;height:46.5938px;">Papel / Escopo Técnico</td><td style="width:11.7972%;height:46.5938px;">Nível de Criticidade</td><td style="width:39.8119%;height:46.5938px;">Controles &amp; Certificações de Segurança</td></tr><tr style="height:80.1875px;"><td style="width:15.6138%;height:80.1875px;"><span>AWS (Amazon Web Services)  
São Paulo</span></td><td style="width:32.8963%;height:80.1875px;"><span>Provedor global de infraestrutura em nuvem (hospedagem ECS/Fargate, bancos de dados RDS MySQL, armazenamento S3, redes e backups).</span></td><td class="align-center" style="width:11.7972%;height:80.1875px;"><span>Alta</span></td><td style="width:39.8119%;height:80.1875px;"><span>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.</span></td></tr><tr style="height:80.1875px;"><td style="width:15.6138%;height:80.1875px;"><span>Nuvme (AWS Partner)</span></td><td style="width:32.8963%;height:80.1875px;"><span>Parceiro especializado para suporte técnico consultivo, arquitetura de infraestrutura e sustentação do ambiente AWS.</span></td><td class="align-center" style="width:11.7972%;height:80.1875px;"><span>Média</span></td><td style="width:39.8119%;height:80.1875px;"><span>Acesso restrito via credenciais temporárias (IAM) sob o princípio do menor privilégio, contrato de confidencialidade (NDA) e canal oficial de chamados.</span></td></tr><tr style="height:80.1875px;"><td style="width:15.6138%;height:80.1875px;"><span>Desenvolvedores / Consultorias Terceirizadas de Software</span></td><td style="width:32.8963%;height:80.1875px;"><span>Desenvolvimento, manutenção de código-fonte, correção de bugs e evolução das aplicações do ecossistema.</span></td><td class="align-center" style="width:11.7972%;height:80.1875px;"><span>Média/Alta</span></td><td style="width:39.8119%;height:80.1875px;"><span>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.</span></td></tr></tbody></table>

#### 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

<div dir="ltr" id="bkmrk-c%C3%B3digo-do-documento%3A" style="text-align:left;"><table style="width:97.2619%;"><colgroup><col style="width:50%;"></col><col style="width:50%;"></col></colgroup><tbody><tr><td>Código do Documento: DEC-CRT-022

</td><td>Versão: 1.0

</td></tr><tr><td>Data de Emissão: Janeiro de 2026

</td><td>Classificação de Informação: Uso Interno / Clientes / Auditoria

</td></tr><tr><td>Área Responsável: Governança de TI, Segurança &amp; DevOps

</td><td>Aplica-se a: Todos os Serviços e Infraestrutura em Nuvem

</td></tr></tbody></table>

</div>#### 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.

<div dir="ltr" id="bkmrk-camada-%2F-%C3%82mbito-enti" style="text-align:left;"><table style="width:99.6429%;"><colgroup><col style="width:25%;"></col><col style="width:25%;"></col><col style="width:25%;"></col><col style="width:25%;"></col></colgroup><tbody><tr><td>**Camada / Âmbito**

</td><td>**Entidade Responsável**

</td><td>**Status de Certificação / Auditoria**

</td><td>**Descrição do Escopo do Atendimento**

</td></tr><tr><td>Segurança DA Nuvem (Infraestrutura, Data Centers, Hardware e Hipervisores)

</td><td>Amazon Web Services (AWS)

</td><td>Totalmente Certificado

</td><td>Cobertura integral por auditorias independentes mundiais e relatórios atestando a segurança física e lógica da infraestrutura base.

</td></tr><tr><td>Segurança NA Nuvem (Aplicação, Código-Fonte, Regras de Negócio e Gestão de Dados)

</td><td>Organização (Desenvolvimento e Operação)

</td><td>Controles Internos Aplicados

</td><td>Segurança assegurada por meio de políticas e controles internos de governança (DevSecOps, testes automatizados, auditoria de código e gestão de acessos).

</td></tr></tbody></table>

</div>#### 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.