Compartilhar via

Controle de Segurança: Segurança de DevOps

  • Artigo

O DevOps Security abrange os controles relacionados à engenharia de segurança e operações nos processos do DevOps, incluindo a implantação de verificações de segurança críticas (como teste de segurança de aplicativo estático, gerenciamento de vulnerabilidades) antes da fase de implantação para garantir a segurança em todo o processo de DevOps; ele também inclui tópicos comuns, como modelagem de ameaças e segurança de fornecimento de software.

DS-1: Conduzir a modelagem de ameaças

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
16.10, 16.14 SA-15 6.5, 12.2

Princípio de segurança: execute a modelagem de ameaças para identificar as possíveis ameaças e enumerar os controles mitigadores. Verifique se a modelagem de ameaças atende às seguintes finalidades:

  • Proteger seus aplicativos e serviços no estágio de tempo de execução.
  • Proteger os artefatos, o pipeline de CI/CD subjacente e outros ambientes de ferramentas usados para compilação, teste e implantação. A modelagem de ameaças pelo menos deve incluir os seguintes aspectos:
  • Definir os requisitos de segurança do aplicativo. Verificar se esses requisitos são abordados adequadamente na modelagem de ameaças.
  • Analisar os componentes de aplicativo, as conexões de dados e suas relações. Verificar se essa análise também inclui as conexões upstream e downstream fora do escopo do aplicativo.
  • Listar as possíveis ameaças e vetores de ataque aos quais os componentes do aplicativo, as conexões de dados e os serviços upstream e downstream podem ser expostos.
  • Identificar os controles de segurança aplicáveis que podem ser usados para atenuar as ameaças enumeradas e identificar as lacunas de controle (por exemplo, vulnerabilidades de segurança) que podem exigir planos de tratamento adicionais.
  • Enumerar e projetar os controles que podem atenuar as vulnerabilidades identificadas.

Diretrizes do Azure: use ferramentas de modelagem de ameaças, como a ferramenta de modelagem de ameaças da Microsoft com o modelo de modelo de ameaça do Azure inserido para impulsionar seu processo de modelagem de ameaças. Use o modelo STRIDE para enumerar as ameaças internas e externas e identificar os controles aplicáveis. Verifique se o processo de modelagem de ameaças inclui os cenários de ameaça no processo de DevOps, como injeção de código mal-intencionado por meio de um repositório de artefatos inseguros com política de controle de acesso configurada incorretamente.

Se o uso de uma ferramenta de modelagem de ameaças não for aplicável, você deverá, no mínimo, usar um processo de modelagem de ameaças baseada em questionário para identificar as ameaças.

Verifique se os resultados da análise ou modelagem de ameaças são registrados e atualizados quando há uma alteração importante de impacto para a segurança em seu aplicativo ou no cenário de ameaças.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: use ferramentas de modelagem de ameaças, como a ferramenta de modelagem de ameaças da Microsoft com o modelo de modelo de ameaça do Azure inserido para impulsionar seu processo de modelagem de ameaças. Use o modelo STRIDE para enumerar as ameaças internas e externas e identificar os controles aplicáveis. Verifique se o processo de modelagem de ameaças inclui os cenários de ameaça no processo de DevOps, como injeção de código mal-intencionado por meio de um repositório de artefatos inseguros com política de controle de acesso configurada incorretamente.

Se o uso de uma ferramenta de modelagem de ameaças não for aplicável, você deverá, no mínimo, usar um processo de modelagem de ameaças baseada em questionário para identificar as ameaças.

Verifique se os resultados da análise ou modelagem de ameaças são registrados e atualizados quando há uma alteração importante de impacto para a segurança em seu aplicativo ou no cenário de ameaças.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: use ferramentas de modelagem de ameaças, como a ferramenta de modelagem de ameaças da Microsoft com o modelo de modelo de ameaça do Azure inserido para impulsionar seu processo de modelagem de ameaças. Use o modelo STRIDE para enumerar as ameaças internas e externas e identificar os controles aplicáveis. Verifique se o processo de modelagem de ameaças inclui os cenários de ameaça no processo de DevOps, como injeção de código mal-intencionado por meio de um repositório de artefatos inseguros com política de controle de acesso configurada incorretamente.

Se o uso de uma ferramenta de modelagem de ameaças não for aplicável, você deverá, no mínimo, usar um processo de modelagem de ameaças baseada em questionário para identificar as ameaças.

Verifique se os resultados da análise ou modelagem de ameaças são registrados e atualizados quando há uma alteração importante de impacto para a segurança em seu aplicativo ou no cenário de ameaças.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

DS-2: garantir a segurança da cadeia de suprimentos de software

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
16.4, 16.6, 16.11 SA-12, SA-15 6.3, 6.5

Princípio de segurança: verifique se o SDLC da sua empresa (Ciclo de Vida de Desenvolvimento de Software) ou o processo inclui um conjunto de controles de segurança para controlar os componentes de software internos e de terceiros (incluindo software proprietário e de software livre) em que seus aplicativos têm dependências. Defina critérios de avaliação para impedir que componentes vulneráveis ou mal-intencionados sejam integrados e implantados no ambiente.

Os controles de segurança da cadeia de suprimentos de software devem, pelo menos, incluir os seguintes aspectos:

  • Gerencie corretamente uma SBOM (Fatura de Materiais de Software) identificando as dependências de upstream necessárias para a fase de desenvolvimento de serviço/recurso, build, integração e implantação.
  • Inventariar e acompanhar os componentes de software internos e de terceiros para vulnerabilidades conhecidas quando houver uma correção disponível no upstream.
  • Avaliar as vulnerabilidades e malware nos componentes de software usando testes de aplicativos estáticos e dinâmicos para vulnerabilidades desconhecidas.
  • Verificar se as vulnerabilidades e malware são atenuados usando a abordagem apropriada. Isso pode incluir correção local ou upstream do código-fonte, exclusão de recursos e/ou aplicação de controles de compensação se a mitigação direta não estiver disponível.

Se componentes de terceiros de código fechado forem usados em seu ambiente de produção, você poderá ter uma visibilidade limitada de sua postura de segurança. Você deve considerar controles adicionais, como controle de acesso, isolamento de rede e segurança de ponto de extremidade para minimizar o impacto se houver uma atividade mal-intencionada ou vulnerabilidade associada ao componente.

Diretrizes do Azure: para a plataforma GitHub, verifique a segurança da cadeia de fornecedores de software por meio da seguinte funcionalidade ou ferramentas do GitHub Advanced Security ou do recurso nativo do GitHub:- Use o Dependency Graph para examinar, inventariar e identificar todas as dependências e vulnerabilidades relacionadas do seu projeto por meio do Banco de Dados Consultivo.

  • Use o Dependabot para garantir que a dependência vulnerável seja controlada e corrigida e verifique se o repositório acompanha automaticamente as versões mais recentes dos pacotes e aplicativos dos quais ela depende.
  • Use o recurso de verificação de código nativo do GitHub para verificar o código-fonte ao fornecer o código externamente.
  • Use Microsoft Defender para Nuvem para integrar a avaliação de vulnerabilidade para sua imagem de contêiner no fluxo de trabalho de CI/CD. Para o Azure DevOps, você pode usar extensões de terceiros para implementar controles semelhantes para inventário, análise e correção de componentes de software de terceiros e suas vulnerabilidades.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: se você usar plataformas de CI/CD da AWS, como CodeCommit ou CodePipeline, verifique a segurança da cadeia de fornecedores de software usando o CodeGuru Reviewer para verificar o código-fonte (para Java e Python) por meio dos fluxos de trabalho de CI/CD. Plataformas como CodeCommit e CodePipeline também dão suporte a extensões de terceiros para implementar controles semelhantes ao inventário, analisar e corrigir os componentes de software de terceiros e suas vulnerabilidades.

Se você gerenciar o código-fonte por meio da plataforma GitHub, verifique a segurança da cadeia de fornecedores de software por meio da seguinte funcionalidade ou ferramentas do GitHub Advanced Security ou do recurso nativo do GitHub:

  • Use o Grafo de Dependência para verificar, inventariar e identificar todas as dependências do projeto e vulnerabilidades relacionadas por meio do Banco de Dados de Assistência.
  • Use o Dependabot para garantir que a dependência vulnerável seja controlada e corrigida e verifique se o repositório acompanha automaticamente as versões mais recentes dos pacotes e aplicativos dos quais ela depende.
  • Use o recurso de verificação de código nativo do GitHub para verificar o código-fonte ao fornecer o código externamente.
  • Se aplicável, use Microsoft Defender para Nuvem para integrar a avaliação de vulnerabilidade para sua imagem de contêiner no fluxo de trabalho de CI/CD.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: use o Escudo de Entrega de Software para executar a análise de segurança da cadeia de fornecedores de software de ponta a ponta. Isso inclui o serviço de OSS (software de software livre) garantido para acesso e incorpora os pacotes de OSS que foram verificados e testados pelo Google, bem como pacotes Java e Python validados criados usando os pipelines seguros do Google. Esses pacotes são verificados, analisados e testados regularmente em busca de vulnerabilidades. Esses recursos podem ser integrados ao Google Cloud Build, Cloud Deploy, Artifact Registry, Artifact Analysis como parte dos fluxos de trabalho de CI/CD.

Se você gerenciar o código-fonte por meio da plataforma GitHub, verifique a segurança da cadeia de fornecedores de software por meio da seguinte funcionalidade ou ferramentas do GitHub Advanced Security ou do recurso nativo do GitHub:

  • Use o Grafo de Dependência para verificar, inventariar e identificar todas as dependências do projeto e vulnerabilidades relacionadas por meio do Banco de Dados de Assistência.
  • Use o Dependabot para garantir que a dependência vulnerável seja controlada e corrigida e verifique se o repositório acompanha automaticamente as versões mais recentes dos pacotes e aplicativos dos quais ela depende.
  • Use o recurso de verificação de código nativo do GitHub para verificar o código-fonte ao fornecer o código externamente.
  • Se aplicável, use Microsoft Defender para Nuvem para integrar a avaliação de vulnerabilidade para sua imagem de contêiner no fluxo de trabalho de CI/CD.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

DS-3: Infraestrutura segura de DevOps

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
16.7 CM-2, CM-6, AC-2, AC-3, AC-6 2.2, 6.3, 7.1

Princípio de segurança: verifique se a infraestrutura e o pipeline do DevOps seguem as práticas recomendadas de segurança em todos os ambientes, incluindo seus estágios de build, teste e produção. Normalmente, isso inclui os controles de segurança para o seguinte escopo:

  • Repositórios de artefatos que armazenam código-fonte, pacotes e imagens de compilação, artefatos de projetos e dados de negócios.
  • Servidores, serviços e ferramentas que hospedam pipelines de CI/CD.
  • Configuração de pipeline de CI/CD.

Diretrizes do Azure: como parte da aplicação do Microsoft Cloud Security Benchmark aos controles de segurança de infraestrutura do DevOps, priorize os seguintes controles:

  • Proteja artefatos e o ambiente subjacente para garantir que os pipelines de CI/CD não se tornem caminhos para inserir código mal-intencionado. Por exemplo, examine o pipeline de CI/CD para identificar qualquer configuração incorreta em áreas principais do Azure DevOps, como Organização, Projetos, Usuários, Pipelines (Build & Versão), Connections e Agente de Build para identificar quaisquer configurações incorretas, como acesso aberto, autenticação fraca, configuração de conexão insegura e assim por diante. Para o GitHub, use controles semelhantes para proteger os níveis de permissão da organização.
  • Verifique se a infraestrutura do DevOps é implantada de forma consistente em projetos de desenvolvimento. Acompanhe a conformidade da infraestrutura do DevOps em escala usando Microsoft Defender para Nuvem (como Painel de Conformidade, Azure Policy, Gerenciamento de Postura na Nuvem) ou suas próprias ferramentas de monitoramento de conformidade.
  • Configure permissões de identidade/função e políticas de permissões no Microsoft Azure AD, serviços nativos e ferramentas de CI/CD em seu pipeline para garantir que as alterações nos pipelines sejam autorizadas.
  • Evite fornecer acesso privilegiado permanente "permanente" às contas humanas, como desenvolvedores ou testadores, usando recursos como identificadores gerenciados do Azure e acesso just-in-time.
  • Remova chaves, credenciais e segredos de códigos e scripts usados em trabalhos de fluxo de trabalho de CI/CD e mantenha-os em um repositório de chaves ou no Azure Key Vault.
  • Se você executar agentes de build/implantação auto-hospedados, siga os controles do Microsoft Cloud Security Benchmark, incluindo segurança de rede, gerenciamento de postura e vulnerabilidades e segurança de ponto de extremidade para proteger seu ambiente.

Observação: consulte as seções Log e Detecção de Ameaças, DS-7 e Postura e Gerenciamento de Vulnerabilidades para usar serviços como o Azure Monitor e o Microsoft Sentinel para habilitar governança, conformidade, auditoria operacional e auditoria de risco para sua infraestrutura de DevOps.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: como parte da aplicação do Microsoft Cloud Security Benchmark aos controles de segurança da infraestrutura do DevOps, como GitHub, CodeCommit, CodeArtifact, CodePipeline, CodeBuild e CodeDeploy, priorize os seguintes controles:

  • Consulte estas diretrizes e o pilar de segurança do AWS Well-architected Framework para proteger seus ambientes de DevOps na AWS.
  • Proteja artefatos e a infraestrutura de suporte subjacente para garantir que os pipelines de CI/CD não se tornem caminhos para inserir código mal-intencionado.
  • Verifique se sua infraestrutura de DevOps é implantada e sustentada consistentemente em projetos de desenvolvimento. Acompanhe a conformidade da infraestrutura do DevOps em escala usando a Configuração do AWS ou sua própria solução de marcar de conformidade.
  • Use CodeArtifact para armazenar e compartilhar com segurança pacotes de software usados para o desenvolvimento de aplicativos. Você pode usar o CodeArtifact com ferramentas de build populares e gerenciadores de pacotes, como Maven, Gradle, npm, yarn, pip e twine.
  • Configure permissões de identidade/função e políticas de permissão no AWS IAM, serviços nativos e ferramentas de CI/CD em seu pipeline para garantir que as alterações nos pipelines sejam autorizadas.
  • Remover chaves, credenciais e segredos de códigos e scripts usados em trabalhos de fluxo de trabalho de CI/CD e mantê-los no repositório de chaves ou AWS KMS
  • Se você executar agentes de build/implantação auto-hospedados, siga os controles do Microsoft Cloud Security Benchmark, incluindo segurança de rede, gerenciamento de postura e vulnerabilidades e segurança de ponto de extremidade para proteger seu ambiente. Use o Inspetor do AWS para verificação de vulnerabilidades em busca de vulnerabilidades no ambiente EC2 ou em contêineres como o ambiente de build.

Observação: consulte as seções Log e Detecção de Ameaças, DS-7 e Postura e Gerenciamento de Vulnerabilidades para usar serviços como a AWS CloudTrail, CloudWatch e Microsoft Sentinel para habilitar a governança, a conformidade, a auditoria operacional e a auditoria de risco para sua infraestrutura de DevOps.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: como parte da aplicação do Microsoft Cloud Security Benchmark aos controles de segurança de infraestrutura do DevOps, priorize os seguintes controles:

  • Proteja artefatos e o ambiente subjacente para garantir que os pipelines de CI/CD não se tornem caminhos para inserir código mal-intencionado. Por exemplo, examine seu pipeline de CI/CD para identificar qualquer configuração incorreta em serviços como Google Cloud Build, Cloud Deploy, Artifact Registry, Connections e Build Agent para identificar quaisquer configurações incorretas, como acesso aberto, autenticação fraca, configuração de conexão insegura e assim por diante. Para o GitHub, use controles semelhantes para proteger os níveis de permissão da organização.
  • Verifique se a infraestrutura do DevOps é implantada de forma consistente em projetos de desenvolvimento. Acompanhe a conformidade da infraestrutura do DevOps em escala usando o Google Cloud Security Command Center (como Painel de Conformidade, Política Organizacional, Registro de ameaças individuais e Identificação de configurações incorretas) ou suas próprias ferramentas de monitoramento de conformidade.
  • Configure permissões de identidade/função e políticas de direitos em serviços nativos de Identidade de Nuvem/AD e ferramentas de CI/CD em seu pipeline para garantir que as alterações nos pipelines sejam autorizadas.
  • Evite fornecer acesso privilegiado permanente "permanente" às contas humanas, como desenvolvedores ou testadores, usando recursos como identificadores gerenciados pelo Google.
  • Remova chaves, credenciais e segredos de códigos e scripts usados em trabalhos de fluxo de trabalho de CI/CD e mantenha-os em um repositório de chaves ou no Google Secret Manager.
  • Se você executar agentes de build/implantação auto-hospedados, siga os controles do Microsoft Cloud Security Benchmark, incluindo segurança de rede, gerenciamento de postura e vulnerabilidades e segurança de ponto de extremidade para proteger seu ambiente.

Observação: consulte as seções Detecção de Logs e Ameaças, DS-7 e Postura e Gerenciamento de Vulnerabilidades para usar serviços como o Azure Monitor e o Microsoft Sentinel ou o pacote de operações do Google Cloud e o Chronicle SIEM e SOAR para habilitar a governança, conformidade, auditoria operacional e auditoria de risco para sua infraestrutura de DevOps.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

DS-4: Integrar testes de segurança de aplicativos estáticos ao pipeline de DevOps

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
16.12 SA-11 6.3, 6.5

Princípio de segurança: verifique se os testes difusos do SAST (teste de segurança de aplicativo estático), testes interativos, testes móveis de aplicativo fazem parte dos controles de gating no fluxo de trabalho de CI/CD. A restrição pode ser definida com base nos resultados do teste para impedir que pacotes vulneráveis sejam confirmados no repositório, compiladas nos pacotes ou implantados na produção.

Diretrizes do Azure: integre o SAST ao pipeline (por exemplo, em sua infraestrutura como modelo de código) para que o código-fonte possa ser verificado automaticamente no fluxo de trabalho de CI/CD. O Pipeline do Azure DevOps ou o GitHub podem integrar as ferramentas abaixo e as ferramentas SAST de terceiros ao fluxo de trabalho.

  • GitHub CodeQL para análise de código-fonte.
  • Microsoft BinSkim Binary Analyzer para Windows e análise binária *nix.
  • Verificador de Credenciais do Azure DevOps (extensão de DevOps de Segurança da Microsoft) e verificação de segredo nativo do GitHub para verificação de credenciais no código-fonte.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: integre o SAST ao pipeline para que o código-fonte possa ser verificado automaticamente no fluxo de trabalho de CI/CD.

Se estiver usando o CodeCommit da AWS, use o Revisor de CodeGuru do AWS para análise de código-fonte Python e Java. O Codepipeline da AWS também pode dar suporte à integração de ferramentas SAST de terceira parte ao pipeline de implantação de código.

Se estiver usando o GitHub, as ferramentas abaixo e as ferramentas SAST de terceiros poderão ser integradas ao fluxo de trabalho.

  • GitHub CodeQL para análise de código-fonte.
  • Microsoft BinSkim Binary Analyzer para Windows e análise binária *nix.
  • Verificação de segredo nativo do GitHub para verificação de credenciais no código-fonte.
  • Análise de código-fonte do CodeGuru do AWS para Python e Java.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: integre o SAST (como o Escudo de Entrega de Software, a Análise de Artefatos) ao pipeline (por exemplo, em sua infraestrutura como modelo de código) para que o código-fonte possa ser verificado automaticamente em seu fluxo de trabalho de CI/CD.

Serviços como Cloud Build, Cloud Deploy, Artifact Registry dão suporte à integração com o Software Delivery Shield e a Artifact Analysis, que podem verificar o código-fonte e outros artefatos no fluxo de trabalho de CI/CD.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

DS-5: Integrar testes de segurança de aplicativos dinâmicos no pipeline de DevOps

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
16.12 SA-11 6.3, 6.5

Princípio de segurança: verifique se o DAST (teste de segurança de aplicativo dinâmico) faz parte dos controles de gating no fluxo de trabalho de CI/CD. A restrição pode ser definida com base nos resultados do teste para impedir que vulnerabilidades sejam compiladas nos pacotes ou sejam implantadas na produção.

Diretrizes do Azure: integre o DAST ao pipeline para que o aplicativo de runtime possa ser testado automaticamente no conjunto de fluxos de trabalho de CI/CD no Azure DevOps ou no GitHub. O teste de penetração automatizado (com validação assistida manual) também deve fazer parte do DAST.

O Pipeline do Azure DevOps ou o GitHub dá suporte à integração de ferramentas DAST de terceiros ao fluxo de trabalho de CI/CD.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: integre o DAST ao pipeline para que o aplicativo de runtime possa ser testado automaticamente em seu fluxo de trabalho de CI/CD definido no CodePipeline ou no GitHub da AWS. O teste de penetração automatizado (com validação assistida manual) também deve fazer parte do DAST.

O AWS CodePipeline ou GitHub dá suporte à integração de ferramentas DAST de terceiros ao fluxo de trabalho de CI/CD.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: integre o DAST (como o Cloud Web Security Scanner) ao pipeline para que o aplicativo de runtime possa ser testado automaticamente no conjunto de fluxos de trabalho de CI/CD nos serviços como Google Cloud Build, Cloud Deploy ou GitHub. O Verificador de Segurança da Web na Nuvem pode ser usado para identificar a vulnerabilidade de segurança em seus aplicativos Web de carga de trabalho hospedados no Mecanismo de Aplicativo, no Mecanismo de Kubernetes do Google (GKE) e no Mecanismo de Computação. O teste de penetração automatizado (com validação assistida manual) também deve fazer parte do DAST.

Google Cloud Build, Google Cloud Deploy, Artifact Registry e GitHub também dão suporte à integração de ferramentas DAST de terceiros ao fluxo de trabalho de CI/CD.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

DS-6: Impor a segurança da carga de trabalho durante todo o ciclo de vida de DevOps

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
7.5, 7.6, 7.7, 16.1, 16.7 CM-2, CM-6, AC-2, AC-3, AC-6 6.1, 6.2, 6.3

Princípio de segurança: verifique se a carga de trabalho é protegida durante todo o ciclo de vida em desenvolvimento, teste e estágio de implantação. Use o Microsoft Cloud Security Benchmark para avaliar os controles (como segurança de rede, gerenciamento de identidade, acesso privilegiado e assim por diante) que podem ser definidos como guardrails por padrão ou deslocar para a esquerda antes do estágio de implantação. Em particular, verifique se os seguintes controles estão em vigor em seu processo de DevOps: – Automatizar a implantação usando o Azure ou ferramentas de terceiros no fluxo de trabalho de CI/CD, gerenciamento de infraestrutura (infraestrutura como código) e teste para reduzir a superfície de erro e ataque humano.

  • Verifique se as VMs, as imagens de contêiner e outros artefatos estão protegidos contra manipulação mal-intencionada.
  • Verifique os artefatos de carga de trabalho (em outras palavras, imagens de contêiner, dependências, verificações de SAST e DAST) antes da implantação no fluxo de trabalho de CI/CD
  • Implante a avaliação de vulnerabilidades e a funcionalidade de detecção de ameaças no ambiente de produção e use continuamente esses recursos no tempo de execução.

Diretrizes do Azure: diretrizes para VMs do Azure:

  • Use a Galeria de Imagens Compartilhadas do Azure para compartilhar e controlar o acesso a suas imagens por diferentes usuários, entidades de serviço ou grupos do AD dentro de sua organização. Use o RBAC (controle de acesso baseado em função) do Azure para garantir que somente usuários autorizados possam acessar suas imagens personalizadas.
  • Defina as linhas de base de configuração segura para as VMs para eliminar credenciais, permissões e pacotes desnecessários. Implante e imponha linhas de base de configuração por meio de imagens personalizadas, modelos de Resource Manager do Azure e/ou Azure Policy configuração de convidado.

Diretrizes para serviços de contêiner do Azure:

  • Use Registro de Contêiner do Azure (ACR) para criar seu registro de contêiner privado em que o acesso granular pode ser restrito por meio do RBAC do Azure, para que somente serviços e contas autorizados possam acessar os contêineres no registro privado.
  • Use o Defender para Contêineres para avaliação de vulnerabilidade das imagens em sua Registro de Contêiner do Azure privada. Além disso, você pode usar Microsoft Defender para Nuvem para integrar as verificações de imagem de contêiner como parte de seus fluxos de trabalho de CI/CD.

Para serviços sem servidor do Azure, adote controles semelhantes para garantir que os controles de segurança "mudem para a esquerda" para o estágio anterior à implantação.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: use o Registro de Contêiner Elástico da Amazon para compartilhar e controlar o acesso às suas imagens por diferentes usuários e funções em sua organização. E use o IAM da AWS para garantir que somente usuários autorizados possam acessar suas imagens personalizadas.

Defina as linhas de base de configuração seguras para as imagens AMI do EC2 para eliminar credenciais, permissões e pacotes desnecessários. Implante e imponha linhas de base de configurações por meio de imagens de AMI personalizadas, modelos de CloudFormation e/ou Regras de Configuração do AWS.

Use o Inspetor do AWS para verificação de vulnerabilidade de ambientes em contêineres e VMs, protegendo-os contra manipulação mal-intencionada.

Para serviços sem servidor da AWS, use o CodePipeline do AWS em conjunto com o AWS AppConfig para adotar controles semelhantes para garantir que os controles de segurança "mudem para a esquerda" para o estágio anterior à implantação.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: o Google Cloud inclui controles para proteger seus recursos de computação e recursos de contêiner do GKE (Mecanismo de Kubernetes do Google). O Google inclui a VM Blindada, que protege as instâncias de VM. Ele fornece segurança de inicialização, monitora a integridade e usa o VTPM (Virtual Trusted Platform Module).

Use o Google Cloud Artifact Analysis para verificar vulnerabilidades em imagens de contêiner ou sistema operacional e outros tipos de artefatos sob demanda ou automaticamente em seus pipelines. Use a Detecção de Ameaças de Contêiner para monitorar continuamente o estado de Container-Optimized imagens de nó do sistema operacional. O serviço avalia todas as alterações e tentativas de acesso remoto para detectar ataques de runtime quase em tempo real.

Use o Registro de Artefatos, para configurar o armazenamento seguro de artefatos de build privado para manter o controle sobre quem pode acessar, exibir ou baixar artefatos com funções e permissões IAM nativas do Registro e para obter tempo de atividade consistente na infraestrutura segura e confiável do Google.

Para serviços sem servidor GCP, adote controles semelhantes para garantir que os controles de segurança "mudem para a esquerda" para o estágio anterior à implantação.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):

DS-7: Habilitar registro e monitoramento em DevOps

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
8.2, 8.5, 8.9, 8.11 AU-3, AU-6, AU-12, SI-4 10.1, 10.2, 10.3, 10.6

Princípio de segurança: verifique se o escopo de registro em log e monitoramento inclui ambientes de não produção e elementos de fluxo de trabalho de CI/CD usados no DevOps (e em qualquer outro processo de desenvolvimento). As vulnerabilidades e ameaças que se direcionam a esses ambientes poderão apresentar riscos significativos ao seu ambiente de produção se elas não forem monitoradas corretamente. Os eventos do fluxo de trabalho de compilação, teste e implantação de CI/CD também devem ser monitorados para identificar desvios nos trabalhos do fluxo de trabalho de CI/CD.

Diretrizes do Azure: habilite e configure os recursos de log de auditoria em ambientes de ferramentas de CI/CD e não produção (como o Azure DevOps e o GitHub) usados em todo o processo de DevOps.

Os eventos gerados do Azure DevOps e do fluxo de trabalho de CI/CD do GitHub, incluindo os trabalhos de build, teste e implantação, também devem ser monitorados para identificar quaisquer resultados anormais.

Ingerir os logs e eventos acima no Microsoft Sentinel ou em outras ferramentas SIEM por meio de um fluxo de log ou API para garantir que os incidentes de segurança sejam monitorados e triagem adequadamente para tratamento.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: habilite e configure o AWS CloudTrail para recursos de log de auditoria em ambientes de ferramentas de CI/CD e não produção (como CodePipeline do AWS, CodeBuild da AWS, CodeDeploy da AWS, AWS CodeStar) usados em todo o processo de DevOps.

Os eventos gerados a partir dos ambientes de CI/CD da AWS (como AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) e o fluxo de trabalho de CI/CD do GitHub, incluindo os trabalhos de build, teste e implantação, também devem ser monitorados para identificar quaisquer resultados anormais.

Ingerir os logs e eventos acima no AWS CloudWatch, microsoft sentinel ou outras ferramentas SIEM por meio de um fluxo de log ou API para garantir que os incidentes de segurança sejam devidamente monitorados e triagem para tratamento.

Implementação da AWS e contexto adicional:

Diretrizes do GCP: habilite e configure os recursos de log de auditoria em ambientes de ferramentas de CI/CD e não produção para produtos como Cloud Build, Google Cloud Deploy, Artifact Registry e GitHub, que podem ser usados em todo o processo de DevOps.

Os eventos gerados a partir dos ambientes de CI/CD do GCP (como Cloud Build, Google Cloud Deploy, Artifact Registry) e o fluxo de trabalho de CI/CD do GitHub, incluindo os trabalhos de build, teste e implantação, também devem ser monitorados para identificar quaisquer resultados anormais.

Ingerir os logs e eventos acima no Microsoft Sentinel, no Google Cloud Security Command Center, no Chronicle ou em outras ferramentas SIEM por meio de um fluxo de log ou API para garantir que os incidentes de segurança sejam devidamente monitorados e triagem para tratamento.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):