Protegendo a infraestrutura em nuvem para a auditoria PCI

O processo de certificação PCI é bastante abrangente e envolve infraestrutura, software e o acesso dos funcionários aos sistemas, especialmente a conjuntos de dados e à forma como eles são acessados. Essas verificações são essenciais não apenas para o setor de pagamentos como um todo, mas também para gerar confiança entre os usuários, que sabem que seus dados estão protegidos. O processo de conformidade com o PCI consiste em uma série de verificações, geralmente realizadas por uma entidade terceira credenciada, para garantir que os processos de tratamento seguro de dados estejam em vigor.

Neste post do blog, vamos mostrar como você pode proteger sua infraestrutura em nuvem para ficar em conformidade com o PCI.

Quais são os requisitos de conformidade com o PCI?

O Padrão de Segurança de Dados do Setor de Cartões de Pagamento, também conhecido como PCI DSS, é um conjunto de diretrizes regulamentadas pelo setor para ajudar a manter seguros os dados confidenciais dos titulares de cartões. O padrão é mantido pelo PCI Security Standards Council, responsável por todos os detalhes do padrão, que abrange desde as normas de conformidade até os fornecedores de certificação para o PCI DSS.

Os requisitos de conformidade com o PCI abrangem diversos pontos, especialmente os relacionados a todos os aspectos do ciclo de vida de desenvolvimento de software (SDLC). A lista completa está disponível aqui. Em linhas gerais, os requisitos são:

1. Instalar e manter uma configuração de firewall para proteger os dados dos titulares de cartões. O firewall tem a função de analisar todo o tráfego de rede e impedir que redes não confiáveis acessem o sistema.

2. Alterar as senhas padrão e outros parâmetros de segurança fornecidos pelos fornecedores. Essas senhas podem ser facilmente descobertas por meio de informações públicas e usadas por pessoas mal-intencionadas para obter acesso não autorizado aos sistemas.

3. Proteger os dados armazenados dos titulares de cartões. Criptografia, hashing, mascaramento e truncamento são métodos usados para proteger esses dados.

4. Criptografar a transmissão de dados dos titulares de cartões em redes públicas e abertas. Uma criptografia forte, que use apenas chaves e certificados confiáveis, reduz o risco de ataques de hackers por pessoas mal-intencionadas.

5. Proteger todos os sistemas contra malware e atualizar regularmente o software antivírus. O malware pode entrar em uma rede de várias formas, incluindo uso da internet, e-mails de funcionários, dispositivos móveis ou dispositivos de armazenamento. Manter o antivírus atualizado ou usar um software antimalware complementar reduz o risco de exploração por malware.

6. Desenvolver e manter sistemas e aplicações seguros. As vulnerabilidades em sistemas e aplicações permitem que pessoas mal-intencionadas obtenham acesso privilegiado. Os patches de segurança devem ser instalados imediatamente para corrigir vulnerabilidades e evitar a exploração e o comprometimento dos dados dos titulares de cartões.

7. Restringir o acesso aos dados dos titulares de cartões somente a pessoas autorizadas. Devem ser usados sistemas e processos para limitar o acesso a esses dados com base no princípio da necessidade de acesso.

8. Identificar e autenticar o acesso aos componentes do sistema. Cada pessoa com acesso aos componentes do sistema deve receber um identificador exclusivo (ID) que permita responsabilizá-la pelo acesso a sistemas com dados críticos.

9. Restringir o acesso físico aos dados dos titulares de cartões. O acesso físico aos dados dos titulares de cartões ou aos sistemas que os armazenam deve ser protegido para impedir o acesso não autorizado ou a remoção dos dados.

10. Rastrear e monitorar todo o acesso aos dados dos titulares de cartões e aos recursos de rede. Devem existir mecanismos de registro para rastrear as atividades dos usuários, essenciais para prevenir, detectar ou minimizar o impacto de violações de dados.

11. Testar regularmente os sistemas e processos de segurança. Novas vulnerabilidades são descobertas continuamente. Sistemas, processos e softwares precisam ser testados com frequência para identificar vulnerabilidades que possam ser exploradas por pessoas mal-intencionadas.

12. Manter uma política de segurança da informação para todos os funcionários. Uma política de segurança sólida ajuda os funcionários a entender a confidencialidade dos dados e sua responsabilidade de protegê-los.

Requisitos do PCI específicos para infraestrutura

Ao analisar com mais detalhes a lista abrangente, neste post vamos nos concentrar nos pontos mais relacionados à infraestrutura como parte do SDLC.

1.3 Proibir o acesso público direto entre a internet e qualquer componente do sistema no ambiente de dados dos titulares de cartões.

Como vimos em violações de segurança anteriores, esse ponto destaca a necessidade de garantir que vulnerabilidades e configurações incorretas não permitam acesso não autorizado aos bancos de dados principais. Isso também pode se aplicar, por exemplo, ao acesso a componentes disponíveis para usuários ou sessões.

2.2.2 Habilitar apenas os serviços, protocolos, daemons etc. necessários para o funcionamento do sistema.

2.2.4 Configurar os parâmetros de segurança do sistema para evitar o uso indevido.

2.2.3 Implementar recursos de segurança adicionais para os serviços, protocolos ou daemons necessários considerados inseguros.

5.1.1 Garantir que os programas antivírus sejam capazes de detectar, remover e proteger contra todos os tipos conhecidos de software malicioso.

5.2 Garantir que todos os mecanismos antivírus sejam mantidos da seguinte forma:

• Manter atualizados

• Executar verificações periódicas

• Gerar logs de auditoria e retê-los conforme o Requisito 10.7 do PCI DSS.

5.3 Garantir que os mecanismos antivírus estejam em execução e não possam ser desativados ou alterados pelos usuários, a menos que a gerência autorize especificamente a mudança caso a caso e por um período limitado.

Felizmente, tudo isso pode ser verificado automaticamente com apenas alguns cliques e integrado facilmente aos pipelines de processo com uma conta gratuita da Snyk.

Simplifique a auditoria PCI com Snyk Container e Snyk IaC

Uma das coisas de que mais gosto é a automação. Para garantir a conformidade com o PCI, isso significa configurar uma boa análise de segurança nos seus pipelines de CI/CD. Isso pode ajudar de várias formas, inclusive gerando logs e identificando pontos vulneráveis na infraestrutura.

Há várias maneiras de configurar a análise de segurança com a Snyk. Vamos ver alguns exemplos usando o microservices-demo de comércio eletrônico do Google.

Diretamente do repositório

Se quiser acompanhar, comece criando um fork do repositório microservices-demo.

Criar um fork do código diretamente na sua conta do GitHub é uma maneira fácil de desenvolver em plataformas. Assim, fica mais fácil personalizar o código conforme necessário em branches durante o desenvolvimento. Você também pode cloná-lo em ambientes de desenvolvimento locais para testar e executar o código.

Análise de segurança com a Snyk

Há algumas maneiras de testar o código a partir daqui. Uma opção é usar a Snyk CLI na raiz do projeto. Com essa abordagem, você pode usar snyk test para executar testes locais ou snyk monitor para monitorar vulnerabilidades continuamente.

Você também pode conectar o repositório de código do fork diretamente ao app da Snyk usando a integração Snyk GitHub. Para isso, acesse sua conta da Snyk e clique no botão Add Project no meu painel da Snyk. Há várias opções de integração no menu de adição rápida de projetos. Você também pode clicar em Other e buscar a plataforma Git que preferir.

Depois de conectar a integração com o GitHub, você pode buscar o repositório microservices-demo do fork e iniciar uma análise.

Depois de selecionado, o repositório será analisado continuamente e mostrará todos os problemas detectados. Os problemas serão organizados em itens separados para cada componente do projeto, facilitando uma investigação mais aprofundada.

Para acompanhar a auditoria PCI, o melhor é que todas as descobertas ficam registradas na seção de histórico de cada item. Ela mostra os problemas detectados e recomendações de correção a cada análise, algo muito útil durante uma auditoria de conformidade com o PCI.

Além disso, a Snyk também pode se integrar a IDEs de programação para ajudar a identificar problemas enquanto você desenvolve aplicações. Isso é muito útil porque permite identificar problemas e receber recomendações de correção durante a programação.

Incorpore segurança ao pipeline de CI/CD

A automação é ótima para todas as pessoas envolvidas em qualquer etapa do SDLC. Ela facilita as implantações regulares e contínuas e também ajuda a definir as etapas e os processos necessários para uma implantação. Um excelente pipeline de automação consegue extrair código de uma branch do Git, preparar o ambiente e fazer a implantação, com testes integrados em todas as etapas.

A base de qualquer SDLC automatizado é o pipeline de CI/CD, que deve ser configurado para se conectar a todos os aspectos do seu SDLC.

Configurar a segurança como parte do pipeline de CI/CD é uma prática altamente recomendada, pois a segurança também deve ser contínua. Para ajudar nisso, a Snyk se integra a diversos pipelines e a todos os principais provedores de nuvem, como AWS, GCP e Azure. Para saber mais sobre as práticas recomendadas de integração com CI/CD, acesse nossa página sobre práticas recomendadas de CI/CD.

Exemplo de segurança no AWS CodePipeline

Neste exemplo, vamos configurar a análise de segurança no AWS CodePipeline usando a integração da Snyk com a AWS.

Vamos começar com um pipeline básico do AWS CodePipeline para configurar uma implantação usando a aplicação de demonstração de microsserviços e, em seguida, integrar a Snyk para fazer uma análise de segurança.

Acesse o painel do AWS CodePipelines e clique em Create Pipeline. Na tela da Etapa 1, defina o nome do pipeline e escolha uma função de serviço. Na Etapa 2, escolha o repositório Git em que está o código que você quer implantar. Se esta for a primeira vez que você se conecta ao serviço Git, siga as etapas para conectar-se e solicitar as permissões necessárias.

Depois de conectar o local do código-fonte, escolha o repositório e a branch que serão usados no fluxo de implantação.

Dica útil: Se você estiver se conectando ao GitHub, use o método de conexão GitHub version 2. A versão 1 do GitHub será descontinuada em breve.

Clique no botão Next para ir à Etapa 3, na qual você definirá os parâmetros de build. Como provedor de build, normalmente uso o AWS CodeBuild, mas você também pode adicionar uma conexão com o Jenkins. Defina o nome do projeto e as variáveis de ambiente necessárias para sua aplicação.

Para implantações básicas de aplicações de demonstração, você pode usar Single build em Build Type. Para implantações mais complexas, Batch build é útil para distribuir o trabalho por uma infraestrutura maior.

Na Etapa 4, definimos a configuração de implantação. Para esta demonstração, podemos usar a opção AWS CodeDeploy, que utiliza uma infraestrutura predefinida. Os campos seguintes desta etapa permitem escolher a infraestrutura e mudam conforme a opção selecionada.

Na etapa final, a Etapa 5, você poderá revisar a configuração do AWS CodePipeline antes de salvar. Em seguida, o pipeline iniciará o processo de implantação, começando pela recuperação do código que será implantado.

Adicione a segurança da Snyk ao pipeline

Agora, vamos adicionar uma análise de segurança da Snyk a esse fluxo usando a integração da Snyk com o AWS CodePipeline. Clique no nome do CodePipeline no painel para ver cada etapa do fluxo de implantação.

Agora vamos adicionar uma etapa de segurança a esse fluxo do CodePipeline. Clique no botão Edit no canto superior direito.

Em seguida, digite um nome para a etapa que será adicionada. Neste exemplo, vou usar security como nome exibido no fluxo final do CodePipeline.

Clique em Add Stage para abrir a página de configuração da etapa. Defina o nome da ação e, na seção Invoke da lista suspensa, procure Snyk no menu suspenso Action provider.

Na seção Input artifacts, você pode compilar a partir de SourceArtifact, que fará a análise diretamente antes da compilação da aplicação.

Clique no botão Connect to Snyk para abrir a janela de integração da Snyk com o AWS CodePipeline.

Depois de fazer login, você voltará à configuração do Snyk AWS CodePipelines. Aqui, você pode definir a organização e configurar os controles de bloqueio para quando uma vulnerabilidade for encontrada, além do nível de gravidade.

Quando tudo estiver configurado, clique em Continue para voltar à página de edição da ação. Por fim, informe um nome para os artefatos de saída e, se quiser, os campos de namespace. Depois, clique em Done.

Não se esqueça de clicar no botão Release Change para colocar a alteração em produção. Isso vai executar novamente o fluxo de implantação e analisar o código durante a implantação.

Assim como no exemplo anterior de análise direta do repositório, todos os registros da análise são armazenados, o que é útil nas auditorias de conformidade com o PCI. Para saber mais sobre as integrações com o AWS CodePipeline, confira esta publicação do blog: Como automatizar a análise de vulnerabilidades no AWS CodePipeline com o Snyk.

Proteja sua infraestrutura em nuvem gratuitamente com o Snyk

As verificações de conformidade com o PCI são uma tarefa muito importante, realizada uma vez por ano por uma organização de certificação independente. Embora o processo seja detalhado e possa levar bastante tempo, ter as verificações e os registros certos ajuda a agilizar o processo e, acima de tudo, a manter seu aplicativo, sua plataforma e seus usuários protegidos.

Comece a proteger seu código com um plano gratuito do Snyk, que inclui a análise de contêineres e IaC, correções automatizadas para imagens base vulneráveis e orientações de correção para desenvolvedores resolverem configurações incorretas de IaC diretamente no código.