Consuma artefatos de software de terceiros em sua cadeia de suprimentos somente quando for verificado e marcado como seguro para uso, por processos bem definidos. Este padrão é um sidecar operacional para o processo de desenvolvimento. O consumidor desse padrão invoca esse processo para verificar e bloquear o uso de software que poderia potencialmente introduzir vulnerabilidades de segurança.
Contexto e problema
As soluções na nuvem dependem frequentemente de software de terceiros obtido de fontes externas. Binários de código aberto, imagens de contêineres públicos, imagens do sistema operacional do fornecedor são alguns exemplos desses tipos de artefatos. Todos esses artefatos externos devem ser tratados como não confiáveis.
Em um fluxo de trabalho típico, o artefato é recuperado de um armazenamento fora do escopo da solução e, em seguida, integrado ao pipeline de implantação. Existem alguns problemas potenciais nesta abordagem. A origem pode não ser confiável, o artefato pode conter vulnerabilidades ou pode não ser adequado de alguma outra forma para o ambiente do desenvolvedor.
Se esses problemas não forem resolvidos, as garantias de integridade e confidencialidade dos dados da solução podem ser comprometidas ou causar instabilidade devido à incompatibilidade com outros componentes.
Alguns desses problemas de segurança podem ser evitados adicionando verificações a cada artefato.
Solução
Tenha um processo que valide o software para segurança antes de introduzi-lo em sua carga de trabalho. Durante o processo, cada artefacto passa por um rigoroso rigor operacional que o verifica face a condições específicas. Somente depois que o artefato satisfaz essas condições, o processo o marca como confiável.
O processo de quarentena é uma medida de segurança, que consiste em uma série de pontos de verificação que são empregados antes de um artefato ser consumido. Esses pontos de verificação de segurança garantem que um artefato transite de um status não confiável para um status confiável.
É importante notar que o processo de quarentena não altera a composição do artefato. O processo é independente do ciclo de desenvolvimento de software e é invocado pelos consumidores, conforme necessário. Como consumidor do artefato, bloqueie o uso de artefatos até que eles tenham passado pela quarentena.
Aqui está um fluxo de trabalho de quarentena típico:
O consumidor sinaliza sua intenção, especifica a fonte de entrada do artefato e bloqueia seu uso.
O processo de quarentena valida a origem da solicitação e obtém os artefatos do armazenamento especificado.
Um processo de verificação personalizado é realizado como parte da quarentena, que inclui a verificação das restrições de entrada e a verificação dos atributos, da origem e do tipo em relação aos padrões estabelecidos.
Algumas dessas verificações de segurança podem ser verificação de vulnerabilidade, deteção de malware e assim por diante, em cada artefato enviado.
As verificações reais dependem do tipo de artefato. Avaliar uma imagem do sistema operacional é diferente de avaliar um pacote NuGet, por exemplo.
Se o processo de verificação for bem-sucedido, o artefato será publicado em um repositório seguro com anotações claras. Caso contrário, fica indisponível para o consumidor.
O processo de publicação pode incluir um relatório cumulativo que mostra a prova de verificação e a criticidade de cada verificação. Inclua a expiração no relatório, além da qual o relatório deve ser inválido e o artefato é considerado inseguro.
O processo marca o fim da quarentena sinalizando um evento com informações de estado acompanhadas de um relatório.
Com base nas informações, os consumidores podem optar por tomar medidas para usar o artefato confiável. Essas ações estão fora do escopo do padrão de quarentena.
Problemas e considerações
Como uma equipe que consome artefatos de terceiros, certifique-se de que eles sejam obtidos de uma fonte confiável. Sua escolha deve estar alinhada aos padrões aprovados pela organização para artefatos que são adquiridos de fornecedores terceirizados. Os fornecedores devem ser capazes de atender aos requisitos de segurança da sua carga de trabalho (e da sua organização). Por exemplo, certifique-se de que o plano de divulgação responsável do fornecedor atenda aos requisitos de segurança da sua organização.
Crie segmentação entre recursos que armazena artefatos confiáveis e não confiáveis. Use controles de identidade e rede para restringir o acesso aos usuários autorizados.
Tenha uma maneira confiável de invocar o processo de quarentena. Certifique-se de que o artefato não seja consumido inadvertidamente até ser marcado como confiável. A sinalização deve ser automatizada. Por exemplo, tarefas relacionadas a notificar as partes responsáveis quando um artefato é ingerido no ambiente do desenvolvedor, confirmar alterações em um repositório GitHub, adicionar uma imagem a um registro privado e assim por diante.
Uma alternativa à implementação de um padrão de quarentena é terceirizá-lo. Existem profissionais de quarentena especializados em validação de ativos públicos como modelo de negócio. Avalie os custos financeiros e operacionais da implementação do padrão versus a terceirização da responsabilidade. Se os seus requisitos de segurança precisarem de mais controlo, recomenda-se a implementação do seu próprio processo.
Automatize o processo de ingestão do artefato e também o processo de publicação do artefato. Como as tarefas de validação podem levar tempo, o processo de automação deve ser capaz de continuar até que todas as tarefas sejam concluídas.
O padrão serve como uma primeira oportunidade de validação momentânea. Passar com sucesso pela quarentena não garante que o artefato permaneça confiável indefinidamente. O artefato deve continuar a passar por varredura contínua, validação de pipeline e outras verificações de segurança de rotina que servem como validações de última oportunidade antes de promover a liberação.
O padrão pode ser implementado por equipes centrais de uma organização ou por uma equipe de carga de trabalho individual. Se houver muitas instâncias ou variações do processo de quarentena, essas operações devem ser padronizadas e centralizadas pela organização. Nesse caso, as equipes de carga de trabalho compartilham o processo e se beneficiam do gerenciamento do processo de descarregamento.
Quando utilizar este padrão
Utilize este padrão quando:
A carga de trabalho integra um artefato desenvolvido fora do escopo da equipe de carga de trabalho. Exemplos comuns incluem:
Um artefato Open Container Initiative (OCI) de registros públicos, como DockerHub, registro de contêiner GitHub, registro de contêiner da Microsoft
Uma biblioteca de software ou pacote de fontes públicas, como NuGet Gallery, Python Package Index, repositório Apache Maven
Um pacote externo de infraestrutura como código (IaC), como módulos Terraform, livros de receitas do Community Chef, módulos verificados do Azure
Uma imagem do SO fornecida pelo fornecedor
A equipe de carga de trabalho considera o artefato como um risco que vale a pena mitigar. A equipe entende as consequências negativas da integração de artefatos comprometidos e o valor da quarentena para garantir um ambiente confiável.
A equipe tem uma compreensão clara e compartilhada das regras de validação que devem ser aplicadas a um tipo de artefato. Sem consenso, o padrão pode não ser eficaz.
Por exemplo, se um conjunto diferente de verificações de validação for aplicado cada vez que uma imagem do sistema operacional for ingerida em quarentena, o processo geral de verificação das imagens do sistema operacional se tornará inconsistente.
Este padrão poderá não ser prático quando:
O artefato de software é criado pela equipe de carga de trabalho ou por uma equipe de parceiro confiável.
O risco de não verificar o artefato é menos dispendioso do que o custo de construção e manutenção do processo de quarentena.
Design da carga de trabalho
Um arquiteto e a equipe de carga de trabalho devem avaliar como o padrão de quarentena pode ser usado como parte das práticas de DevSecOps da carga de trabalho. Os princípios subjacentes são abordados nos pilares do Azure Well-Architected Framework.
| Pilar | Como esse padrão suporta os objetivos do pilar |
|---|---|
| As decisões de design de segurança ajudam a garantir a confidencialidade, integridade e disponibilidade dos dados e sistemas da sua carga de trabalho. | A primeira responsabilidade da validação de segurança é servida pelo padrão de quarentena. A validação em um artefato externo é conduzida em um ambiente segmentado antes de ser consumida pelo processo de desenvolvimento. - SE:02 Ciclo de vida de desenvolvimento seguro - SE:11 Testes e validação |
| A Excelência Operacional ajuda a fornecer qualidade de carga de trabalho por meio de processos padronizados e coesão da equipe. | O padrão de quarentena oferece suporte a práticas de implantação segura (SDP), certificando-se de que os artefatos comprometidos não sejam consumidos pela carga de trabalho, o que pode levar a violações de segurança durante implantações de exposição progressiva. - OE:03 Práticas de desenvolvimento de software - OE:11 Testes e validação |
Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.
Exemplo
Este exemplo aplica o fluxo de trabalho da solução a um cenário em que a equipe de carga de trabalho deseja integrar artefatos OCI de registros públicos a uma instância do Azure Container Registry (ACR), que pertence à equipe de carga de trabalho. A equipe trata essa instância como um armazenamento de artefatos confiáveis.
O ambiente de carga de trabalho usa a Política do Azure para Kubernetes para impor a governança. Ele restringe as extrações de contêiner somente de sua instância de registro confiável. Além disso, os alertas do Azure Monitor são configurados para detetar quaisquer importações para esse Registro de fontes inesperadas.
Uma solicitação para uma imagem externa é feita pela equipe de carga de trabalho por meio de um aplicativo personalizado hospedado nos Aplicativos Web do Azure. O aplicativo coleta as informações necessárias apenas de usuários autorizados.
Ponto de verificação de segurança: a identidade do solicitante, o registro do contêiner de destino e a fonte da imagem solicitada são verificados.
A solicitação é armazenada no Azure Cosmos DB.
Ponto de verificação de segurança: Uma trilha de auditoria é mantida no banco de dados, mantendo o controle da linhagem e validações da imagem. Esta trilha também é usada para relatórios históricos.
A solicitação é tratada por um orquestrador de fluxo de trabalho, que é uma Função do Azure durável. O orquestrador usa uma abordagem de dispersão-coleta para executar todas as validações.
Ponto de verificação de segurança: o orquestrador tem uma identidade gerenciada com acesso suficiente para executar as tarefas de validação.
O orquestrador faz uma solicitação para importar a imagem para o Registro de Contêiner do Azure (ACR) de quarentena que é considerado um armazenamento não confiável.
O processo de importação no registro de quarentena obtém a imagem do repositório externo não confiável. Se a importação for bem-sucedida, o registro de quarentena terá uma cópia local da imagem para executar validações.
Ponto de verificação de segurança: o registro de quarentena protege contra adulteração e consumo de carga de trabalho durante o processo de validação.
O orquestrador executa todas as tarefas de validação na cópia local da imagem. As tarefas incluem verificações como deteção de CVE (Common Vulnerabilities and Exposures), avaliação de lista de materiais de software (SBOM), deteção de malware, assinatura de imagens e outros.
O orquestrador decide o tipo de verificação, a ordem de execução e o tempo de execução. Neste exemplo, ele usa a Instância de Contêiner do Azure como executores de tarefas e os resultados estão no banco de dados de auditoria do Cosmos DB. Todas as tarefas podem levar um tempo significativo.
Ponto de verificação de segurança: esta etapa é o núcleo do processo de quarentena que executa todas as verificações de validação. O tipo de verificação pode ser personalizado, de código aberto ou soluções compradas pelo fornecedor.
O orquestrador toma uma decisão. Se a imagem passar em todas as validações, o evento será anotado no banco de dados de auditoria, a imagem será enviada por push para o registro confiável e a cópia local será excluída do registro de quarentena. Caso contrário, a imagem é excluída do registro de quarentena para evitar seu uso inadvertido.
Ponto de verificação de segurança: o orquestrador mantém a segmentação entre locais de recursos confiáveis e não confiáveis.
Nota
Em vez de o orquestrador tomar a decisão, a equipe de carga de trabalho pode assumir essa responsabilidade. Nessa alternativa, o orquestrador publica os resultados da validação por meio de uma API e mantém a imagem no registro de quarentena por um período de tempo.
A equipe de carga de trabalho toma a decisão depois de analisar os resultados. Se os resultados atenderem à tolerância ao risco, eles puxarão a imagem do repositório de quarentena para a instância do contêiner. Esse modelo de pull é mais prático quando esse padrão é usado para dar suporte a várias equipes de carga de trabalho com diferentes tolerâncias de risco de segurança.
Todos os registros de contêiner são cobertos pelo Microsoft Defender for Containers, que verifica continuamente se há problemas recém-encontrados. Esses problemas são mostrados no Gerenciamento de vulnerabilidades do Microsoft Defender.
Próximos passos
As orientações a seguir podem ser relevantes ao implementar esse padrão:
As recomendações para proteger um ciclo de vida de desenvolvimento fornecem orientação sobre o uso de unidades confiáveis de código em todos os estágios do ciclo de vida do desenvolvimento.
Práticas recomendadas para uma cadeia de suprimentos de software segura, especialmente quando você tem dependências do NuGet em seu aplicativo.
A documentação do Azure Artifacts é uma biblioteca de informações relacionadas ao gerenciamento de pacotes de software com o Azure Artifacts.