O Documento de Arquitetura Tecnológica é o mapa da infraestrutura de TI da serventia. Mostra como os equipamentos se conectam, por onde os dados trafegam, onde ficam os backups, quais sistemas são usados e como tudo se integra. É o documento que permite a qualquer técnico entender a operação tecnológica do cartório sem precisar perguntar para quem montou.
O item 2.8 da Etapa 2 do Provimento 213 exige a elaboração desse documento com seis elementos obrigatórios. Não precisa ser um projeto de engenharia com dezenas de páginas, mas precisa ser completo, preciso e atualizado.
O que o provimento exige
O documento técnico simplificado deve conter, no mínimo:
- Topologia básica de rede
- Ambientes utilizados (local, nuvem, híbrido, SaaS ou compartilhado)
- Fluxos de dados críticos
- Localização dos backups
- Integrações externas
- Mecanismos de alta disponibilidade ou redundância
Estrutura do documento
1. Objetivo
Descreva o propósito do documento de forma direta.
Este documento descreve a arquitetura tecnológica da serventia [nome do cartório], incluindo a topologia de rede, os ambientes utilizados, os fluxos de dados críticos, a localização dos backups, as integrações externas e os mecanismos de redundância adotados, em conformidade com o item 2.8 do Provimento 213 do CNJ.
2. Visão geral do ambiente
Antes de entrar nos detalhes, descreva o cenário geral da serventia. Essa seção ajuda o leitor a entender rapidamente o contexto.
Informações básicas:
| Item | Descrição |
|---|---|
| Modelo de operação | [SaaS / On-premise / Híbrido] |
| Sistema principal | [nome do sistema, versão] |
| Fornecedor do sistema | [nome do fornecedor] |
| Provedor de nuvem (se aplicável) | [AWS / Azure / GCP / outro] |
| Quantidade de estações de trabalho | [número] |
| Servidor local (se aplicável) | [modelo, sistema operacional] |
| Quantidade de links de internet | [número, operadoras] |
3. Topologia básica de rede
Este é o diagrama que mostra como os equipamentos e sistemas se conectam. Não precisa ser feito em software profissional de diagramação. Um desenho claro e legível, mesmo feito em ferramenta simples, já atende ao requisito.
O diagrama deve incluir:
- Link(s) de internet (operadora, tecnologia, velocidade)
- Roteador(es)
- Switch(es)
- Estações de trabalho (identificadas por função: guichê 1, guichê 2, atendimento, administrativo)
- Servidor local (se houver)
- Nobreak(s) e quais equipamentos protegem
- Impressoras e scanners de rede
- Roteador 4G/5G de contingência (se houver)
- Conexão com o sistema principal (SaaS via internet ou rede local)
Modelo para serventia SaaS (sistema em nuvem):
Internet (Link 1 - [operadora] - [velocidade])
│
├── Internet (Link 2 - [operadora] - [velocidade]) [backup]
│
▼
Roteador [modelo]
│
▼
Switch [modelo, portas]
│
├── Estação 1 (Guichê 1) ── Nobreak secundário
├── Estação 2 (Guichê 2) ── Nobreak secundário
├── Estação 3 (Administrativo)
├── Impressora de rede [modelo]
├── Scanner [modelo]
│
├── Roteador, Switch ── Nobreak principal
│
└── [Roteador 4G/5G contingência - modelo, operadora]
┌─────────────────┐
│ Sistema (SaaS) │
│ Provedor: [nome] │
│ Nuvem: [AWS/etc] │
└─────────────────┘
(via internet)Modelo para serventia on-premise (servidor local):
Internet (Link 1 - [operadora] - [velocidade])
│
├── Internet (Link 2 - [operadora] - [velocidade]) [backup]
│
▼
Roteador [modelo]
│
▼
Switch [modelo, portas]
│
├── Servidor [modelo, SO] ── Nobreak principal
│ │
│ └── Banco de dados [tipo, versão]
│
├── Estação 1 (Guichê 1) ── Nobreak secundário
├── Estação 2 (Guichê 2) ── Nobreak secundário
├── Estação 3 (Administrativo)
├── Impressora de rede [modelo]
├── Scanner [modelo]
│
└── [Roteador 4G/5G contingência - modelo, operadora]Esses são modelos simplificados. Adapte à realidade da serventia, incluindo todos os equipamentos relevantes. Se a serventia tiver mais de um andar, VLANs, Wi-Fi ou estrutura de rede mais complexa, o diagrama precisa refletir isso.
Para o diagrama gráfico, ferramentas como draw.io (gratuita), Visio ou até PowerPoint funcionam. O importante é que seja legível e que qualquer técnico consiga entender a estrutura olhando o diagrama.
4. Ambientes utilizados
Descreva o modelo de operação da serventia. Essa seção detalha onde cada componente do sistema roda.
Serventia SaaS (sistema em nuvem)
| Componente | Ambiente | Provedor | Observação |
|---|---|---|---|
| Sistema principal | Nuvem (SaaS) | [fornecedor, ex: SIG Virtual] | Acesso via navegador |
| Banco de dados | Nuvem | [provedor de nuvem, ex: AWS] | Gerenciado pelo fornecedor |
| E-mail institucional | Nuvem | [Google Workspace / Microsoft 365 / outro] | — |
| Armazenamento de documentos | Nuvem | [provedor] | Vinculado ao sistema principal |
| Estações de trabalho | Local | — | Windows [versão] |
| Rede local | Local | — | Roteador + switch próprios |
Nesse modelo, a responsabilidade sobre servidores, banco de dados, segurança física do datacenter e redundância de infraestrutura é do provedor. A serventia é responsável pela rede local, estações de trabalho, conectividade e controle de acesso.
Documente essa divisão de responsabilidade referenciando o modelo de responsabilidade compartilhada do provedor de nuvem. Para AWS, por exemplo, o documento é público: “AWS Shared Responsibility Model”. Solicite ao fornecedor do sistema a documentação de conformidade (SOC 2, ISO 27001) e anexe ao documento de arquitetura.
Serventia on-premise (servidor local)
| Componente | Ambiente | Especificação | Observação |
|---|---|---|---|
| Sistema principal | Local | [nome do sistema, versão] | Instalado no servidor |
| Servidor | Local | [modelo, processador, RAM, disco, SO] | Sala de servidores |
| Banco de dados | Local | [tipo, versão, ex: PostgreSQL 15] | No servidor |
| Backup local | Local | [HD externo / NAS / fita] | [localização] |
| Backup off-site | Nuvem / externo | [provedor / cofre externo] | Cópia remota |
| E-mail institucional | Nuvem | [provedor] | — |
| Estações de trabalho | Local | [qtd], Windows [versão] | — |
| Rede local | Local | — | Roteador + switch próprios |
No modelo on-premise, a serventia é responsável por toda a infraestrutura: servidor, banco de dados, backup, segurança física, climatização, energia, atualizações de sistema operacional e aplicações. Isso precisa estar explícito no documento.
5. Fluxos de dados críticos
Mapeie por onde os dados sensíveis trafegam. O objetivo é identificar os caminhos que os dados percorrem desde a entrada até o armazenamento e compartilhamento, para que os controles de segurança estejam aplicados nos pontos certos.
Fluxo principal (atendimento ao público):
| Etapa | Descrição | Dados envolvidos | Caminho |
|---|---|---|---|
| 1 | Coleta de dados no guichê | Nome, CPF, RG, documentos | Estação → sistema (via rede local ou internet) |
| 2 | Processamento do ato | Dados do ato, partes envolvidas | Sistema (servidor local ou nuvem) |
| 3 | Armazenamento | Registro completo do ato | Banco de dados (local ou nuvem) |
| 4 | Envio para central eletrônica | Dados do ato conforme layout da central | Sistema → central (via internet, API/webservice) |
| 5 | Backup | Cópia do banco de dados | Servidor → backup local → backup off-site |
Fluxos de compartilhamento externo:
| Destino | Dados compartilhados | Meio | Frequência |
|---|---|---|---|
| Central eletrônica (ex: CRI, CENSEC, CRC) | Dados dos atos registrados | API / webservice | Em tempo real ou diário |
| Receita Federal (DOI) | Dados de transações imobiliárias | Sistema da RFB | Mensal |
| Receita Federal (CPF) | Dados de nascimento para emissão de CPF | Sistema da RFB | Por demanda |
| SIRC | Registros civis | Webservice | Em tempo real |
| Prefeitura (ITBI) | Dados de transmissão de imóveis | Varia por município | Por demanda |
| Poder Judiciário | Penhoras, indisponibilidades | CNIB / sistema judicial | Por demanda |
| eSocial / FGTS | Dados de colaboradores | Sistema gov.br | Mensal |
Adapte essa tabela à realidade da serventia. Cada tipo de cartório tem integrações específicas. O importante é que todos os fluxos de compartilhamento de dados estejam documentados, com o destino, os dados enviados, o meio técnico e a frequência.
Fluxos internos sensíveis:
Além dos fluxos externos, documente os fluxos internos que envolvem dados sensíveis:
| Fluxo | Dados | Caminho | Controle |
|---|---|---|---|
| Acesso ao sistema | Credenciais individuais | Estação → sistema | Login individual + MFA (admin) |
| Backup | Banco de dados completo | Servidor → mídia local → off-site | Criptografia, acesso restrito |
| Acesso remoto (se houver) | Dados do sistema | Internet → VPN → rede local | VPN com autenticação |
| Impressão de documentos | Dados de atos | Estação → impressora | Retirada imediata, descarte seguro |
6. Localização dos backups
Detalhe a estratégia de backup da serventia. Esse é um dos pontos mais importantes do documento, porque o backup é a última linha de defesa contra perda de dados.
Serventia SaaS
| Tipo | Responsável | Localização | Frequência | Retenção | Teste |
|---|---|---|---|---|---|
| Backup do sistema/banco | Fornecedor do sistema | Infraestrutura do fornecedor (nuvem) | [frequência informada pelo fornecedor] | [período] | Solicitar evidência ao fornecedor |
| Backup de documentos digitalizados | Fornecedor do sistema | Infraestrutura do fornecedor | [frequência] | [período] | Solicitar evidência |
| Backup de e-mail | Provedor de e-mail | Nuvem | Contínuo | [período] | — |
| Exportação periódica | Serventia | [local: HD externo / nuvem própria] | [semanal / mensal] | [período] | [frequência de teste] |
No modelo SaaS, o backup principal é responsabilidade do fornecedor. Mas a serventia precisa ter documentação do fornecedor comprovando a estratégia de backup: frequência, retenção, localização e testes de restauração. Solicite formalmente essas informações e anexe ao documento.
Considere também manter uma exportação periódica dos dados em formato aberto, independente do fornecedor. Se o contrato for encerrado ou o fornecedor tiver uma falha grave, a serventia precisa ter acesso aos seus dados.
Serventia on-premise
| Tipo | Responsável | Localização | Frequência | Retenção | Teste |
|---|---|---|---|---|---|
| Backup completo do banco | [nome] | HD externo na sala de servidores | [diário / semanal] | [período] | [mensal / trimestral] |
| Backup incremental | [nome] | Mesmo HD ou NAS | [diário] | [período] | — |
| Backup off-site | [nome] | [nuvem: provedor / cofre externo: endereço] | [diário / semanal] | [período] | [trimestral] |
| Backup de configurações | [nome] | [local] | [mensal] | [período] | — |
| Backup de e-mail | Provedor de e-mail | Nuvem | Contínuo | [período] | — |
Para serventias on-premise, o backup off-site é obrigatório. O backup não pode ficar apenas no mesmo local físico do servidor. Se houver incêndio, inundação ou furto, o backup local vai junto. A cópia off-site (nuvem ou local físico separado) é o que garante a recuperação.
Os parâmetros de RPO (perda máxima de dados) e RTO (tempo para restaurar) definidos no PCN/PRD devem ser compatíveis com a frequência e a estratégia de backup documentadas aqui. Se o RPO da serventia é de 4 horas (Classe 3), o backup precisa ser feito pelo menos a cada 4 horas.
7. Integrações externas
Liste todas as integrações do sistema da serventia com sistemas externos. Cada integração é um ponto de entrada e saída de dados que precisa estar documentado e protegido.
| Integração | Sistema externo | Protocolo | Autenticação | Dados trafegados | Frequência | Responsável |
|---|---|---|---|---|---|---|
| Central de RI | [nome da central] | API REST / webservice SOAP | Certificado digital / token | Dados de registros | Tempo real | Fornecedor do sistema |
| Central de Notas | CENSEC / e-Notariado | [protocolo] | Certificado digital | Atos notariais | [frequência] | Fornecedor do sistema |
| Central de RCPN | CRC Nacional | [protocolo] | [autenticação] | Registros civis | Tempo real | Fornecedor do sistema |
| SIRC | Sistema do MJ | [protocolo] | [autenticação] | Registros civis | Tempo real | Fornecedor do sistema |
| Receita Federal (DOI) | Sistema da RFB | [protocolo] | Certificado digital | Transações imobiliárias | Mensal | Serventia |
| Receita Federal (CPF) | Sistema da RFB | [protocolo] | [autenticação] | Dados de nascimento | Por demanda | Serventia |
| CNIB | Central de indisponibilidade | [protocolo] | [autenticação] | Ordens judiciais | Por demanda | Fornecedor do sistema |
| eSocial | Sistema gov.br | Webservice | Certificado digital | Dados trabalhistas | Mensal | Contador / serventia |
| Prefeitura (ITBI) | [sistema municipal] | [protocolo] | [autenticação] | Dados de transmissão | Por demanda | Serventia |
Adapte a tabela ao tipo de serventia. Nem todas as integrações se aplicam a todos os cartórios. O importante é que nenhuma integração fique de fora.
Para cada integração, registre também:
- Se a comunicação é criptografada (HTTPS/TLS)
- Se usa certificado digital da serventia
- Quem é o contato técnico do sistema externo
- Se há SLA ou prazo de resposta em caso de falha
8. Mecanismos de alta disponibilidade ou redundância
Documente os mecanismos que a serventia adota para evitar ou minimizar indisponibilidade.
Serventia SaaS
| Mecanismo | Descrição | Responsável |
|---|---|---|
| Redundância de infraestrutura | Servidores redundantes, failover automático | Fornecedor do sistema / provedor de nuvem |
| Backup automático | Backup contínuo ou periódico na nuvem | Fornecedor do sistema |
| Link de internet secundário | [operadora, tecnologia, velocidade] | Serventia |
| Roteador 4G/5G | Contingência em caso de falha dos dois links | Serventia |
| Nobreak | Autonomia de [X] minutos para estações e rede | Serventia |
| SLA do fornecedor | [percentual de disponibilidade, ex: 99,5%] | Fornecedor do sistema |
Solicite ao fornecedor do sistema a documentação de SLA e os mecanismos de redundância que ele adota. Anexe ao documento.
Serventia on-premise
| Mecanismo | Descrição | Responsável | Status |
|---|---|---|---|
| RAID no servidor | [tipo de RAID, ex: RAID 1 espelhamento] | Serventia | [implementado / pendente] |
| Fonte redundante no servidor | [sim/não] | Serventia | [implementado / pendente] |
| Backup off-site | Cópia remota do banco de dados | Serventia | [implementado / pendente] |
| Link de internet secundário | [operadora, tecnologia] | Serventia | [implementado / pendente] |
| Roteador 4G/5G | Contingência de conectividade | Serventia | [implementado / pendente] |
| Nobreak | Autonomia de [X] min para servidor + rede + estações | Serventia | [implementado / pendente] |
| Servidor sobressalente | [sim/não, especificação] | Serventia | [implementado / pendente] |
| Procedimento de restauração testado | Restauração do backup em ambiente separado | Serventia | [última data de teste] |
No modelo on-premise, a redundância é inteiramente responsabilidade da serventia. Um servidor sem RAID pode perder dados por falha de um único disco. Um servidor sem fonte redundante pode desligar abruptamente por falha da fonte de alimentação. Cada mecanismo que não for implementado representa um ponto único de falha que precisa estar documentado como risco no PCN/PRD.
A coluna “Status” é importante: nem todos os mecanismos precisam estar implementados no momento da elaboração do documento, mas os que não estiverem devem constar como itens pendentes no plano de ação da serventia.
9. Informações complementares
Dependendo da complexidade da serventia, pode ser útil incluir seções adicionais:
Segmentação de rede (se aplicável): Se a serventia usa VLANs, redes separadas para visitantes/Wi-Fi, ou segmentação entre rede administrativa e rede de atendimento, documente a estrutura.
Acesso remoto: Se colaboradores ou prestadores acessam o sistema remotamente, descreva o mecanismo (VPN, área de trabalho remota, acesso web) e os controles aplicados (autenticação, registro de sessão, horários permitidos).
Certificados digitais: Liste os certificados digitais da serventia, com tipo (e-CPF, e-CNPJ), titular, validade e uso (assinatura de atos, integração com centrais, eSocial). Essa informação deve ser consistente com o inventário de ativos (item 1.7 do provimento).
Política de atualização: Descreva como e quando as atualizações de sistema operacional, firmware de equipamentos e aplicações são realizadas. Atualizações de segurança pendentes são vulnerabilidades conhecidas.
10. Manutenção do documento
O documento de arquitetura deve ser atualizado sempre que houver:
- Troca de equipamentos (estações, roteador, switch, servidor)
- Mudança de link de internet ou operadora
- Novo sistema ou integração
- Alteração na estratégia de backup
- Mudança de fornecedor de sistema ou provedor de nuvem
- Inclusão ou remoção de mecanismos de redundância
Inclua um controle de versão no documento:
| Versão | Data | Autor | Alteração |
|---|---|---|---|
| 1.0 | [data] | [nome] | Versão inicial |
O SIG Virtual mantém controle de versão automático dos documentos publicados na plataforma, facilitando o histórico de alterações e a rastreabilidade.
Dicas práticas
Comece pelo inventário de ativos. Se a serventia já preencheu o inventário (item 1.7 do provimento), boa parte das informações necessárias já está disponível. O documento de arquitetura organiza essas informações numa visão integrada.
Peça ajuda ao técnico de TI. O diagrama de rede e os detalhes de configuração são trabalho técnico. Se a serventia tem contrato com prestador de TI, solicite que ele elabore ou revise o documento. O titular aprova, mas o conteúdo técnico deve ser produzido por quem conhece a infraestrutura.
Solicite documentação ao fornecedor do sistema. Para serventias SaaS, o fornecedor deve fornecer informações sobre a infraestrutura de nuvem, mecanismos de backup, redundância e SLA. Inclua essas informações como anexo.
Não invente dados. Se a serventia não sabe a velocidade real do link de internet, faça um teste de velocidade. Se não sabe a autonomia real do nobreak, faça um teste de carga. Se não sabe o RPO efetivo do backup, calcule com base na frequência. O documento precisa refletir a realidade, não a expectativa.
Documente os pontos fracos. Se o link secundário ainda não foi contratado, registre como pendente. Se o servidor não tem RAID, registre. Se o backup off-site ainda não está configurado, registre. Omitir fragilidades no documento não as elimina, só dificulta a correção.
Documentação complementar
O Documento de Arquitetura Tecnológica se conecta com outros documentos da serventia:
- A Política de Segurança da Informação define as diretrizes gerais de segurança que a arquitetura deve suportar
- O PCN e PRD referenciam a arquitetura para identificar pontos de falha e definir procedimentos de recuperação
- O Plano de Contingência Energética detalha o que acontece com os equipamentos listados no diagrama durante uma queda de energia
- O ROPA/RAT identifica os dados pessoais que trafegam pelos fluxos documentados na arquitetura
- O inventário de ativos (item 1.7 do provimento) é a fonte dos equipamentos e sistemas listados no documento
Referências
- Provimento 213/2026 do CNJ
- Guia de implementação das Etapas 1 e 2 do Provimento 213
- Como elaborar o PCN e PRD do seu cartório
- ISO 27001: Segurança da informação
O SIG Virtual ajuda serventias a organizar políticas, documentos técnicos e controles de gestão numa única plataforma, com versionamento e rastreabilidade. Se o seu cartório precisa se adequar ao Provimento 213, faça o teste gratuito e veja como estruturar esse processo. Confira nossos planos e preços ou entre em contato.
Quer ver o SIG Virtual funcionando?
Teste grátis e veja se faz sentido pra sua empresa.