Consuma artefatos de software de terceiros em sua cadeia de fornecedores somente quando for verificado e marcado como seguro para uso, por processos bem definidos. Esse 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 de nuvem geralmente dependem de softwares de terceiros obtidos de fontes externas. Binários de software livre, imagens de contêiner público, 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 repositório fora do escopo da solução e integrado ao pipeline de implantação. Há alguns problemas potenciais nessa abordagem. A origem pode não ser confiável, o artefato pode conter vulnerabilidades ou pode não ser adequado de alguma outra maneira 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 o software para segurança antes de introduzi-lo em sua carga de trabalho. Durante o processo, cada artefato passa por um rigor operacional completo que o verifica em condições específicas. Somente depois que o artefato atender a essas condições, o processo o marcará como confiável.
O processo de quarantining é 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 faça a transição 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.
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 repositório especificado.
Um processo de verificação personalizado é executado como parte da quarentena, que inclui verificar as restrições de entrada e verificar os atributos, a origem e o tipo em relação aos padrões estabelecidos.
Algumas dessas verificações de segurança podem ser verificação de vulnerabilidade, 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 da avaliação de 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, ele permanecerá 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 do qual o relatório deve ser inválido e o artefato é considerado não seguro.
O processo marca o fim da quarentena sinalizando um evento com informações de estado acompanhadas por um relatório.
Com base nas informações, os consumidores podem optar por executar ações 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, verifique se ele é obtido de uma fonte confiável. Sua escolha deve estar alinhada aos padrões aprovados pela organização para artefatos adquiridos de fornecedores de terceiros. Os fornecedores devem ser capazes de atender aos requisitos de segurança de sua carga de trabalho (e de sua organização). Por exemplo, verifique se o plano de divulgação responsável do fornecedor atende aos requisitos de segurança da sua organização.
Crie uma 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. Verifique se o artefato não é consumido inadvertidamente até ser marcado como confiável. A sinalização deve ser automatizada. Por exemplo, tarefas relacionadas à notificação das partes responsáveis quando um artefato é ingerido no ambiente do desenvolvedor, confirmando alterações em um repositório GitHub, adicionando uma imagem a um registro privado e assim por diante.
Uma alternativa para implementar um padrão de quarentena é terceirizar. Há profissionais de quarentena especializados em validação de ativos públicos como seu modelo de negócios. Avalie os custos financeiros e operacionais da implementação do padrão versus a terceirização da responsabilidade. Se os 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 ser capaz de continuar até que todas as tarefas sejam concluídas.
O padrão serve como uma validação momentânea de primeira oportunidade. Passar a quarentena com êxito não garante que o artefato permaneça confiável indefinidamente. O artefato deve continuar a passar por verificação 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 versão.
O padrão pode ser implementado por equipes centrais de uma organização ou uma equipe de carga de trabalho individual. Se houver muitas instâncias ou variações do processo de quarentena, essas 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 do gerenciamento de processos de descarregamento.
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 OCI (Open Container Initiative) de registros públicos, como DockerHub, registro de contêiner do GitHub, registro de contêiner da Microsoft
Uma biblioteca de software ou um pacote de fontes públicas, como a Galeria Do NuGet, o Índice de Pacotes python, o repositório Apache Maven
Um pacote iac (infraestrutura como código) externo, como módulos do Terraform, Livros de Receitas do Chef da Comunidade, Módulos Verificados do Azure
Um instalador de software ou imagem do sistema operacional fornecido pelo fornecedor
A equipe de carga de trabalho considera o artefato como um risco que vale a pena atenuar. A equipe entende as consequências negativas da integração de artefatos comprometidos e o valor da quarentena para assegurar 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 sempre que uma imagem do sistema operacional for ingerida em quarentena, o processo de verificação geral para 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 parceiro confiável.
O risco de não verificar o artefato é menor do que o custo de compilaçã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 de DevSecOps da carga de trabalho. Os princípios subjacentes são abordados nos pilares do Azure Well-Architected Framework.
| Coluna | Como esse padrão dá suporte a metas de pilar |
|---|---|
| A primeira responsabilidade da validação de segurança é atendida pelo padrão de quarentena. A validação em um artefato externo é realizada em um ambiente segmentado antes de ser consumida pelo processo de desenvolvimento. - de ciclo de vida de desenvolvimento protegido se:02 - de teste e validação se:11 |
|
| de Excelência Operacional ajuda a fornecer de qualidade da carga de trabalho por meio processos padronizados e coesão de equipe. | O padrão de quarentena dá suporte a SDP (práticas de implantação seguras) garantindo que 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. práticas de desenvolvimento de software - OE:03 - de teste e validação do OE:11 |
Assim como acontece com qualquer decisão de design, considere quaisquer compensações em relação às metas dos outros pilares que possam ser introduzidas 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 ACR (Registro de Contêiner do Azure), que pertence à equipe de carga de trabalho. A equipe trata essa instância como um repositório de artefatos confiável.
O ambiente de carga de trabalho usa o Azure Policy para Kubernetes para impor a governança. Ele restringe os pulls de contêiner somente de sua instância de registro confiável. Além disso, os alertas do Azure Monitor são configurados para detectar 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 somente de usuários autorizados.
Ponto de verificação de segurança: a identidade do solicitante, o registro de contêiner de destino e a origem da imagem solicitada são verificadas.
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 das 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 durável do Azure. O orquestrador usa uma abordagem de coleta de dispersão 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 ACR (Registro de Contêiner do Azure) de quarentena que é considerado como um repositório 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 violaçã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 CVE (Vulnerabilidades Comuns e Exposições), avaliação de fatura de software de material (SBOM), detecção de malware, assinatura de imagem 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: essa etapa é o núcleo do processo de quarentena que executa todas as verificações de validação. O tipo de verificação pode ser soluções personalizadas, de software livre ou compradas pelo fornecedor.
O orquestrador toma uma decisão. Se a imagem passar todas as validações, o evento será observado 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 impedir 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 revisar os resultados. Se os resultados atenderem à tolerância a riscos, eles efetuarão pull da imagem do repositório de quarentena para a instância de 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 para Contêineres, que verifica continuamente se há 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 ao implementar esse padrão:
Recomendações para proteger um ciclo de vida de desenvolvimento fornece diretrizes sobre como usar unidades confiáveis de código 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.
Proteger contra pacotes públicos mal-intencionados usando o Azure Artifacts.