Privacidade "by Design" – ArteSoftware
Privacidade "by design" é uma abordagem para desenvolvimento de soluções de software que valoriza e prioriza as questões de privacidade desde a concepção. Ela perpassa todo o processo de construção de uma solução de software e está presente em vários aspectos do produto final, incluindo, principalmente, os processos de negócio para os quais a solução foi criada.
Este termo e suas implicações vêm sendo largamente usados no contexto da LGPD [1] e da tendência de proteção à privacidade em soluções de software. A importância do tema é diretamente proporcional aos investimentos, impactos e dilemas que as empresas vêm enfrentando para se adequar à nova legislação de proteção de dados pessoais (LGPD).
Caso você queira saber mais sobre LGPD e seus impactos, acesse os artigos relacionados. Neste artigo, apresentaremos os 7 princípios da "privacidade by design" e os relacionaremos a um ciclo de vida genérico de criação de uma solução de software. O conteúdo sobre os 7 princípios é baseada e traduzida diretamente dos conteúdos originais [2] sobre o tema, já a segunda parte é um conteúdo original e será expandido, em breve, em artigos futuros.
Comumente, o termo original em inglês "privacy by design" é traduzido para "privacidade desde a concepção". Esta tradução reforça uma das mais importantes características da abordagem que é o fato de uma solução ter a privacidade contemplada desde o primeiro momento. Contudo, perde um pouco da semântica em relação à privacidade sendo inserida, embutida e como parte integrante do "design" ou projeto desta solução. Assim, daremos preferência a usar o termo misto "privacidade by design", sem contudo, diminuir a importância da necessidade da precocidade do tema.
O termo original "privacy by design" foi criado por Ann Cavoukian em meados da década de 90 e posteriormente formalizado por autoridades de proteção de dados do Canadá e da Holanda. Em 2009 foi publicado o "Privacy by Design Framework" e , desde então, vem sendo adotado por organizações internacionais de proteção de dados.
Em 2016 foi criada a GDPR [3] (General Data Protection Regulation – Regulamento Geral sobre Proteção de Dados – em tradução livre), entrando em vigor dois anos depois. Na GDPR foram incorporados os princípios da privacidade "by design" e, dessa forma, a abordagem ganhou muita relevância dentro do tema proteção de dados pessoais e consequentemente na área de desenvolvimento de soluções de software.
Em alguns países europeus sob a regulação da GDPR os dados pessoais são considerados parte indissociável do cidadão e portanto as regras e formas de uso tendem a respeitar ao máximo os direitos do titular dos dados. Dessa forma, a privacidade "by design" encaixou-se perfeitamente ao novo contexto por, entre outras coisas, ter o usuário como centro das preocupações. Assim, a GDPR e a privacidade "by design" influenciaram-se e potencializaram-se mutuamente, fazendo do tema um assunto indispensável na área de TI.
Modo de Operação Padrão das Organizações
Ao considerarmos que legislações como LGPD e GDPR afetam desde empresas gigantes que atuam sobre dados como Google e Facebook até uma padaria ou o consultório médico, podemos inferir que a privacidade "by design" é igualmente abrangente para as organizações. Na verdade, de acordo com a privacidade "by design", as organizações devem fazer da proteção de dados o seu modo de operação padrão e não ações avulsas ou eventuais. Isso vale para todas as organizações.
A estratégia de simplesmente tentar cumprir os itens das regras em vigor (compliance), no caso da construção de soluções de software, pode não só não funcionar como ser um tiro no pé. A organização como um todo deve incorporar os princípios e boas práticas de privacidade de forma sustentável a longo prazo.
Soluções com Privacidade "by Design"
A adoção de privacidade como operação padrão implica em aplicar privacidade "by design" não só nos sistemas informatizados, mas em todo o processo de negócio que um sistema venha a suportar. Se o negócio da empresa não leva em consideração a privacidade, ou pior, é baseado em tratamento irregular de dados pessoais, o software fica com opções muitíssimo limitadas em relação aos direitos dos titulares destes dados.
Privacidade "by design" deve aplicar-se a toda a solução, desde o processo de negócio, passando pela construção de software e indo até a sustentação da solução em produção. Isto inclui sensibilizar e capacitar todas as pessoas envolvidas nestes processos.
Os 7 Princípios da Privacidade "by Design"
De uma forma simplificada, a privacidade "by design" pode ser apresentada através de seus 7 princípios fundamentais [2]. Neste artigo, além de apresentar o conteúdo original, serão apresentadas ações que podem ser tomadas dentro de um ciclo de vida de desenvolvimento de soluções de software. Não foi selecionado nenhum ciclo de vida ou processo de software específico. Na verdade, as ações práticas foram organizadas em 5 etapas comuns a quase todo processo de desenvolvimento e podem ser vistas na figura 1.
Figura 1 – Ciclo de vida genérico de solução
Este ciclo de vida genérico apresenta 5 etapas ou fases que podem ser brevemente descritas conforme abaixo:
Prospecção – Ocorre antes da solução de fato existir. É quando uma oportunidade de negócio está tendo sua viabilidade avaliada e será tomada a decisão de iniciar a construção ou não (Go/No Go). Geralmente esta é a fase onde melhor pode-se influenciar o negócio.
Concepção – A solução já foi demandada e o produto de software precisa ser pensado e projetado. Em alguns processos é a fase de requisitos e/ou análise e projeto onde decisões são tomadas.
Construção – Etapa onde o software está sendo efetivamente implementado. Pode ser dividida em muitas outras etapas como iterações, sprints ou releases inteiras.
Entrega – Momento em que o cliente afere se o produto é o que de fato esperava. Caso afirmativo, ocorre uma entrega para uso em produção.
Produção – Representa a solução de software efetivamente sendo usada. Apesar do processo de construção poder ter sido encerrado, muitas ações de outras naturezas devem ser tomadas. Em caso de novos módulos ou releases, as outras etapas ocorrem em paralelo com o produto em produção.
A seguir são apresentados cada um dos 7 princípios da privacidade "by design" e algumas ações práticas que foram organizadas de acordo com as etapas acima.
Princípio 1: Proativo, não Reativo; Preventivo, não Corretivo
A abordagem de privacidade "by design" (PbD) é caracterizada por medidas proativas e não reativas. Antecipa e evita eventos invasivos de privacidade antes que eles aconteçam. A PbD não espera que os riscos de privacidade se materializem, nem oferece remédios para resolver infrações de privacidade depois que elas ocorrerem – ela visa impedir que isso ocorra. Em resumo, a privacidade "by design" vem antes do fato, não depois. [2]
A palavra chave relacionada a este princípio é "antecipação". Isto porque quando se trata de privacidade e dados pessoais, os incidentes não costumam permitir "voltar atrás". Ou seja, um vazamento de dados, por exemplo, não pode ser desfeito ou revertido. Dessa forma, a melhor abordagem sempre é a de tomar ações preventivas mesmo quando elas parecem desnecessárias ou exageros para algumas pessoas.
Naturalmente, tais ações tem um custo. Como qualquer investimento ou seguro, deve estar claro para o investidor as consequências de economizar neste item. Postergar ações práticas sobre privacidade pode gerar uma dívida técnica que jamais será paga até que ocorra alguma consequência mais séria.
Capacitar as pessoas antes do início dos projetos
Mapear antecipadamente possíveis falhas e incidentes com seus impactos
Incluir nos requisitos não funcionais as questões de privacidade
Realizar evento de avaliação com áreas transversais e/ou especialistas
Elaborar/manter/aplicar manual de boas práticas sobre privacidade e desenvolvimento seguro
Verificação dos requisitos de privacidade junto aos testes
Elaborar/manter um checklist do que deve ser verificado na homologação
Incorporar questões de privacidade aos critérios de aceite da homologação
(dividir a responsabilidade com o cliente)
Princípio 2: Privacidade como Configuração Padrão (by Default)
Todos podemos ter certeza de uma coisa – o "default" reina! A privacidade "by design" busca oferecer o nível máximo de privacidade, garantindo que os dados pessoais sejam protegidos automaticamente em qualquer sistema de TI ou prática de negócio. Se um indivíduo não faz nada, sua privacidade ainda permanece intacta. Nenhuma ação é necessária por parte do indivíduo para proteger sua privacidade – ela está embutida no sistema, por padrão. [2]
O usuário é o titular sobre seu dados pessoais, ou seja, ele é o dono do dado enquanto a empresa que realizará tratamentos com fins comerciais estará usando estes dados emprestados. Dessa forma, é justo que o usuário não tenha que se preocupar em configurar sua privacidade em dezenas ou centenas de sistemas e aplicativos que acaba usando ao longo da vida.
O mais justo nessa relação entre titular e organizações que usam seus dados é que, no mínimo, os sistemas já venham com a maior configuração de privacidade garantindo a tranquilidade do usuário/titular. Assim, caso ele deseje e/ou aceite, ele mesmo pode ajustar essas configurações, mas sem essa obrigação.
Não especificar nenhum clique ou ação do usuário para o software rodar no nível mais alto de proteção de privacidade
Aferir se após instalado/implantado o software tem a configuração com maior privacidade possível
Princípio 3: Privacidade Embutida no Design
A privacidade "by design" está incorporada ao design e arquitetura dos sistemas de TI e práticas de negócios. Não é adicionada como um complemento, após o fato. O resultado é que a privacidade se torna um componente essencial do núcleo da funcionalidade sendo entregue. A privacidade é parte integrante do sistema, sem reduzir as funcionalidades. [2]
Na realidade de um projeto de software, os aspectos de privacidade são bastante semelhantes a outras práticas de desenvolvimento por vários motivos. Se pensarmos em como testes de unidade devem ser feitos, sabemos que o maior valor de um teste desse tipo é quando feito junto ou até mesmo antes da própria unidade de código. Fazer mais tarde acaba por perder o feedback sobre o design e, na maioria dos casos, o teste simplesmente nunca mais será feito.
Da mesma forma, a privacidade não deve ser adicionada ao software como uma funcionalidade separada, pois não é. Cada funcionalidade que trata dados pessoais vai precisar estar alinhada com as normas e melhores práticas de privacidade desde a primeira linha de código bem como o requisito que a especificou. Uma tentativa de adicionar aspectos de privacidade tardiamente pode mostrar-se simplesmente inviável do ponto de vista do prazo, esforço ou até mesmo do negócio que já pode ter sido modelado de forma equivocada.
Mapear no negócio as questões de privacidade (não só no software)
Especificar e classificar os metadados
Prever nos requisitos funcionais as questões de privacidade
Privacidade não é funcionalidade à parte e não é priorizável como item de backlog
Princípio 4: Funcionalidade Completa – Soma Positiva e não Soma Zero
A privacidade "by design" busca acomodar todos os interesses e objetivos legítimos de maneira positiva em que todos saem ganhando, não através de uma abordagem datada de soma zero, onde são feitas compensações desnecessárias. A privacidade "by design" evita a pretensão de falsas dicotomias, como privacidade versus segurança, demonstrando que é possível ter as duas. [2]
Uma parte significativa da economia mundial hoje é totalmente baseada na coleta, processamento e análise de dados pessoais. Milhões de empregos são gerados nas empresas cujos modelos de negócio dependem totalmente da capacidade de acesso a este tipo de dado. De outro lado, os usuários, que também são a matéria prima destes modelos de negócio, devem ter total controle sobre uma coisa que lhes é propriedade e até parte deles mesmos (de acordo com a lei de alguns países).
Neste cenário, este aparente conflito é o tema deste quarto princípio da privacidade "by design". Se temos que escolher entre um ou outro estamos diante de algo parecido com um jogo de "soma zero" [4] onde alguém ganha e alguém perde. Contudo, o princípio da funcionalidade completa propõe que se usados para interesses legítimos da organizações e devidamente consentidos pelos usuários, as soluções de software podem perfeitamente fazer uso de dados pessoais, gerando valor para ambos: titular e controlador do dado.
Este outro cenário, onde todos podem tirar vantagem, se parece mais com um jogo de soma positiva, como um jogo onde todos jogam contra o tabuleiro de forma cooperativa. Se eventualmente requisitos ou desejos do negócio conflitam com a privacidade do usuário, deve-se fazer uma adaptação da funcionalidade de forma que a solução permaneça justa e benéfica para todos.
Validar viabilidade em relação à privacidade (LGPD) antes de dar "GO"
Especificar funcionalidades que usam dados pessoais com real necessidade
Especificar requisitos harmônicos entre si (os de negócio e os de privacidade)
Especificar estratégia de anonimização e retenção dos dados
Princípio 5: Segurança de Ponta a Ponta
A privacidade "by design", tendo sido incorporada ao sistema antes do primeiro elemento de informação ser coletado, estende-se com segurança por todo o ciclo de vida dos dados envolvidos – fortes medidas de segurança são essenciais à privacidade, do início ao fim. Isso garante que todos os dados sejam retidos com segurança e, em seguida, com segurança e em tempo hábil, destruído no final do processo. Assim, a privacidade "by design" garante do berço ao túmulo, ciclo de vida seguro do gerenciamento da informação, de ponta a ponta. [2]
Problemas de software têm origem fora do software com mais frequência do que costumamos supor. Uma falha de segurança é rapidamente atribuída a falta de conhecimento técnico ou simples erro de implementação. De fato, essa costuma ser a versão oficial quando algo catastrófico ocorre. Porém, muitas vezes, os erros na fase de construção ou desenvolvimento são gerados em momentos anteriores através de prazos inadequados, falta de capacitação ou simples aumento inesperado de escopo.
Como visto no primeiro princípio, questões de privacidade não costumam dar uma segunda chance. Assim, é necessário aplicar medidas de segurança de dados desde o momento em que a solução ainda nem existem até o momento em que ela já é um software sendo usado em produção. Estas medidas são do interesse do time de desenvolvimento, mas são igualmente parte do trabalho de todos os envolvidos no processo de sustentação da solução, incluindo o cliente que provavelmente é um controlador de dados pessoais e tem responsabilidades legais sobre eles.
O cliente e a equipe devem ser informados e sensibilizados sobre o tema
Elaborar os planos de ação e definições de autorização
Aplicar ações contínuas e de segurança previamente definidas
Princípio 6: Transparência e Visibilidade
A privacidade "by design" procura garantir a todos os interessados que, independentemente da prática de negócio ou tecnologia envolvida, de fato, age-se de acordo com as promessas e objetivos declarados, sujeito a verificação independente. Suas partes integrantes e operações permanecem visíveis e transparentes, tanto para usuários quanto para fornecedores. Lembre-se: confie, mas verifique. [2]
Quando elaborado em meados da década de 90, este princípio era uma forte recomendação para as organizações. Atualmente, com a chegada da GDPR, LGPD e demais legislações sobre o tema, a transparência em relação a uso de dados pessoais é uma premissa sem a qual uma solução não deveria sequer ser construída. Tanto a GDPR quanto a LGPD, por exemplo, possuem artigos específicos sobre os direitos dos titulares dos dados – e eles não são poucos.
Atualmente, uma solução de software que utiliza dados pessoais não pode ser pensada sem algum tipo de módulo de relacionamento com o titular do dado. Através deste conjunto de funcionalidades o titular pode, por exemplo, confirmar existência de uso de seus dados, obter ou corrigir os dados e, de forma geral, até exclui-los permanentemente. Tais funcionalidades passarão a ser aspectos absolutamente comuns aos sistemas tanto quanto funcionalidades de autenticação e autorização (login), por exemplo.
Outra questão bastante séria e sensível é a troca de dados entre empresas. Tanto a GDPR quanto a LGPD tratam esse assunto de forma especial. Um dos muitos direitos do titular é saber com quem uma empresa compartilhou seus dados pessoais. Isto requer um esforço extra de monitoramento e registro de operações e processos que atualmente é bastante raro de ser encontrado. É melhor que uma solução já seja criada com este tipo de capacidade, caso contrário a implementação de uma extração desse tipo pode ser proibitiva.
Elaborar e publicar uma política de privacidade clara e conhecida pelo usuário
Prever e mapear o registro dos tratamentos realizados nos dados pessoais
Previsão de funcionalidades para relacionamento com o titular dos dados onde ele mesmo pode conferir o uso de seus dados
Mapeamento de integrações com foco em trocas de dados pessoais
Auditar as políticas e estratégias definidas (anonimização, retenção etc)
Princípio 7: Respeito pela Privacidade do Usuário (Usuariocêntrico)
Acima de tudo, a privacidade "by design" exige que arquitetos e operadores mantenham os interesses do indivíduo em primeiro lugar, oferecendo medidas como fortes padrões de privacidade, avisos apropriados e fortalecimento de opções de facilidade de uso. [2]
Usando os termos presentes na LGPD, em relação a dados pessoais, existem dois tipos principais de atores: o titular que é o dono do dado e o controlador que é a quem cabe as decisões sobre o que fazer com o dado visando alguma finalidade, com ou sem fins comerciais. Ao segundo são assegurados vários direitos, mas é ao primeiro que está garantida a titularidade e propriedade dos seus próprios dados pessoais. Assim, este último princípio da privacidade "by design" deixa claro que o direito do usuário é o centro das decisões e escolhas de negócio ou tecnológicas que venham a ser tomadas na construção de uma solução.
Uma nova solução, por exemplo, ao realizar um evento de "design thinking" deve sempre ter o usuário como persona e suas "dores" de privacidade elencadas para ajudar na definição de funcionalidades e requisitos. Os requisitos não funcionais, inclusive, devem ter claramente descritos os termos de consentimento e uso para que a construção os obedeça. Além disso, os requisitos não funcionais devem contemplar questões como facilidade de uso e padrões de consentimento para que o usuário possa exercer seus direitos sem precisar ser um especialista em várias modalidades de interfaces de consentimento.
Empatização: Incorporar a persona "Usuário" e suas "dores" relativas a privacidade (o sistema pertence a um cliente, mas é usado por alguém que pode não ser ele)
Elaborar termos de consentimento acessíveis, claros e com finalidades definidas
Aplicação de melhores práticas de UX (experiência do usuário, padrões de uso e avisos sobre privacidade)
MAP-CVS: Mapa de Ações de Privacidade no Ciclo de Vida da Solução
Figura 2 – Mapa de Ações Práticas no Ciclo de Vida da Solução
A figura 2 mostra um esquema visual para organizar as ações práticas associadas aos seus devidos princípios (números) e dentro de alguma etapa do ciclo de vida (cores/área). Este mapa de ações pode ser considerado um resumo das ações práticas aplicadas às etapas que normalmente ocorrem em um processo de desenvolvimento de solução de software.
No mapa geral as ações são elencadas como lembretes para que o time tenha seu conjunto de boas práticas relacionadas à privacidade. Na verdade, cada item pode ser desmembrado em outras ações e áreas de conhecimento.
"Dados são o petróleo do século 21". Esta frase vem sendo repetida à exaustão e a cada ano torna-se mais verdadeira. Cada vez mais empresas fazem dos dados uma fonte de receita, direta ou indiretamente, apoiando seus próprios processos de negócio. No rastro dessa transformação, estão sendo criadas regulamentações como LGPD, GDPR etc, empoderando o cidadão/usuário em relação aos seus dados pessoais – o tal "novo petróleo".
Nesse contexto, muito em breve, não haverá espaço para organizações que não adéquem suas soluções de software às novas exigências legais e às demandas da sociedade cada vez mais consciente de seus direitos. Assim, a privacidade "by design" apresenta-se como uma abordagem mandatória para a indústria de software no tocante a entrar ou continuar neste mercado.
Contudo, este artigo tentou demonstrar que a questão inicia-se muito antes do software, sendo necessárias ações já na fase de prospecção ou momento similar onde o negócio ainda está sendo moldado. Neste momento, cliente e time de desenvolvimento precisam ser sensibilizados e/ou capacitados sobre o tema. Caso contrário, a solução será construída sem as devidas ações e precauções necessárias a este novo cenário que se apresenta. Dessa forma, é provável que custos muito maiores que os adicionados pelo cuidado com privacidade sejam incorporados ao software através de penalidades, multas e até mesmo no impacto negativo sobre a imagem da organização. Privacidade "by design" deve, idealmente, tornar-se o modo de operação padrão das organizações.
[1] LGPD, https://artesoftware.com.br/2019/09/28/lgpd/
[2] Privacy by Design, The 7 Foundational Principles, disponível em: https://www.ipc.on.ca/wp-content/uploads/Resources/7foundationalprinciples.pdf