A engenharia de segurança transforma um requisito de carga de trabalho em um controle que pode ser testado, monitorado e removido com segurança. No Azure, esse trabalho abrange o locatário do Microsoft Entra, o Azure Resource Manager dentro de uma assinatura e o plano de dados de cada serviço; portanto, uma configuração aparentemente correta pode acabar protegendo o escopo errado.
Utilizaremos uma carga de trabalho de desenvolvimento delimitada no grupo de recursos fictício rg-orders-dev. O objetivo é expor as decisões, as evidências e os limites que um engenheiro de segurança em nuvem deve estabelecer antes de considerar uma configuração como uma medida de proteção.
Comece com um requisito vinculado a um ativo e a uma ameaça. Por exemplo, uma API de processamento de pedidos deve recuperar um segredo sem expô-lo à internet pública. Um controle é o mecanismo configurado para atender a esse requisito, enquanto uma evidência é um registro observável que sustenta uma afirmação específica sobre sua configuração ou atividade.
Nosso fluxo de trabalho é consistente. Identificamos o ativo, o limite de dados, a identidade e a ameaça; escolhemos o controle apropriado mais simples; definimos a falha esperada caso o acesso seja negado ou o tráfego siga uma rota não pretendida; e, em seguida, verificamos o resultado desejado com evidências de configuração e de tempo de execução. A limpeza remove permissões temporárias, segredos de teste ou configurações de diagnóstico quando não são mais necessários, evitando que artefatos de teste se tornem pontos de exposição permanente.
Evidências de configuração e evidências de tempo de execução respondem a perguntas diferentes. Uma atribuição de função ou configuração de ponto de extremidade privado demonstra o estado pretendido do plano de controle. Um evento de auditoria do Key Vault, um log de diagnóstico de armazenamento ou uma falha de aplicativo demonstra uma tentativa observada no plano de dados dentro de sua janela de tempo registrada. Isoladamente, nenhum deles garante que todos os caminhos estejam seguros ou que um incidente não tenha outra causa.
As recomendações identificam lacunas na postura de segurança, mas a imposição deve vir de uma política de negação ou do próprio controle.
A Microsoft protege a infraestrutura física subjacente do Azure, enquanto o cliente permanece responsável pelos dados da carga de trabalho, comportamento do aplicativo, identidades e decisões de acesso. Esse limite de responsabilidade compartilhada não significa que um serviço gerenciado pela plataforma dispense o trabalho de segurança por parte do cliente. Significa que devemos identificar qual parte é responsável por cada camada antes de selecionar evidências ou medidas de correção.
O diretório Microsoft Entra autentica usuários, aplicativos e identidades gerenciadas. O Azure Resource Manager, frequentemente chamado de ARM, é o plano de controle do Azure para criar e configurar recursos em uma assinatura ou grupo de recursos. As atribuições de função do Azure RBAC nesses escopos autorizam ações no plano de controle, como alterar a configuração de rede de uma conta de armazenamento.
O plano de dados de um serviço é a interface específica do serviço que lê, grava ou utiliza dados protegidos. A recuperação de segredos do Key Vault e o acesso a dados de Blob ocorrem em seus respectivos planos de dados, onde a autorização do plano de dados e os controles de rede são aplicados independentemente da autorização do ARM. Um Colaborador (Contributor) que pode configurar um cofre não está, por isso, autorizado a ler seus segredos.
A regra reutilizável consiste em identificar a entidade de segurança (principal), a ação, o escopo e o plano antes de avaliar se o acesso deve ser bem-sucedido.
Nossa carga de trabalho fictícia é a app-orders-api, um aplicativo do Azure App Service no grupo de recursos rg-orders-dev, dentro de uma assinatura fictícia <subscription-id>. Ela é executada em uma região do Azure escolhida e utiliza a vnet-orders-dev para integração de rede virtual de saída. O aplicativo precisa de dados de pedidos em stordersdev e de um segredo em kv-orders-dev, enquanto law-sec-01 é o workspace do Log Analytics utilizado pelo Microsoft Sentinel.
A rede virtual é o limite de rede do aplicativo, e não o local de todos os recursos de serviço do Azure. stordersdev e kv-orders-dev permanecem como serviços da plataforma Azure fora da vnet-orders-dev; os pontos de extremidade privados (private endpoints) posicionam interfaces de rede privadas para esses serviços na rede virtual. O DNS privado e as configurações de rede do serviço devem direcionar a solicitação de saída da API para esses endereços de ponto de extremidade, em vez de para um ponto de extremidade público.
A identidade gerenciada do aplicativo precisará, posteriormente, de permissões separadas no plano de dados para as ações pretendidas no Key Vault e no Storage. O Sentinel é executado no law-sec-01, onde conectores e configurações de diagnóstico determinam quais registros são recebidos para análise. Um workspace pode dar suporte à investigação apenas de dados que foram efetivamente coletados nele.
Trace o limite da carga de trabalho, indo da API até seus pontos de extremidade privados e o workspace de monitoramento.