PCI, GDPR, LGPD e BACEN: das siglas à prática
Sempre que ouvimos estas siglas logo ficamos com dúvidas do que é cada uma e como atender seus requisitos de forma prática.
Neste post tentarei passar um pouco do que aprendemos aqui na Hotmart durante o árduo trabalho de tornar o ambiente de desenvolvimento e produção cada vez mais seguro.
Por que falar disso e qual a importância?
- Garantir que os dados sejam íntegros, confidenciais e disponíveis para os usuários donos da informação
- Evitar e mitigar riscos de vazamento e perda de dados
- Ficar em conformidade com as regulações e melhores práticas de proteção de dados
- Talvez o principal: proteger o negócio da empresa!
Sistemas Regulatórios
Existem vários sistemas regulatórios que, de formas semelhantes e/ou complementares, controlam, auditam e regulam manipulação e armazenamento de dados de usuários (pessoais, financeiros, etc) e dados da empresa (faturamento, portfólio de clientes, funcionários, etc).
Recentemente temos lidado com alguns específicos, que é o foco deste post. São eles:

Payment Card Industry
É um conjunto de regras estabelecidas e mantidas pelas principais bandeiras de cartão de crédito com intuito de proteger transações envolvendo cartão de crédito. Agentes devidamente autorizadas realizam processo de auditoria nas empresas que transacionam com cartão de crédito, se a empresa estiver em conformidade com todos os requisitos ela ganha um “selo / certificado” de conformidade e está permitida a operar com as bandeiras que compõem o grupo PCI.
Existem 4 níveis de certificação, onde o nível 4 é o menos exigente e o 1 é o mais. O nível 1 se aplica a todas as empresas que armazenam ou trafegam dados de cartão, transacionam acima de 6 milhões de transações por ano, ou se for uma subadquirente. Somos nível 1.
Para o nível 1 é necessário estar em conformidade com os 12 requisitos abaixo:

Mais à frente veremos como aplicar estes requisitos de forma prática.

General Data Protection Regulation
É um sistema regulatório focado na privacidade e proteção de dados de indivíduos europeus ou residentes na Europa. Regulamenta também exportação de dados de europeus ou residentes para fora da União Europeia. Está em vigor desde Maio de 2018 e já aplicaram algumas multas milionárias desde então. Esta regulamentação não foca apenas em sistemas computacionais, um caso intrigante que demonstra isso foi em uma rede de hotéis que possuía uma lista de clientes, com todos os seus dados pessoais impressos na entrada do restaurante, alguns clientes ficaram incomodados e denunciaram o local, o que gerou uma multa de aproximadamente € 16Mi.

Lei Geral de Proteção de Dados
É o “fork” do GDPR no Brasil. Entra em vigor em Agosto de 2020. Tecnicamente trata ações bem semelhantes às do GDPR, tendo diferenças quanto às sanções e outros pormenores não muito técnicos.

Banco Central do Brasil
Autarquia federal integrante do Sistema Financeiro Nacional que normatiza e fiscaliza as instituições financeiras no Brasil (nacionais ou que operam no Brasil). É quem chancela uma instituição financeira e/ou de pagamentos a operarem dinheiro de terceiros no país.
O que todos estes sistemas têm em comum?
Escopo
Todos eles irão estabelecer requisitos e processos que tratam violação de segurança, indo além de sistemas computacionais e dados de clientes, mas também envolvendo o como os dados são transitados em meios físicos (impressos em papel) e qualquer dado que envolva uma pessoa (física ou jurídica) incluindo nisso seus funcionários.
É considerado um incidente de segurança:
- Evento que tem impacto negativo na confidencialidade, integridade e disponibilidade dos dados. Ex.: perda de USB ou laptop com informações confidenciais do negócio
Uma violação de segurança só se torna uma violação de dados pessoais quando envolve a perda de dados pessoais ou se houve processamento ilegal destes dados.
Sanções
Todas tem em comum sanções como estas:
- Advertência e eliminação de dados pessoais até a regularização
- Multas de até 4% do faturamento, limitando-se a valores definidos pelo sistema regulatório local
- As sanções podem ser aplicadas cumulativamente, por dia e infração, sempre com base na gravidade e extensão da violação
- Divulgação da infração para autoridades, em mídias de alto alcance e para as pessoas afetadas
- Encerramento judicial das operações
Definição sobre Dados Pessoais
Talvez um dos itens que mais trás dúvidas é: quais dados são sensíveis, quais não são, quais precisam ser tratados???
Vamos tentar entender isso… Na matriz abaixo temos uma classificação do que é considerado sensível/não sensível e direto/indireto:

Sensível: proibido serem armazenados, mesmo criptografados, a não ser que sejam necessários para cumprir alguma obrigação legal, regulatória ou judicial
Não sensível: permitido serem armazenados, porém precisam de consentimento da coleta, clareza e transparência na necessidade.
Todos os dados classificados como “Diretos” devem ser tratados, seja criptografando, minificando ou truncando. Não podem ser exibidos para qualquer um de forma plain text.
Dados classificados como “Indiretos”, se estiverem só, sem um outro dado “Direto” em conjunto, não precisam ser tratados. Por exemplo, podemos armazenar o IP do usuário desde que não tenha outra informação complementar, que identifique o indivíduo, como nome, endereço, documentos…
Requisitos Funcionais e Operacionais
Segue abaixo os principais requisitos funcionais e operações comuns a todos estes sistemas regulatórios:
1- Tratamento adequado dos dados pessoais
Minimização: descarte/eliminação de dados não necessários para o negócio. Exemplo, se não precisarmos em nenhum momento do campo UserName, porque não eliminá-lo de vez?

Pseudonomização: armazenamento sem a possibilidade de associação, direta ou indireta, a um indivíduo, senão por estruturas externas de associação (de-para). No mesmo exemplo, se o UserName for necessário em algum momento, podemos exportar esta informação para um novo sistema que possua um nível de segurança maior, deixando no sistema antigo um dado sujo e reversível apenas se utilizado a estrutura do sistema novo.

Anonimização: “sujar” o dado real com algum conteúdo fake, irreversível, mas que permita o funcionamento do sistema sem impactar na sua integridade. Ainda no mesmo exemplo, a ideia seria simplesmente manter a coluna, porém com dado sujo e irreversível, as vezes esta pode ser a única solução para sistemas legados ou produtos caixa preta onde o dado é obrigatório e a exclusão da coluna pode quebrar a consistência do sistema.

2- Consentimento e clareza: todos os dados coletados devem ser conhecidos e aprovados pelo usuário, inclusive o compartilhamento para terceiros
3- Exclusão: permitir que o usuário possa solicitar a exclusão parcial ou completa dos seus dados pessoais
4- Livre acesso e portabilidade: possibilitar acesso e exportação dos dados pessoais do usuário para serem utilizados em outra plataforma que ele desejar
5- Controle de acesso: identificar e individualizar os acessos aos dados sensíveis
6- Auditoria: registro de todos os acessos aos dados sensíveis via sistema
7- Comunicação: comunicar qualquer tipo de incidente, tanto para autoridades quanto para os usuários afetados
Requisitos Não Funcionais
Atualmente, nosso ambiente produtivo impactado por estes sistemas regulatórios está rodando na AWS, então algumas soluções técnicas que iremos ver abaixo estão direcionadas para este ambiente Cloud, algumas das soluções podemos encontrar nos outros providers Cloud.
Vamos à lista de RNFs:
1- Desenvolvimento de código seguro
- Inibir dados pessoais nos logs da aplicação
- Não versionar chaves, senhas e tokens de acesso dentro do código, em formato plain-text
- Evitar implementações que possibilitem injections (ex: concatenar SQL)
- Pseudonomizar ou anonimizar dados pessoais
- Minimizar/descartar dados pessoais que não são necessários para o negócio
- Consumir serviços sempre através de protocolos seguros (HTTPS)
- Não utilizar dados reais em testes (ex: número de cartão de crédito real)
- Code Review focado em segurança (ex: plugins de segurança do Sonar)
- Treinamento focado em desenvolvimento seguro
2- Controlar e identificar os acessos aos recursos de infraestrutura
3- Auditar acessos aos recursos num sistema centralizado
4- Criptografar chaves, senhas e tokens usados em cada aplicação
5- Rotacionar chaves, senhas e tokens usados em cada aplicação
6- Prevenir contra ataques, vazamentos e vulnerabilidades
7- Monitorar e notificar ações suspeitas
8- Restabelecer serviços em caso de desastres
9- Segregar infraestrutura em contas e redes separadas
10- Configurar ACLs do Firewall restringindo acessos entre camadas
11- Antivírus nas estações de trabalho, servidores e dispositivos móveis
Dos requisitos não funcionais 2 ao 11, por si só, são muito vagos, e os sistemas regulatórios, a maioria deles, não deixam claro o que fazer e como fazer de forma prática e em cada contexto técnico. Daqui em diante vamos ver como conseguimos chegar lá…
Abaixo temos estes 11 RNFs aplicáveis em cada escopo técnico e de infra. Vamos começar pelo mais óbvio, a aplicação, depois banco de dados, rede e assim por diante.
RNF na aplicação:

- Comunicar através canal seguro:
TLS 1.2 +
mTLS em APIs internas, com Service Mesh
HTTPS para externa
- Regras de firewall segmentada e restringindo origem e destino
Security Groups liberando apenas requisições vindas do Load Balancer ou de outras aplicações na mesma rede. Limitar também acesso externos a partir das apps para ips e portas conhecidas.

- Criptografar dados sensíveis com chaves rotacionáveis
KMS é a melhor opção dentro do ambiente AWS, atente aos requisitos de rotação e encriptação, porém usa-lo dentro do código pode não ser tão simples. Pra simplificar a deixar o código mais agnóstico, utilizamos o sops, ferramenta da Mozilla focada em encriptação com multichaves de qualquer tipo de arquivo.
- Rotacionar senhas, chaves e tokens de acesso a cada 90 dias
Secrets Manager é o serviço da AWS que realiza o armazenamento e rotacionamento de secrets. É facilmente customizável, o fluxo de rotação aciona lambdas que ficam provisionadas na própria conta e podemos, com isso, implementar como precisarmos.
- Restringir credencial de serviços Cloud apenas para a aplicação
Todas as aplicações devem utilizar credenciais de aplicação para acesso aos serviços AWS, fornecidas por IAM Role, com policies explicitando tudo que a aplicação terá acesso. Eventualmente, o uso de IAM Role poderá exigir ajustes no código, para o credential provider conseguir usar a role certa. No caso de Java, utilize preferencialmente a implementação da classe DefaultAWSCredentialsProviderChain.
- Controlar, identificar e logar acessos remotos ao ambiente
Uma ótima opção em ambiente AWS é o Session Manager, ele permite acesso individual e identificado às EC2 via IAM, também gera logs de todos os comandos realizados durante a sessão. A sessão pode ser estabelecida dentro do Console AWS, sem precisar instalar nenhuma ferramenta local. O setup é simples, basta atachar a policy AmazonEC2RoleforSSM à EC2 e instalar o agente amazon-ssm-agent. Não é necessário abrir porta 22, basta a EC2 ter acesso aos IPs do serviço na porta 443, o agente que realiza a comunicação entre o painel AWS e a EC2.
- Proteger ambiente através de antivírus
Depois de testar algumas opções, optamos pelo Symantec Endpoint Protection para as estações de trabalho e servidores Windows. Estações de trabalho Linux usamos o ClamAV.
- Escanear vulnerabilidades em código, binários e ambiente produtivo
truffleHog: opção boa para escanear código em busca de chaves, senhas e tokens hardcoded
Hadolint: lint docker que previne alguns erros e vulnerabilidades
trivy: realiza scan de vulnerabilidades em imagens docker
AWS Inspect: é a solução da própria AWS que realiza scan nas EC2 e reporta vulnerabilidades sobre todos os binários da EC2
- Utilizar ferramenta de File Integrity Monitoring (FIM)
Por fim, é necessário uma ferramenta que monitore alterações em arquivos de configuração ou críticos para a segurança do SO. Em linux usamos o ossec, para Windows usamos EventSentry. Ambos reportam os eventos de alteração em sistema centralizado de logs.
RNF em Bancos de Dados:

- Rotacionar senha root pelo menos a cada 90 dias
Também pode ser usado o AWS Secrets Manager
- Regras de firewall segmentada e restringindo origem e destino
Security Groups liberando apenas acessos vindos das aplicações
- Auditar todas as ações realizadas sobre os dados
RDS mysql: usar versão 5.6 ou 5.7 com o plugin MariaDB Audit plugin + Audit Log habilitado. Versão 8 ainda não suporta auditoria das ações dentro do banco de dados. RDS postgres possui suporte, sendo necessário ativar os parâmetros log_statement=all e log_min_duration_statement=0. No Redshift a ativação é simples, via parameter group também.
- Todo acesso ao banco deve ser identificado e individual
Nos bancos AWS é possível ativar a integração via IAM, outras soluções, como Mongo Atlas, é possível integrar ao AD. Opte por soluções que se integrem via IAM ou AD.
- Criptografar dados sensíveis com chaves rotacionáveis
Disco deve ser encriptado com KMS. Para dados pessoais o KMS também é uma opção, mas pode deixar a conta mais salgada, outra opção são as Self Assigned Key, porém usando esta opção, é necessário se atentar com as políticas de rotação da chave.
- Replicação para casos de desastres e permitir continuidade
Imprescindível ativação de Multi AZ em todos os bancos, réplica de leitura em outras regiões e até para outra cloud. Os bancos gerenciados na AWS permitem este tipo de recurso. Para replicação entre clouds, uma opção dentro da AWS é o DMS (Data Migration Service).
RNF na DMZ:

- Apenas load balancers
Optamos por ALB ou NLB: possuem menor custo e suporte a N aplicações na mesma instância
- Regras de firewall segmentada e restringindo origem e destino
Security Groups liberando acesso de entrada para internet, porta 80 e 443, e egress apenas para servidores de aplicação
- Comunicar através de canal seguro (TLS 1.2+)
HTTPS e ACM com renovação automática são essenciais
- Registro de todos os requests
Todos os requests precisam ser registrados em ferramenta de SIEM. OS LBs da AWS possibilitam que estes logs sejam enviados para um bucket no S3.
RNF envolvendo a rede:

- Infraestrutura e serviços cloud separados por área de negócio
Nossas contas AWS estão estruturadas por área de negócio e gerenciadas via AWS Organization, com conta adicional para ambiente de desenvolvimento.
- Segmentos claros de redes com as devidas responsabilidades
Utilizar VPCs para definir as redes das aplicações na AWS, com pelo menos as seguintes camadas:
Pública: para rodar apenas LBs
Privada: para rodar apenas aplicações (EC2, Lambdas…)
Data: para rodar bancos (RDS, Redshift, Elastic, Redis)
- Isolamento entre as camadas (Internet > Public > Private > Data)
No ambiente AWS, as Network ACLs permitem estes isolamentos, de forma que cada camada só alcance o que pode.
RNF envolvendo infra on-premises e Cloud:

- Autenticação deve ser sempre em uma base centralizada, com políticas básicas de senha (força da senha, tempo de vida, 2fa, etc)
Uma boa opção é o Active Directory, pois atende desde estações à servidores e Console AWS, através do AWS SSO.
Além de possibilitar a integração com AD, o AWS SSO também possibilita a centralização do acesso de todas as contas num único painel, além da inclusão de outras ferramentas mais utilizadas durante o ciclo de desenvolvimento (Sonar, Artifactory, Jenkins, NewRelic, etc). Também limita o tempo de vida das credenciais de acesso ao ambiente AWS, durante até no máximo 12h. É possível também criar políticas de Deny até mesmo para acessos como root. Limitações: não tem CLI/SDK e permissions set limitados.
Para o 2fa, o SSO permite uso do protocolo RADIUS, então uma solução é subir este serviço dentro da infa Cloud e plugar o SSO nele. Utilizamos o FreeRADIUS, plugado em uma instância do AD Connect, que serve como um proxy para as EC2 que possuem a instalação full do AD, sincronizadas via VPN IPSec com uma réplica na rede on-premises.
- Identificação da origem de rede do acesso aos recursos
A solução de VPN da AWS, com IPSec permite a propagação do IP da rede local até recurso de destino, desta forma é possível identificar ações suspeitas, como o acesso por um IP for fixo por pessoa em um recurso AWS utilizando uma credencial compartilhada.
- Data Loss Prevention (DLP) para rede e serviços SaaS, como G-Mail, G-Drive, Dropbox, etc…
Para DLPs de rede, Symantec DLP é uma boa opçõa. Para serviços SaaS, como G-Suite, Symantec CASB é uma boa opção.
Um pouco mais desta topologia:

RNF envolvendo a borda da rede

- Web Application Firewall (WAF)
São filtros de borda da rede que podem aplicar regras diversas (rate limit, injections, cross-site, etc). AWS WAF atende aos requisitos, embora seja bem limitado
- Intrusion Detection System (IDS) ou Intrusion Protection System (IPS)
São ferramentas que detectam ou bloqueiam pacotes que contém características maliciosos. AWS GuardDuty não é exatamente um IDS/IPS, mas ajuda neste requisito. Ele analisa eventos de acesso, identificando e alertando quando detecta comportamentos anômalos.
- Eventos e logs de bloqueios do WAF ou detecções do IDS/IPS, devem ser enviados para SIEM
Estas ferramentas podem gerar um volume muito grande de logs, então é necessário ter atenção quanto a ferramenta de ingestão e armazenamento. Utilizamos o AWS Kinesis para ingerir e S3 para armazenar.
RNF envolvendo monitoramento e auditorias:

- Precisa ser centralizado, com acesso controlado e gerando logs, ou seja, até mesmo o acesso na plataforma de logs/monitoramento também deve gerar eventos de acesso, identificando quem e o que acessou na ferramenta
Como dito anteriormente, é necessário usar soluções que consigam ingerir muito volume de logs, sugestão dentro da AWS é o AWS Kinesis.
- Retenção mínima de 90 dias em format de acesso rápido (online), e até 5 anos em formato que pode ter um load mais lento (offline)
Offline: Armazenar no S3 Deep Archive
Online: Elasticsearch Open Distro ou Elastic Cloud com plugin pago X-Pack. AWS Elasticsearch não é uma opção aceitável, pois não registra os acessos dentro dele mesmo.
- Obrigatório alertas e registro de comportamentos anômalos
AWS Security Hub: centraliza findings do AWS Config, AWS Inspect, AWS GuardDuty, AWS CloudTrail e outros. Fundamental seu uso no ambiente
- Registro de todos os logs de acesso, segurança e auditoria de infra
Isso inclui: scan, antivírus (estações e servers), WAF, acesso remoto (vpn e ssh/rdp), auditoria em bancos e recursos aws, AD, FIM, rotação, IDS/IPS…
Então, de forma resumida, o landscape ficou assim:

E é só… Obrigado!