Compartilhar via

Controle de segurança: segurança do DevOps

A Segurança do DevOps abrange os controles relacionados à engenharia de segurança e operações nos processos de 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 ameaça do Azure embutido, 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 (Ciclo de Vida de Desenvolvimento de Software) da sua empresa inclui um conjunto de controles de segurança para controlar os componentes de software internos e de terceiros (incluindo software proprietário e software 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 fornecimento de software devem, pelo menos, incluir os seguintes aspectos:

  • Gerencie corretamente um SBOM (Software Bill of Materials) identificando as dependências 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 fornecimento de software por meio da funcionalidade ou ferramentas a seguir da Segurança Avançada do GitHub ou do recurso nativo do GitHub:- Use o Dependency Graph para verificar, 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 o 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 do AWS, como CodeCommit ou CodePipeline, verifique a segurança da cadeia de fornecimento 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 fornecimento de software por meio da seguinte funcionalidade ou ferramentas da Segurança Avançada do GitHub 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 o 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 Software Delivery Shield para executar a análise de segurança da cadeia de fornecimento de software de ponta a ponta. Isso inclui o serviço OSS (Software open source) 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, à Implantação de Nuvem, ao Registro de Artefatos, à Análise de Artefatos 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 fornecimento de software por meio da seguinte funcionalidade ou ferramentas da Segurança Avançada do GitHub 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 o 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 melhores práticas de segurança entre ambientes, incluindo seus estágios de compilação, 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 abrigam 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 seu pipeline de CI/CD para identificar qualquer configuração incorreta nas principais áreas do Azure DevOps, como Organização, Projetos, Usuários, Pipelines (Build & Versão), Conexões e Agente de Build para identificar 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 sua infraestrutura de DevOps é implantada consistentemente em projetos de desenvolvimento. Acompanhe a conformidade da infraestrutura do DevOps em escala usando o Microsoft Defender para Nuvem (como Painel de Conformidade, Azure Policy, Gerenciamento de Postura de 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 às contas humanas, como desenvolvedores ou testadores, usando recursos como identidades gerenciadas 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 compilação/implantação autogeridos, siga os controles do Microsoft Cloud Security Benchmark, incluindo segurança de rede, gestão de postura e vulnerabilidades, e segurança de terminais para proteger seu ambiente.

Observação: consulte as seções de Registro e Monitoramento de Logs, DS-7 e Gerenciamento de Postura de Segurança e Vulnerabilidades para utilizar serviços como o Azure Monitor e o Microsoft Sentinel e, assim, habilitar governança, conformidade, auditoria operacional e auditoria de risco para sua infraestrutura de DevOps.

Implementação do Azure e contexto adicional:

Diretrizes do 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 mantida 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 verificação de conformidade.
  • Use CodeArtifact para armazenar e compartilhar com segurança pacotes de software usados para 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 IAM do AWS, 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 tarefas de CI/CD e mantê-los no repositório de chaves ou AWS KMS.
  • Se você executar agentes de compilação/implantação autogeridos, siga os controles do Microsoft Cloud Security Benchmark, incluindo segurança de rede, gestão de postura e vulnerabilidades, e segurança de terminais para proteger seu ambiente. Use o AWS Inspector para escanear vulnerabilidades no ambiente EC2 ou em contêineres como ambiente de construção.

Observação: consulte as seções Registro e Detecção de Ameaças, DS-7, e Postura e Gerenciamento de Vulnerabilidades para usar serviços como 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 o 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 sua infraestrutura de DevOps é implantada consistentemente 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" às contas de pessoas, como desenvolvedores ou testadores, usando recursos como identidades gerenciadas 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 compilação/implantação autogeridos, siga os controles do Microsoft Cloud Security Benchmark, incluindo segurança de rede, gestão de postura e vulnerabilidades, e segurança de terminais para proteger seu ambiente.

Observação: consulte as seções de Registro de Logs e Detecção de Ameaças; DS-7 e Gestão de Postura e 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, a conformidade, a auditoria operacional e a 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 o teste de segurança de aplicativo estático (SAST), o teste fuzz, o teste interativo e o teste de aplicativo móvel fazem parte dos controles de validação 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 DevOps de Segurança da Microsoft) e verificação de segredos nativos do GitHub para escanear 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 do AWS, use o Revisor de CodeGuru do AWS para análise de código-fonte python e Java. O Codepipeline do 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.
  • Escaneamento nativo de segredos do GitHub para detecção de credenciais no código-fonte.
  • Análise de código-fonte do AWS CodeGuru para Python e Java.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: integrar SAST (como o Software Delivery Shield, Artifact Analysis) 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.

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 do AWS: integre o DAST ao pipeline para que o aplicativo de runtime possa ser testado automaticamente em seu conjunto de fluxos de trabalho CI/CD no CodePipeline ou no GitHub do 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 a aplicação em tempo de execução possa ser testada automaticamente no seu fluxo de trabalho de CI/CD em 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 transferidos para a esquerda antes da fase 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 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 do Azure Resource Manager e/ou configuração de convidado do Azure Policy.

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

  • Use o Registro de Contêiner do Azure (ACR) para criar seu registro de contêiner privado, no qual o acesso granular pode ser restrito por meio do RBAC do Azure, para que somente serviços e contas autorizadas possam acessar os contêineres no registro privado.
  • Use o Defender para Contêineres para avaliação de vulnerabilidade das imagens em seu Registro de Contêiner do Azure privado. Além disso, você pode usar o 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 sejam aplicados no 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 do 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 EC2 para eliminar credenciais, permissões e pacotes desnecessários. Implantar e impor linhas de base de configurações por meio de imagens AMI personalizadas, modelos 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 do 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 Mecanismo de Kubernetes do Google (GKE). 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 Detecção de Ameaças de Contêiner para monitorar continuamente o estado das imagens do nó Container-Optimized do sistema operacional. O serviço avalia todas as alterações e tentativas de acesso remoto para detectar ataques em tempo de execução quase em tempo real.

Use Registro de Artefatos para configurar um armazenamento seguro de artefatos de build privado, mantendo o controle sobre quem pode acessar, visualizar ou fazer o download dos artefatos com funções e permissões IAM nativas do Registro, e para garantir um tempo de atividade consistente na infraestrutura segura e confiável do Google.

Para os serviços serverless do GCP, adote controles semelhantes para garantir que as medidas de segurança sejam aplicadas antecipadamente, ainda na fase 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 anômalos.

Ingestar 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 devidamente monitorados e triados para tratamento.

Implementação do Azure e contexto adicional:

Diretrizes do AWS: habilitar e configurar 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, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) usados em todo o processo de DevOps.

Os eventos gerados a partir dos ambientes de CI/CD do AWS (como CodePipeline do AWS, CodeBuild do AWS, CodeDeploy do AWS, 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 triados para serem tratados.

Implementação do 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.

Ingira 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 da API para garantir que os incidentes de segurança sejam devidamente monitorados e triados para tratamento.

Implementação do GCP e contexto adicional:

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