A residência de dados descreve onde os dados são armazenados ou tratados. Um servidor suíço não estabelece a localização de backups, sistemas de suporte, integrações externas ou de todas as pessoas com acesso; avalie esses componentes separadamente.
Separe a localização da máquina do percurso dos dados
Uma etiqueta de país num plano de alojamento responde a uma questão restrita: onde está localizada a configuração listada. A sua aplicação pode ainda enviar informação para outros locais. O relato de erros, a entrega de email, o processamento de pagamentos, os backups externos e o acesso administrativo fazem parte do serviço mesmo quando estão ausentes do diagrama de infraestrutura. Trate o destino suíço como uma entrada num mapa de dados, em vez de uma conclusão sobre o projeto completo.
Comece por nomear a informação que trata. Um site de documentação pública, um portal de clientes e um arquivo privado precisam de controlos diferentes. Distinga conteúdo publicado, informação pessoal, segredos de autenticação e registos operacionais internos. Registe por que existe cada categoria e o que aconteceria se fosse divulgada, alterada ou perdida. Isto torna as decisões posteriores de localização concretas, em vez de depender do apelo geral de uma jurisdição.
Construa um pequeno registo de tratamento
Siga uma ação representativa do utilizador desde o browser até ao armazenamento. Anote que sistema recebe o pedido, o que escreve e que outros serviços são notificados. Repita o exercício para criação de conta, recuperação de palavra-passe, uploads e suporte. Descobrirá frequentemente cópias secundárias em logs, filas de email e exportações de diagnóstico. Registe-as enquanto a arquitetura ainda é suficientemente simples para ser alterada.
Use um registo com uma finalidade, destino, responsável de acesso e decisão de retenção para cada componente. Não precisa de uma ferramenta de conformidade elaborada para começar. A propriedade útil é que alguém consiga explicar cada linha e atualizá-la após uma nova integração. Um diagrama sem localizações de backup ou acesso administrativo está incompleto para uma decisão de residência.
| Componente | O que estabelecer | Evidência útil |
|---|---|---|
| Base de dados principal | Localização de alojamento e acesso permitido | Especificação do serviço e política de acesso |
| Cópia de recuperação | Destino, retenção e eliminação | Configuração de backup e procedimento de restauração |
| Exportação de suporte | Conteúdo e destinatários | Amostra redigida e política de suporte |
| Integração externa | Informação enviada e termos de tratamento | Configuração da integração e documentação do fornecedor |
Compreenda a responsabilidade que permanece consigo
O Comissário Federal Suíço de Proteção de Dados e Informação explica que a externalização do tratamento não remove a responsabilidade do responsável pelo tratamento pela proteção de dados. As suas orientações abrangem a seleção de subcontratantes, a emissão de instruções e a verificação do tratamento de dados pessoais. Isto é razão para inspecionar a relação de serviço, bem como a localização do rack. As obrigações exatas para a sua organização dependem do quadro aplicável e da informação envolvida.
Quando a informação pode ser divulgada além-fronteiras, use as orientações oficiais relevantes e obtenha aconselhamento para decisões que exijam uma avaliação jurídica. Evite declarar que um nome de país torna automaticamente a aplicação conforme. Pergunte quem são os subcontratantes e subcontratantes adicionais, onde ocorre o tratamento e que disposições se aplicam. Mantenha as respostas com a documentação operacional do projeto para que a decisão possa ser revista mais tarde.
Reduza a informação que exige uma decisão de localização
Recolha apenas o que serve uma finalidade definida. Uma newsletter não precisa necessariamente de uma morada postal completa, e um relatório de resolução de problemas raramente precisa de toda uma base de dados de clientes. Remover campos desnecessários reduz a exposição e simplifica a retenção. Mantenha segredos fora das ferramentas de diagnóstico e considere se medições agregadas respondem à questão operacional sem reproduzir registos individuais.
A encriptação pode ajudar a proteger cópias específicas, mas identifique quem controla as chaves e onde ocorre a desencriptação. Uma aplicação que tem de tratar dados legíveis não pode ser tratada como se ninguém pudesse alguma vez aceder-lhes. Da mesma forma, um identificador pseudónimo pode ainda ligar registos ao longo do tempo. Descreva o controlo implementado com precisão, em vez de usar um selo de encriptação como substituto do mapa de tratamento.
Um cenário prático: um pequeno portal de clientes
Imagine um portal alojado num VPS suíço, com uma cópia de recuperação independente e um serviço de email de terceiros. A base de dados de clientes permanece no VPS durante o funcionamento normal, mas as mensagens de reposição de palavra-passe e as notificações de suporte saem dessa máquina. A equipa deve registar os campos mínimos dessas mensagens, o destino utilizado para as cópias de segurança e as pessoas autorizadas a exportar registos.
Uma revisão sensata pode substituir um registo completo num relatório de erro por uma referência de incidente aleatória, reduzir o período de retenção de diagnósticos e restringir o acesso às cópias de segurança. Estas alterações são úteis independentemente do país selecionado. O exemplo é um exercício de planeamento, não uma afirmação de que o SwissOctet inclui estas integrações ou verificou um determinado regime de residência de dados.
Verifique o mapa antes de assumir um compromisso público
Antes de prometer uma localização aos seus utilizadores, compare o registo com a configuração real e os termos de serviço confirmados. Teste se os procedimentos de cópia de segurança e eliminação funcionam como esperado. Reveja as exportações, os agentes de monitorização e as tarefas agendadas, porque podem introduzir cópias de que ninguém se lembra durante a compra inicial. Atribua a alguém a aprovação de novos destinos e a atualização do registo quando a arquitetura mudar.
O SwissOctet apresenta configurações suíças no seu catálogo. As disposições de tratamento do operador em produção, o acesso ao suporte e as regras de retenção devem ser confirmados separadamente antes de uma encomenda real. Escolha a infraestrutura com esse limite em vista: uma localização suíça clara pode suportar a sua arquitetura, enquanto um mapa de dados completo e mantido sustenta as afirmações que faz sobre ela.
A sua lista de verificação prática.
- Classifique a informação tratada pelo projeto.
- Mapeie o armazenamento principal, as cópias de segurança, os registos e as integrações.
- Identifique os subcontratantes, os responsáveis pelo acesso e as decisões de retenção.
- Reveja as orientações oficiais para as questões transfronteiriças aplicáveis.
- Verifique a configuração real antes de prometer residência de dados.
Os detalhes que importam.
Um servidor suíço significa que todas as cópias permanecem na Suíça?+
Não. Os destinos das cópias de segurança, as exportações, os sistemas de suporte e as integrações têm os seus próprios percursos de dados e devem ser verificados separadamente.
A encriptação elimina a necessidade de mapear o tratamento?+
Não. Continua a ser necessário saber onde existem os dados e as chaves, quem os pode desencriptar e que tratamento é efetuado.
Este guia certifica uma implementação do SwissOctet?+
Não. Fornece um método de planeamento. Os termos de tratamento em produção e os controlos implementados têm de ser confirmados para o serviço específico.
Vá à fonte.
Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.
- FDPIC: Tratamento de dados na nuvem www.edoeb.admin.ch
- FDPIC: Externalização do tratamento de dados www.edoeb.admin.ch
- FDPIC: Transferência transfronteiriça de dados pessoais www.edoeb.admin.ch
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.