Livreto Fundamentos Das Tecnologias Da Informacao e Comunicacao TICs e Privacidade 1

Pós Graduação:
Proteção e Privacidade de Dados
Sumário
1. Introdução à Ciência da Computação ............................................................................ 2
1.1. Áreas de conhecimento necessárias à Ciência da Computação .................... 5
1.2. Sistemas de Informação ............................................................................................. 7
1.3. Profissionais de Tecnologia e suas Responsabilidades ................................... 9
2. Desenvolvimento de Sistemas e o Ciclo de Vida de Softwares ............................ 12
2.1. Modelagem de Sistemas e Documentação de Software .................................. 15
3. Introdução à Segurança da Informação....................................................................... 18
3.1. Abrangência da Segurança da Informação e Privacidade .............................. 20
3.2. Ataques à Segurança da Informação .................................................................... 21
3.2.1. Malwares.................................................................................................................... 22
3.2.2. Roubo de Credenciais e Outras Vulnerabilidades ......................................... 23
4. O Ciclo de Vida dos Dados.............................................................................................. 24
4.1. Notificação e Consentimento .................................................................................. 25
4.2. Coleta ............................................................................................................................. 26
4.3. Processamento ........................................................................................................... 27
4.4. Retenção ....................................................................................................................... 28
4.5. Divulgação .................................................................................................................... 28
4.6. Destruição .................................................................................................................... 29
4.7. Análise Crítica do Ciclo de Vida dos dados ........................................................ 29
5. Introdução aos Modelos de Risco à Privacidade ...................................................... 31
5.1. Processos de Software e Ciclo de Vida de Sistemas com Foco em
Privacidade .......................................................................................................................... 36
5.1.1. Um Framework para Implantação de Privacidade .......................................... 37
6. Introdução ao Design Orientado à Privacidade ......................................................... 38
6.1. Gestão de Requisitos e Matrizes de Rastreabilidade ....................................... 40
6.2. Design de Privacidade de Alto Nível ..................................................................... 42
6.3. Design de Privacidade de Baixo Nível .................................................................. 43
7. Introdução à Governança da Informação .................................................................... 44
1
Pós Graduação:
1. Introdução à Ciência da Computação
Os sistemas digitais, como os conhecemos, são muito diferentes dos

primeiros sistemas que surgiram no mundo. Charles Babbage (1791-1871) é um
dos primeiros cientistas dos quais se tem notícia que dedicou seus trabalhos a
desenvolver projetos de computadores. Durante sua carreira, projetou um
sistema computacional totalmente mecânico, conhecida como máquina analítica,
era baseado em engrenagens, cujo propósito original era realizar cálculos de
propósito geral. Uma espécie de calculadora, um ábaco mais avançado, de certa
forma, mais automatizado do que o que se tinha até então.
Figura 1 – Máquina analítica de Charles Babbage

Fonte: wikimmedia.commons
A máquina de Babbage possuía apenas o projeto de hardware. Prevendo

a necessidade da construção de softwares para operá-la, o cientista se alinhou
com Ada Lovelace, filha do poeta inglês Lord Byron, para que ela criasse os
primeiros softwares. Isso mostra a importância das mulheres logo nos primórdios
da computação. Todavia, as aspirações da dupla de cientistas não saíram do
papel, ficando, mesmo, apenas na etapa de projeto pois a tecnologia da época
não era capaz de produzir as engrenagens necessárias para que a máquina
fosse funcional.
2
Pós Graduação:
Entre as décadas de 1930 e 1940, tivemos a explosão da segunda guerra

mundial e com isso, também muitos avanços tecnológicos surgiram a partir daí.
Em 1939, Alan Turing e sua equipe em Betchley Park criavam a Bombe (Bomba
Eletromecânica), máquina criada para tentar decodificar mensagens encriptadas
de origem alemã. Era uma espécie de computador que funcionava com rotores,
e componentes eletromecânicos.
A partir daí, cientistas começaram a empregar o uso de válvulas elétricas
que seriam capazes de chavear sinais elétricos utilizando, para isso, lógica
binária. O Electrical Numerical Integrator and Computer (ENIAC) é um dos
primeiros exemplos de computadores digitais, baseado em um modelo
computacional que utilizamos até hoje. Esse computador começou a ser
construído em 1943, com o intuito de ser utilizado para calcular trajetórias
balísticas e também auxiliar na logística de guerra. Todavia, ele só foi finalizado
em 1946, muito tarde para ser útil no esforço bélico da segunda grande guerra.
Com o surgimento do componente eletrônico conhecido como transistor,
os computadores começaram a se tornar mais confiáveis. Assim, em meados da
década de 1950, já era possível encontrar alguns computadores digitais em
universidades e grandes agências governamentais em países europeus e nos
estados unidos. O transistor foi, de fato, o componente que revolucionou a
computação e trouxe os computadores a o que conhecemos hoje:
microscópicos, velozes e financeiramente acessíveis a pessoas comuns.
Outro fator que impulsionou em muito a adoção de sistemas
computacionais foi o surgimento da internet. No Brasil, em meados da década
de 1990, começamos a notar o uso comercial de computadores ligados à rede,
mas foi nos anos 2000, com a popularização de dispositivos móveis que, de fato,
fez com que tivéssemos ampla adoção do uso de sistemas informatizados na
rotina de corporações e pessoas físicas.
Na data em que este texto é escrito, temos uma realidade naturalmente
digital. Praticamente toda empresa depende, de uma forma ou de outra, de
algum tipo de sistema informatizado. Pessoas comuns, como eu ou você, temos
acesso a inúmeros aplicativos na palma de nossas mãos, quando acessamos
nossos smartphones.
Mas, apesar de toda essa dominação por parte dos dispositivos
computacionais, você se sente confortável com os conceitos básicos da
3
Pós Graduação:
computação? Por exemplo, uma coisa que pessoas comuns muitas vezes não
sabem, é a diferença entre hardware e software. Existe uma piada bem bobinha
que ajuda a compreender os conceitos: “quando estamos nervosos com o
sistema, o hardware é identificado como a parte que a gente chuta, já o software
é a parte que a gente xinga”.
Piadas à parte, é importante entender que o hardware é todo componente
físico, que é palpável, que é possível tocar, literalmente. Já o software, é a
porção do sistema que é puramente virtual. Sem um hardware como uma tela,
ou um teclado, seria praticamente impossível interagirmos com o software. Ou
seja, o software não é algo palpável, tangível diretamente. A ilustração a seguir
mostra como poderíamos entender a relação entre os diversos softwares e os
hardwares de um sistema.
Figura 2 – Hardware, software e usuários

Fonte: o autor
No cerne de tudo, temos o processador (CPU), os dispositivos de entrada e saída

de dados, como teclados, monitores, mouse e também os componentes de
comunicação de um computador, como placas de rede, wifi, etc. Sobre isso,
conseguimos instalar e utilizar softwares que operacionalizam e tornam mais
simples o uso do hardware, como o famoso Sistema Operacional (SO). Windows,
Linux, Mac OS são exemplos de SOs bastante utilizado em computadores
pessoais (PCs) e laptops. Em sistemas móveis, o iOS e o Android são os
sistemas operacionais mais comuns. A partir daí, tem-se os programas ou
aplicações de usuário. Quando eu ou você editamos um texto no Microsoft Word,
4
Pós Graduação:
ou quando estamos acessando um site via Google Chrome, estamos utilizando

aplicações a nível de usuário.
Enfim, basicamente, todo sistema de computação é uma combinação
entre dispositivos eletrônicos físicos que se tornam úteis por suas
funcionalidades virtuais. Do ponto de vista dos usuários, um sistema é como uma
“caixa preta”, na qual o usuário é capaz de inserir dados, pedir para que tais
dados sejam processados/armazenados de acordo com uma necessidade
específica, e então, os dados podem ser visualizados. Em suma, o que um
sistema computacional faz é: receber entradas, processar/armazenar, e fornecer
um resultado, uma saída.
1.1. Áreas de conhecimento necessárias à Ciência da Computação
Como vimos anteriormente, os computadores tomam por base a lógica binária

que, no fim das contas, não passa de pura matemática. Assim, torna-se evidente
a necessidade de cientistas da computação conhecerem os fundamentos do
cálculo, álgebra, estatística e lógica computacional, para citar algumas das
bases matemáticas utilizadas.
Todavia, a parte mais famosa, mais visível da Ciência da Computação é
a programação, o desenvolvimento de sistemas. Aqui, já vale a pena
entendermos melhor cada uma das sub áreas que que dão embasamento ao
desenvolvimento de software:
• Algoritmos e Lógica de Programação: um sistema, geralmente, é um
composto complexo de instruções computacionais organizadas de
maneira lógica para poder receber dados, processar e apresentar um
resultado. Através de algoritmos e de lógica de programação, é possível
construir soluções computacionais úteis aos diversos tipos de usuário.
• Estruturas de Dados: uma vez que o profissional de desenvolvimento
sabe criar algoritmos básicos, precisará entender métodos mais
avançados. As estruturas de dados são as formas com as quais os dados
são armazenados em ambiente digital, e sobre elas, existem diversos
algoritmos clássicos que são utilizados com frequência.
• Programação Orientada a Objetos: para modelar o mundo real em
ambiente digital, utiliza-se o conceito de objetos – são como entidades do
5
Pós Graduação:
mundo real, abstraídas via código-fonte para o mundo virtual. Por

exemplo, um carro, no mundo real, possui vários atributos e
funcionalidades que, quando transportadas para ambiente lógico,
precisam ser modeladas da maneira mais fiel possível.
• Programação WEB e Mobile: com o advento da internet e da computação
móvel, os sistemas computacionais se desenvolveram a ponto de
seguirem padrões arquiteturais e de design que se adaptam melhor a
essa realidade. Sistemas WEB e mobile têm a característica de se
aproveitarem de conceitos como escalabilidade, comodidade e
disponibilidade da rede mundial de computadores.
• Bancos de Dados: para coletar, manter e administrar dados de forma
estruturada, existem os bancos de dados. Sistemas Gerenciadores de
Bancos de Dados (SGBDs) são softwares que formam o núcleo da
maneira com a qual podemos armazenar dados da forma mais
consistente que se tem conhecimento.
• Interfaces homem-máquina: à medida em que a computação se torna um
item primordial da sociedade atual, seres humanos passam tendem a
interagir cada vez mais com computadores. Por isso, a necessidade de
estudar e evoluir constantemente as interfaces de comunicação
existentes entre seres humanos e máquinas.
• Engenharia de Software: o desenvolvimento de sistemas de software não
é tão bem definido como, por exemplo, em projetos da construção civil.
Não é comum que um projeto de software tenha começo, meio e fim, ao
invés disso, o processo de construção de um sistema geralmente é algo
interativo e incremental. Um software é como um organismo vivo, que
cresce e evolui com o tempo e por isso, depende muito do trabalho de
designers, projetistas e gestores.
Para além das áreas de estudo que estão relacionadas à base do

desenvolvimento de software, existem aquelas áreas que, vão além disso.
Conteúdos voltados à eletrônica, circuitos digitais, arquitetura e organização de
computadores, sistemas operacionais, redes de computadores, sistemas
distribuídos, robótica e controle e automação são algumas das sub áreas da
6
Pós Graduação:
Ciência da Computação que, para além do apoio ao desenvolvimento de

sistemas, dão suporte à evolução da própria ciência em si.
Como você deve saber, tecnologia é algo que evolui a passos largos, e a
todo momento novos conceitos, métodos e técnicas vêm a público. Tecnologias
emergentes como as áreas da Inteligência Artificial (IA), Ciência de Dados,
Internet das Coisas (IoT), Blockchain e Computação Quântica, chamam atenção
em termos do que já apresentam de resultados, bem como os seus potenciais
impactos no mundo como conhecemos. Enfim, a Ciência da Computação é um
domínio fascinante, em ampla expansão, sem a qual a existência do mundo
globalizado de hoje seria praticamente impossível.
1.2. Sistemas de Informação
Uma parte da Ciência da Computação que merece destaque, diz respeito aos
Sistemas de Informação. Antes de mais nada, precisamos entender a diferença
entre sistemas de computação e sistemas de informação. Um sistema de
computação, é algo mais abrangente, que pode compreender toda e qualquer
aplicação desenvolvida com computadores quaisquer. Por exemplo: um portão
eletrônico que é ativado por meio de reconhecimento facial, pode ser
considerado um sistema de computação.
Já um sistema de informação, está muito mais relacionado à forma com a
qual os dados e informações do sistema são utilizados. Em geral, sistemas de
informação dão suporte à operacionalização, gestão e tomada de decisão e
organizações diversas. Vamos ao exemplo do nosso portão com
reconhecimento facial. Se esse sistema estiver completamente desconectado da
internet, e funciona com o simples propósito de controlar acesso a uma
residência, por exemplo, então não podemos entende-lo como um sistema de
informação. Todavia, se esse o sistema de reconhecimento facial estiver
conectado a um servidor de uma empresa de vigilância, que realiza o
monitoramento remoto, gera relatórios, e auxilia a tomada de decisão dos
envolvidos com o sistema, então já podemos considera-lo um sistema de
informação.
7
Pós Graduação:
Figura 3 – Dos dados à sabedoria

Fonte: adaptado de wikimedia.commons
Para tornar as coisas mais claras, observe a figura acima. Podemos

entender dados como algo bruto, a matéria prima que ainda não foi trabalhada.
Quando processados, e trabalhados, os dados são transformados em
informações úteis. A partir de processos de tomada de decisão e execução, com
base nas informações, vai se criando o conhecimento que envolve tais
informações. Daí em diante, através da criatividade humana seria possível
extrair ideias e com isso, solidificar todo o saber envolvido com dados,
informações, conhecimento e as próprias ideias.
Figura 4 – Dados, informação e conhecimento

Fonte: o autor
Stair e Reynolds (2016) definem sistema de informação como um sistema

formal, sócio, ético e organizacional, projetado para coletar, processar,
armazenar e distribuir informação. Do ponto de vista computacional, Rainer e
8
Pós Graduação:
Cegielski (2015) colocam um sistema de informação como a integração de

componentes para coleta, armazenamento e processamento dos dados os quais
são utilizados para se extrair informação, contribuindo para o conhecimento, bem
como a criação de produtos digitais. Ou seja, apesar de um sistema de
informação não ser, necessariamente, implementado em vias digitais, nota-se
que automatização desse tipo de aplicação por vias computacionais é o que se
vê com maior frequência.
Com o intuito de materializar um pouco mais as formas com as quais os
sistemas de informação se manifestam em nosso dia a dia, vejamos os principais
exemplos desse tipo de aplicação:
• Armazéns de Dados: softwares responsáveis por conglomerar
informações de bases de dados distintas que, muitas vezes, são de fontes
distintas e tecnologias variadas;
• Enterprise Resource Planning (ERP): um dos softwares mais comuns
em organizações de todos os tipos – são responsáveis por auxiliar na
operação e gerência de empresas e corporações diversas;
• Costumer Relationship Management (CRM): softwares que estão
relacionados à manutenção de informações relacionadas aos clientes de
uma organização;
• Sistemas Especialistas: muito comuns em áreas aplicadas como a
saúde, segurança, ambiental, etc. – agregam conhecimento sobre áreas
específicas para auxiliar a vida dos profissionais das respectivas áreas;
• Business Intelligence: aglomeram informação e conhecimento sobre,
tanto os ambientes internos quanto externos, em relação a organizações
– úteis para o corpo diretivo no processo de controle e tomada de decisão.
• Outros: motores de busca (ex.: Google), Sistemas de Informação
Geográfica (SIG), Sistemas de Informação Globais, Redes Sociais
Digitais, Sistemas de Automação de Escritório, E-commerces, etc.
1.3. Profissionais de Tecnologia e suas Responsabilidades
Como dito anteriormente, o desenvolvimento de tecnologias é algo não trivial e

pode se tornar altamente complexo, à medida surgem novas tecnologias, bem
9
Pós Graduação:
como à medida em que aumenta o número de funcionalidades necessárias às

aplicações. Para lidar melhor com essa complexidade, quem almeja trabalhar
com privacidade e proteção de dados deve conhecer qual é a função de cada
um dos profissionais envolvidos nesta área, principalmente, os que estão
intimamente envolvidos com o desenvolvimento de sistemas:
• Gestor de Projetos: como todo produto/serviço em desenvolvimento, é
preciso alguém que gerencie os recursos, entregas e riscos de um
software. Essa figura muitas vezes recebe nomes distintos, dependendo
do tipo de gestão que faz, como por exemplo, Project Owner (PO), Tech
Lead, entre outros.
• Engenheiro de Requisitos: um sistema é criado com base nas
funcionalidades que precisa implementar, bem como nas características
não funcionais às quais o projeto precisa atender. Tais funcionalidades e
características são modeladas como requisitos de sistema.
• Arquitetos e Designers: uma vez estabelecidos os requisitos, é preciso
estimar as tecnologias, ferramentas que serão utilizadas, bem como os e
modelos de como os componentes do sistema deverão ser
implementados, utilizados e integrados para compor o todo.
• Desenvolvedores: a arquitetura e o design projetados para o sistema
devem ser traduzidos em código-fonte que, de alguma forma, será
executado nas máquinas dos clientes. Essa transformação de projeto em
código é de responsabilidade dos programadores.
• Analistas de qualidade e testes: uma vez que partes ou todo o sistema
foi codificado, é preciso validar e testar suas funcionalidades e
características, tanto pelos próprios desenvolvedores quando pela equipe
de qualidade (quando ela existe).
• Implantadores: com o sistema pronto e validado internamente, é possível
levar o sistema até o cliente, para que a aplicação seja utilizada, em
campo, pelos usuários finais que operarão o software/hardware
construído.
• Administradores: usuários e operadores finais devem, de alguma forma,
utilizar o sistema de acordo com configurações adequadas. A gestão de
configuração, políticas e conformidade fica a critério dos administradores
10
Pós Graduação:
do sistema (usuários com mais privilégios que os operadores comuns do

sistema).
• Suporte de infraestrutura: profissionais dedicados a garantir que toda a
infraestrutura tecnológica necessária à implantação e operacionalização
do sistema se dê de forma adequada. Muitas vezes, têm relação íntima
com os administradores ou eles próprios acumulam a função de
administração do sistema.
• Suporte ao usuário: equipe qualificada de acordo com as regras de
negócio implementadas no sistema, bem como com a forma de se utilizar
o sistema para que possam atender às dúvidas e necessidades dos
usuários.
• Jurídico, marketing e vendas: profissionais que não necessariamente
têm formação e qualificação técnica em TI, mas detêm o conhecimento
necessário em áreas específicas para que o serviço/produto tecnológico
seja eficaz dentro do mercado como um todo.
Para a Associação Internacional de Profissionais de Privacidade (2020),
podemos categorizar profissionais de TI com foco em privacidade de acordo com
as seguintes classes:
• Desenvolvedores de tecnologia: são os responsáveis por projetar,
desenvolver e testar sistemas hardware e software. Entendem que,
quanto antes o conceito de privacidade for inserido no processo de
concepção e construção das ferramentas tecnológicas, riscos e custos
com privacidade tendem a ser fortemente mitigados;
• Aquisitores de tecnologia: têm o compromisso de levantarem
informações sobre as ferramentas e sistemas sendo
comprados/licenciados dentro de uma organização. Para esses
profissionais, é preciso ter uma visão crítica de como os requisitos
entregues pelos sistemas adquiridos se encaixam às necessidades da
organização, principalmente do ponto de vista de conformidade e
adequação às legislações, regulações e políticas de privacidade;
• Administradores de tecnologia: do ponto de vista da operacionalização
dos sistemas tecnológicos, sejam eles adquiridos ou desenvolvidos sob
medida, o administrador deve ser capaz de alinhar a gestão dos sistemas.
11
Pós Graduação:
Recursos de infraestrutura, noções contratuais, noções de integração e

compatibilidade entre diversas tecnologias, noções jurídicas e de
segurança da informação são bastante úteis àqueles que desejam atuar
com privacidade e proteção de dados.
Cabe aos profissionais de privacidade e proteção de dados entender como se
alinhar com todos esses atores de forma holística, atuando como uma espécie
de “tradutor” entre os diversos interessados (stakeholders) de um sistema. Não
basta apenas ter uma visão unilateral, seja do ponto de vista jurídico, seja do
ponto de vista dos objetivos de negócio ou da operacionalização tecnológica. Um
bom Data Protection Officer (DPO) irá alinhar todos os recursos, pessoas e
conceitos necessários para que se atinja um equilíbrio saudável do ponto de vista
de privacidade e proteção de dados.
2. Desenvolvimento de Sistemas e o Ciclo de Vida de Softwares
É muito provável que você já tenha ouvido aquele bom e velho clichê “é melhor
prevenir que remediar”. Quando se trata de privacidade e proteção de dados,
essa é uma verdade absolutamente incontestável. Para tanto, a capacidade de
mitigar, contornar ou mesmo eliminar, danos à privacidade de dados em
ambiente digital, estará intimamente relacionada a cada uma das etapas da
construção dos sistemas tecnológicos envolvidos no programa.
Apesar de toda a complexidade inerente aos processos de
desenvolvimento de software, de modo geral, é possível identificar modelos de
processos de desenvolvimento bem conhecidos na academia e na indústria.
Basicamente, podemos dividi-los em processos de desenvolvimento de software
tradicionais, e em modelos ágeis.
No modelo tradicional conhecido como Desenvolvimento em Cascata,
assume-se que o software tem “começo, meio e fim”. A partir do 1 -
Levantamento de Requisitos, tem-se a possibilidade de criar o 2 – Projeto de
arquitetura e design e, em seguida, 3 – Implementar o projeto em um software
funcional. Feito isso, pode-se realizar a 4 – Verificação do software, em termos
de seus requisitos e funcionalidades implementadas para, depois, levar o projeto
à etapa contínua de 5 – Manutenção, conforme podemos visualizar na figura a
seguir.
12
Pós Graduação:
Figura 5 – Processo de Software: Modelo em Cascata

Fonte: wikimedia.commons
O modelo Cascata é antigo, e remete aos primórdios da engenharia da

computação. Todavia, devido a certa “inflexibilidade”, esse é um modelo que não
é muito prático. Com isso novas alternativas surgiram, como é o caso do Modelo
em Espiral, como podemos visualizar na figura que se segue:
Figura 6 – Processo de Software: Modelo em Espiral

Fonte: IAPP (2020)
Diferentemente do Modelo em Cascata, o Modelo em Espiral permite que as

diversas etapas do ciclo de desenvolvimento sejam revisitadas, até que o
sistema seja entregue de forma mais assertiva. Todavia, mesmo com certa
13
Pós Graduação:
flexibilidade, o Modelo em Espiral tem a desvantagem de ser mais lento quando

comparado às metodologias ágeis.
Figura 7 – Processos de Software: Métodos Ágeis

Fonte: IAPP (2020)
Xtreme Programming e Scrum são dois dos métodos mais conhecidos,

quando se trata de processos de desenvolvimento ágil. Nesses modelos, admite-
se tanta flexibilidade quanto possível. As etapas de planejamento,
implementação e testes são realizadas em períodos curtos de tempo. No Scrum,
por exemplo, chama-se o ciclo de entregas de sprint, que por sua vez, têm em
torno de sete a trinta dias de duração.
14
Pós Graduação:
Figura 8 – DevOps
Fonte: IAPP (2020)
Devemos fazer uma menção especial ao modelo DevOps, que para além
da inclusão de ciclos de desenvolvimento, também abarca o conceito de
entregas contínuas, implantação e operacionalização do sistema, tudo dentro do
mesmo processo.
2.1. Modelagem de Sistemas e Documentação de Software
Assim como no mundo corporativo existem diversos documentos textuais

e visuais que orientam o funcionamento de diversas regras de negócio e
processos organizacionais, temos documentos de software. No caso do
desenvolvimento de programas de computador, sejam eles para ambientes
desktop, WEB ou dispositivos móveis, é preciso padronizar uma linguagem que
sirva para que os diversos stakeholders envolvidos se façam entender de
maneira tão inequívoca quanto possível.
No início de um processo de desenvolvimento de software, o engenheiro
de requisitos deve se reunir com todos os stakeholders do sistema para levantar
as funcionalidades e características essenciais do sistema. Ou seja, é preciso
que usuários, administradores, gestores, clientes, fornecedores ou qualquer
outro ator que interage com o sistema, listem as funcionalidades que o sistema
deve implementar. Já pensou como seria, se não houvesse uma forma
padronizada de se comunicar uma diversidade tão grande de atores?
Assim sendo, justifica-se a existência de padronizações como é o caso da
Unified Modeling Language (UML). A UML descreve termos, diagramas,
sintaxes, notações gráficas, que podem ser combinadas para se criar
documentos e artefatos úteis na compreensão de como o sistema se descreve.
Alguns dos diagramas mais comuns utilizados em documentações de software
são:
• Fluxograma – auxiliam na visualização de fluxos de informações,
podendo incluir tomadas de decisão, entrada e saída de dados, etc.
15
Pós Graduação:
Figura 9 – Fluxograma
Fonte: o autor
• Diagramas de Caso de Uso – úteis para identificar atores, stakeholders
e funcionalidades chave;
Figura 10 – Diagrama de Casos de Uso

• Diagramas de Classes – úteis para modelar a estrutura de entidades
que serão codificadas e implementada dentro dos programas do sistema;
16
Pós Graduação:
Figura 11 – Diagrama de Classes

• Diagramas Entidade-Relacionamento – úteis para se mapear quais
são as entidades do mundo real, seus atributos e as relações entre eles
para que sejam transformados em dados a serem armazenados de forma
persistente no sistema;
Figura 12 – Diagrama Entidade-Relacionamento

• Diagramas de Sequência – úteis para apresentar maior detalhamento
no fluxo de informações e trocas de mensagens entre entidades dentro
do sistema.
17
Pós Graduação:
Figura 13 – Diagrama de Sequência

Fonte: Stack Overflow
3. Introdução à Segurança da Informação
A essa altura do curso, você provavelmente já ouviu falar bastante em segurança

da informação e privacidade de dados. Assim, penso que vale a pena ressaltar
apenas o que há de mais importante: segurança da informação se faz em
camadas, e considerando atributos de qualidade. O famoso “tripé da segurança
da informação”, deve estar na ponta da língua de um DPO. Por isso, vamos
reforçar tais conceitos com suas respectivas descrições:
• A confidencialidade trata dos proprietários de uma informação. Se um
colaborador da área de vendas envia um e-mail para seu gestor
imediatamente superior, não é de se esperar que essa mensagem seja
acessada por um colega que esteja no mesmo nível hierárquico que o
respectivo colaborador. Ou seja, somente quem realmente estiver
autorizado, deveria ter acesso à informação, e nada mais;
• A integridade diz respeito à forma com a qual os dados se mantêm
corretos, robustos, atualizados e com qualidade. Se, por exemplo, ao
armazenarmos informações em um disco rígido que está com problemas
e, eventualmente, alguns arquivos se corrompem devido a interferências
18
Pós Graduação:
eletromagnéticas, então estamos comprometendo a integridade de tais

dados;
• Por fim, a disponibilidade, corresponde à capacidade de o sistema se
manter em pleno funcionamento, mesmo que em face de ataques. É
muito comum, por exemplo, que “exércitos de computadores infectados”
(zombie botnets) inundem os servidores de, por exemplo, um órgão
público, na tentativa de tirar aquele serviço público do ar, comprometendo
sua disponibilidade.
A importância da Segurança da Informação para a privacidade parece bastante

óbvia, uma vez que geralmente, falha de segurança implicará em falha de
privacidade. Muitas vezes, os motivos para que danos à segurança e privacidade
ocorram parecem banais: softwares desatualizados ou pirateados; má
configuração dos sistemas; reutilização de credenciais de autenticação. Aqui,
torna-se evidente a importância de qualificação e treinamento em segurança da
informação. Ter conhecimento dos problemas em potencial, os ricos e as formas
de solucioná-los (geralmente através de prevenção), é algo que se sobrepõe a
ferramentas tecnológicas de segurança. Não existe “bala de prata”, é preciso
educar.
Dentro das organizações, muitas vezes, a equipe de segurança da
informação nem existe. Basicamente, gestores acumulam funções de técnicos
em infraestrutura que, muitas vezes, já estão sobrecarregados com as próprias
funções. Isso, é claro, não deve resultar em boa conduta no que tange a
segurança da informação. Ainda, quando há equipe própria para isso, corre-se
o risco de que se preocupem meramente com a legislação e regulação, quando,
na verdade, segurança da informação se estende às ferramentas, processos,
controles e principalmente a pessoas.
Nas organizações em que há uma preocupação em desenhar controles
tecnológicos para aumentar os níveis de segurança, aí entra em ação a
“preguiça”. Em nome da comodidade, de alguma espécie de vícios de cultura
organizacional ou, às vezes, por falta de capacitação e treinamento, os usuários
dos sistemas de uma organização simplesmente não fazem sua parte. Tratam
senhas de forma inadequada, menosprezam controles que podem ser
contornáveis, etc. Para piorar esse cenário, existem as situações nas quais os
19
Pós Graduação:
colaboradores utilizam dispositivos “próprios” para exercer suas funções

organizacionais. É o que chamamos de “bring your own device” (BYOD), quando,
por exemplo, um colaborador utiliza seu smartphone ou laptop dentro do
ambiente organizacional, misturando usos pessoais com o seu trabalho. Isso
aumenta em muito os riscos da organização.
Por outro lado, a organização poderia tentar aumentar os níveis de
segurança, forçando o uso de ferramentas de vigilância nos dispositivos dos
colaboradores. Do ponto de vista de privacidade, seria um dano aos
colaboradores.
3.1. Abrangência da Segurança da Informação e Privacidade
Existem diversas propostas, ao redor do globo, no sentido de instruir, orientar e

capacitar profissionais de segurança da informação e privacidade. Algumas
delas têm reconhecimento notório, como a Information Systems Audit and
Control Association (ISACA), associação internacional que dá apoio e patrocina
métodos, técnicas e modelos com foco no desempenho de auditorias e controle
em sistemas de informação.
O International Information Systems Security Certification Consortium
(ISC²) é outro exemplo de organização focada em certificações, métodos,
modelos e treinamentos. Todavia, a ISP² é muito mais voltada à segurança da
informação propriamente dita. Nessa mesma linha, a International Association of
Privacy Professionals (IAPP), é especializada em certificações voltadas à
privacidade ao redor do globo.
Todavia, para além de organizações voluntárias, com ou sem fins
lucrativos, existem algumas agências governamentais que instituem padrões.
Daremos atenção, aqui, ao “bureau nacional de padrões” norte-americano, o
National Institute of Standards and Technology (NIST) – poderíamos compara-lo
a uma espécie de INMETRO, no Brasil.
O NIST está envolvido em iniciativas norte-americanas, como por
exemplo, no caso da segurança da informação e privacidade, o que é conhecido
como National Initiative for Cybersecurity Education (NICE). Através de uma
parceria entre governo, academia e setor privado, dão atenção à criação de boas
20
Pós Graduação:
práticas e padronizações para se atuar com segurança e privacidade em

ambientes digitais.
Os princípios instituídos pelo NICE se repetem em diversas legislações,
regulações e políticas ao redor do mundo. Tomando-o como base, distinguimos
os seguintes aspectos que deveriam ser pontos de atenção ao se trabalhar com
tecnologia segura: arquitetura e design (provisão segura); operação e
manutenção; proteção e defesa; resposta a incidentes; investigação; supervisão
e governança e, por fim; coleta, operação e análise.
Em suma, para cada ponto elencado, o NICE coloca pontos de análise
para se criar perspectivas e auxiliar na análise para posterior tomada de decisão.
Por exemplo:
• Pensar em quais tecnologias estariam envolvidas, e as formas nas
quais os dados fluem dentro do projeto de um software.
• Ponderar se vale a pena criar um software do zero, ou customizar algo
que já existe.
• Como avaliar riscos de qualidade, conformidade, segurança e
privacidade.
• Como administrar, operacionalizar e dar suporte a infraestrutura e ao
uso de sistemas, considerando proteção e privacidade.
• De quais formas sugere-se que um sistema seja protegido ativamente
e como prevenir, detectar e gerir vulnerabilidades e ataques.
• Boas práticas para respostas a incidentes: documentações, impactos,
medidas de remediação, análises de tradeoffs, etc.
• Acompanhamento e programas de melhorias constantes.
3.2. Ataques à Segurança da Informação
Um software, como dito anteriormente, é uma espécie de “organismo vivo”, e

está em constante evolução. A complexidade alta, ao se tentar organizar
recursos, gerir riscos, avaliar resultados de forma tornar viável a existência de
um sistema de informação. É comum que o desenvolvimento de um sistema
extremamente simples seja altamente custoso, e geralmente tem-se urgência na
entrega das funcionalidades, o que faz que além de caro, os prazos são, com
21
Pós Graduação:
frequência, descumpridos. Perceba, portanto, que segurança da informação e

privacidade, geralmente, fica em segundo plano, quando a própria viabilidade
financeira do software está em risco.
Tanenbaum (2016) nos permite concluir que a quantidade de falhas que
se tolera em uma na maioria dos sistemas existentes torna o trabalho dos
profissionais de segurança bastante complicado. É fácil perceber que muitas
empresas sequer possui uma equipe de testes e qualidade dedicada a dar
atenção a falhas convencionais (bugs) que, nem sequer afetam a segurança.
Aqui vale a distinção: nem toda falha, como um bug simples, é uma
vulnerabilidade de segurança. Por exemplo, pode ser, apenas, que uma
funcionalidade do programa tenha deixado de apresentar resultados precisos,
sem que o sistema seja comprometido em sua segurança.
Ao falar de vulnerabilidades de segurança e privacidade, nos referimos à
possibilidade real de que o sistema seja comprometido em termos de
confidencialidade, integridade ou disponibilidade. O que torna um ataque
possível, geralmente, é alguma combinação entre: exploração de falhas de
segurança; infecção por malwares; roubo de credenciais; má configuração;
ameaças internas.
3.2.1. Malwares
Definimos como malware todo e qualquer tipo de software cujos propósitos são
obscuros. Podemos, por exemplo, dizer que todo vírus de computador é um
malware, mas nem todo malware é um vírus. Perceba, portanto, que tipos
distintos de malware. Vejamos alguns deles:
• Vírus: malware que tenta se espalhar por vários pontos da máquina;
• Verme (worm): malware que tenta se espalhar em rede;
• Cavalo de Tróia (trojan): malware que promete algo mas entrega
vulnerabilidades por detrás;
• Keylogger: malware que registra tudo o que é digitado via teclado;
• Screenlogger: malware que registra o que é mostrado na tela do
computador;
• Backdoor: vulnerabilidade colocada em um software propositalmente;
22
Pós Graduação:
• Expolit: malware que busca e explora vulnerabilidades na máquina alvo;

• Sniffer: monitoramento e rastreio de pacotes que trafegam em uma rede;
3.2.2. Roubo de Credenciais e Outras Vulnerabilidades
Para um hacker, não há nada mais prazeroso que ter acesso a uma conta de
administrador com privilégios plenos sobre o sistema em ataque. A ampla
maioria dos ataques requer acesso a credenciais para serem efetivos. O roubo
dessas credenciais pode ocorrer de várias formas.
Imagine que você se cadastrou num site de e-commerce para comprar um
produto qualquer. Você informou um e-mail válido e sua senha, para poder
realizar sua transação. Eis que, tempos depois, o site tem todas as credenciais
de seus usuários vazadas, pois não armazenavam as senhas com criptografia.
Você, desavisado, não sabe disso, e utiliza a mesma senha em outros acessos.
Perceba que, um hacker em posse de seus dados de login, poderia, por exemplo,
tentar acessar outras plataformas se passando por você.
Outra forma de ter credenciais roubadas, é utilizando máquinas públicas
ou computadores que são compartilhados com muitas pessoas. Algum dos
usuários com quem você compartilhou essa máquina pode ter sido vítima de
infecção por um keylogger ou screenlogger (ou mesmo, alguém pode ter
instalado propositalmente). Assim, você já imagina, suas credenciais estariam,
mais uma vez, em mãos erradas.
Uma forma muito comum que hackers utilizam para “arrecadar”
credenciais roubadas, é através de sites falsos. Clonam a aparência de um site
de uma organização confiável, como, por exemplo um banco com identidade
visual bem conhecida. Através do site falso, solicitam suas credenciais de forma
que a vítima, desatenta, acaba informando seus dados por acreditar se tratar de
um site idôneo. É muito comum que isso seja feito via e-mail, inclusive.
Para além das credenciais, existem ainda os casos nos quais as
configurações dos sistemas são menosprezadas. Ocorre que os usuários
assumem que o sistema vem todo configurado corretamente “por padrão”.
Infelizmente, o usuário só vai perceber que estava mal configurado quando
aparecer um problema. O sistema pode estar 99% correto do ponto de vista de
suas configurações, mas se 1% estiver comprometido, todo o resto está em
23
Pós Graduação:
risco. Somando-se a isso, pode ser que colaboradores estejam com más
intenções, facilitando a ocorrência de falhas em processos ou roubando
informações deliberadamente, visando ações obscuras ou ilícitas.
4. O Ciclo de Vida dos Dados
Depois de uma visão geral sobre Ciência da Computação, Desenvolvimento de

Software e Segurança da Informação, podemos dar um pouco mais de foco à
questão da privacidade. Quando se trata de ambientes digitais, geralmente
existe uma grande diversidade de atores que fazem parte do ecossistema que
permeia o respectivo sistema. Juristas geralmente tendem a assumir uma
posição defensiva, dando maior atenção aos riscos legais e de compliance.
Desenvolvedores de tecnologia, por outro lado, estão mais preocupados com a
entrega de sistemas robustos, extensíveis e úteis ao negócio e à vida dos
usuários. Por fim, gestores e tomadores de decisão estão comprometidos no
equilibro entre prover valor aos clientes e garantir que os riscos sejam
minimizados sem comprometer a viabilidade das operações de uma
organização.
Do ponto de vista da privacidade e proteção dos dados, esses três tipos
de atores, a saber, juristas, desenvolvedores e administradores, são os
principais stakeholders que devem se articular para que um programa de
implantação de privacidade seja efetivo. Para tanto, é útil que tais profissionais
conheçam modelos de análise de como os dados podem fluir dentro dos
ambientes digitais. Assim, nesta seção, trataremos de compreender o Ciclo de
Vida dos Dados (Data Lifecycle).
Processos de negócio, sistemas computacionais e até a estrutura física,
para além do ambiente digital, são pontos que devem ser considerados ao se
analisar o fluxo de dados pela organização. É importante que organizações
mantenham o controle e consistência sobre o que dizem fazer com os dados e
o que realmente fazem com ele. Tanto do ponto de vista de propósitos, quanto
na forma com a qual as políticas de privacidade são aplicadas. Já os usuários
deveriam ser capazes de determinar exatamente os propósitos para os quais
autoriza tais usos, desde que não hajam bases legais que autorizem
controladores e operadores a utilizarem os dados com base em hipóteses de
24
Pós Graduação:
tratamento que não obriguem a coleta do consentimento. Vale lembrar que tanto
os modelos de negócio, propósitos de uso e o próprio software evoluem com o
tempo e, portanto, as políticas de privacidade devem evoluir em consonância.
Figura 14 – Data Lifecycle

Fonte: IAPP (2020)
Assim sendo, o Ciclo de Vida dos Dados pode ser entendido como um
modelo que serve como base para que o desenvolvimento de um programa de
conformidade com legislações e regulações. Por isso, vamos entender as etapas
pelas quais dados passam ao longo de sua vida, em cada processo ou sistema
de uma organização. A literatura é vasta, nesse sentido e, por isso, tomaremos
o modelo da IAPP (2020), que lista seis etapas, a saber: 1 – Notificação e
Consentimento; 2 – Coleta; 3 – Processamento; 4 – Retenção; 5 – Divulgação;
6 – Destruição.
4.1. Notificação e Consentimento
Existem diversos mecanismos bem conhecidos para se notificar sobre os

propósitos de uso dos dados pessoais de um indivíduo, bem como coletar o
consentimento para os respectivos usos. De maneira ideal, seria interessante
sempre coletar o consentimento antes de qualquer tipo de coleta ou tratamento
e dados. De acordo com legislações ao redor do globo, deve-se dar a opção de
o titular dos dados ter condições tanto de optar pela entrada, quanto pela saída,
quando se trata de fornecer dados para usos específicos.
25
Pós Graduação:
É importante notar que usuários, na esmagadora maioria das vezes, não

está disposto a ler termos de uso, políticas de privacidade, ou quaisquer
informações que sejam demasiado extensas e complexas. Por isso, é comum
que o próprio titular acabe por fornecer consentimento sobre aquilo que nem
sabe o que é. Assim sendo, o sistema deveria ser capaz de capturar o
consentimento de uma forma que seja tão explícita e inequívoca quanto possível,
para que o usuário não venha a questionar tal consentimento futuramente.
Das formas mais comuns para se coletar consentimento, podemos citar:
notificação textual combinada com alguma espécie de checkbox no qual o
usuário deve clicar para consentir; notificação combinada com alguma espécie
de botão, no qual o usuário, novamente, deve clicar para entregar o
consentimento; ainda, é comum que se exija uma resposta a um e-mail que,
geralmente, também possui alguma espécie de botão que explicite a
necessidade de haver consentimento para que haja a continuidade da prestação
do serviço por parte do sistema e consequente coleta dos dados.
Ainda, podemos falar no chamado consentimento passivo, no qual o
sistema não faz o usuário se engajar ativamente para entregar seu
consentimento. Ao invés disso, o sistema assume que o usuário consente pelo
simples fato de estar utilizando o sistema. Essa é a forma menos adequada
quando se trata desse tema, já que o titular dos dados poderia questionar a
coleta e formas de uso, alegando não estar ciente disso. Além disso, a
comunidade de usuários pode acabar por perder a confiança, tanto naquele
sistema, quanto em ambientes tecnológicos de modo geral.
4.2. Coleta
Basicamente, existem dois tipos de coleta de dados, sendo a ativa e a passiva.

Lembremos que sistemas computacionais podem ser altamente complexos e,
nesse sentido, devemos estar atentos ao fato de que os dados podem ser
coletados em ao longo de vários pontos, dentro do sistema. Na coleta ativa o
usuário deve informar seus dados diretamente, geralmente por meio de um
formulário eletrônico ou algo semelhante. No caso da coleta passiva, o sistema
acaba por analisar fluxos de dados produzidos automaticamente pelo usuário,
26
Pós Graduação:
muitas vezes, sem que ele conheça os mecanismos técnicos por trás dessa
coleta.
Um exemplo de coleta passiva, é o caso dos famosos cookies, que não
passam de conjuntos de identificadores para que o servidor de um sistema saiba
consiga identificar um usuário mesmo que esse usuário tenha entrado e saído
do sistema por várias vezes consecutivas. Cookies são como “migalhas” de pão,
jogadas em uma “trilha” virtual, assim como na história da Chapéuzinho
Vermelho. Em suma, para além de identificar um usuário, um sistema pode
utilizar cookies para realizar inferências sobre o comportamento em ambiente
digital do respectivo usuário.
A coleta está intimamente relacionada a todas as etapas que vêm em sua
sequência, uma vez que sem ela, não há tratamento algum. Por isso, devemos
ter muita atenção com, por exemplo, o caso em que dados são reaproveitados
para outros propósitos, ressignificando a coleta feita anteriormente. É preciso,
ao menos, notificar usuários quando da ocorrência de tais alterações. Ainda,
quando coletamos dados e repassamos tais dados a terceiros, por exemplo,
quando um controlador repassa dados a um operador, devemos deixar isso claro
aos titulares.
4.3. Processamento
O tratamento ou processamento dos dados deve sempre estar em pleno

alinhamento com o que foi notificado. Ou seja, o uso verdadeiro por detrás das
políticas de privacidade, deve coincidir com o que o usuário espera. Nesse ponto
de nossos estudos, isso pode parecer óbvio, mas muitas vezes, os tomadores
de decisão da organização tentarão persuadir o profissional de privacidade e
proteção de dados a “contornar” tais situações, o que é altamente conflitante com
as regulações e legislações existentes.
É preciso deixar claro que a ressignificação ou reuso dos dados nem
sempre é vista pelos usuários como algo negativo. Desde que a organização
esteja analisando riscos e mitigando situações críticas, sempre realizando
notificações adequadas, é possível prosseguir com novas tratativas no
processamento dos dados.
27
Pós Graduação:
Usos secundários de dados não se limitam a, mas incluem os seguintes

exemplos: dados coletados para operações e completude de transações
financeiras sendo utilizados para marketing, também; dados coletados por
companhias aéreas para serem utilizado em voos sendo reutilizados para
detectar atos de terrorismo; empresas coletando dados de localização para
traçar rotas de delivery sendo reutilizados para inferir padrões de deslocamento
e ou condições de trânsito.
4.4. Retenção
Para além da coleta e processamento, os dados normalmente acabam por ficar

armazenados nas bases das corporações. Aqui, o princípio da minimização deve
ser observado, focando em reter apenas o necessário, pelo tempo necessário
para atender os objetivos da organização. A partir de modelos de risco, é
possível entender os possíveis problemas ao se reter alguns tipos de dados,
sempre levando em conta as políticas, regulação e legislação vigentes.
Tomemos como exemplo o caso de companhias aéreas. Inicialmente, a
retenção dos dados seria necessária apenas durante o período de tempo em
que o cliente complete seus voos. Todavia, a regulação relacionada à aviação
civil, pode requerer que os dados sejam mantidos por mais tempo, por motivos
de segurança nacional e auditoria. Ainda que a regulação não dissesse nada a
respeito de manter os dados, a companhia poderia desejar manter os dados
armazenados para fins de marketing, melhoria de serviços, etc.
4.5. Divulgação
A ampla maioria dos frameworks regulatórios e legais ao redor do globo

convergem no sentido de garantirem aos titulares o direito a terem acesso aos
seus próprios dados. Ou seja, antes de mais nada, os dados pessoais de um
indivíduo devem, antes de mais nada, estarem disponíveis ao a ele. Para além
disso, pode ser que a empresa divulgue dados pessoais, seja de forma direta,
pseudoanônima ou anônima, ao público geral, para fins diversos. Ainda, é
comum que dados pessoais sejam divulgados a terceiros, parceiros de negócio
da organização, com fins comerciais.
28
Pós Graduação:
Plataformas digitais diversas, hoje em dia, contam com o conceito de

APIs, que são interfaces de programação para que desenvolvedores de terceiros
usem os dados e funcionalidades da respectiva plataforma, estendendo seus
usos. Isso é particularmente comum em campanhas de marketing, onde
geralmente existem operadores que entregam serviços de mail marketing,
tráfego pago, canais de atendimento ao cliente, entre outros.
Independente dos objetivos para os quais os dados foram divulgados,
geralmente é preciso garantir que haja consentimento para tanto. Ainda, no caso
de APIs e de uso de dados por terceiros, é interessante que se estendam aos
respectivos terceiros que os propósitos de uso sejam respeitados para os
mesmos consentimentos coletados pela organização original. A saída mais óbvia
é que tais garantiras estejam claras em contrato firmado entre a organização e
seus terceiros, já que a organização original provavelmente não terá acesso
direto às formas com as quais os terceiros estão trabalhando com esses dados.
4.6. Destruição
A última etapa do Ciclo de Vida dos Dados parece trivial: quando chegar a hora,
os dados devem ser removidos do sistema. Na maioria das vezes, basta uma
delação simples para garantir que o sistema esteja em conformidade, sem
maiores prejuízos tanto aos titulares, quando à organização. Todavia, há casos
em que os dados são extremamente sensíveis ou estratégicos, podendo estar
armazenados em dispositivos físicos vulneráveis. Nesses casos, existem até
normas que podem ser seguidas para se destruir tais dados. A Publicação
Especial 800-88 (Apêndice A) do NIST traz orientações sobre como sanitizar
dispositivos, por exemplo, com degaussificação eletromagnética por sobrescrita
pseudorrandômica, impedindo que um atacante com acesso ao dispositivo físico
recupere os dados. Em casos mais sérios, pode-se optar até pela incineração
física de mídias como discos rígidos (HDs ou SSDs).
4.7. Análise Crítica do Ciclo de Vida dos dados
29
Pós Graduação:
Como dito anteriormente, notamos que alguns atores envolvidos na privacidade

de uma organização tendem a ter visões “opostas” sobre um mesmo aspecto do
sistema. Em se tratando do ciclo de vida de dados, poderíamos vislumbrar,
basicamente, dois pontos de vista: o primeiro, mais “agressivo”, que maximiza a
utilidade da informação e o valor potencial dos dados pessoais, geralmente
abrindo mão de privacidade para atingir objetivos de negócio; o outro, mais
“defensivo”, visa mitigar ao máximo os riscos à privacidade e proteção dos
dados, minimizando informações potencialmente tóxicas e analisando a
viabilidade dos usos desejados.
Na etapa da coleta, um profissional de privacidade agressivo
provavelmente tentará coletar todo e qualquer tipo de dado possível, assumindo
que o valor futuro a ser obtido supera os riscos. No que tange os termos de
privacidade, o agressivo adotará um texto generalista, com flexibilidade para
adotar modificações futuras. Já um profissional defensivo, deverá coletar apenas
o essencial para propósitos específicos, dando a oportunidade de os titulares
cancelar serviços que julga desnecessário antes mesmo da coleta.
A etapa de processamento, quando visualizada de forma agressiva
provavelmente irá garantir o compartilhamento de dados através dos diversos
setores da organização no intuito de estimular competitividade e inovação. De
forma defensiva, os dados seriam utilizados apenas para o propósito original,
limitando o compartilhamento apenas às áreas verdadeiramente necessárias.
Vale lembrar que, independentemente da visão, quaisquer usos secundários
devem ser notificados e devem ter consentimento, quando aplicável.
No que tange a divulgação dos dados, principalmente no
compartilhamento com terceiros, uma posição agressiva permitiria a ampla
divulgação, geralmente visando alavancar estratégias de marketing ou de
terceirização/expansão de serviços. Todavia, defensivamente, poderia se limitar
a divulgação e compartilhamento única e exclusivamente para os propósitos
originais. Quais novos compartilhamentos e divulgações deveriam requerer
notificação e consentimento.
Sobre a retenção, intuitivamente, podemos entender que
agressivamente, uma organização irá reter tantos dados quanto for possível.
Manter os dados armazenados em seus sistemas por longos períodos de tempo
faz com que a organização seja capaz de realizar análises históricas, preditivas,
30
Pós Graduação:
de forma a melhorar seus serviços e produtos. Já do ponto de vista defensivo, a

organização destruiria os dados tão logo não fossem necessários para completar
as transações internas. Novamente, reuso e necessidade de maior retenção
deve ser notificada e consentida.
Intimamente à retenção, a etapa de destruição agressiva irá evitar a
destruição, através da manutenção de backups de longo prazo, geralmente
reduzindo o acesso aos dados originais, mantendo um sumário dos dados para
eventuais usos futuros. Defensivamente, a organização provavelmente irá
destruir os dados assim que possível. Ainda, se preocupa com os métodos de
destruição, de forma robusta, impedindo recuperações indevidas.
5. Introdução aos Modelos de Risco à Privacidade
O Ciclo de Vida dos Dados, recém abordado, pode ser encarado como um
modelo, um framework para dar apoio à análise de como os dados e informações
fluem através dos sistemas de uma organização. Em complemento a isso,
podemos falar também em modelos para racionalizar e analisar os riscos de
privacidade aos quais os dados podem estar susceptíveis.
O formato mais comum e, na maioria das vezes, indispensável, é o
modelo de compliance. Na tradução para o português, dizemos que a
conformidade é uma forma bastante flexível para adequar uma organização,
seus processos e sistemas, à legislação aplicável, bem como às políticas
internas e regulações apropriadas. Nesse modelo, do ponto de vista tecnológico,
os riscos são delineados em termos de falhas a cumprir requisitos funcionais e
não funcionais, bem como em termos do que deve ser evitado ou proibido.
Profissionais costumam documentar processos, sistemas, entre outros artefatos,
de forma a identificar a quantia de ameaças e vulnerabilidades, bem como a
forma com a qual os elementos de um sistema se relacionam com os respectivos
requisitos. Para isso, é útil construir matrizes de rastreabilidade, que veremos
mais adiante.
Um ponto de atenção no modelo de conformidade é o fato de que
controles de privacidade de alto nível, como políticas internas de privacidade,
podem se mostrar inviável em alguns pontos. Por isso, torna-se importante um
gerenciamento de risco que solucione tais situações através da busca por
31
Pós Graduação:
alternativas viáveis que entreguem o mesmo nível de controle de riscos. Assim,

através de compliance, seria possível conciliar: políticas organizacionais,
legislações nacional e internacional, regulações para áreas específicas,
requisitos de sistema, etc.
Um modelo bastante conhecido no âmbito internacional são os Fair
Implementation Privacy Principles (FIPPs), publicado há muito, em 1980, pela
Organization for Economic Cooperation and Development (OECD). Vários
países ao redor do globo se manifestaram como concordantes com os princípios
desse modelo. Basicamente, descrevem-se prescrições e proscrições sobre
qualidades específicas e comportamentos que sistemas devem implementar, ao
lidar com informações pessoais. Os FIPPs seriam formariam um modelo que é
ainda mais abstrato que frameworks legais como a LGPD ou a GDPR, sendo
uma espécie de guia orientativo para a criação de legislação, políticas públicas,
regulações e até políticas organizacionais internas. Para traduzir tais princípios
em controles práticos é necessária análise significativa, já que do alto nível para
o baixo nível de implementação de privacidade, existem nuances específicas,
em contextos específicos.
No ano de 2011, Ryan Calo propôs, em seu artigo “The Boundaries of
Privacy Harm”, alguns pontos de referência na análise de riscos, também
considerando um alto nível de abstração. Conhecido como Dicotomia
Subjetiva/Objetiva (S/O D), esse modelo prevê que, basicamente, danos à
privacidade podem ser enquadrados em duas grandes categorias: uma
subjetiva, outra objetiva. Danos subjetivos estariam relacionados as percepções
individuais dos titulares sobre observações indesejadas de seus dados pessoais
(independentemente se os dados são precisos ou não), levando à sensação de
terem sidos expostos ao risco. No caso dos danos objetivos, poderíamos
relaciona-los a ações que incluam o uso não antecipado ou coercitivo de
informações pessoais, levando a consequências reais, para além do sentimento
de exposição.
Tempos antes, em 2006, Daniel Solove já havia feito um trabalho
semelhante, todavia, sendo muito mais específico sobre como descrever danos
à privacidade. A Taxonomia da Privacidade de Solove lista quatro grandes
categorias nas quais ocorrem danos à privacidade. São elas: coleta de
informação; processamento de informação; disseminação de informação e;
32
Pós Graduação:
invasão. Para cada uma dessas classes de danos, temos termos específicos que
descrevem ataques práticos à privacidade. Vejamos cada uma delas, com um
pouco mais de detalhes:
• Vigilância: tentativa de capturar ou observar as atividades de um
indivíduo. Por exemplo, quando são inseridos códigos-fonte em
páginas HTML para se rastrear o comportamento do usuário
naquele site, como cliques em links, etc.;
• Interrogação: trata-se de questionar o titular ativamente, para que
ele insira informações que não necessariamente seriam
necessárias. Por exemplo, quando um formulário de coleta de
leads pede telefone, quando telefone não era necessário;
• Agregação: combinam-se fontes de informação distintas para se
aferir informações mais robustas. Por exemplo, uma empresa de
varejo pode correlacionar uma séria de compras de uma mulher
para tentar descobrir se ela está, ou não, grávida, e assim oferecer
produtos/serviços para gestantes;
• Identificação: quando é possível ligar informações quaisquer a
indivíduos específicos. Por exemplo, quando se utilizam cookies, o
endereço IP, ou outro identificador para acessar o histórico de
pesquisas ou navegação daquele indivíduo;
• Insegurança: quando há falha na proteção às informações de um
indivíduo. Por exemplo, quando o site não implementa o protocolo
TLS (para conexões HTTPS), ou então não utiliza criptografia no
armazenamento em dispositivos de memória;
• Uso secundário: coletar informações para um propósito, porem
utiliza-las para outros fins, sem que o usuário tenha ciência. Por
exemplo, empresa de varejo que usa e-mails para enviar
campanhas de marketing quando, na verdade, o e-mail havia sido
coletado apenas para concretizar transações de venda;
• Exclusão: negar ao indivíduo a informação ou o que está sendo
feito com seus dados pessoais. Por exemplo, empresa de
marketing que compra dados de outra companhia sem
conhecimento dos titulares;
33
Pós Graduação:
• Brecha de confidencialidade: revelar informações sobre um

indivíduo, mesmo tendo afirmado não fazer isso, em seus termos
e políticas de privacidade. Por exemplo, uma plataforma poderia
divulgar dados de quem utiliza um plug-in de terceiros, através de
usa API, mesmo tendo prometido não o fazer;
• Divulgação: revelar informação correta sobre o titular, porém,
afetando-o negativamente. Por exemplo, alguma plataforma que
presta serviços de “estilo de vida” (ex.: fitness) divulga sua lista de
membros para tentar impulsionar suas vendas, expondo tais
membros a grupos sociais que “criticam” tal estilo de vida;
• Distorção: espalha-se informação falsa, propositalmente incorreta
ou não intencionalmente incorreta sobre uma pessoa. Por exemplo,
um serviço de RH que identifica incorretamente um candidato como
sendo um criminoso, privando-o do acesso à vaga de emprego;
• Exposição: diz respeito a quando se revelam informações que
normalmente deveriam estar ocultadas. Por exemplo, empresa que
registra compras de produtos de incontinência urinária sendo
utilizado em uma campanha de vendas que, por sua vez, acaba
sendo direcionada à rede de contatos próximos a quem comprou,
constrangendo o titular;
• Acessibilidade aumentada: trata da facilidade em se acessar
informações sobre um indivíduo. Por exemplo, serviço de
entretenimento para crianças que permite que qualquer adulto
estranho seja capaz de interagir com elas;
• Extorsão (blackmail): ameaça da divulgação de informações
pessoais contra a vontade do titular. Por exemplo, serviço de
processamento de reclamações médicas ameaça liberar dados de
pacientes caso “melhores” condições de emprego não forem
atendidas;
• Apropriação: utilizar a identidade de um indivíduo de acordo com o
interesse de terceiros. Por exemplo, um serviço de
relacionamentos amorosos que usa dados históricos pessoais,
34
Pós Graduação:
incluindo idade, biografia e formação para promover seu site a

novos clientes;
• Intrusão: trata-se da perturbação da tranquilidade ou solitude de
um indivíduo. Por exemplo, alerta de mobilidade do smartphone
que notifica usuários em potencial, informando-os que estão
próximos a um ponto de venda;
• Interferência: inserção de um indivíduo em um processo de tomada
de decisão que afetaria seus interesses pessoais. Por exemplo,
site limitando acesso a revisões negativas de seus produtos, para
promover vendas a novos clientes;
Outro modelo de riscos à privacidade bastante conhecido, é a Integridade
Contextual de Helen Nissembaum, que basicamente traz a noção de que cada
organização, cada sistema, está inserido em um contexto bastante particular. O
contexto envolve pontos como normas, regras, valores internos, propósitos ou
objetivos da organização. Cada contexto também possui atores diversos,
atributos específicos e princípios de transmissão particulares, relacionado ao
fluxo das informações.
Por exemplo, quando nos referimos a serviços de prestação de serviços
de saúde. Considere o caso em que um médico precisa realizar uma consulta
com um paciente. O médico tem a expectativa de que o paciente seja
transparente, sincero, e também cuidadoso, ao lhe entregar informações no
primeiro encontro entre os dois. Todavia, depois que existe alguma confiança
estabelecida entre médico e paciente, a troca de informações é livre – isso tem
relação com as normas com as quais a troca de informação se dá, do ponto de
vista da Integridade Contextual. Ainda, pode ser que o médico insira algumas
informações em seus sistemas para preencher prontuário, diagnóstico e
prescrição. O sistema pode, indevidamente, compartilhar tais informações com
redes de farmácias conveniadas para o tratamento do paciente, e então o
paciente começa a receber propagandas farmacêuticas. Nesse caso, isso não
necessariamente seria um grande problema, sobretudo quando há
consentimento por parte do titular, nesse caso, o paciente.
Aqui, mais uma vez, vale a pena mencionar o NIST, em específico, os
descritivos que a iniciativa traz sobre vulnerabilidades explícitas, eventos
adversos e também ajuda a entender as probabilidades de ocorrência de tais
35
Pós Graduação:
eventos e seus impactos. Entendendo vulnerabilidade como “ações de dados

problemáticas”, modelo se baseia em: 1 – descrições de comportamento do
sistema; 2 – implicações de tais comportamentos; 3 – eventos adversos oriundos
de tais comportamentos; 4 – como a ocorrência dos eventos afetam indivíduos;
5 – impactos negativos. Além disso, o NIST também apresenta uma
nomenclatura para eventos adversos, de forma similar ao que faz a Taxonomia
da Privacidade de Solove, a saber: perda de autonomia, exclusão, perda de
liberdade, estigmatização, poder desbalanceado, perda de confiança, perdas
econômicas.
Ainda que existam diversos modelos de riscos nos quais se basear,
muitos deles têm semelhanças e em alguns momentos, podem até ser
considerados sobrepostos uns aos outros. Isso é positivo, uma vez que a
combinação de modelos permite que se complementem em porções nas quais
um único modelo não resolveria todo o caso. Redundância, do ponto de vista de
privacidade e segurança, pode ser um aspecto altamente positivo, uma vez que
controles “duplicados” podem auxiliar na prevenção de ataques. Todavia, não
vale a pena “abraçar o mundo”, sendo inteligente o uso limitado de modelos no
intuito de diminuir a complexidade da análise de riscos.
5.1. Processos de Software e Ciclo de Vida de Sistemas com Foco em

Privacidade
Feita a introdução de alguns dos modelos de racionalização de riscos

mais populares internacionalmente, podemos, agora, tentar inserir tais modelos
em processos de desenvolvimento de software. Para isso, a Associação
Internacional de Profissionais de Privacidade introduz um framework que pode
servir de base para a construção de softwares seguros e com alta possibilidade
de entrega de privacidade a seus usuários.
Como sabemos, a concepção e construção de um software não é algo
trivial. Existem diversas arquiteturas, padrões, ferramentas, tecnologias, riscos,
mudanças, incertezas, etc. Um modelo de processo de software geralmente
envolve, como dito anteriormente, as seguintes etapas: levantamento de
requisitos, projeto e design, implementação, testes, implantação e manutenção.
Independentemente do modelo, seja ele o tradicional, em Cascata, em Espiral,
36
Pós Graduação:
ou métodos ágeis como Scrum ou até mesmo DevOps, quando se trata de

mitigar riscos de privacidade, é possível integrá-la como um ponto focal em
qualquer ponto do processo de construção do software, preservando requisitos
legais através da inclusão das observações do especialista em privacidade de
dados.
Podemos listar uma ampla gama de métodos de desenvolvimento de
software com foco em privacidade que poderiam ser empregados por uma
organização, por exemplo:
• Privacy Management Reference Model and Methodology (PMRM)
- promulgado pela Organization for the Advancement of Structured
Information Standards (OASIS)
• Preparing Industry do Privacy-by-design by suppoting its
Application in Research (PRIPARE) (European Comission)
• LINDDUN da Bélgica
• Privacy Risk Assessment Methodology (PRAM) - NIST
5.1.1. Um Framework para Implantação de Privacidade
Conhecendo os modelos de risco, e padrões de desenvolvimento de software

com foco em privacidade, podemos, a partir daí, estabelecer um framework para
a implantação de privacidade em sistemas computacionais. A IAPP (2020)
coloca seis etapas básicas para tentar criar uma estrutura de privacidade dentro
das organizações. Vejamos cada uma dessas etapas:
1. Caracterização – se preocupa em responder perguntas como:
a. Como informações pessoais fluem pelo sistema?
b. Como são processadas?
c. Quais tecnologias estão envolvidas?
d. Como é o ciclo de vida dos dados?
e. Quem são os atores?
f. Quais dados entram, quais ficam, e o que sai?
2. Identificação de eventos – com base em modelos de risco, entender quais
são as ameaças:
a. O que pode dar errado?
b. Quais normas podem ser violadas?
37
Pós Graduação:
3. Avaliação de riscos – com base nos eventos, suas probabilidades de

ocorrência e impactos em potencial, responder coisas como:
a. Qual a probabilidade de ocorrência de um ataque dada a existência
de uma vulnerabilidade?
b. Como racionalizar riscos?
4. Resposta a riscos – com atenção aos recursos disponíveis, como reagir
à existência de riscos, respondendo perguntas como?
a. Devo aceitar, transferir, mitigar ou evitar certos tipos de riscos?
5. Controle – a partir de uma estrutura de mapeamento de riscos,
implementar controles administrativos e tecnológicos.
a. Quem é o DPO?
b. Como estão documentados os procedimentos de segurança e
privacidade?
c. Qual a frequência e quais treinamentos em privacidade estão em
vigor?
d. Como se dá o inventário de informações pessoais?
e. Como estão estruturadas as práticas de rastreamento?
f. Temos a implementação de controles tecnológicos como
autenticação, autorização, criptografia, logs, etc?
6. Monitoramento e revisão – a implantação de privacidade em uma
organização é um processo contínuo, por isso, é importante estabelecer
revisões e acompanhamento constantes. Estabelecer pontos nas quais
revisões são obrigatórias é uma das alternativas para garantir esse ponto.
6. Introdução ao Design Orientado à Privacidade
Neste curso você terá uma disciplina específica para tratar apenas deste tema:
o projeto e design de sistemas orientado à privacidade, também conhecido como
Engenharia de Privacidade. Apesar de não mergulharmos fundo, nesse tema,
por hora, introduziremos alguns mecanismos e benefícios oriundos dessa que é
uma área que vem se tornando bastante popular não só entre profissionais de
tecnologia, mas também gestores e juristas voltados à privacidade.
A essa altura já temos uma boa noção de que a etapa de levantamento
de requisitos é o primeiro passo no ciclo de vida de um sistema. Quando
38
Pós Graduação:
colocamos privacidade como prioridade, devemos estar atentos em como ela

pode ser descrita em termos da descrição das funcionalidades, restrições e
limites do software. Os requisitos iniciais de um sistema evoluem com o tempo,
e dão embasamento não só na construção de sistema, mas também quando a
decisão é por contratar uma solução pronta. Geralmente representamos
requisitos em termos de documentações de software (através de UML, por
exemplo), modelos matemáticos e também como histórias de processos ágeis.
O mais importante a se notar: quando o mapeamento de requisitos inclui
privacidade desde o início, a mitigação de riscos é muito mais certeira; além
disso, é muito mais barato construir privacidade do zero, do que modificar o
sistema futuramente.
Já falamos, anteriormente, por algumas vezes, sobre requisitos funcionais
e requisitos não funcionais. Vamos distingui-los, agora: os funcionais descrevem
e se traduzirão em funcionalidades reais do sistema, funcionalidades diretas e
específicas; já os não funcionais descrevem restrições ou propriedades
intrínsecas do sistema, que deverão ser traduzidos ao longo dos requisitos
funcionais ou elementos de design do sistema. Para racionalizar um requisito,
geralmente, descrevemos o que chama de Especificação de Requisitos de
Software (Software Requirement Specification - SRS). Em uma SRS, para cada
requisito mapeado pelo engenheiro junto aos stakeholders, temos informações
como: um identificador próprio (ID), sentença descritiva, autor, número da
revisão, data da liberação, palavras-chave, conformidade legal, descrição do
cenário, suposições de design e glossário de termos (opcional).
Durante os anos em que a engenharia de privacidade vem se
desenvolvendo, entidades vêm levantando requisitos de privacidade comuns
através de sistemas diversos. Por isso, muitas vezes, incentiva-se o reuso,
através do acesso a repositórios de requisitos de privacidade. Por exemplo, um
designer, em seu projeto, pode diferenciar dois mecanismos de consentimento
diferentes: 1 – mecanismo de indução, assumindo que o titular concorda quando
está utilizando o site e seus dados estão sendo coletados através de requisições
HTTP; 2 – mecanismo de checkbox, quando o usuário é solicitado a consentir
ativamente, clicando na caixinha que marca sua ciência. Esse são dois padrões
comuns de coleta de consentimento e, provavelmente será possível encontrar
tais padrões listados nos repositórios de requisitos.
39
Pós Graduação:
Para além da mera representação textual, podemos nos apoiar em

linguagens visuais, como a UML, para modelar requisitos em termos de
diagramas de processo, diagramas de caso de uso, fluxograma, papéis e
matrizes de permissão, diagramas de estado, etc. Na prática, organizações
menores terão dificuldade em manter documentação precisa sobre requisitos,
exigindo do profissional de privacidade, muitas vezes, que faça certa engenharia
reversa, partindo do sistema pronto, para recriar uma documentação do zero.
O levantamento de requisitos pode se apropriar de várias fontes de
informação. Pode-se tentar realizar entrevistas e pesquisas de campo com
usuários em potencial, ou com grupos de trabalho. Confiando em reuso, se
inspirar em catálogos de padrões de privacidade como os FIPPs e o NIST.
Muitas vezes, será preciso interpretar legislação e regulações para tangibilizar
requisitos para que o sistema esteja adequado às necessidades. Contratos,
blogs, revistas, jornais, benchmarks de concorrentes também são fontes em
potencial para se aferir as funcionalidades e as características de um sistema.
6.1. Gestão de Requisitos e Matrizes de Rastreabilidade
Conforme o software vai evoluindo, é preciso acompanhar a mudança de seus

requisitos de forma a facilitar a rastreabilidade e a manutenibilidade do sistema.
Às vezes, a mera documentação textual e/ou visual descritas anteriormente não
bastam para uma boa gerenciabilidade dos requisitos em relação ao que foi
mapeado suas reais implementações práticas. Para auxiliar nesse sentido, surge
o conceito de matrizes de rastreabilidade. A ideia é compreender melhor as
relações entre requisitos e regulações, legislação, riscos, dentre outros aspectos
relacionados a privacidade.
Tomemos como exemplo, alguns incisos da LGPD, em seu artigo 6º:
“IV - livre acesso: garantia, aos titulares, de consulta
facilitada e gratuita sobre a forma e a duração do tratamento,
bem como sobre a integralidade de seus dados pessoais;
V - qualidade dos dados: garantia, aos titulares, de exatidão,
clareza, relevância e atualização dos dados, de acordo com
a necessidade e para o cumprimento da finalidade de seu
tratamento;
40
Pós Graduação:
VI - transparência: garantia, aos titulares, de informações

claras, precisas e facilmente acessíveis sobre a realização
do tratamento e os respectivos agentes de tratamento,
observados os segredos comercial e industrial;”
Continuando o exemplo, um sistema de e-commerce qualquer poderia ter como
requisitos o que se lista a seguir:
• REQ-32: Link de rodapé em todas as telas, dando acesso às Políticas de
Privacidade e Termos de uso.
• REQ-33: Coletar o consentimento para cada propósito de uso, de forma
independente, através de checkbox.
• REQ-34: Disponibilização de dashboard contendo os dados do usuário
autenticado para consulta, correção ou deleção de dados pessoais.
Uma matriz de rastreabilidade relacionando a legislação vigente, e os requisitos
listados acima, poderia permitir identificar quais dos requisitos atendem aos itens
específicos da legislação. Observe a tabela abaixo:
Tabela 1 – Relação entre requisitos e legislação

Fonte: o autor
Nesse caso, podemos aferir algumas conclusões. Percebamos que um mesmo

inciso da lei pode estar relacionado a mais de um requisito, e o mesmo acontece
com um mesmo requisito que está relacionado a mais de um item da legislação.
Tomemos como exemplo o requisito REQ-34, que visa disponibilizar uma tela de
dashboard para que o usuário consiga acessar os dados que disponibilizou
dentro da plataforma. Esse requisito se relaciona ao inciso IV do artigo 6º, pois
41
Pós Graduação:
auxilia no livre acesso dos dados pelo titular, ao passo que também permite que
o usuário esteja atento à qualidade dos dados o que, por sua vês, é mencionado
no inciso V do artigo 6º da LGPD. Reparemos, portanto, que conseguimos
racionalizar a real implementação das características necessárias no sistema,
do ponto de vista de legislação, nesse caso.
Todavia, poderíamos criar matrizes de rastreabilidade para, por exemplo,
listar os requisitos em cada uma das colunas da matriz e, nas linhas, listaríamos
os riscos ou vulnerabilidades que o sistema pode apresentar. Com isso, teríamos
um novo ângulo de visão do sistema, agora, relacionando a forma com a qual
um requisito pode levar a um dano à privacidade ou à segurança dos dados.
Independentemente das relações que se deseja explorar, é sempre válido ter em
mente: o sistema evolui, e com isso, as análises devem ser acompanhar esse
fato. Uma boa gestão de requisitos e de compliance entende que, conforme
mudanças são implementadas no software, relações devem ser reavaliadas.
6.2. Design de Privacidade de Alto Nível
Projetistas e designers de software geralmente partem de abstrações maiores,

menos palpáveis, quando começam a conceber o sistema. Uma das primeiras
coisas que se decide, é em qual estrutura arquitetural se basear para dar vida
às funcionalidades. Na era da internet e dos dispositivos móveis, é muito comum
que se fale, por exemplo, em Arquiteturas Cliente-Servidor. Nesse tipo de
sistema, o usuário usa um dispositivo próprio, chamado de cliente, e o
processamento pesado é executado em um outro computador com o qual o
cliente se conecta, chamado de servidor. Basicamente, o cliente faz requisições,
e o servidor responde a tais requisições.
Um servidor é, de fato, um computador conectado à internet que tem seu
conteúdo acessado, geralmente, através de clientes em seus browsers de
navegação. Todavia, um aplicativo para smartphone, apesar de não ser um
browser, também pode fazer papel de cliente, e realizar requisições a servidores.
Perceba, portanto, que aqui, teríamos o caso de um sistema voltado tanto à
WEB, quanto a mobile. Outras arquiteturas como Service Oriented Architecture
(SOA), computação em nuvem e arquiteturas federadas, também similaridades
com o modelo Cliente-Servidor.
42
Pós Graduação:
Uma outra arquitetura que vale a pena mencionar, é o que conhecemos

como Ponto-a-ponto (P2P – Peer-to-peer). Aqui, uma mesma máquina pode se
conectar a uma rede de outras máquinas, formando uma aplicação
descentralizada, na qual não se depende de um servidor único para atender a
requisições. Ao invés disso, em sistemas P2P, cada máquina pode ser tanto
cliente quanto servidor, realizando requisições ou entregando respostas e
fornecendo recursos.
Do ponto de vista de alto nível, para além das escolhas arquiteturais feitas,
pode-se avaliar o sistema em termos de alguns atributos de qualidade. Por
exemplo, de que forma uma pessoa pode ser identificada no sistema? Qual a
extensão com a qual as informações estão armazenadas no lado do “cliente” de
um sistema? Qual a extensão na qual as informações pessoais estão acessíveis
a outros? Quão disponível estão a aplicação, as funcionalidades e os dados?
Como o sistema mantém um estado confiável quanto à qualidade dos dados, se
mantendo tolerante a falhas?
Tais perguntas devem orientar o processo de racionalização do design,
para que, mesmo em um alto nível de abstração, se tenha um desenho de como
os dados e informações fluirão ao longo do sistema. A partir disso, novamente,
pode-se investigar por vulnerabilidades, tentando antecipar problemas que
venham a acontecer antes mesmo que o sistema seja codificado e entregue aos
clientes.
6.3. Design de Privacidade de Baixo Nível
Uma vez que já existe um desenho de alto nível, projetado por arquitetos de
software e profissionais de privacidade, pode-se partir para maiores detalhes de
implementação do sistema. Indo de um maior nível de abstração, para um nível
menos abstrato, já podemos começar a falar no trabalho de programadores
enquanto tradutores do design em código-fonte.
Ainda na etapa de projeto, é possível pensar em reuso de padrões de
projeto clássicos, sejam padrões de programação ou de privacidade. Reuso
também é aplicável a frameworks e bibliotecas clássicas disponíveis para
diversas linguagens de programação. A ideia é que os elementos suas
respectivas responsabilidades dentro software produzam um efeito que reduza
43
Pós Graduação:
dependência entre as entidades codificadas, isolando informações de forma a

restringir acesso não desejado. É o que chamamos de boas práticas de
desenvolvimento de software.
Além disso, caso a empresa tenha recursos para tanto, é saudável
implementar processos de revisão de código, durante as etapas de
desenvolvimento, para tentar minimizar erros que passariam despercebidos. Por
fim, novamente, dependendo dos recursos da organização, deve-se estimular a
criação de documentação sobre como o software foi, está sendo e será
implementado.
7. Introdução à Governança da Informação
Para além da informação digital, toda e qualquer informação contida em quadros,

avisos, arquivos físicos, documentos em papel, entre outras, fazem parte do que
deve ser protegido, quando se fala de privacidade, proteção e segurança de
dados. Em uma organização, uma boa estratégia de governança de informação
tenta buscar os tradeoffs entre riscos de informação e o valor que tais
informações entregam.
Distintas organizações podem optar por criar seus próprios frameworks
de governança informacional, ou mesmo adaptar o que já existe no mercado.
Objetivos como buscar transparência nas operações, manter conformidade
legal, estabelecer boas políticas, manter procedimentos de forma estruturada,
gerir registros e documentação e implementar métodos e ferramentas de
segurança da informação.
Conforme a organização vai evoluindo, seus setores, processos e
negócios tendem a aumentar em tamanho e complexidade. Por isso instituições
como a ISACA trazem em seu portfólio frameworks de governança da
informação como o Control Objectives for Information and Related Technologies
(COBIT). Aqui, apresentam-se objetivos de controle, mapas de auditoria,
ferramentas de implementação e técnicas de gerenciamento de sistemas
informativos. O COBIT é popular por sua robustez, tendo sua eficácia
comprovada através de diversas organizações ao redor do mundo. Outro
framework bastante conhecido é a Information Technology Infrastructure Library
(ITIL).
44
Pós Graduação:
Tais frameworks fazem-se notórios pela centralidade do TI no mundo

atual. Não bastasse o papel central que a tecnologia assume no dia a dia das
organizações e indivíduos, profissionais dessa área são obrigados a lidar com
demandas urgentes, entregando soluções escaláveis e desenvolvidas tão rápido
quanto possível. Há escassez de profissionais no mercado, e, mais uma vez, o
cenário se torna mais complexo a cada dia que passa, devido à evolução da
própria ciência da computação.
Nesse contexto, cabe aos engenheiros de privacidade, gestores de
tecnologia e analistas jurídicos digitais, a responsabilidade por tentar se manter
em consonância com as demandas do mercado e da sociedade. Por meio de
soluções práticas e mensuráveis, é preciso que esse tipo de profissional tenha
condições de se manter em um processo contínuo de reciclagem e revisão, de
forma autorregulada.
45

Livreto Fundamentos Das Tecnologias Da Informacao e Comunicacao TICs e Privacidade 1

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livreto Fundamentos Das Tecnologias Da Informacao e Comunicacao TICs e Privacidade 1

Enviado por

Direitos autorais:

Formatos disponíveis

Pós Graduação:

Proteção e Privacidade de Dados

1. Introdução à Ciência da Computação

Os sistemas digitais, como os conhecemos, são muito diferentes dos

Figura 1 – Máquina analítica de Charles Babbage

A máquina de Babbage possuía apenas o projeto de hardware. Prevendo

Entre as décadas de 1930 e 1940, tivemos a explosão da segunda guerra

Figura 2 – Hardware, software e usuários

No cerne de tudo, temos o processador (CPU), os dispositivos de entrada e saída

ou quando estamos acessando um site via Google Chrome, estamos utilizando

1.1. Áreas de conhecimento necessárias à Ciência da Computação

Como vimos anteriormente, os computadores tomam por base a lógica binária

mundo real, abstraídas via código-fonte para o mundo virtual. Por

Para além das áreas de estudo que estão relacionadas à base do

Ciência da Computação que, para além do apoio ao desenvolvimento de

1.2. Sistemas de Informação

Figura 3 – Dos dados à sabedoria

Para tornar as coisas mais claras, observe a figura acima. Podemos

Figura 4 – Dados, informação e conhecimento

Stair e Reynolds (2016) definem sistema de informação como um sistema

Cegielski (2015) colocam um sistema de informação como a integração de

1.3. Profissionais de Tecnologia e suas Responsabilidades

Como dito anteriormente, o desenvolvimento de tecnologias é algo não trivial e

como à medida em que aumenta o número de funcionalidades necessárias às

do sistema (usuários com mais privilégios que os operadores comuns do

Recursos de infraestrutura, noções contratuais, noções de integração e

2. Desenvolvimento de Sistemas e o Ciclo de Vida de Softwares

Figura 5 – Processo de Software: Modelo em Cascata

O modelo Cascata é antigo, e remete aos primórdios da engenharia da

Figura 6 – Processo de Software: Modelo em Espiral

Diferentemente do Modelo em Cascata, o Modelo em Espiral permite que as

flexibilidade, o Modelo em Espiral tem a desvantagem de ser mais lento quando

Figura 7 – Processos de Software: Métodos Ágeis

Xtreme Programming e Scrum são dois dos métodos mais conhecidos,

2.1. Modelagem de Sistemas e Documentação de Software

Assim como no mundo corporativo existem diversos documentos textuais

Figura 10 – Diagrama de Casos de Uso

Figura 11 – Diagrama de Classes

Figura 12 – Diagrama Entidade-Relacionamento

Figura 13 – Diagrama de Sequência

3. Introdução à Segurança da Informação

A essa altura do curso, você provavelmente já ouviu falar bastante em segurança

eletromagnéticas, então estamos comprometendo a integridade de tais

A importância da Segurança da Informação para a privacidade parece bastante

colaboradores utilizam dispositivos “próprios” para exercer suas funções

3.1. Abrangência da Segurança da Informação e Privacidade

Existem diversas propostas, ao redor do globo, no sentido de instruir, orientar e

práticas e padronizações para se atuar com segurança e privacidade em

3.2. Ataques à Segurança da Informação

Um software, como dito anteriormente, é uma espécie de “organismo vivo”, e

frequência, descumpridos. Perceba, portanto, que segurança da informação e

• Expolit: malware que busca e explora vulnerabilidades na máquina alvo;

3.2.2. Roubo de Credenciais e Outras Vulnerabilidades

4. O Ciclo de Vida dos Dados

Depois de uma visão geral sobre Ciência da Computação, Desenvolvimento de

Figura 14 – Data Lifecycle

4.1. Notificação e Consentimento

Existem diversos mecanismos bem conhecidos para se notificar sobre os

É importante notar que usuários, na esmagadora maioria das vezes, não

Basicamente, existem dois tipos de coleta de dados, sendo a ativa e a passiva.

O tratamento ou processamento dos dados deve sempre estar em pleno

Usos secundários de dados não se limitam a, mas incluem os seguintes