A cartografia dos sistemas de informação mostra como a atividade depende de aplicações, dados, pessoas, equipamentos e prestadores. Um inventário de software é um ponto de partida, mas não explica por onde circula a informação nem o efeito de uma falha. O resultado útil combina uma lista de objetos com relações e vistas adequadas às decisões que a organização precisa de tomar.
Este guia propõe uma construção progressiva, com um fluxo preenchido de gestão de clientes e critérios de verificação. O mapa serve a segurança, a continuidade e a proteção de dados. Deve ajudar a responder a perguntas concretas: quem recebe uma exportação, que aplicações dependem do mesmo serviço de identidade e que processos param se um fornecedor ficar indisponível?
Definir o objetivo antes de desenhar
Escolha as decisões que o mapa deve apoiar. Uma equipa de resposta a incidentes precisa de relações entre sistemas e acessos; o responsável por proteção de dados precisa de ligar finalidades, destinatários e operações; a direção precisa de compreender serviços críticos e dependências. Uma única imagem com todos os detalhes pode não servir bem nenhum destes leitores.
A ANSSI apresenta uma metodologia progressiva de cartografia, organizada em cinco etapas e apoiada em diferentes vistas. O guia tem origem francesa e pode ser usado como referência metodológica por outras organizações, sem transpor obrigações setoriais francesas para Portugal. ANSSI: cartografia do sistema de informação.
No primeiro âmbito, escolha um processo relevante e algumas dependências. Por exemplo, siga um pedido de cliente desde o formulário até ao serviço prestado e à faturação. Uma amostra completa e verificável pode revelar campos necessários no inventário antes de a organização tentar representar todas as aplicações.
Separar atividades, aplicações e infraestrutura
A vista de atividade descreve processos, responsáveis e informação necessária. A vista aplicacional identifica serviços de software e fluxos. A vista técnica descreve componentes e ligações relevantes para operar e proteger esses serviços. As vistas devem poder ser relacionadas através de identificadores estáveis.
Uma aplicação pode suportar várias finalidades, e uma finalidade pode usar várias aplicações. A gestão de clientes pode envolver formulário, CRM, correio eletrónico, armazenamento e faturação. Não crie uma equivalência automática entre uma aplicação e uma linha do registo de tratamento.
O registo de atividades de tratamento mantém o enquadramento das operações de dados pessoais. O artigo 30.º do RGPD define os elementos dos registos do responsável e do subcontratante. A cartografia acrescenta relações operacionais e técnicas, ajudando a manter esses elementos coerentes com a realidade. RGPD, artigo 30.º.
Criar um inventário mínimo de objetos
Para cada aplicação, registe nome, identificador, função, dono do processo, administrador, fornecedor e estado. Acrescente localização relevante dos dados, tipos de utilizador, dependências e fonte da informação. Um objeto sem dono tende a permanecer desatualizado porque ninguém recebe a responsabilidade de confirmar mudanças.
| Objeto no exemplo | Identificador | Responsabilidade e finalidade |
|---|---|---|
| Formulário de pedidos | APP-01 | Equipa comercial; receber contactos e descrição inicial |
| Gestão de clientes | APP-02 | Dono do processo comercial; acompanhar pedidos |
| Arquivo de documentos | APP-03 | Responsável operacional; guardar documentos necessários à prestação |
| Faturação | APP-04 | Responsável financeiro; emitir e gerir documentos de faturação |
| Serviço de identidade | ID-01 | TI; autenticar utilizadores nas aplicações abrangidas |
Não coloque palavras-passe, chaves privadas ou tokens no inventário. A localização de um segredo pode ser descrita como uma referência controlada ao mecanismo de gestão, sem revelar o valor. O mapa pode ser sensível e deve ter permissões proporcionais ao detalhe que contém.
Descrever os fluxos como operações
Cada ligação deve indicar origem, destino, conteúdo, finalidade, frequência e meio de transmissão. Uma seta sem legenda não permite saber se há leitura em tempo real, envio de ficheiro ou cópia integral. Também não mostra quem pode iniciar a operação ou o que acontece quando ela falha.
No exemplo, APP-01 transmite nome, contacto e descrição do pedido para APP-02 após o envio do formulário. APP-02 envia para APP-04 apenas os dados necessários à faturação quando há uma prestação confirmada. APP-03 guarda documentos do serviço e fornece uma referência ao pedido, evitando copiar o mesmo ficheiro para todos os sistemas.
Registe também os percursos manuais. Um colaborador pode exportar uma lista para uma folha de cálculo e enviá-la a um prestador, mesmo sem existir uma integração formal. Estes fluxos costumam aparecer numa entrevista com o dono do processo, e podem não constar da documentação técnica do fornecedor.
Identificar pessoas e entidades que recebem dados
Distingua utilizadores internos, prestadores e outros destinatários. O fornecedor da aplicação, o prestador de suporte e o parceiro que recebe um relatório podem ser entidades diferentes. Confirme os nomes jurídicos quando a decisão depende da entidade e não apenas da marca do serviço.
A matriz de responsável e subcontratante ajuda a qualificar os papéis por operação. Não deduza o papel apenas do facto de existir uma fatura ou um contrato de software. Registe quem define a finalidade e as decisões essenciais do tratamento, e quem executa instruções.
A avaliação de transferências internacionais precisa de mais do que o país do centro de dados. Inclua acessos remotos e subcontratação subsequente quando relevantes. O alojamento na União Europeia não dispensa verificar se outro destinatário pode aceder aos dados a partir de um país terceiro e em que condições.
Descobrir dependências que uma lista de software não revela
Uma aplicação depende frequentemente de identidade, rede, correio, certificados, armazenamento e pessoas autorizadas. A falha de um serviço partilhado pode afetar vários processos ao mesmo tempo. Identifique essas dependências comuns para evitar planos que tratem cada aplicação como se fosse independente.
O plano de continuidade usa estas relações para definir prioridades de recuperação e alternativas. Se o canal alternativo exige a mesma autenticação que falhou, a alternativa não resolve o cenário. A cartografia deve mostrar a dependência para que a equipa possa rever o desenho antes de um incidente.
Inclua também prestadores externos de telecomunicações, suporte e operações críticas. O objetivo não é desenhar toda a cadeia económica, mas compreender os elos necessários ao serviço e os contactos para os gerir. A profundidade depende da decisão e da capacidade de manter a informação atualizada.
Recolher informação de várias fontes
Combine entrevistas, contratos, registos de compras, configurações e inventários técnicos. Cada fonte tem limites. A equipa de compras conhece contratos, mas pode não conhecer uma integração instalada por um utilizador; o administrador conhece sistemas, mas pode não saber por que motivo uma área exporta dados todas as semanas.
Peça demonstrações com exemplos de ensaio quando a descrição não for clara. Siga o percurso de um pedido e confirme onde surgem cópias e notificações. Registe como a informação foi verificada, a data e as dúvidas ainda abertas. Uma suposição deve continuar visível como suposição até ser confirmada.
A política de logs pode ajudar a corroborar fluxos, respeitando o acesso e a finalidade dos registos. Não transforme a construção do mapa numa recolha massiva de conteúdo de utilizadores. Muitas relações podem ser verificadas através de configuração e metadados, sem abrir documentos de clientes.
Exemplo preenchido de uma lacuna descoberta
Durante a revisão de APP-02, a equipa identifica uma exportação mensal para uma ferramenta de análise que não estava no inventário. O dono do processo explica que o ficheiro inclui contactos, notas livres e estado do pedido. A finalidade declarada é acompanhar tempos de resposta, o que pode não exigir todos esses campos.
A decisão hipotética é: “Adicionar a ferramenta e o fluxo ao inventário; suspender novas exportações com notas livres até à revisão; definir conjunto mínimo de campos; confirmar destinatário, acesso e conservação; atribuir ao dono comercial a validação da necessidade e a TI a configuração do envio.”
A auditoria de minimização desenvolve a revisão dos campos. Depois da alteração, o mapa deve refletir o novo fluxo e conservar a referência da decisão. Não basta apagar a seta antiga do desenho se a exportação continuar programada na aplicação.
Escolher uma representação que a equipa mantenha
Uma folha de cálculo pode ser suficiente para o inventário inicial, desde que tenha identificadores, campos consistentes e controlo de versões. Um diagrama pode apresentar relações selecionadas. Ferramentas especializadas podem ajudar em volumes maiores, mas não resolvem automaticamente nomes inconsistentes, donos ausentes ou finalidades por esclarecer.
Defina uma legenda simples para objetos, fluxos e estado de validação. Evite usar a cor como único meio de distinguir um elemento. Mostre a data e o âmbito em cada vista para que um leitor não interprete uma representação parcial como retrato de toda a organização.
Se a informação for exportada para apresentações, indique a fonte e a versão. Uma cópia desatualizada pode circular muito depois de a base ter sido corrigida. Para decisões operacionais, a equipa deve saber onde consultar a versão de referência.
Proteger e atualizar o mapa
Atribua diferentes níveis de acesso quando necessário. A direção pode consultar uma vista de serviços e riscos sem receber detalhes de administração de rede. Um prestador deve ver o âmbito necessário à sua tarefa, não todas as dependências e controlos internos da organização.
A política de segurança deve definir a responsabilidade de manutenção. Alterações de aplicação, fornecedor, finalidade, acesso ou integração devem desencadear uma revisão do mapa. Integre essa revisão nos processos existentes de contratação e mudança, para que não dependa apenas de uma campanha anual de entrevistas.
Registe também o encerramento de aplicações. Confirme o destino dos dados, contas, integrações e cópias. Uma aplicação pode desaparecer da lista de compras e continuar acessível num equipamento ou serviço antigo, com informação que ninguém voltou a rever.
Verificação final com três perguntas
Escolha um fluxo e peça a outra pessoa que identifique o dono, os dados enviados e o destinatário sem consultar o autor do mapa. Depois escolha uma aplicação indisponível e peça que indique os processos afetados e as dependências a recuperar. Finalmente, escolha um fornecedor que muda o local de suporte e identifique as avaliações que precisam de revisão.
Se as respostas exigirem adivinhação, falta informação ou a representação não está adequada ao seu objetivo. Corrija o inventário e as relações antes de acrescentar mais detalhe gráfico. O mapa está pronto para uso quando apoia decisões reais, mostra o que ainda não foi confirmado e tem responsáveis capazes de o manter ao longo das mudanças.