Proteja o ambiente do desenvolvedor para o Zero Trust

Este artigo ajuda você, como desenvolvedor, a proteger seu ambiente de desenvolvimento para que você possa implementar os princípios de Zero Trust (verificar explicitamente, usar acesso de privilégios mínimos, assumir violação). Ele apresenta conteúdo do nosso eBook Protegendo ambientes de DevOps Corporativos e destaca as práticas recomendadas para segurança de filiais e ferramentas, extensões e integrações confiáveis.

A velocidade do desenvolvedor depende de sua capacidade de trabalhar como e onde você deseja maximizar os resultados de negócios. Você quer máquinas poderosas e personalizáveis com acesso root ou de administrador. No entanto, as demandas dos desenvolvedores podem ser contrárias às normas de conformidade e à necessidade de auditar e controlar o acesso e o armazenamento do ambiente privado dos funcionários.

Máquinas não gerenciadas que se conectam à rede da organização desafiam as equipes de segurança, compras e o conselho de governança. O melhor cenário de fornecer aos desenvolvedores ambientes de funcionários padrão e protegidos cria desdém de ambos os lados. Quando os funcionários se conectam de qualquer lugar, as redes Wi-Fi vulneráveis são uma porta aberta para ataques cibernéticos. O roubo e a perda de hardware são grandes preocupações.

As vulnerabilidades se estendem às integrações do ambiente de desenvolvimento. As ferramentas de desenvolvimento que apresentam extensibilidade avançada podem ter integrações sem manutenção em seus mercados. Extensões maliciosas podem colocar em risco as ferramentas de desenvolvedor e causar violações em toda a empresa.

No diagrama abaixo, observe como o ambiente do desenvolvedor se conecta ao ambiente de ferramentas de DevOps para afetar as ramificações do Git. Ele amplia a superfície do ambiente através da conexão com pacotes de código aberto e extensões de aplicativos. As extensões apresentam vetores de ataque em vulnerabilidades de aplicativos de dependência e extensão.

Dar aos membros da equipe de DevOps flexibilidade e controle, ao mesmo tempo em que evita ataques mal-intencionados, é um desafio fundamental para os escritórios de segurança. O DevOps pode controlar o ambiente do desenvolvedor com um ambiente de nuvem (consulte Inicialização confiável para VMs do Azure e GitHub Enterprise Cloud Docs) e proteger o ambiente do desenvolvedor com contêineres (consulte Documentação do GitHub Codespaces).

Além disso, os desenvolvedores podem implementar estas medidas Zero Trust para ajudar a proteger o ambiente do desenvolvedor:

• Configure o privilégio mínimo.
• Limite quem pode alterar e aprovar o código com segurança de filial.
• Adote apenas ferramentas, extensões e integrações confiáveis.

Práticas recomendadas para privilégios mínimos

Os desenvolvedores geralmente acreditam que podem capturar malware, phishing e violações em seus ambientes. Grandes superfícies de ameaças ao ambiente do desenvolvedor tornam irrealista para os desenvolvedores manter o conhecimento onipresente do sistema. Uma organização perde um tempo precioso de correção quando deteta uma violação depois que um ataque compromete um ambiente de desenvolvedor que tem acesso de administrador a todos os sistemas.

Para corrigir possíveis oportunidades de acesso que fazem com que hackers tenham como alvo a função de desenvolvedor de software, considere as seguintes práticas recomendadas de segurança de privilégios mínimos Zero Trust para aplicativos.

• Implemente privilégios mínimos e acesso just-in-time para DevOps. Certifique-se de que os membros da equipe mantenham apenas acesso mínimo aos ambientes pelo menor tempo necessário. Implemente políticas para cobrir os direitos de acesso de administrador em dispositivos principais, ferramentas de DevOps, pipelines de versão, repositórios de código, ambientes, armazenamentos secretos e bancos de dados. Para equipes de DevOps, o requisito básico é uma conexão com o repositório de identidades da organização. Use a federação de identidades para integração com ambientes SaaS para evitar a duplicação de identidades em plataformas de terceiros e reduzir o risco de exposição.
• Não use tokens de acesso pessoais para acesso ao código-fonte. As práticas seguras para equipes de DevOps incluem acesso a ferramentas de DevOps baseadas em SaaS, repositórios de código (via SSH, HTTPS ou token de acesso pessoal). Para acesso a ambientes baseados em SaaS, tenha instruções claras sobre como os princípios de acesso ditam quem pode baixar (clonar) repositórios de código de sistemas e de quais dispositivos (local, nuvem e contêiner). Por exemplo, o OneDrive pode bloquear ou limitar o acesso a dispositivos não gerenciados.
• Padronize e sincronize as contas de usuário do GitHub Enterprise Managed User (EMU) com identidades corporativas. Com os Enterprise Managed Users, pode controlar as contas de utilizador dos membros da sua empresa através do seu fornecedor de identidade (IdP). No armazenamento de identidades da sua organização, defina explicitamente nomes de usuário, e-mails e nomes de exibição do GitHub. Os usuários identificam facilmente os colaboradores.
• Para as três maneiras pelas quais um desenvolvedor pode se conectar a um ambiente SaaS (HTTPS com uma identidade, token de acesso pessoal, conexão com chave SSH), faça conexões com o repositório de identidades da organização. Com o GitHub (exceto para contas UEM do GitHub), sua identidade é sempre sua identidade pública. O acesso controlado via logon único (SSO) requer conexão com o repositório de identidades da organização.
• Use uma autoridade de certificação (CA) SSH para fornecer certificados SSH assinados para que os membros acessem recursos com segurança com o Git. Um certificado SSH é um mecanismo para uma chave SSH assinar outra chave SSH. O GitHub Enterprise Cloud suporta certificados SSH para dar às organizações mais controle sobre como os membros acessam os repositórios. Os administradores podem carregar sua chave pública de CA SSH e emitir certificados para os membros usarem para autenticação Git. Os certificados só podem acessar repositórios que pertençam à organização. Os administradores podem exigir que os membros usem certificados ao acessar seus repositórios.
• Use um gerenciador de credenciais Git para proteger o acesso ao seu código. Ferramentas como o Visual Studio (VS) têm suporte interno a identidades. O VS Code defere para um gerenciador de credenciais Git.

Práticas recomendadas para segurança de filiais

Quando os hackers obtêm acesso ao repositório de código, eles podem estudar a segurança do sistema e modificar o código sem que as equipes percebam. Para impedir o acesso não autorizado ao repositório de código, implemente uma estratégia de ramificação para estabelecer controle sobre as alterações de código (veja o exemplo ilustrado no diagrama a seguir).

Para corrigir possíveis oportunidades de acesso ao repositório, considere as seguintes práticas recomendadas de segurança de ramificação.

• Proteja as filiais com revisões de código para dar às equipes de DevOps controle sobre alterações de código e avanços de auditoria. A estratégia de ramificação no diagrama anterior articula um fluxo controlado de alterações que fornece uma cadeia de comando clara e um plano para lidar com alterações de código. Das diferentes abordagens para a estratégia de ramificação, uma semelhança é que as ramificações protegidas servem como fonte para novas versões para produção.
• Fazer com que os administradores dos repositórios Git controlem as autorizações de aprovação. O mecanismo de controle das estratégias de ramificação está no fluxo de trabalho de aprovação. As ramificações protegidas exigem validações, revisões e aprovações antes de aceitar alterações. Uma opção é criar uma regra de proteção de ramificação para impor fluxos de trabalho. Por exemplo, exija uma revisão de aprovação ou um passo de verificação de status para todas as solicitações pull mescladas na ramificação protegida. As políticas de filiais ajudam as equipes a proteger ramos importantes do desenvolvimento. As políticas reforçam a qualidade do código e os padrões de gerenciamento de alterações da sua equipe.

Práticas recomendadas para confiar em ferramentas, extensões e integrações

A extensibilidade em ambientes de desenvolvedor integrados (IDE) é tão produtiva que é essencialmente um recurso obrigatório. Você confia na capacidade de aplicar e selecionar extensões dentro do mercado de um IDE específico para projetar seu ambiente de trabalho ideal.

Para corrigir IDEs seguros, considere as seguintes práticas recomendadas de ferramenta, extensão e integração.

• Certifique-se de integrar apenas ferramentas de mercados e editores confiáveis. Por exemplo, o mercado VS Code tem milhares de extensões para facilitar a sua vida. No entanto, quando suas equipes adotam novas ferramentas ou extensões, o aspeto mais importante pode ser verificar a confiabilidade de um editor.
• Configure práticas seguras para controlar o uso de extensões para limitar a superfície de ataque de ambientes de desenvolvedores. A maioria das extensões IDE requer a aprovação de certos privilégios para funcionar, geralmente como um arquivo com permissões de leitura no sistema para analisar o código. As extensões exigem conexões com ambientes de nuvem para funcionar (comum em ferramentas métricas). A aprovação de funcionalidades extras sobre o IDE abre as organizações para mais ameaças.
• Em máquinas de desenvolvedores, acompanhe o número e a maturidade das extensões usadas para entender a superfície de ataque potencial. Incorpore apenas extensões de mercado VS Code de editores verificados. Ao instalar extensões de aplicativo com o VS Code, verifique regularmente as extensões que você está executando com a linha de comando, código --list-extensions --show-versions. Tenha uma boa compreensão dos componentes extensíveis que você está executando em seu ambiente de desenvolvedor.

Próximos passos

• Incorporar a segurança Zero Trust no seu fluxo de trabalho de desenvolvedor ajuda você a inovar de forma rápida e segura.
• Proteger o ambiente da plataforma DevOps ajuda você a implementar os princípios Zero Trust em seu ambiente de plataforma DevOps e destaca as práticas recomendadas para gerenciamento de segredos e certificados.
• Os ambientes Secure DevOps para Zero Trust descrevem as práticas recomendadas para proteger seus ambientes de DevOps com uma abordagem Zero Trust para evitar que hackers comprometam caixas de desenvolvedores, infetem pipelines de liberação com scripts mal-intencionados e obtenham acesso a dados de produção por meio de ambientes de teste.
• Implementar os princípios do Zero Trust, conforme descrito no memorando 22-09 (em apoio à ordem executiva dos EUA 14028, Improving the Nation's Cyber Security) usando o Microsoft Entra ID como um sistema centralizado de gerenciamento de identidade.
• Acelere e proteja seu código com o Azure DevOps com ferramentas que oferecem aos desenvolvedores a experiência de código para nuvem mais rápida e segura.
• Configure o Azure para confiar no OIDC do GitHub como uma identidade federada. O OpenID Connect (OIDC) permite que seus fluxos de trabalho de Ações do GitHub acessem recursos no Azuresem a necessidade de armazenar as credenciais do Azure como segredos de longa duração do GitHub.