Proteger 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 ambientes controlados. Nesta unidade, você aprende a estruturar as permissões dos usuários para ambientes do Azure. Isso inclui como permitir acesso em situações de emergência e como auditar as alterações ocorridas em seus ativos do Azure.
Bloquear o acesso humano
Ao bloquear o acesso humano aos seus ambientes controlados, você garante que as alterações acidentais ou mal-intencionadas 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á contornar inadvertidamente os controles que você gastou tanto tempo planejando e implementando em todo o repositório e nos pipelines.
Sem bloquear controles, também fica fácil de alguém cometer erros acidentais. Por exemplo, suponha que um usuário tenha duas cópias do portal do Azure abertas. Uma é para um ambiente de teste e a outra é para o ambiente de produção. Ao alternar entre as guias do navegador, o usuário pode facilmente se enganar e aplicar alterações do ambiente de teste em produção, ou vice-versa.
Para bloquear o acesso de pessoas, 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ções internas, incluindo:
- Leitor, que tem acesso somente leitura ao ambiente.
- Colaborador, que pode modificar recursos.
- Proprietário, que pode modificar recursos e conceder acesso aos demais.
É importante conceder acesso em um escopo apropriado. Se sua organização seguir a prática recomendada de usar assinaturas do Azure dedicadas 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 apenas uma assinatura do Azure para todos os ambientes, evite conceder a pessoas acesso a toda a assinatura, pois todos os recursos, incluindo seus ambientes controlados, herdarão essa permissão.
Dica
As atribuições de função são recursos do ARM (Azure Resource Manager). Isso significa que você pode configurar suas atribuições de função RBAC do Azure no código, como usando o Bicep.
Quando você planeja suas atribuições de função, 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 de Leitor aos ambientes controlados. Com essa função, eles podem acessar o ambiente de produção dentro do portal do Azure para examinar a configuração dos recursos, exibir métricas e logs e investigar problemas ou bugs sem fazer nenhuma alteração 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 controle | Permissão de administrador | Permissão do desenvolvedor |
|---|---|---|---|
| Desenvolvimento | Controlado | Leitor | Leitor |
| Teste | Controlado | Leitor | Leitor |
| Staging | Controlado | Leitor | Leitor |
| Produção | Controlado | Leitor | Leitor |
| Demonstração | Não controlado | Proprietário | Colaborador |
| Testes de desempenho | Não controlado | Proprietário | Nenhum |
| Teste de penetração | Não controlado | Proprietário | Nenhum |
| Revisões de PR | Não controlado | Proprietário | Proprietário |
| Áreas restritas de desenvolvimento | Não controlado | Proprietário | Proprietário |
Ao planejar suas atribuições de função, não deixe de testá-las por completo. À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. Examine todos os problemas que eles enfrentam.
Audite suas atribuições de função regularmente. Verifique se você não concedeu acidentalmente acesso às pessoas erradas ou concedeu acesso muito amplo.
Acesso ao plano de dados
Existem dois tipos de operações no Azure:
- Operações do painel de controle, usadas para gerenciar os recursos da sua assinatura.
- Operações do plano de dados, usadas para acessar as características expostas por um recurso.
Por exemplo, você usaria uma operação de painel 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 recursos do Azure, considere também como essa restrição se aplica às operações do plano de dados. Por exemplo, o processo de implantação pode armazenar a chave de uma conta de armazenamento em um local que um administrador pode 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 por meio do Microsoft Entra ID.. Esse suporte reduz a probabilidade de você vazar chaves ou conceder acesso ao plano de dados inadvertidamente. Uma prática recomendada é usar o Microsoft Entra ID para acesso ao plano de dados sempre que possível.
Acesso de emergência
Às vezes, ocorrem emergências e alguém precisa rapidamente ter acesso a um ambiente de produção para investigar ou resolver um problema. É importante planejar e ensaiar como você deseja responder a essas situações de emergência bem antes que elas ocorram. Você não vai querer ter dificuldade para reagir em meio a uma interrupção.
Uma abordagem a ser considerada é uma conta de emergência, que é uma conta de usuário especial com níveis mais altos de permissões do que os demais usuários. Ela é chamada de conta de emergência, pois exige uma ação incomum para obter acesso às suas credenciais, semelhante à quebra do vidro em um painel de alarme de incêndio em caso de emergência. Você pode fornecer uma forma segura para seus operadores obterem acesso às credenciais da conta de emergência. Esses operadores podem entrar como a conta de emergência para executar alterações emergenciais.
A sequência de etapas para usar uma conta de emergência é:
- O usuário tenta executar 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 emergência e entra como esse usuário.
- O usuário (atuando já na conta de emergência) tem permissão para executar a operação necessária.
O uso de contas de emergência exige um elevado nível de disciplina. Deve ocorrer somente em situações reais de emergência. Gerencie e proteja cuidadosamente suas credenciais, pois a conta é altamente privilegiada. É uma boa prática alterar as credenciais da conta de emergência com frequência, para minimizar a chance de que elas tenham sido expostas ou comprometidas.
As contas de emergência geralmente são compartilhadas com uma equipe, portanto, é difícil rastrear quem as usou e o que esses usuários fizeram. Uma abordagem alternativa às contas de emergência é adotar o recurso Microsoft Privileged Identity Management (PIM). Ele permite que a própria conta do usuário receba temporariamente um nível de permissões mais elevado.
A sequência de etapas para usar o PIM é:
O usuário tenta executar 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 validação adicional da identidade do usuário ou solicitar aprovação de alguém, dependendo de como ele foi configurado para cada organização.
Se a solicitação for autorizada, o PIM atualizará temporariamente as permissões do usuário.
O usuário tem permissão para executar a operação.
Depois que o período definido tiver decorrido, o PIM revogará as permissões elevadas concedidas ao usuário.
O PIM e o Azure gravam logs de auditoria abrangentes para ajudar você a entender quem solicitou permissões elevadas e por quê. Os logs também controlam o que essas pessoas fizeram em seu ambiente quando as permissões foram concedidas.
Observação
O PIM requer uma licença premium do Microsoft Entra ID.
Após o término da emergência
Após o término da emergência, é importante ter um processo para retornar às operações normais. Siga esse processo o quanto antes, ou você correrá o risco de esquecer informações importantes ou deixar a configuração em um estado não seguro.
Examine cuidadosamente os logs de auditoria do Azure e do PIM para entender as alterações executadas em seus ambientes controlados e, especialmente, o ambiente de produção.
Importante
Alguém que usa o PIM ou uma conta de emergência pode ter a oportunidade de conceder à sua conta de usuário regular acesso mais amplo do que deveria. Eles também podem usar as permissões temporárias para obter acesso às chaves do painel de dados, que poderão continuar sendo usadas mesmo depois que as permissões temporárias forem revogadas.
Audite cuidadosamente todo o uso de suas contas de emergência ou PIM. Revogue ou rotacione 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 eventuais alterações que tenham sido feitas durante a emergência. Por exemplo, suponha que, como parte da resolução de um problema urgente, um administrador tenha aumentado manualmente a SKU de um plano 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 pipeline, a SKU poderá ser redefinida para o valor anterior e causar outra interrupção.
Auditar alterações no ambiente do Azure
Também é uma boa prática configurar a auditoria e o log em todo o ambiente do Azure e monitorar eventos ou ameaças específicos.
Considere usar uma ferramenta de SIEM (gerenciamento de eventos e informações de segurança), como o Microsoft Sentinel. Você pode usar essa ferramenta para coletar e analisar logs de deus ativos do Azure e até mesmo Azure DevOps, do GitHub e de 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 branch em seu repositório.