 |
Dentre os pilares do Well Architected Framework, o pilar de segurança está relacionado com a implementação de uma forte base de identidade, a habilidade de rastrear ações que ocorrem no sistema, conseguindo aplicar os aspectos de segurança em todas as camadas dos sistemas, protegendo dados em trânsito e em repouso. O pilar de Segurança olha ainda para formas de criar mecanismos e ferramentas para reduzir acesso direto das pessoas aos dados e preparar o sistema para eventos de segurança.
Já quando estamos tratando do ponto de vista workloads de Data & Analytics, que são as aplicações construídas com uso ou para uso intensivo de dados, além desses pontos básicos, alguns extras devem ser adicionados e aprofundados para tratarmos as especificidades de aplicação de uso intensivo de dados. Vamos a elas:
Entenda as classificações de dados e sua proteção políticas
Depois que entendemos como os dados são classificados dentro da organização, podemos usar esse conhecimento para planejar como cada classe de dados precisa ser protegida. Os sistemas de dados, por natureza, estão o tempo todo recebendo e enviando dados de várias formas, então é interessante, por exemplo, criptografar os dados no momento de movimentação entre os sistemas e criptografar os dados em repouso para evitar roubo de dados, minimizar impacto de atividades maliciosas e aumentar a proteção contra acesso indesejável aos dados.
Construir uma estrutura de classificação dos dados envolve conseguir responder perguntas como:
- Quem deveria poder ver cada tipo de dados?
- Estou classificando cada tipo de dados de acordo com alguma regra, como por exemplo Restrito, Confidencial, Interno e Público, que é sugerido no whitepaper de Classificação de Dados?
- Tenho regras de acesso aos dados criados pelos donos dos dados?
- Existe algum modelo de isolar os dados baseado nas suas classificações?
- Tenho algum mecanismo contínuo para buscar informações sensíveis nos dados, e implementar políticas para ofuscá-las, implementando políticas para prevenir acesso a esse dados sensíveis?
Identifique os proprietários dos dados de origem e faça com que eles definam as classificações de dados
Os donos dos dados, podem ser os administradores do Data Lake, podem ser equipes diversas responsáveis por produtos, até mesmo uma equipe de TI interna que tem responsabilidade nos dados salvos de modo histórico. Em outras palavras, precisam identificar quem são os donos dos dados para que eles classifiquem as permissões de cada tipo de dado ao longo dos sistemas de dados.
Como cada organização tem diferentes tipos de classificação, os sistemas de dados devem fornecer limites lógicos entre o processamento de dados de diferentes níveis de classificação de dados.
Para garantir a classificação, existem algumas perguntas que podem ser feitas:
- Cada fonte de dados tem um dono?
- O dono de cada fonte de dados está sendo envolvido em problemas com as permissões de acesso de cada fonte?
- Existe algum tipo de expiração para as permissões, onde os donos de cada fonte de dados tem a possibilidade de re-confirmar ou atualizar as permissões?
Registre as classificações de dados no Catálogo de Dados para que a carga de trabalho de análise possam utilizar
O processo do uso do catálogo deve ser difundido para toda organização, onde todas as pessoas e departamentos com permissão de ver determinada informação, consigam se orientar de modo centralizado, usando o catálogo. Para isso acontecer, o catálogo precisa ser confiável e estar atualizado.
Para prover esse nível de confiança, os pipelines de dados precisam ter permissão para atualizar o catálogo e a classificação dos dados também precisa estar registrada no catálogo, de modo a centralizar não só a informação mas também o tipo de informação e quem pode acessá-la.
Alguns pontos que podemos levantar sobre isso são:
- Existem Tags no catálogo para indicar a classificação de cada dado?
- Existe algum sistema de Linhagem de dados que salva as modificações no catálogo?
- Existem políticas mapeadas de criptografia para cada classe de dados?
- Existem políticas de criptografia para dados em trânsito e em repouso implementadas?
- Existem políticas de backup para cada classificação dos dados?
- Para os sistemas que usam e retém dados, existem políticas de retenção baseadas nas classificações dos dados?
- Existe um catálogo compartilhado entre todas as contas para garantir que os donos de dados consigam gerenciar as permissões que os sistemas usuários terão?
- Existe algum sistema que monitora a elegibilidade dos sistemas usuários quando acessam os dados confidenciais do sistema de origem?
Implemente políticas de criptografia para cada classe de dados
Podem existir diferentes tipos de criptografia exigida para cada classificação de dados. Usar as ferramentas corretas para atingir a individualização das políticas de criptografia para cada classificação de dados é outro fator que deve ser levado em conta quando estamos falando em proteção de dados.
Os pontos mais relevantes que podemos levantar sobre isso é:
Implemente políticas de retenção de dados para cada classe de dados
As políticas de retenção de dados, para toda a organização, devem considerar a classificação de dados. As políticas de ciclo de vida de dados, como as presentes no Amazon S3, devem ser implementadas para garantir que cada sistema siga as regras de segurança de dados e requisitos de conformidade.
Com isso, alcançamos o objetivo de manter backups de acordo com cada classificação de dados. Existem sistemas que exigem backups de 3 anos, 5 anos, 10 anos, outros até que o backup não tem expiração, logo, manter as políticas de retenção por classe de dados ajuda a dar visibilidade de custos e a cumprir as regulações e exigências de cada classificação de dados.
Sobre retenção de dados, devemos considerar também:
Exija que os sistemas que usam os dados mantenham as classificações corretas
Como os dados da organização podem ser consumidos por outros sistemas de domínios diferentes, parceiros, clientes, etc. Uma boa prática de segurança é exigir que esses outros sistemas, usuários dos dados, implementem as políticas exigidas para cada classe. Isso significa, por exemplo, se uma chave do AWS KMS é utilizada para criptografar dados no sistema de origem, os sistemas usuários, também chamados downstream systems, também precisam saber como o que o fazer para seguir as políticas de segurança da origem.
Ainda sobre esse ponto, podemos levantar:
Ficou interessado em como podemos endereçar cada um desses pontos com tecnologias, técnicas e boas práticas em ambientes de dados e computação em nuvem? Não deixe de acompanhar os próximos artigos desta série do Well Architected com foco em Data & Analytics.