Proteja seu ambiente do Azure
Agora que você entende como controlar seus ambientes e proteger seus pipelines de implantação, pode considerar desabilitar o acesso humano aos seus ambientes controlados. Nesta unidade, você aprenderá a estruturar as permissões de seus usuários para ambientes do Azure. Incluindo como permitir o acesso em situações de emergência e como auditar quaisquer alterações que aconteçam no seu património do Azure.
Bloquear o acesso humano
Ao bloquear o acesso humano aos seus ambientes controlados, você garante que alterações acidentais ou maliciosas não possam ignorar os processos de revisão e implantação automatizada da sua equipe. Se você não bloquear o acesso humano, alguém poderá inadvertidamente contornar os controles que você gastou tanto tempo planejando e implementando em todo o repositório e pipelines.
Sem bloquear os controles, também é fácil para alguém quebrar acidentalmente algo. Por exemplo, suponha que um usuário tenha duas cópias do portal do Azure abertas. Um é para um ambiente de teste e o outro é para o ambiente de produção. Quando o usuário está alternando entre as guias do navegador, é fácil para ele fazer alterações acidentalmente em um ambiente de produção que foram feitas para um ambiente de teste.
Para bloquear o acesso humano, você pode usar o RBAC (controle de acesso baseado em função) do Azure. No RBAC, você cria atribuições de função para definir:
- Quais usuários, grupos ou entidades de serviço podem acessar um conjunto definido de recursos do Azure (o escopo).
- O que esses usuários, grupos ou entidades de serviço podem fazer quando acessam os recursos (a função).
O RBAC do Azure fornece muitos tipos de função interna, incluindo:
- Reader, que tem acesso somente leitura ao ambiente.
- Contribuidor, que pode modificar recursos.
- Proprietário, que pode modificar recursos e conceder acesso a outros.
É importante conceder acesso em um escopo apropriado. Se sua organização seguir a prática recomendada de usar assinaturas dedicadas do Azure para cada ambiente, considere usar grupos de gerenciamento do Azure para simplificar o escopo de suas atribuições de função. Se sua organização usa uma única assinatura do Azure para todos os seus ambientes, evite conceder aos humanos acesso à assinatura inteira, porque todos os recursos, incluindo seus ambientes controlados, herdariam essa permissão.
Gorjeta
As atribuições de função são recursos do Azure Resource Manager (ARM). Isso significa que você pode configurar suas atribuições de função RBAC do Azure no código, como usando o Bicep.
Ao planejar suas atribuições de função, você precisa decidir o que faz sentido para sua organização. Por exemplo, suponha que sua organização crie assinaturas separadas para cada um de seus ambientes. Você pode optar por conceder aos administradores e desenvolvedores acesso do Reader aos seus ambientes controlados. Com essa função, eles podem acessar o ambiente de produção no portal do Azure para revisar a configuração de seus recursos, exibir métricas e logs e investigar problemas ou bugs sem fazer alterações no ambiente.
Veja como você pode configurar suas atribuições de função para os ambientes da sua empresa de brinquedos, tanto para os administradores do Azure quanto para os desenvolvedores que escrevem seu código e scripts:
| Nome do ambiente | Nível de controlo | Permissão de administrador | Permissão de desenvolvedor |
|---|---|---|---|
| Desenvolvimento | Controlado | Leitor | Leitor |
| Teste | Controlado | Leitor | Leitor |
| Processo de teste | Controlado | Leitor | Leitor |
| Produção | Controlado | Leitor | Leitor |
| Demonstração | Descontrolado | Proprietário | Contribuinte |
| Testes de desempenho | Descontrolado | Proprietário | Nenhuma |
| Testes de penetração | Descontrolado | Proprietário | Nenhuma |
| Avaliações de RP | Descontrolado | Proprietário | Proprietário |
| Ambientes de teste de desenvolvimento | Descontrolado | Proprietário | Proprietário |
Ao planejar suas atribuições de função, certifique-se de testá-las minuciosamente. Às vezes, as operações de gerenciamento podem exigir permissões que não são óbvias. Dê aos membros da sua equipe a oportunidade de testar todo o seu trabalho diário com as permissões que você planeja usar. Analise quaisquer problemas que eles tenham enfrentado.
Audite suas atribuições de função regularmente. Certifique-se de que você não concedeu acidentalmente acesso às pessoas erradas ou concedeu acesso muito amplo.
Acesso ao plano de dados
Há dois tipos de operações no Azure:
- Controle as operações do plano para gerenciar os recursos em sua assinatura.
- Operações de plano de dados para acessar recursos que um recurso expõe.
Por exemplo, você usaria uma operação de plano de controle para criar uma conta de armazenamento. Você usaria uma operação de plano de dados para se conectar à conta de armazenamento e acessar os dados que ela contém.
Ao bloquear o acesso direto do usuário aos seus recursos do Azure, considere também como essa restrição se aplica às operações do plano de dados. Por exemplo, seu processo de implantação pode armazenar a chave de uma conta de armazenamento em um local que um administrador possa acessar. Esse administrador poderia potencialmente usar a chave para contornar seus controles e acessar diretamente o plano de dados da conta de armazenamento.
Um número crescente de recursos do Azure dá suporte à configuração do controle de acesso do plano de dados usando a ID do Microsoft Entra. Esse suporte reduz a probabilidade de você vazar chaves ou conceder acesso ao plano de dados inadvertidamente. É uma boa prática usar o Microsoft Entra ID para acesso ao plano de dados sempre que puder.
Acesso de emergência
Às vezes, emergências acontecem e alguém precisa ter acesso rápido a um ambiente de produção para investigar ou resolver um problema. É importante planear e ensaiar como pretende responder a estas situações de emergência bem antes de elas ocorrerem. Você não quer ter que se esforçar para responder no meio de uma interrupção.
Uma abordagem a considerar é uma conta de vidro de quebra, que é uma conta de usuário especial que tem níveis mais altos de permissões do que os usuários normalmente têm. É chamada de conta quebra-vidro porque requer algo incomum para ter acesso à sua credencial, semelhante a quebrar o vidro em um painel de alarme de incêndio. Você pode fornecer uma maneira segura para seus operadores terem acesso às credenciais da conta de quebra-vidro. Esses operadores podem então entrar como a conta para realizar alterações de emergência.
A sequência de passos para usar uma conta de quebra-vidro é:
- O usuário tenta realizar uma alteração de emergência usando sua conta normal, mas a operação é bloqueada porque a conta de usuário normal não tem permissão suficiente.
- O usuário acessa as credenciais da conta de quebra-vidro e entra como esse usuário.
- O usuário (agindo como a conta de quebra-vidro) tem permissão para executar a operação.
O uso de contas quebra-vidro requer um alto nível de disciplina. A sua utilização deve ser reservada para verdadeiras situações de emergência. Gerencie e proteja cuidadosamente suas credenciais, porque a conta é altamente privilegiada. É uma boa prática alterar as credenciais de contas quebra-vidro com frequência, para minimizar a chance de que elas tenham sido expostas ou comprometidas.
As contas de quebra-vidro geralmente são compartilhadas dentro de uma equipe, por isso é difícil rastrear quem as usou e o que esses usuários fizeram. Uma abordagem alternativa para contas quebra-vidro é adotar o recurso Microsoft Entra Privileged Identity Management (PIM). Ele permite que a própria conta de um usuário receba temporariamente um nível mais alto de permissão.
A sequência de etapas para usar o PIM é:
O usuário tenta realizar uma alteração de emergência usando sua conta normal, mas a operação é bloqueada porque a conta de usuário normal não tem permissões suficientes.
O usuário entra em contato com o PIM e solicita uma elevação temporária de permissões.
O PIM pode executar uma validação adicional da identidade do usuário ou pedir a aprovação de alguém, dependendo de como ele está configurado para a organização.
Se a solicitação for autorizada, o PIM atualizará as permissões do usuário temporariamente.
O usuário tem permissão para executar a operação.
Após o período de tempo definido, o PIM revoga as permissões elevadas que concedeu ao usuário.
Tanto o PIM quanto o Azure gravam logs de auditoria abrangentes para ajudá-lo a entender quem solicitou permissões elevadas e por quê. Os logs também rastreiam o que eles fizeram em seu ambiente quando as permissões foram concedidas.
Nota
O PIM requer uma licença premium para o Microsoft Entra ID.
Após o fim da emergência
Após o fim de uma emergência, é importante ter um processo para voltar às operações normais. Você deve seguir esse processo antes que muito tempo tenha transcorrido, ou corre o risco de esquecer informações importantes ou deixar as configurações em um estado não seguro.
Analise cuidadosamente os logs de auditoria do Azure e do PIM para entender as alterações que foram executadas em seus ambientes controlados e, especialmente, em seu ambiente de produção.
Importante
Alguém que usa PIM ou uma conta de quebra-vidro pode ter a oportunidade de conceder à sua conta de usuário regular um acesso mais amplo do que deveria. Eles também podem usar as permissões temporárias para obter acesso a chaves de plano de dados que podem continuar a usar depois que suas permissões forem revogadas.
Audite cuidadosamente todo o uso de suas contas de quebra-vidro ou PIM. Revogue ou gire todas as chaves que possam ter sido expostas durante a emergência.
Logo após a emergência, ressincronize seus ativos de infraestrutura como código com quaisquer alterações feitas durante a emergência. Por exemplo, suponha que, como parte da resolução de um problema urgente, um administrador aumentou manualmente a SKU de um plano do Serviço de Aplicativo do Azure. Atualize seus modelos de implantação para incluir a nova SKU na configuração de recursos. Caso contrário, durante a próxima implantação regular do seu pipeline, a SKU pode ser redefinida para o valor anterior e causar outra interrupção.
Auditar alterações no seu ambiente do Azure
Também é uma boa prática configurar a auditoria e o registro em log em todo o ambiente do Azure e monitorar eventos ou ameaças específicos.
Considere o uso de uma ferramenta de gerenciamento de eventos e informações de segurança (SIEM), como o Microsoft Sentinel. Você pode usar essa ferramenta para coletar e analisar logs de seu patrimônio do Azure e até mesmo do Azure DevOps, GitHub e outros sistemas. Você pode usar o Sentinel para monitorar alterações inesperadas ou não autorizadas em seus recursos do Azure. Você também pode importar os logs de auditoria do pipeline e disparar alertas quando eventos acontecem, como quando um administrador altera uma política de proteção de ramificação em seu repositório.