Protegendo o ambiente do desenvolvedor para o Confiança Zero

Este artigo ajudará você, como desenvolvedor, a proteger seu ambiente de desenvolvimento para poder implementar os princípios da Confiança Zero (verificação explícita, uso do acesso com privilégios mínimos, suposição de violação). Ele apresenta o conteúdo do nosso eBook Proteger ambientes de DevOps corporativos e destaca as melhores práticas para segurança de branches 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 do desenvolvedor podem ser contrárias às normas de conformidade e à necessidade de auditar e controlar o acesso e o armazenamento do ambiente de funcionários privados.

As máquinas não gerenciadas que se conectam à rede da organização desafiam as equipes de segurança, as aquisições e o conselho de governança. O melhor cenário de fornecer aos desenvolvedores ambientes de funcionários padrão e endurecidos 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. Roubo e perda de hardware são as principais preocupações.

As vulnerabilidades se estendem às integrações do ambiente de desenvolvimento. Ferramentas de desenvolvimento que apresentam extensibilidade avançada podem ter integrações sem manutenção no seus mercados. Extensões maliciosas podem colocar em risco as ferramentas do desenvolvedor e cautilizar 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 por meio da conexão com pacotes de código aberto de terceiros e extensões de aplicativos. As extensões apresentam vetores de ataque em vulnerabilidades de aplicativos de dependência e extensão.

O diagrama ilustra ambientes de desenvolvedor e ameaças à segurança, conforme descrito no eBook anterior e resumido em artigos relacionados vinculados aqui.

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

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

  • Configure o privilégio mínimo.
  • Limite quem pode alterar e aprovar o código com a segurança da 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 no seus ambientes. Grandes superfícies de ameaças do ambiente do desenvolvedor tornam irreal para os desenvolvedores manter o conhecimento onipresente do sistema. Quando uma organização detecta uma violação após um ataque comprometer um ambiente de desenvolvedor que tem acesso de administrador a todos os sistemas, um tempo precioso de correção pode já ter passado.

Para remediar possíveis oportunidades de acesso que fazem com que os hackers tenham como alvo a função de desenvolvedor de software, considere as seguintes melhores práticas recomendadas de segurança de privilégio mínimo da Confiança Zero 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. Coloque políticas para cobrir direitos de acesso de administrador em dispositivos principais, ferramentas de DevOps, pipelines de versão, repositórios de código, ambientes, repositórios 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. Utilize 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 utilize tokens de acesso pessoal 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 ambiente baseado em SaaS, tenha instruções claras sobre como os princípios de acesso determinam 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 não gerenciado a dispositivos.
  • Padronize e sincronize contas de usuário do GitHub Enterprise Managed User (EMU) com identidades corporativas. Com Usuários gerenciados corporativos, você pode controlar as contas de usuário dos membros da sua empresa por meio do seu provedor de identidade (IdP). No repositório de identidades da sua organização, defina explicitamente nomes de usuário, emails e nomes de exibição do GitHub. Os usuários identificam facilmente os colaboradores, mesmo quando eles nunca se encontraram pessoalmente.
  • 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 do GitHub EMU), sua identidade é e sempre será sua identidade pública. O acesso controlado via SSO requer conexão com o repositório de identidades da organização.
  • Utilize 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 utilizado para uma chave SSH assinar outra chave SSH. O GitHub Enterprise Cloud oferece suporte a 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 utilizarem para autenticação Git. Os certificados só podem acessar repositórios que pertencem à organização. Os administradores podem exigir que os membros usem certificados ao acessar seus repositórios.
  • Utilize um gerenciador de credenciais do Git para proteger o acesso ao seu código. Ferramentas como o Visual Studio (VS) têm suporte de identidade integrado. O VS Code será encaminhado para um gerenciador de credenciais do 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 evitar o acesso não autorizado ao repositório de código, implemente uma estratégia de ramificação para estabelecer o controle sobre as alterações de código (veja o exemplo ilustrado no diagrama a seguir).

O diagrama ilustra um exemplo de estratégia de branch que protege o repositório principal.

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

  • Proteja ramificações 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 mudanças que fornece uma cadeia de comando e um plano claros para lidar com as mudanças no código. Das diferentes abordagens para a estratégia de ramificação, um ponto em comum é que as ramificações protegidas servem como fonte para novos lançamentos para a produção.
  • Fazer com que os administradores de 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 aprovação de verificação de status para todas as pull requests mescladas no branch protegido. As políticas de branch ajudam as equipes a proteger seus importantes branches de desenvolvimento. As políticas impõem a qualidade de 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 integrados de desenvolvedor (IDE) é tão produtiva que é essencialmente um recurso obrigatório. Você conta com a capacidade de aplicar e organizar extensões no 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 Marketplace do VS Code tem milhares de extensões para facilitar sua vida. No entanto, quando suas equipes adotam novas ferramentas ou extensões, o aspecto mais importante pode ser verificar a confiabilidade de um editor.
  • Configure práticas seguras para controlar o uso da extensão para limitar a superfície de ataque dos ambientes do desenvolvedor. 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 em cima do IDE abre as organizações para mais ameaças.
  • Em máquinas de desenvolvedor, acompanhe o número e a maturidade das extensões usadas para entender a superfície de ataque potencial. Incorpore somente extensões do Marketplace do VS Code de fornecedores verificados. Ao instalar extensões de aplicativos de terceiros 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 no seu ambiente de desenvolvedor.

Próximas etapas