Considerações sobre conformidade do Kubernetes e containers

Se você está executando containers, você já pensou nos potenciais riscos de segurança. Você pode estar adotando uma abordagem de DevOps nos fluxos de trabalho ou pode ter um pipeline de CI/CD bem-estabelecido, mas quer proteger seus dados confidenciais.

O controle de acesso baseado em função (RBAC) oferece o método padrão para gerenciar a autorização para os endpoints da API do Kubernetes. A configuração do RBAC do cluster do Kubernetes controla quais indivíduos podem executar quais verbos, em quais tipos de recursos, em quais namespaces. No entanto, o RBAC não prescreve como configurar suas funções. É aí que entram os frameworks de conformidade.

A National Institute of Standards and Technology Special Publication 800-190 (NIST 800-190) oferece um framework que ajudará na compreensão de alguns desafios específicos relacionados à proteção de aplicações em containers. Ele também explicará o que as organizações precisam fazer para melhorar o perfil de segurança da aplicação.

As diretrizes do NIST são destinadas a agências governamentais dos EUA e prestadores de serviços do governo. No entanto, qualquer companhia pode querer seguir as diretrizes do NIST 800-190 para melhorar a segurança geral e atender a outros frameworks de conformidade com mais facilidade, como o PCI e o HIPAA.

Os riscos

O NIST 800-190 destaca fontes comuns de vulnerabilidades de segurança em aplicações conteinerizadas, como:

• Imagens comprometidas
• Configurações incorretas em imagens de container
• Imagens de containers não confiáveis
• Segredos mal administrados
• Controles de acesso configurados incorretamente
• Vulnerabilidades do sistema operacional
• Superfícies de ataque grandes demais

O NIST 800-190 também destaca a necessidade de as organizações cuidarem da segurança de aplicações conteinerizadas de maneira diferente do que faziam com aplicações tradicionais. Aplicações em containers têm fatores de risco diferentes de máquinas virtuais e exigem um conjunto diferente de práticas de segurança.

O NIST 800-190 exige que as organizações:

• Usem ferramentas com finalidade específica para gerenciar vulnerabilidades de imagens em todo o ciclo de vida da imagem, desde a criação até a implantação e o ambiente de execução.
• Certifiquem-se de que as imagens estejam em conformidade com as práticas recomendadas de configuração.
• Protejam segredos armazenando-os fora da imagem, usando o Kubernetes para gerenciá-los, restrinjam o acesso aos segredos pelos containers que precisam deles e criptografem os segredos em repouso e em trânsito.
• Usem uma conexão segura ao extrair ou enviar imagens do registro.
• Certifiquem-se de que o container sempre usa a versão mais recente da imagem.
• Segmentem o tráfego de rede, para, no mínimo, isolar as redes confidenciais das que não são confidenciais.
• Usem o Kubernetes para introduzir nós de maneira segura e manter um inventário dos nós e os estados de conexão deles.
• Controlem o tráfego de saída dos containers.
• Assegurem conformidade contínua com os padrões de configurações do ambiente de execução de containers, como os CIS benchmarks.
• Usem controles de segurança para detectar ameaças e potenciais intrusões no nível do container e da infraestrutura.
• Usem um sistema operacional reforçado e específico para containers com a menor superfície de ataque possível.
• Impeçam a adulteração do sistema de arquivos do host, garantindo que os containers tenham o mínimo de permissões possível para funcionar conforme o previsto.

Até as organizações que não precisam atender aos requisitos do NIST 800-190 deveriam considerá-los um framework útil para melhorar a condição de segurança da empresa. Eles asseguram que as organizações vão verificar a segurança em todas as frases de criação, implantação e ambiente de execução, cuidando dos requisitos únicos de segurança de cada etapa.

O Payment Card Industry Data Security Standard (PCI DSS) foi criado em 2004 pela Visa, MasterCard, American Express, Discover e JCP para estabelecer um padrão de segurança e proteção de dados em todo o setor. Os padrões foram atualizados várias vezes desde o lançamento, de modo a acompanhar as mudanças tecnológicas. Os padrões se aplicam a tudo no ambiente de dados do portador do cartão, ou seja, as pessoas, processos e tecnologias que armazenam, processam ou transmitem dados. Em termos de tecnologia, isso inclui hardware e software.

Não é fácil cumprir com os requisitos do PCI, que têm um custo médio para as empresas de US$ 5,5 milhões por ano. No entanto, a falta de conformidade sai ainda mais caro, com um custo médio anual de US$ 14,8 milhões em multas. Com os processos e ferramentas certos, a conformidade com o PCI não será um desafio tão grande.

O PCI DSS conta com 12 requisitos mapeados em mais seis objetivos gerais. São eles:

Criar e manter um sistema de redes seguro

1. Instalar e manter uma configuração de firewall para proteger os dados do portador do cartão
2. Não usar padrões do fornecedor para senhas do sistema e outros parâmetros de segurança

Proteger os dados do portador do cartão

1. Proteger os dados armazenados do portador do cartão
2. Criptografar a transmissão dos dados do portador do cartão em redes públicas e abertas

Garantir a manutenção de programas de gerenciamento de vulnerabilidades

1. Proteger todos os sistemas contra malwares e exploits e atualizar regularmente o software de antivírus
2. Desenvolver e manter a segurança de sistemas e aplicações
3. Implementar medidas sólidas de controle de acesso

Restringir acesso das empresas aos dados do portador do cartão, permitindo acesso apenas ao que for necessário

1. Identificar e autenticar acesso aos componentes do sistema
2. Restringir acesso físico aos dados do portador do cartão

Monitorar e testar redes com regularidade

1. Rastrear e monitorar todo o acesso aos recursos de rede e dados do portador do cartão
2. Testar sistemas de segurança e processos com regularidade

Garantir a manutenção das políticas de segurança da informação

1. Manter uma política que cuide da segurança da informação de toda a equipe

Conformidade com o PCI para aplicações em containers

Muitos requisitos de cada um dos seis objetivos abordados pelo PCI são diretamente relevantes para ambientes de container e do Kubernetes. Avalie as ferramentas de segurança do seu container e Kubernetes para garantir que possam cumprir com os requisitos a seguir:

1.12 Diagrama de rede atual que identifica todas as conexões entre o ambiente de dados do portador do cartão (CDE) e outras redes, incluindo redes sem fio

1.1.4 Requisitos para um firewall em cada conexão da internet e entre uma zona desmilitarizada (ZDM) e a zona de rede interna.

1.2 Criar configurações de firewall e de roteadores que restrinjam conexões entre redes não confiáveis e componentes do sistema no ambiente de dados do portador do cartão.

1.2.1 Restringir o tráfego de entrada e saída para somente o necessário para o ambiente de dados do portador do cartão e recusar todos os outros tráfegos.

1.3.2 Limitar tráfego de entrada da internet a endereços IP dentro da ZDM.

1.3.4 Não permitir tráfego de saída não autorizado do ambiente de dados do portador do cartão para a internet.

1.3.5 Permitir somente conexões "estabelecidas" dentro da rede.

2.1 Sempre alterar padrões do fornecedor e remover ou desabilitar contas padrão desnecessárias antes de instalar um sistema na rede.

2.2 Desenvolver padrões de configuração para todos os componentes do sistema. Garantir que esses padrões abordam todas as vulnerabilidades de segurança conhecidas e são consistentes com os padrões de reforço do sistema aceitos pelo setor.

2.2.1 Implementar somente uma função primária por servidor, para impedir funções que exijam níveis de segurança diferentes dos que já existem no mesmo servidor. Por exemplo, servidores web, servidores de banco de dados e DNS devem ser implementados em servidores separados.

2.2.2 Habilitar somente serviços, protocolos, daemons etc. necessários, conforme exigido para a função do sistema.

2.2.3 Implementar funcionalidades de segurança adicionais para serviços, protocolos ou daemons obrigatórios considerados inseguros.

2.2.5 Remover todas as funcionalidades desnecessárias, como scripts, drivers, recursos, subsistemas, sistemas de arquivos e servidores web desnecessários.

2.3 Criptografar todo o acesso administrativo fora do console usando criptografia sólida.

2.4 Manter um inventário de componentes do sistema que estejam no escopo do PCI DSS.

3.6.2 Distribuição segura de chaves criptográficas.

6.1 Estabelecer um processo para identificar vulnerabilidades de segurança, usando fontes externas com boa reputação para obter informações sobre essas vulnerabilidades, e atribuir uma classificação de riscos (por exemplo, "alto", "médio" ou "baixo") para as recém-descobertas.

6.2 Garantir que todos os componentes do sistema e softwares estejam protegidos das vulnerabilidades conhecidas, instalando patches de segurança aplicáveis do fornecedor. Instalar patches de segurança críticos em até um mês do lançamento.

6.4.1 Separar ambientes de desenvolvimento/teste dos de produção e reforçar a separação com ferramentas de acesso.

6.4.2 Separação de deveres entre ambientes de desenvolvimento/teste e os de produção.

6.5.1 Falhas nas injeções, especialmente a injeção de SQL. Considere também a injeção de comando do sistema operacional, falhas na injeção de LDAP e XPath e outras.

6.5.3 Armazenamento criptográfico inseguro.

6.5.4 Comunicações inseguras.

6.5.6 Todas as vulnerabilidades de "alto risco" identificadas no processo de identificação de vulnerabilidades (conforme definido no Requisito do PCI DSS 6.1).

10.2.5 Implementar trilhas de auditoria automatizadas para todos os componentes do sistema para reconstruir o uso de mecanismos de identificação e autenticação e alterações deles. Isso inclui a criação de novas contas e o aumento de privilégios, além de todas as alterações, adições e exclusões de contas com privilégios raiz ou administrativos.

11.2.1 Procurar vulnerabilidades internas trimestralmente. Cuidar das vulnerabilidades e verificar novamente se todas as vulnerabilidades de "alto risco" foram resolvidas de acordo com a classificação da entidade (conforme Requisito 6.1). As verificações devem ser realizadas pela equipe qualificada.

11.5 Implementar um mecanismo de detecção de alterações (por exemplo, ferramentas de monitoramento da integridade do arquivo) para alertar a equipe sobre modificações não autorizadas, incluindo alterações, adições e exclusões, de arquivos críticos do sistema, arquivos de configuração ou de conteúdo. Além disso, configurar o software para realizar comparações entre arquivos críticos com frequência mínima semanal.

11.5.1 Implementar um processo para responder a quaisquer alertas gerados pela solução de detecção de alterações.

A Lei de Portabilidade e Responsabilidade de Informações de Saúde de 1996 criou o framework de conformidade HIPAA para cuidar da privacidade do paciente em relação a todos os registros de saúde. A Regra de Segurança, adicionada em 2003, governa os registros digitais de saúde. Toda organização que lida com informações de saúde protegidas eletronicamente (ePHI) e é individualmente identificável deve cumprir com os requisitos do HIPAA. Isso inclui aplicações usadas diretamente por provedores do setor da saúde para atendimento, comunicação ou faturamento.

O principal desafio para conformidade com o HIPAA é que o framework de segurança oferece somente orientação geral, em vez de informações específicas sobre como as organizações devem cumprir com essas diretrizes em containers e no Kubernetes. Além disso, a diferença entre o que é e o que não é informação de saúde protegida costuma ser menos óbvia do que, por exemplo, o que é e o que não é informação de cartão de crédito que deve ser protegida em conformidade com o PCI.

Além dos próprios provedores do setor da saúde, toda organização que oferecer serviços como armazenamento ou faturamento a eles, e esses serviços envolverem informações eletrônicas de saúde pessoal (ePHI), devem atender aos requisitos do HIPAA.

Os padrões da Regra de Segurança do HIPAA são divididos em medidas de proteção técnicas, físicas e administrativas. As medidas técnicas, relacionadas à infraestrutura da TI, incluem os seguintes padrões:

• Controle de acesso
• Controles de auditoria
• Integridade
• Autenticação
• Segurança na transmissão

A Regra de Segurança do HIPAA não oferece informações específicas sobre como as organizações devem proteger as ePHI e também não é específica para aplicações em containers. Normalmente, para ter conformidade com o HIPAA, o melhor é começar aplicando o framework do NIST SP 800-190, que oferece diretrizes e práticas recomendadas para a segurança de containers. Diferente do HIPAA, o NIST SP 800-190 oferece um framework específico para containers e, portanto, é mais fácil de demonstrar conformidade. No entanto, cumprir com os requisitos do HIPAA inclui implementar controles adicionais de segregação de dados para proteger as ePHI e mantê-las separadas de outros tipos de dados.

O HIPAA também exige que as organizações mantenham backups, não apenas de dados, mas também de arquivos de configuração. Desse modo, a aplicação pode ser totalmente recuperada para demonstrar conformidade contínua.