Receber apenas os dados necessários
Primeiro verificamos se nomes, moradas, dados de contacto, texto livre e conjuntos completos de dados podem ser eliminados. Antes de dados em massa, preferimos pequenas amostras anonimizadas.
Segurança e tratamento de dados
Tratar dados confiados
sem ambiguidade.
Definimos quais dados são tratados, com que finalidade, por quem, em que ambiente e por quanto tempo. De protótipos matemáticos a operações em produção, limites e responsabilidades são acordados primeiro e mantidos como evidência revisável.
PLANO DE CONTROLO DE DADOSPROJETO / 001
01ClienteDados de origem e regras de negócio
Mínimo necessário
02FINITE FIELDDesenho, desenvolvimento, verificação
Âmbito acordado
03Serviços utilizadosNuvem e integrações externas
FinalidadeDefinida antecipadamente
AcessoLimitado às pessoas necessárias
ArmazenamentoLocalização e período acordados
EliminaçãoMétodo e evidência definidos
DESENHAR ANTES DE TRANSFERIRReceber depois de definir os limites
A nossa posição
Publicamos material de decisão, não garantias vagas.
A segurança não é determinada pelo nome de um produto nem por uma única função. Desenhamos em torno do tipo de dados, da finalidade, da organização, das operações e dos subprocessadores, mantendo revisável o âmbito implementado.
Definir limites antes de transferir
A localização de armazenamento, as pessoas com acesso, os serviços externos, o uso de IA, a retenção e a eliminação são acordados antes de receber dados ou passar para produção.
Deixar artefactos revisáveis
Fluxos de dados, permissões de acesso, subprocessadores, backups, eliminação e contactos de incidentes são mantidos como artefactos verificáveis.
O que publicamosPolítica, elementos de desenho e artefactos revisáveis
O que cada projeto decideServiços concretos, permissões, retenção e âmbito de testes
O que não publicamosSegredos ou configurações detalhadas que poderiam ajudar um atacante
Percurso dos dados
Decidir cada etapa desde a receção até à eliminação.
Os mesmos dados exigem controlos diferentes no diagnóstico, em protótipos e na operação em produção. Separamos o que é recebido, o que deve ser decidido e que evidência permanece.
RECEÇÃO
Começar com materiais explicativos e amostras anonimizadas.
Preferir baixo volume de tratamentoExemplos recebidos
- Colunas atuais da folha de cálculo
- Algumas linhas fictícias ou anonimizadas
- Regras de negócio e problemas atuais
- Métricas a melhorar
Decidir antecipadamente
- Se nomes reais são necessários
- Como os anexos são enviados
- Quem gere a consulta
- Retenção depois da consulta
Artefactos mantidos
- Lista de dados recebidos
- Nota de finalidade
- Data-alvo de eliminação
- Perguntas em aberto
PROTÓTIPO
Dados mínimos para testar se o problema pode ser resolvido.
Desenhar validação isoladaExemplos recebidos
- Identificadores de equipa, casos ou equipamentos
- Tempo, qualificação, capacidade e ordem
- Plano atual e métricas
- Amostras de exceções
Decidir antecipadamente
- Método de pseudonimização
- Ambiente de validação e pessoas com acesso
- Uso de IA externa
- Eliminação ou uso continuado após a entrega
Artefactos mantidos
- Dicionário de dados
- Lista de restrições
- Tabela de ambiente e acesso
- Registo de tratamento ao final da validação
DESENVOLVIMENTO
Fixar papéis e limites para dados de produção.
Revisão de desenho necessáriaExemplos recebidos
- Estrutura de dados equivalente à produção
- Utilizadores, permissões e dados da organização
- Especificações de integração externa
- Requisitos de auditoria e backup
Decidir antecipadamente
- Separação de ambientes e segredos
- Privilégio mínimo e autenticação
- Âmbito e retenção de logs
- Âmbito de testes e revisão
Artefactos mantidos
- Diagrama de fluxo de dados
- Matriz de acesso
- Lista de serviços externos
- Registo de revisão pré-lançamento
OPERAÇÃO
Preparar-se para detetar, responder e recuperar, não apenas para proteger.
Operação contínua necessáriaExemplos recebidos
- Contas e permissões
- Logs e alertas
- Backups
- Dependências e atualizações
Decidir antecipadamente
- Horário de monitorização e resposta
- Revisões de alterações e acessos
- Objetivos de recuperação
- Caminho de contacto em caso de incidente
Artefactos mantidos
- Procedimento de operações
- Registo de teste de backups
- Registo de revisão de acessos
- Histórico de incidentes e alterações
ELIMINAÇÃO
Decidir o tratamento mesmo depois de o projeto terminar.
Confirmar o âmbito de eliminaçãoExemplos recebidos
- Cópias de trabalho
- Armazenamento partilhado
- Backups
- Logs, tickets e anexos
Decidir antecipadamente
- Devolução ou eliminação
- Retenção legal e contratual
- Momento de eliminação de backups
- Formato de evidência
Artefactos mantidos
- Lista de objetivos
- Data de eliminação
- Exceções e motivo de retenção
- Confirmação de conclusão
Construtor de perfil de segurança
Organize um rascunho de desenho específico do projeto em cerca de dois minutos.
Esta é uma ajuda de desenho para a primeira reunião, não uma auditoria nem uma garantia. Não são exigidos dados de contacto.
Passo 01 / Classe de dados
Selecione os dados que podem ser tratados
O rascunho baseia-se na categoria que exige o tratamento mais cuidadoso. São permitidas várias seleções.
Passo 02 / Fase de entrega
Que fase está a considerar?
Uma validação breve e uma operação em produção exigem controlos diferentes, mesmo para os mesmos dados.
Passo 03 / Tratamento externo
IA externa e serviços
Serviços de nuvem, e-mail, mapas, analytics e notificações são revistos com a mesma abordagem de fluxo de dados.
Passo 04 / Necessidades operacionais
Selecione as necessidades operacionais requeridas
São permitidas várias seleções. Mesmo pontos incertos são incluídos como temas de reunião.
Rascunho de desenho / não é uma auditoria
Desenho de protótipo limitado
Começar com dados mínimos, retenção breve e um ambiente de validação separado.
PerfilPADRÃOP0-B
Controlos mínimos
Decisões do projeto
Artefactos a preparar
Como ler este resultado:
Este é um rascunho preliminar de desenho com base nas entradas selecionadas. Os controlos finais são decididos depois de confirmar obrigações legais, condições contratuais, ameaças, arquitetura de nuvem e operações.
Modelo de controlo
Cobrir deteção, resposta e recuperação, não apenas prevenção.
Usamos as seis funções do NIST Cybersecurity Framework 2.0 como pontos de vista para a revisão do projeto. Isto não é uma certificação nem uma declaração de conformidade completa.
Governar
Clarificar responsáveis, política, contratos, subprocessadores e risco aceitável.
Exemplo: tabela de responsabilidades, lista de serviçosIdentificar
Compreender ativos, dados, dependências, ameaças e impacto.
Exemplo: fluxo de dados, registo de ativosProteger
Desenhar autenticação, mínimo privilégio, encriptação, segredos e implementação segura.
Exemplo: matriz de permissões, verificação de implementaçãoDetetar
Definir logs necessários, monitorização, alertas e critérios de anomalia.
Exemplo: itens de monitorização, retenção de logsResponder
Preparar triagem, contenção, investigação, comunicação e prevenção.
Exemplo: árvore de contactos, procedimento de primeira respostaRecuperar
Desenhar integridade dos backups, ordem de recuperação, reinício do negócio e revisão posterior.
Exemplo: guia de recuperação, registo de testeSegurança de aplicações
Em sites e aplicações, verificar desde o desenho até à operação.
Usamos o OWASP ASVS 5.0 como referência para requisitos de segurança e itens de verificação. Revisões, verificações automáticas, verificações manuais e testes externos são combinados conforme a importância e o orçamento.
- 01Requisitos e ameaçasOrganizar dados, permissões e superfície de ataque
- 02ImplementaçãoAutenticação, entradas, segredos e dependências
- 03VerificaçãoRevisão, testes e verificação de configuração
- 04OperaçãoMonitorização, atualizações, permissões e recuperação
Protótipo frente a produção
Não tratamos protótipos e produção da mesma forma.
Esta comparação mostra critérios de desenho que são fechados por projeto, não garantias fixas.
| Item de revisão | P0 protótipo matemático | P1 sistema de produção |
|---|---|---|
| Finalidade | Validar viabilidade e métricas | Processamento empresarial contínuo |
| Volume de dados | Preferir campos pequenos, anonimizados e necessários | Definir formalmente o âmbito operacional necessário |
| Ambiente | Separar um ambiente temporário de validação | Considerar separação de desenvolvimento, testes e produção |
| Acesso | Limitar às pessoas designadas | Permissões por função, autenticação e revisões |
| IA externa | Partir de um desenho que não envie dados desnecessários | Acordar finalidade, destino, contrato, configuração e logs |
| Retenção | Decidir primeiro a data de encerramento | Considerar finalidade, lei, operações e backups |
| Eliminação | Confirmar eliminação ou uso continuado após a entrega | Desenhar desativação de contas, fim de contrato, retenção legal e backups |
| Recuperação | Avaliar se pode ser recriado | Definir objetivos de recuperação e testes de backup |
Responsabilidade partilhada
Separar quem protege o quê antes do contrato.
Usar a nuvem não torna tudo seguro automaticamente, e um desenvolvedor não consegue gerir todos os riscos sozinho. Separamos os papéis do cliente, da Finite Field e dos serviços utilizados.
NOSSO ÂMBITO
Desenho, implementação e operações de desenvolvimento
Dentro do âmbito contratado, gerimos os controlos do sistema e o tratamento de dados durante o desenvolvimento.
- Desenho de fluxos de dados e permissões
- Implementação segura de aplicações
- Gestão de segredos e do ambiente de desenvolvimento
- Testes e revisões acordados
- Monitorização, atualizações e resposta dentro do âmbito de manutenção
ÂMBITO DO CLIENTE
Responsabilidades de negócio, utilizadores e dados
O uso lícito dos dados, a operação de utilizadores e dispositivos, e as regras internas continuam a ser responsabilidades importantes do cliente.
- Finalidade e validade dos dados de entrada
- Registo e desativação de utilizadores, e pedidos de permissões
- Dispositivos, rede interna e método de partilha
- Notificação de eventos suspeitos e decisões de negócio
- Instruções de devolução ou eliminação ao finalizar o contrato
ÂMBITO DA PLATAFORMA
O que os serviços de plataforma cobrem
As instalações físicas, os serviços de plataforma e o âmbito dos serviços geridos dependem do contrato e do modelo de responsabilidade partilhada de cada serviço.
- Centros de dados e infraestrutura
- Disponibilidade do serviço e atualizações
- Acesso à plataforma e funções de encriptação
- Condições contratuais de armazenamento e processamento
- Informações sobre incidentes e segurança do serviço
Elementos que devem ser explicitados no contratoOperadorHorário de monitorizaçãoBackupTrabalho de recuperaçãoConsultasTratamento ao final da utilização
IA e terceiros
Não transforme IA externa num subprocessador invisível.
Quando os dados seguem para IA generativa, mapas, e-mail, analytics, notificações, pagamentos ou outros serviços, a finalidade e o âmbito são incluídos no fluxo de dados.
Não enviar
Não envie dados empresariais para IA externa. Use algoritmos comuns, processamento local ou dados anonimizados fixos.
Primeira opção a considerarEnviar dados limitados
Enviar apenas os campos acordados aos serviços definidos depois de remover identificadores. Verificar se as transferências podem ser registadas.
Requer anonimização e minimizaçãoEnviar dentro do âmbito aprovado
Confirmar termos do serviço, retenção, região, condições de reutilização e permissões, e depois documentar os dados abrangidos.
Requer avaliação de risco individualVERIFICAÇÃO DE SERVIÇOS EXTERNOS
O que confirmar por cada serviço externo
- 01Dados enviadosCampos, frequência, volume
- 02FinalidadeProcessamento, notificação, análise
- 03Retenção e reutilizaçãoArmazenamento, aprendizagem, logs
- 04Localização e subprocessadoresPaís, região, cadeia de fornecimento
- 05Parar e eliminarTratamento ao final da utilização
Resposta a incidentes
Planear o que acontece se ocorrer um incidente.
Antes da operação em produção, defina o âmbito de eventos, contactos, primeiro aviso, contenção, recuperação e responsabilidades de prevenção.
Detetar e receber
Detetar eventos a partir da monitorização, contactos de utilizadores ou avisos de serviços.
Conter
Reduzir a propagação e conservar a evidência necessária.
Analisar e decidir
Confirmar dados afetados, causa, impacto e necessidade de notificação.
Comunicar e responder
Contactar as partes interessadas conforme a lei, o contrato e a situação.
Recuperar e melhorar
Recuperar depois de confirmar a segurança e aplicar medidas preventivas.
Antes de produçãoContacto de emergência
Antes de produçãoÂmbito do evento
Antes de produçãoRota do primeiro aviso
Desenho do projetoHorário de monitorização e resposta
Lei e contratoNotificação e relatório
Pacote de evidências
Tornar o trabalho implementado revisável.
Conforme a importância e o âmbito contratual, estes artefactos podem ser criados ou atualizados. Nem todos são entregáveis padrão, por isso o necessário é selecionado durante a estimativa.
CSV / 01
Inventário de dados
Campos, finalidade, sensibilidade, localização, responsável.
Descarregar CSV / 02Registo de fluxo de dados
Origem, destino, finalidade, método, subprocessador.
Descarregar CSV / 03Matriz de acesso
Função, ambiente, operação, aprovação, revisão.
Descarregar CSV / 04Registo de serviços externos
Serviço, finalidade, dados, localização, contrato.
Descarregar CSV / 05Registo de retenção e eliminação
Motivo, prazo, método de eliminação, evidência, exceção.
Descarregar CSV / 06Ficha de contactos de incidentes
Classe de evento, contacto principal, alternativa, responsável pela decisão.
Descarregar CSV / 07Teste de restauração de backups
Objetivo, ponto de recuperação, tempo decorrido, resultado, problema.
Descarregar CSV / 08Lista de verificação de requisitos
Desenho, implementação, testes, operação, tratamento de encerramento.
Descarregar CSV / 09Tabela de decisão sobre IA e serviços externos
Finalidade, campos enviados, retenção, aprovação, procedimento de paragem.
DescarregarPedido
Discutir questionários Apoiar questionários de clientes
Respondemos às listas de verificação de segurança do cliente depois de confirmar as práticas reais e o âmbito do projeto. Elementos ainda não implementados são declarados como tal, separando alternativas.
Referências
Referências e o que não afirmamos.
Usamos leis, diretrizes públicas e normas abertas como referência ao selecionar controlos para um projeto. Referenciá-las não equivale a afirmar certificação nem conformidade completa.
Lei japonesa de privacidade e diretrizes da PPC
É usada como base para verificar medidas de gestão de segurança, regras de tratamento, medidas organizativas, humanas, físicas e técnicas, e ambientes externos.
Abrir fonte oficialNIST Cybersecurity Framework 2.0
As seis funções são usadas como linguagem comum para riscos e lacunas operacionais.
Abrir fonte oficialOWASP ASVS 5.0
É usada como referência ao ordenar requisitos de segurança web e de aplicações, junto com itens de verificação.
Abrir fonte oficialEsta página por si só não implica o seguinte.
Certificação ISO/IEC 27001Certificação PrivacyMarkConformidade completa com o NIST CSFCertificação OWASP ASVSGarantia de ausência de incidentesOs mesmos controlos para todos os projetosPerguntas frequentes
Perguntas frequentes sobre tratamento de dados.
O diagnóstico ou os protótipos exigem dados de produção?
Em princípio, primeiro verificamos se a validação pode ser feita com amostras anonimizadas, pseudonimizadas e minimizadas. Se dados reais forem necessários, acordamos antecipadamente o âmbito, o armazenamento, as pessoas com acesso e o momento de eliminação.
Enviam dados para IA generativa externa?
O uso de IA externa, os dados enviados, a finalidade e a retenção são decididos por projeto. Também pode ser escolhida uma configuração que não envie dados empresariais para IA externa.
É possível escolher o país ou a região de armazenamento?
Verificamos os requisitos de localização dentro das capacidades da nuvem ou dos serviços externos utilizados. Quando a transferência transfronteiriça é relevante, explicitamos os serviços e os fluxos de dados.
O que acontece aos dados e ao código-fonte depois da entrega?
A propriedade, o armazenamento, o acesso, os backups e as responsabilidades de eliminação são clarificados conforme o contrato, o modelo operacional e o âmbito da manutenção.
Têm certificação de segurança?
Esta página não afirma possuir uma certificação específica. Definimos controlos e evidências de revisão por projeto, e respondemos às listas de verificação do cliente quando necessário.
Quando os incidentes são comunicados?
Antes da operação em produção, são definidos os contactos, o âmbito do evento, o método do primeiro aviso e a frequência de atualização. As notificações reais seguem a lei, o contrato e os detalhes do evento.
Podem tratar dados médicos, assistenciais ou outros dados sensíveis?
Devem ser verificados a necessidade, os requisitos legais, o âmbito de acesso, o armazenamento, os logs, a eliminação e os subprocessadores. É necessário um desenho mais rigoroso, e a viabilidade é decidida por projeto.
Podemos solicitar testes de segurança ou avaliação de vulnerabilidades?
Conforme o objetivo e o nível exigido, podem combinar-se revisão de desenho, verificações automatizadas, revisão manual e especialistas externos. O âmbito e os entregáveis são especificados durante a estimativa.
Próximo passo
Primeiro, separe os dados que podem ser partilhados dos dados que devem ficar de fora.
Antes de enviar um workbook completo, pode começar com nomes de colunas ou amostras anonimizadas. Organizaremos em conjunto os controlos necessários e o âmbito de desenvolvimento.
Iniciar o diagnóstico Discutir o tratamento de dados Confirme o método de transferência antes de enviar informação confidencial.