Consuma artefatos de software de terceiros em sua cadeia de suprimentos somente quando eles forem verificados e marcados como seguros para uso, por processos bem definidos. Esse padrão é um complemento operacional para o processo de desenvolvimento. O consumidor desse padrão invoca esse processo para verificar e bloquear o uso de software que possa introduzir vulnerabilidades de segurança.
Contexto e problema
As soluções em nuvem geralmente dependem de software de terceiros obtido de fontes externas. Binários de código aberto, imagens de contêineres públicos e imagens de sistemas operacionais de fornecedores 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 uma loja fora do escopo da solução e depois integrado no pipeline de implantação. Existem alguns possíveis problemas nessa abordagem. A fonte 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 poderão 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 a segurança do software antes de introduzi-lo em sua carga de trabalho. Durante o processo, cada artefato passa por um rigor operacional completo que o verifica em relação a condições específicas. Somente depois que o artefato satisfizer essas condições é que o processo o marcará 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 que um artefato seja 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 observar 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 passem pela quarentena.
Veja um fluxo de trabalho típico de quarentena:
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 é executado como parte da quarentena, que inclui a verificação das restrições de entrada e a verificação dos atributos, origem e tipo em relação aos padrões estabelecidos.
Algumas dessas verificações de segurança podem ser verificação de vulnerabilidades, detecçã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 armazenamento seguro com anotações claras. Caso contrário, permanece indisponível para o consumidor.
O processo de publicação pode incluir um relatório cumulativo que mostre a prova da verificação e a criticidade de cada verificação. Inclua a expiração no relatório além da qual o relatório deverá ficar inválido e o artefato será considerado inseguro.
O processo marca o fim da quarentena ao sinalizar um evento com informações estaduais acompanhadas de relatório.
Com base nas informações, os consumidores podem optar por tomar ações para utilizar 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 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 armazenam 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 na validação de ativos públicos como modelo empresarial. Avalie os custos financeiros e operacionais de implementação do padrão versus terceirização da responsabilidade. Se seus requisitos de segurança precisarem de mais controle, é recomendável implementar seu próprio processo.
Automatize o processo de ingestão de artefatos 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 poder continuar até que todas as tarefas sejam concluídas.
O padrão serve como uma validação momentânea de primeira oportunidade. A passagem bem-sucedida da 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 o lançamento.
O padrão pode ser implementado por equipes centrais de uma organização ou por uma equipe de carga de trabalho individual. Se houver muitos casos ou variações do processo de quarentena, estas operações deverão ser padronizadas e centralizadas pela organização. Nesse caso, as equipes de carga de trabalho compartilham o processo e se beneficiam da transferência de gerenciamento de processos.
Quando usar esse padrão
Use esse 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 da OCI (Open Container Initiative) de registros públicos, como DockerHub, GitHub Container Registry, Microsoft Container Registry
Uma biblioteca ou pacote de software 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, Community Chef Cookbooks, Azure Verified Modules
Uma imagem de sistema operacional proporcionada 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 um entendimento claro e compartilhado 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 inserida na quarentena, o processo geral de verificação das imagens do sistema operacional se tornará inconsistente.
Esse padrão pode não ser útil quando:
O artefato de software é criado pela equipe de carga de trabalho ou por uma equipe de parceiros confiáveis.
O risco de não verificar o artefato é menos dispendioso que o custo de construção e manutenção do processo de quarentena.
Design de 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 DevSecOps da carga de trabalho. Os princípios subjacentes são abordados nos pilares do Azure Well-Architected Framework.
| Pilar | Como esse padrão apoia 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 é atendida pelo padrão de quarentena. A validação de um artefato externo é conduzida em um ambiente segmentado antes de ser consumido pelo processo de desenvolvimento. - SE:02 Ciclo de vida de desenvolvimento seguro - ES:11 Teste e validação |
| A Excelência Operacional ajuda a fornecer qualidade na carga de trabalho por meio de processos padronizados e coesão da equipe. | O padrão de quarentena permite práticas de implementação seguras (SDP), garantindo que os artefatos comprometidos não sejam consumidos pela carga de trabalho, o que pode levar a violações de segurança durante implementações de exposição progressiva. - OE:03 Práticas de desenvolvimento de software - OE:11 Teste e validação |
Tal como acontece com qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com este 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 pretende integrar artefatos OCI de registros públicos a uma instância do registro de contêiner do Azure (ACR), que é propriedade da equipe de carga de trabalho. A equipe trata essa instância como um armazenamento confiável de artefatos.
O ambiente de carga de trabalho utiliza o Azure Policy para Kubernetes para impor a governação. Ele restringe pulls de contêiner apenas de sua instância de registro confiável. Além disso, os alertas do Azure Monitor são configurados para detectar quaisquer importações nesse registro provenientes de fontes inesperadas.
Uma solicitação de 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 origem 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, acompanhando a linhagem e validações da imagem. Essa 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 coleta dispersa para executar todas as validações.
Ponto de verificação de segurança: o orquestrador possui 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 possui 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 detecção de vulnerabilidades e exposições comuns (CVE), avaliação da lista de materiais de software (SBOM), detecção de malware, assinatura de imagens e outros.
O orquestrador decide o tipo de verificações, a ordem de execução e o horário de execução. Nesse exemplo, utiliza a Instância de Contêiner do Azure como executores de tarefas e os resultados estão na base de dados de auditoria 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ções podem ser soluções personalizadas, de código aberto ou adquiridas 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 será 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.
Observação
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 certo período.
A equipe de carga de trabalho toma a decisão após analisar os resultados. Se os resultados atenderem à tolerância ao risco, eles extrairão a imagem do repositório de quarentena para a instância do contêiner. Este modelo pull é mais prático quando este padrão é usado para permitir múltiplas equipes de carga de trabalho com diferentes tolerâncias a riscos de segurança.
Todos os registros de contêiner são cobertos pelo Microsoft Defender para contêineres, que verifica continuamente problemas recém-encontrados. Esses problemas são mostrados no Gerenciamento de Vulnerabilidades do Microsoft Defender.
Próximas etapas
As diretrizes a seguir podem ser relevantes na implementação desse padrão:
As recomendações para proteger um ciclo de vida de desenvolvimento fornecem orientação sobre o uso de unidades de código confiáveis em todos os estágios do ciclo de vida de desenvolvimento.
Práticas recomendadas para uma cadeia de fornecimento de software segura, especialmente quando você tem dependências do NuGet em seu aplicativo.
Documentação do Azure Artifacts é uma biblioteca de informações relacionadas ao gerenciamento de pacotes de software com o Azure Artifacts.