PCI, GDPR, LGPD e BACEN: das siglas à prática

Fábio Viana
Nov 3 · 13 min read

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!

Fábio Viana

Written by

DevOps Team Leader and Specialist at Hotmart

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade