Partilhar via

Controles DevSecOps

  • Artigo

Este artigo descreve como aplicar controles de segurança para dar suporte às práticas de segurança SDL contínuas. Esses controles de segurança são parte integrante de uma estratégia de DevSecOps que abrange pessoas, processos e tecnologia. Esta documentação descreve cada controle e mostra como aplicá-los a três perfis de segurança. Esses perfis atendem aos requisitos de segurança típicos para cenários de negócios comuns na maioria das organizações:

Diagrama de controles de segurança versus tempo e impacto.

Perfis de controlo de segurança

Há três camadas de perfis de controle referenciados neste artigo.

Mínimo temporário – Perfil de segurança abreviado para um estado de exceção temporário para suportar a prototipagem rápida de cargas de trabalho de baixo risco. Esse perfil deve ser usado apenas para exceções temporárias que precisam ser lançadas em um cronograma acelerado para atender às necessidades críticas dos negócios. Os itens que usam esse perfil devem ser rapidamente trazidos para o perfil padrão.

Padrão - Abordagem equilibrada para a maioria das cargas de trabalho, na maioria das vezes.

Alta segurança – Segurança rigorosa para cargas de trabalho com um potencial alto impacto na segurança empresarial e humana.

Controles de segurança DevSecOps

Esta seção fornece uma referência dos controles de segurança recomendados para cada tipo de carga de trabalho. Esta referência pode ser adotada como está ou pode ser adaptada aos seus processos de desenvolvimento de software e segurança de software existentes. A maioria das organizações não pode implementar todos esses controles imediatamente se ainda não estiver fazendo alguns deles. Adotar uma abordagem de melhoria contínua é muitas vezes a melhor abordagem: priorizar controles, implementar o primeiro controle, passar para o próximo controle, implementá-lo e assim por diante. A maioria das organizações deve priorizar os fundamentos críticos primeiro.

Para obter mais informações, consulte A jornada DevSecOps.

Este diagrama resume os controles de segurança e como aplicá-los a cada perfil de segurança de carga de trabalho.

As principais considerações de planejamento incluem:

  • Vire para a esquerda... mas verifique duas vezes - Esta referência é projetada para detetar e corrigir problemas o mais cedo possível para permitir que você os corrija quando for mais fácil e barato corrigir os problemas (às vezes chamado de shift left), mas também para assumir falhas e incluir verificação dupla mais tarde no processo. Verifique sempre todos os controles de segurança no processo de CI/CD, garantindo que problemas evitáveis não cheguem aos sistemas de produção. Este conceito segue os princípios de "defesa em profundidade" e "à prova de falhas".
  • Inteligência Artificial (IA) – As duas principais implicações da inteligência artificial são:
    • Proteja todo o código , independentemente de ser escrito por IA humana ou generativa
    • Use ambos para segurança - Aplique controles clássicos e de IA conforme disponíveis para aumentar a visibilidade e o contexto de quaisquer problemas de segurança (como ferramentas de análise de código)

Controlos de segurança

Os controles são agrupados nos estágios de desenvolvimento aos quais se aplicam e nos controles comuns (fundamentos críticos) que se aplicam a todos os estágios de desenvolvimento e perfis de controle:

Cada um destes elementos é definido nas seguintes secções:

Estabelecer bases críticas

Esse controle suporta a Prática SDL Contínua 1 – Estabelecer padrões, métricas e governança de segurança, a Prática 2 – Exigir o uso de recursos, linguagens e estruturas de segurança comprovados e a Prática 10 – Fornecer treinamento de segurança.

Padrão - Esses controles se aplicam a todos os estágios de desenvolvimento e perfis de controle.

Fornecer formação em segurança

Esse controle se concentra em fornecer aos desenvolvedores e às equipes de segurança treinamento para reconhecer e resolver problemas de segurança durante o ciclo de vida do desenvolvimento. Sem treinamento de segurança, suas equipes podem perder os principais pontos fracos de segurança que levam ao comprometimento durante a vida útil dos aplicativos.

Como resultado, é imperativo que você implemente o treinamento de segurança em todas as funções (incluindo usuários, desenvolvedores, gerentes de linha de produtos, testadores e muito mais). Cada função deve ter educação sobre os riscos de segurança e o seu papel em manter as aplicações seguras. Este treinamento pode assumir a forma de: treinamento formal ou sob demanda, exercícios de simulação, modelagem de ameaças, mentores/conselheiros, campeões de segurança, equipes de suporte de segurança de aplicativos, atividades de equipe roxa, podcasts, vídeos ou quaisquer outros métodos de aprendizagem.

Em última análise, cada função precisa compreender:

  • Por que é importante lidar com os riscos de segurança
  • O que precisam de fazer pela segurança no desempenho das suas funções
  • Como integrar a segurança no seu papel quotidiano

As pessoas que entendem a perspetiva do atacante, seus objetivos e como isso aparece em incidentes de segurança do mundo real rapidamente se tornam aliados de segurança em vez de tentar evitar a segurança.

A segurança é um jogo sem fim onde as ameaças, a tecnologia e os ativos de negócios a proteger estão sempre mudando e os agentes de ameaças nunca desistem. A abordagem da formação em segurança deve ser contínua e evoluir continuamente. O treinamento eficaz alinha e reforça as políticas de segurança, as práticas do ciclo de vida de desenvolvimento de software (SDL), os padrões e os requisitos de segurança de software. O material de formação deve provir de informações derivadas de dados e capacidades técnicas recentemente disponíveis.

Embora a segurança seja uma preocupação de todos, é importante recordar que nem todos precisam de ser peritos em segurança ou competentes na realização de testes de penetração. É essencial garantir que todos entendam os conceitos básicos de segurança e como aplicá-los ao seu papel de criar segurança em software e serviços. Esta formação deve incluir a utilização segura de estações de trabalho, aplicações, identidade e contas.

Em particular, os desenvolvedores e os engenheiros de construção de sistemas geralmente não são especialistas em segurança. O treinamento nos aspetos técnicos e conceituais da modelagem de ameaças é necessário para que eles se tornem eficazes, para que possam construir sistemas seguros por design. Esse treinamento é vital para que o processo de modelagem de ameaças funcione em escala em organizações onde os desenvolvedores superam em muito o número de profissionais de segurança. A modelagem de ameaças deve ser pensada como uma habilidade fundamental de engenharia, na qual todos os desenvolvedores e engenheiros devem ter pelo menos proficiência básica. Portanto, as equipes de desenvolvimento e engenharia devem ser treinadas para serem competentes em modelagem de ameaças como parte da integração e com atualizações periódicas.

Inclua a segurança em postmortems irrepreensíveis

A análise post mortem irrepreensível é um método extremamente importante para as equipas aprenderem com os erros de forma eficaz e eficiente, sem desencadear a defensividade dos membros da equipa, procurando alguém para culpar. Os aprendizados de segurança devem ser explicitamente incluídos no processo post-mortem irrepreensível para garantir que as equipes também maximizem os aprendizados de segurança.

Estabeleça padrões de segurança, métricas e governança

As organizações devem estabelecer esses padrões de segurança, métricas e governança, pois eles sustentam a capacidade de inovar. Ele permite um forte programa de segurança que não apenas protege os ativos da organização, mas também se alinha com seus objetivos de negócios. Os padrões de segurança são os requisitos básicos e as práticas recomendadas para manter os sistemas, os dados e os processos de uma organização seguros.

Estas normas devem ser medidas e regeridas, incluindo a monitorização da conformidade e a sua revisão e atualização regulares em relação às ameaças atuais, às ferramentas e a outros fatores. Esse processo deve abranger todo o ciclo de vida, desde a ideação inicial até a desativação do aplicativo e quaisquer ambientes de desenvolvimento de suporte.

As métricas são medidas usadas para ver a eficácia dos controles e processos de segurança. Uma métrica importante é o MTTR (Mean Time To Remediate) para rastrear por quanto tempo um aplicativo permanece vulnerável. Esta medição permite-nos investir estrategicamente na emissão de correções de segurança mais rapidamente.

Nota

Este conceito difere do MTTR em operações de segurança focadas no tempo para remover o acesso adversário aos ativos da organização.

A governança de segurança atua como uma mão orientadora para as equipes de segurança e muitas vezes é construída sobre estruturas e processos que as organizações usam para gerenciar e controlar sua segurança da informação. Estes incluem Políticas, Procedimentos, Controlos e Gestão de Riscos. As métricas ajudam a quantificar a exposição ao risco. Sem eles, a organização pode não entender completamente suas vulnerabilidades e impacto potencial.

Como os requisitos de segurança podem ser novos, você tem a oportunidade de adotar uma abordagem progressiva que aumenta gradualmente os padrões de codificação para o estado ideal. Essa abordagem dá às equipes tempo para aprender e automatizar o monitoramento e os controles.

Exigir o uso de recursos, linguagens e estruturas de segurança comprovados

Defina e publique uma lista de ferramentas aprovadas e suas verificações de segurança associadas. Usar soluções de segurança bem estabelecidas e comprovadas é importante para evitar erros comuns, porque construir soluções seguras é muito desafiador. A tentativa de reinventar soluções de segurança quase sempre resulta em maior risco de segurança e perda de tempo e esforço.

Certifique-se de que os desenvolvedores e engenheiros estão aproveitando as novas funcionalidades e proteções de análise de segurança. Eles devem sempre usar o compilador mais recente, vinculador, bibliotecas e os sinalizadores de compilador e vinculador apropriados para gerar executáveis seguros.

As organizações devem implementar um processo de revisão e aprovação para validar a segurança de quaisquer componentes integrados. Eles devem estabelecer uma política para usar apenas componentes aprovados em processos de compilação e implantação que são impostos e monitorados.

Segurança de identidade fundamental

Certifique-se de que o uso e a integração da identidade seguem as práticas recomendadas de segurança bem estabelecidas. Os agentes de ameaças usam técnicas de ataque de identidade frequentemente contra sistemas de produção e processos de desenvolvimento. Um ditado popular capta isso: "os atacantes não invadem, apenas fazem login".

A segurança de identidade assume duas formas para o desenvolvimento:

  • Segurança de identidade para o processo de desenvolvimento - Certifique-se de que todos os participantes no processo de desenvolvimento usem métodos de autenticação forte para seu trabalho diário e só tenham privilégios necessários para executar suas tarefas de trabalho. Para obter mais informações, consulte a seção Controles de acesso de identidade/aplicativo.
  • Segurança de identidade para sistemas e aplicativos - Certifique-se de que os sistemas que eles estão projetando e construindo sigam as práticas recomendadas para métodos de autenticação e autorização (e não estejam criando suas próprias imitações fracas de sistemas de identidade comprovados e mantidos).

Aplique a segurança de identidade para sistemas e aplicativos seguindo as orientações nestes recursos:

Padrões criptográficos

Aplique práticas criptográficas sólidas a todo o uso de criptografia. Siga todas as orientações descritas em Continuous SDL Practice 4 – Define and Use cryptographic Standards.

Para obter mais informações, consulte Recomendações criptográficas do Microsoft SDL.

Protegendo seu ambiente de desenvolvimento

Este controlo suporta a Prática SDL Contínua 6 – Proteger o seu ambiente de engenharia.

Esse controle se concentra em proteger seu ambiente de desenvolvimento usando estações de trabalho seguras e ambientes de desenvolvimento integrado (IDEs). Esse controle destaca o benefício de usar uma abordagem Zero Trust em seu ciclo de vida de desenvolvimento de software.

No cenário atual, os invasores expandem suas operações para atingir as máquinas de seus desenvolvedores e adulterar os processos de compilação. Um exemplo crucial desse ataque foi o experimentado pela SolarWinds, onde o invasor inseriu uma DLL maliciosa antes dos estágios finais da compilação do software. Efetivamente, isso backdoorou o aplicativo e resultou em um ataque direcionado que foi distribuído para milhares de clientes em todo o mundo através da cadeia de suprimentos. Para obter mais informações sobre o ataque da SolarWinds, consulte o Blog da Microsoft Analisando o Solorigate, o arquivo DLL comprometido que iniciou um ataque cibernético sofisticado e como o Microsoft Defender ajuda a proteger os clientes.

É essencial fortalecer estações de trabalho, criar ambientes, identidades e outros sistemas de desenvolvimento para garantir a integridade dos aplicativos desenvolvidos. A falha em fazer isso cria um caminho para que os invasores comprometam seu aplicativo por meio do sistema de gerenciamento de código-fonte (SCM) ou da estação de trabalho do desenvolvedor.

Essa prática é uma base crítica do seu ciclo de vida de desenvolvimento e deve ser estabelecida em todos os perfis.

Ao longo desta prática, você deve adotar uma abordagem Zero Trust. Em sua essência, o modelo Zero Trust exige que cada solicitação de acesso (usuário, serviço ou dispositivo) seja verificada como se tivesse se originado de uma rede não confiável, independentemente de onde a solicitação se origina ou qual recurso ela acessa. Baseie esta política de "sempre autenticar e autorizar" em todos os pontos de dados disponíveis. Você deve limitar o acesso do usuário, especialmente os privilegiados, por meio das políticas Just-In-Time e Just-Enough-Access (JIT/JEA) e segmentar o acesso para minimizar os possíveis danos se houver uma violação.

Fortalecer seu ambiente de desenvolvimento pode ser alcançado através de vários métodos, no entanto, um bom ponto de partida é considerar a estação de trabalho do desenvolvedor. Ao utilizar tecnologias como GitHub Codespaces ou Microsoft DevBox, você muda o ambiente de desenvolvimento para aplicativos SaaS, que podem ser gerenciados por meio de configurações de segurança e rede ou por meio de políticas organizacionais.

Para bloquear ainda mais as estações de trabalho do desenvolvedor, você pode emiti-las estações de trabalho de acesso privilegiado/estações de trabalho de acesso seguro (PAW/SAW). Essas estações de trabalho ajudam a reduzir os vetores de ameaças e garantem um dispositivo de desenvolvedor padronizado e controlado.

Design seguro

Executar modelagem de ameaças (revisão do projeto de segurança)

Este controlo suporta a Prática SDL Contínua 3 – Executar Modelação de Ameaças.

Esse controle identifica fraquezas de segurança no projeto que podem resultar em incidentes de segurança e danos aos negócios. As fraquezas de segurança no projeto podem ser difíceis de mitigar depois que o projeto é implementado, portanto, encontrar e corrigir essas fraquezas no início do ciclo de vida é extremamente importante.

A modelagem de ameaças serve como o processo de revisão do projeto de segurança, que integra a segurança no projeto de um sistema ou aplicativo.

A modelagem de ameaças identifica, avalia, prioriza e reduz sistematicamente os riscos de segurança dentro de um sistema de software. Esta abordagem estruturada para analisar o design e a arquitetura de uma aplicação de software identifica potenciais ameaças e vulnerabilidades no início do processo de desenvolvimento.

O objetivo final é entender o sistema e o que pode dar errado. A modelagem de ameaças ajuda a atingir esse objetivo, aplicando uma compreensão profunda do próprio sistema e de como um invasor em potencial o vê.

Esse processo geralmente assume a forma de workshops de descoberta de ameaças, onde uma equipe de especialistas no sistema e especialistas em segurança trabalham juntos para descobrir e documentar riscos. Embora esse processo possa começar informalmente, ele deve evoluir rapidamente para um processo estruturado que discute cada aspeto do serviço que está sendo criado, como ele é usado e as interfaces do sistema.

As etapas da modelagem de ameaças são:

  1. Identificar casos de uso, cenários e ativos – Comece entendendo quais funções de negócios e casos de uso o sistema permite para ajudar a avaliar o potencial impacto nos negócios de qualquer comprometimento do sistema e informar as discussões a seguir.
  2. Criar uma visão geral da arquitetura – Crie um resumo visual do aplicativo (ou use um existente) para fornecer uma compreensão clara do sistema e como ele funciona. Essa visão geral deve incluir: um mapa do processo de negócios, componentes e subsistemas, limites de confiança, mecanismos de autenticação e autorização, interfaces externas e internas e fluxos de dados entre atores e componentes.
  3. Identificar as ameaças - Use uma metodologia comum para enumerar potenciais ameaças à segurança, como o modelo STRIDE ou a modelagem de ameaças OWASP.
  4. Identificar e rastrear mitigações - Monitore e rastreie falhas de projeto descobertas usando processos e ferramentas de desenvolvimento existentes para garantir que as correções sejam implementadas e documentadas. Esse processo deve incluir, priorizando quais mitigações fazer primeiro para que as equipes gastem seu tempo nos esforços mais importantes primeiro. Esse processo é orientado pelo risco e você pode não ter recursos para mitigar totalmente todos os riscos no primeiro ciclo. Considere cuidadosamente quais mitigações, incluindo mitigações parciais, aumentam o custo para um invasor pelo menor custo defensivo e recursos. O objetivo da segurança é a falha do atacante, que pode assumir a forma de bloquear totalmente uma técnica de ataque, detetá-los para permitir uma resposta do defensor, retardá-los para dar tempo aos defensores para responder, limitar o escopo do dano e muito mais.

Um modelo de ameaça geralmente serve como um processo de educação para todos os envolvidos, além de fornecer contexto importante para outros planejamentos, implementação e testes de segurança.

As aplicações que incluem o uso de componentes de Inteligência Artificial (IA) devem avaliar os tipos de risco específicos associados à IA, que são diferentes das aplicações clássicas.

Crie e analise modelos de ameaças: comunicando sobre o design de segurança de seus sistemas, analisando esses projetos para possíveis problemas de segurança usando uma metodologia comprovada e sugerindo e gerenciando mitigações para problemas de segurança.

Código seguro

Análise de código

Este controlo suporta a Prática SDL Contínua 7 – Realizar Testes de Segurança.

Esse controle se concentra em aumentar a segurança do código à medida que os desenvolvedores o escrevem/inserem em um ambiente de desenvolvimento integrado (IDE) ou quando fazem check-in do código. Esse controle é a pedra angular das práticas de DevSecOps, pois aborda diretamente as vulnerabilidades que os invasores exploram regularmente.

Sem esse controle, você pode estar perdendo vulnerabilidades que são codificadas diretamente em seu aplicativo por seus desenvolvedores. Seus desenvolvedores não estão sendo mal-intencionados, mas podem não ter a qualificação necessária para identificar por que o que eles codificaram é inseguro.

Esse controle é fundamental para obter os benefícios de produtividade e segurança de uma abordagem shift left integrando ferramentas diretamente no IDE. Esse processo permite a rápida descoberta e correção de vulnerabilidades na oportunidade mais rápida e econômica. Este processo pode ser aplicado retroativamente a aplicações já desenvolvidas, identificando deficiências de segurança e corrigindo-as mais tarde (embora com maiores custos e dificuldades).

Esse processo normalmente assume a forma de plug-ins IDE ou ferramentas de varredura dedicadas que verificam o código usando conjuntos de ferramentas SAST (Static Analysis Security Testing) e DAST (Dynamic Analysis Security Test).

As ferramentas SAST verificam a base de código existente e têm acesso total ao código. As ferramentas SAST podem identificar os principais pontos fracos no próprio código. O DAST, por outro lado, é executado no aplicativo implantado. Como resultado, ele não tem acesso ao código e é executado para simular e identificar falhas de segurança em tempo de execução.

Nota

As aplicações de IA têm diferentes tipos de vulnerabilidades (como enviesamentos e alucinações) do que as aplicações clássicas e requerem ferramentas que se concentrem nelas.

O controlo de qualidade é importante! Uma consideração fundamental para executar essas ferramentas é garantir que você as esteja ajustando para reduzir o ruído e o esforço desperdiçado de falsos positivos. O ajuste dessas ferramentas normalmente requer um profissional de segurança com experiência em desenvolvedores que entenda os processos de desenvolvimento da sua organização. Os mesmos profissionais também podem fornecer orientação de triagem e experiência em deteções individuais para desenvolvedores. Eles podem ajudar a distinguir verdadeiros e falsos positivos, problemas reais versus falsos alarmes. Os processos para os desenvolvedores acessarem esses especialistas geralmente estão intimamente relacionados ao Fornecimento de Treinamento de Segurança, como por meio de programas de campeões, equipes de suporte de segurança de aplicativos, etc.

Mínimo temporário – Certifique-se de habilitar os recursos de segurança internos do IDE e implementar um nível mínimo de verificação SAST em todo o repositório para identificar vulnerabilidades em todo o aplicativo. Deve haver um processo documentado para corrigir problemas descobertos em um tempo razoável, embora o padrão de "barra de bugs" cujas falhas devem ser corrigidas seja limitado até que o aplicativo atinja os perfis padrão equilibrados ou de alta segurança.

Padrão - Certifique-se de verificar totalmente todos os componentes com todas as ferramentas SAST/DAST aplicáveis e identifique os pontos fracos. Garanta uma cobertura de segurança total sobre o código do seu aplicativo. Certifique-se de que está a seguir o processo documentado de correção e de que tem um padrão de "barra de bugs" que corresponda à tolerância ao risco da sua organização.

Alta segurança – Garanta que todos os aplicativos aplicáveis imponham um processo detalhado e documentado abordando todas as vulnerabilidades de segurança. Aplique correções antes de qualquer atividade de compilação ou lançamento. Certifique-se de estar seguindo o processo documentado de correção e ter uma "barra de bugs" altamente restritiva que corresponda à tolerância ao risco da sua organização para cargas de trabalho críticas para os negócios de alta segurança.

Existem muitas ferramentas disponíveis para uso na análise estática. Consulte a lista em Microsoft Security Development Lifecycle para encontrar mais informações.

Proteja o pipeline de CI/CD

Gestão da cadeia de abastecimento/dependência

Este controlo suporta a Prática SDL Contínua 5 - Proteger a Cadeia de Abastecimento de Software.

Esse controle se concentra em proteger sua cadeia de suprimentos de desenvolvimento usando ferramentas e estruturas de Análise de Composição de Software (SCA), como a Estrutura de Consumo Seguro da Cadeia de Suprimentos (S2C2F). Esses processos ajudam a reduzir o risco de comprometimento por código que não seja da Microsoft.

No cenário atual, a maioria dos aplicativos depende de software de código aberto (OSS) com pouca supervisão ou controle dos consumidores desses componentes. Esse controle destaca as principais estratégias, técnicas e tecnologias para ingerir, consumir, usar e manter o OSS com segurança. Também enfatiza a proteção de dependências internas, garantindo um ciclo de vida completo de ponta a ponta, independentemente de quem codificou o software.

A falha no controle da cadeia de suprimentos de software expõe você a vulnerabilidades significativas introduzidas por código que você não controla. Um exemplo notório é a vulnerabilidade log4J/Log4Shell, que permitia a execução remota de código em qualquer sistema ou aplicativo usando este pacote. Tais vulnerabilidades podem surgir acidentalmente ou maliciosamente.

Proteger sua cadeia de suprimentos é uma parte essencial para garantir um ciclo de vida de desenvolvimento seguro e deve ser considerado em todos os estados do perfil, embora cada estado deva seguir o mesmo processo padronizado de ingestão de dependências.

Mínimo temporário – Inventarie todas as suas dependências para entender o impacto de uma vulnerabilidade OSS em seu aplicativo. Esse inventário pode ser feito usando o Dependabot ou outras ferramentas de Análise de Composição de Software (SCA). Essas ferramentas também podem ajudá-lo a gerar uma lista de materiais de software (SBOM).

Padrão - Analise todas as vulnerabilidades do OSS e corrija-as automaticamente com solicitações pull automáticas. Esse controle também pode ser obtido usando o Dependabot e o gráfico/revisão de dependência do GitHub.

Alta segurança – Bloqueie ativamente todos os pacotes inseguros com vulnerabilidades exploráveis sendo usadas no aplicativo.

Para saber mais sobre esse controle e medir sua maturidade de segurança OSS, revise a estrutura da cadeia de suprimentos do OSS e a documentação de práticas recomendadas do GitHub sobre como proteger seu ciclo de vida de desenvolvimento.

Revisão do código de segurança

Esse controle se concentra em ter um código de revisão de especialistas em segurança para identificar possíveis falhas de segurança. Isso ajuda a encontrar problemas de segurança difíceis de automatizar as deteções.

Essa revisão pode ser realizada por: um colega da mesma equipe com experiência em segurança de aplicativos, um campeão de segurança dentro da organização, um especialista em segurança de aplicativos da equipe central de segurança de aplicativos ou uma parte externa.

Esta revisão deve ser sempre uma pessoa separada do desenvolvedor que escreveu o código. Essa revisão deve ser feita como uma atividade separada após a conclusão da análise automatizada de código.

Mínimo temporário – Este controlo é recomendado para este perfil.

Standard - Este controlo é recomendado para este perfil.

Alta segurança – Este controle é necessário para todas as aplicações de alta segurança e geralmente envolve vários especialistas individuais.

Verificação de credenciais e segredos

Este controlo suporta a Prática SDL Contínua 7 – Realizar Testes de Segurança.

Esse controle se concentra na redução do risco de chaves de autenticação e outros segredos expostos no código. Os agentes de ameaças têm experiência e automação para encontrar e explorar segredos incorporados no código.

A melhor abordagem é usar identidades gerenciadas e protocolos de autenticação modernos em vez de chaves e segredos, quando possível. Embora o uso de chaves e segredos de API tenha sido tradicionalmente uma prática de codificação e teste, o método preferido deve sempre ser a autenticação baseada em identidade para recursos devido às maiores capacidades de segurança e gerenciamento do ciclo de vida. A implementação desse controle assume a forma de usar identidades gerenciadas, como identidades gerenciadas para recursos do Azure.

Se o uso de segredos for necessário, você deve protegê-los durante todo o seu ciclo de vida, incluindo sua criação, uso, rotação regular e revogação. Evite usar diretamente segredos no código e armazene-os apenas em um sistema de armazenamento de chave/segredo seguro, como o Azure Key Vault ou um HSM (Hardware Security Module), se necessário. Sob nenhuma circunstância chaves de texto simples e segredos devem ser armazenados em código, mesmo temporariamente! Os atacantes encontrarão e explorarão esses segredos.

Importante

Os repositórios internos de código-fonte não são seguros!

Os repositórios internos devem estar sujeitos aos mesmos requisitos que os repositórios públicos, uma vez que os agentes de ameaças procuram frequentemente segredos e chaves nos repositórios depois de obterem acesso a um ambiente através de phishing ou outros meios. Isso é necessário para uma abordagem Zero Trust que assume violações e projeta controles de segurança de acordo.

Padrão - Uma boa higiene secreta é essencial e é exigida em todos os perfis.

Nota

Como esses segredos são encontrados por suas equipes ou por invasores, você deve garantir que a chave não possa ser usada para acessar recursos (varia de acordo com o tipo de recurso), além de modificar o mecanismo para um método de acesso mais seguro, como identidades gerenciadas.

Mais detalhes e recursos incluem:

Nota

É altamente recomendável usar chaves por carga de trabalho com soluções de armazenamento secretas, como o Azure Key Vault.

Pipeline seguro

Este controlo suporta a Prática SDL Contínua 5 - Proteger a Cadeia de Abastecimento de Software.

Esse controle se concentra em proteger o pipeline de DevOps e todos os artefatos criados durante os processos de compilação do seu aplicativo.

Os pipelines são uma parte essencial da automação das principais atividades repetíveis dentro do ciclo de vida do DevSecOps. No CI/CD, sua equipe mescla o código do desenvolvedor em uma base de código central em um cronograma regular e executa automaticamente compilações padrão e processos de teste, que incluem conjuntos de ferramentas de segurança.

O uso de pipelines para executar scripts ou implantar código em ambientes de produção pode introduzir desafios de segurança exclusivos. Certifique-se de que seus pipelines de CI/CD não se tornem vias para executar códigos mal-intencionados, permitir que credenciais sejam roubadas ou dar aos invasores qualquer área de superfície para acesso. Você também deve garantir que apenas o código que sua equipe pretende liberar seja implantado. Esse processo inclui artefatos de seus pipelines de CI/CD, especialmente artefatos que são compartilhados entre diferentes tarefas que podem ser usadas como parte de um ataque.

A geração de listas de materiais de software (SBOM) deve ser automatizada no processo de compilação para criar esse artefato de proveniência de código criticamente importante sem exigir ações manuais do desenvolvedor.

A segurança do pipeline pode ser garantida garantindo um bom controle de acesso aos recursos usados no pipeline e validando/atualizando dependências/scripts principais regularmente. É importante notar que os scripts usados em pipelines de CI/CD também são código e devem ser tratados da mesma forma que você trata outros códigos em seu projeto.

Nota

A segurança do pipeline depende da segurança da infraestrutura subjacente e das contas/identidades usadas para o processo. Para obter mais informações, consulte a proteção do seu ambiente de desenvolvimento e os controles de operações seguras (Identity Identity/App Access Controls, Host/Container Controls, Network Access Controls)

Padrão - Esse controle deve ser avaliado em um nível de acesso a todos os recursos do projeto, é um controle necessário em todos os níveis de perfil DevSecOps.

Para saber mais sobre segurança de pipeline, consulte Protegendo pipelines do Azure.

Operações seguras

Testes de penetração no local em tempo real

Este controlo suporta a Prática SDL Contínua 7 – Realizar Testes de Segurança.

Peça aos testadores de penetração de aplicativos profissionais que tentem comprometer uma instância ativa da carga de trabalho completa. Esse teste valida se os controles de segurança da carga de trabalho são eficazes e consistentes. O teste de penetração ajuda a encontrar e destacar o caminho de menor resistência que um invasor pode usar para explorar seu aplicativo e comprometer os negócios. Os testes de penetração podem ser incrivelmente valiosos quando feitos no momento certo. Use-os depois de mitigar as vulnerabilidades baratas e fáceis de explorar encontradas em verificações anteriores.

Recomendamos que você faça esse teste em todos os níveis dos perfis de segurança DevSecOps.

Mínimo temporário – Recomendamos que faça um teste de penetração em todas as aplicações. Devido a restrições de tempo, você só poderá identificar métodos mais fáceis no aplicativo que um invasor pode explorar. Planeje rapidamente elevar isso ao nível padrão no mínimo.

Padrão - Em um perfil padrão, recomendamos que você faça um teste de penetração. Nesse caso, você pode descobrir vulnerabilidades mais complexas devido ao cuidado extra que é tomado no início do processo de desenvolvimento.

Alta segurança – Para aplicativos de linha de negócios e cargas de trabalho críticas, é necessário concluir um teste de penetração. Qualquer vulnerabilidade nestas aplicações deve ser tratada com atenção e cuidado redobrados.

Integre as descobertas e o feedback dessas atividades para melhorar seus processos e ferramentas de segurança.

Controles de acesso de identidade/aplicativo

Este controlo suporta a Prática SDL Contínua 8 – Garantir a segurança da plataforma operacional e a Prática 6 – Proteger o seu ambiente de engenharia.

Certifique-se de que as práticas recomendadas de segurança para gerenciamento de identidade e acesso, incluindo a proteção de acesso privilegiado, sejam seguidas para todos os elementos técnicos do ambiente de desenvolvimento, pipeline de CI/CD, carga de trabalho operacional e outros sistemas de desenvolvimento. Os agentes de ameaças têm métodos sofisticados e automação para ataques de identidade que usam com frequência contra sistemas de produção e processos de desenvolvimento. O gerenciamento de identidade e acesso é um pilar fundamental do modelo Zero Trust recomendado pela Microsoft.

Garanta que as práticas recomendadas de segurança sejam seguidas para todos os sistemas de desenvolvimento e a infraestrutura que os hospeda (VMs, contêineres, dispositivos de rede e muito mais).

Mínimo temporário – Certifique-se de que todos usam autenticação multifator e só podem acessar os sistemas necessários para executar suas tarefas diárias.

Padrão - Certifique-se de que os componentes de infraestrutura que hospedam a carga de trabalho (como VMs, contêineres, rede e sistemas de identidade) atendam às práticas recomendadas de segurança para gerenciamento de identidade e acesso, incluindo a proteção de acesso privilegiado.

Alta segurança – Implemente uma estratégia completa de Zero Trust que incorpore MFA, Identity Threat Detection and Response e Cloud Infrastructure Entitlement Management (CIEM). Execute um modelo de ameaça específico da carga de trabalho de sistemas e componentes de identidade que suportem cada carga de trabalho de alta segurança.

As identidades gerenciadas são o método de autenticação mais seguro e preferido sempre que possível. O uso de tokens e segredos é menos seguro devido à necessidade de armazená-los e recuperá-los na camada de aplicação. Além disso, as Identidades Gerenciadas são automaticamente substituídas sem a necessidade de intervenção manual.

Mais detalhes e recursos incluem:

Controles de host/contêiner/ambiente

Este controlo suporta a Prática SDL Contínua 8 – Garantir a segurança da plataforma operacional e a Prática 6 – Proteger o seu ambiente de engenharia.

Certifique-se de que as práticas recomendadas de segurança sejam seguidas para todos os recursos de computação e ambientes de hospedagem para todos os elementos técnicos do ciclo de vida de desenvolvimento. Os agentes de ameaças têm métodos sofisticados e automação para ataques de infraestrutura e ponto final do usuário que usam com frequência contra sistemas de produção e processos de desenvolvimento. A segurança da infraestrutura é um pilar fundamental do modelo Zero Trust recomendado pela Microsoft.

Este controlo deve incluir todos os elementos do ciclo de vida operacional e de desenvolvimento, incluindo, entre outros:

  • Estações de trabalho e ambientes gerais de TI/operacionais
  • Estações de trabalho e ambientes de desenvolvimento dedicados
  • Infraestrutura de pipeline de CI/CD
  • Ambientes de hospedagem de carga de trabalho
  • Quaisquer outros sistemas de desenvolvimento.

Esse controle inclui qualquer recurso que possa executar qualquer código, incluindo, mas não limitado a:

  • Anfitriões e VMs de Máquina Virtual (VM)
  • Contentores e infraestrutura de contentores
  • Plataformas de hospedagem de aplicativos, scripts e códigos
  • Subscrições/contas e inscrições na nuvem
  • Estações de trabalho para desenvolvedores, usuários e administradores de TI

Certifique-se de aplicar as práticas recomendadas de segurança aos componentes de infraestrutura, incluindo atualizações de segurança (patches), configurações de segurança de linha de base e muito mais.

Mínimo temporário – Aplique configurações empresariais padrão para hosts e assinaturas.

Padrão - Certifique-se de que a infraestrutura atenda às práticas recomendadas de segurança descritas no Microsoft Cloud Security Benchmark (MCSB).

Alta segurança – Aplique rigorosamente os padrões MCSB e execute um modelo de infraestrutura de ameaça específico da carga de trabalho que suporta cada carga de trabalho de alta segurança.

Mais detalhes e recursos incluem:

Controlos de acesso à rede

Este controlo suporta a Prática SDL Contínua 8 – Garantir a segurança da plataforma operacional e a Prática 6 – Proteger o seu ambiente de engenharia.

Certifique-se de que as práticas recomendadas de segurança para o gerenciamento de acesso à rede sejam seguidas para todos os elementos técnicos do ambiente de desenvolvimento, pipeline de CI/CD, ambiente de carga de trabalho operacional e outros sistemas de desenvolvimento. Os agentes de ameaças têm métodos sofisticados e automação para ataques de identidade que usam com frequência contra sistemas de produção e processos de desenvolvimento. A segurança de rede é um pilar fundamental do modelo Zero Trust recomendado pela Microsoft.

A segurança da rede deve incluir:

  • Proteção de rede externa – Isolamento de tráfego externo/internet não solicitado e mitigação de tipos de ataque conhecidos. Esse isolamento normalmente assume a forma de firewall da Internet, firewall de aplicativos da Web (WAF) e soluções de segurança de API.
  • Proteção de rede interna – Isolamento de tráfego interno não solicitado (de outros locais de rede corporativa). Esse isolamento pode usar controles semelhantes como proteção de rede externa e pode ser granular para a carga de trabalho ou para componentes individuais específicos e endereços IP.
  • Mitigações de negação de serviço – Proteções contra DDoS (Distributed Denial of Service) e outros ataques de negação de serviço.
  • Security Service Edge (SSE) – Uso de microssegmentação do lado do cliente para fornecer acesso seguro diretamente aos recursos, incluindo a aplicação de políticas Zero Trust.

Garanta que as práticas recomendadas de segurança sejam seguidas para todos os sistemas de desenvolvimento e a infraestrutura que os hospeda (VMs, contêineres, dispositivos de rede e muito mais).

Mínimo temporário – Aplique configurações empresariais padrão para carga de trabalho.

Padrão - Certifique-se de que todos os sistemas tenham proteção de rede externa, proteção contra DDoS e um mínimo de proteção de rede interna por carga de trabalho.

Alta segurança – Todas as proteções padrão, além de alta granularidade das proteções de rede interna, encapsulamento forçado do tráfego do servidor de saída por meio de mecanismos de proteção de rede externa e um modelo de ameaça específico da carga de trabalho da infraestrutura de rede que suporta cada carga de trabalho de alta segurança.

Mais detalhes e recursos incluem:

Monitorização, resposta e recuperação

Este controlo suporta a Prática SDL Contínua 9 – Implementar Monitorização e Resposta de Segurança.

Certifique-se de que as equipes de operações de segurança (SecOps/SOC) tenham visibilidade, deteção de ameaças e procedimentos de resposta para cargas de trabalho (APIs e aplicativos), bem como a infraestrutura que as hospeda. Certifique-se de que os processos e ferramentas entre equipes entre equipes entre SecOps e equipes de infraestrutura/carga de trabalho permitam uma recuperação rápida após um ataque.

Esse controle sustenta a segurança da carga de trabalho quando ela está em produção e em execução ativa em sua organização. Esse processo deve ser integrado com seu recurso de operações de segurança existente que deteta e responde a incidentes de segurança.

O monitoramento de segurança para cargas de trabalho personalizadas combina soluções XDR (Extended Detection and Response) para componentes comuns, analisando logs e outros dados de aplicativos para detetar e investigar possíveis ameaças à segurança. Os dados personalizados do aplicativo geralmente incluem: informações sobre solicitações do usuário, atividade do aplicativo, códigos de erro, tráfego de rede, outros detalhes relevantes do aplicativo, bancos de dados, pontos de extremidade de rede e outros componentes do sistema.

Esses dados são então aprimorados com informações de inteligência de ameaças em tempo real para identificar padrões de comportamento anômalo que podem indicar possíveis tentativas de infiltração na rede. Uma vez agregada, correlacionada e normalizada, a plataforma XDR e Security Information and Event Management (SIEM) oferece ações de correção.

Mínimo temporário – Implante recursos XDR em seu ambiente para monitorar o tráfego de seus dispositivos de usuário final.

Padrão - Implante XDR e deteções SIEM personalizadas que identifiquem comportamentos anômalos em relação ao ambiente geral. Esse perfil pode incluir deteções personalizadas para cargas de trabalho individuais.

Alta segurança – Controles padrão mais deteções personalizadas por carga de trabalho com base em informações da modelagem de ameaças da carga de trabalho. Combine esse perfil com IA para fornecer conhecimento contextual às recomendações de remediação.

Próximos passos

Adote esses controles de segurança e adapte-os aos requisitos de tolerância ao risco e produtividade da sua organização. Você deve usar uma abordagem de melhoria contínua onde você constrói continuamente em direção ao estado ideal.

Comece priorizando os controles e os níveis mínimos ideais de destino. Certifique-se de ter um impacto positivo na segurança e alterações de baixo atrito primeiro. Priorize, implemente e integre o primeiro controle e, em seguida, repita o processo com o próximo controle.

Você deve priorizar as fundações críticas primeiro por causa de seu amplo impacto positivo e verificação de credenciais e segredos devido ao seu alto impacto e uso frequente de invasores.