[en-gb] ⚠️ Important Disclaimer!

1️⃣ Some time ago, I recorded a course on cloud security in Microsoft environments for a Brazilian university called IGTI. This course was part of a Cloud Computing bootcamp and helped many students who were just starting their careers in the field. (After the institution shut down, the content became unavailable.)

🎯 So, I decided to remaster, sanitize, and re-release this content for free on YouTube, with the goal of continuing to support those who are beginning their journey in Cloud and Cloud Security.

2️⃣ The original course is in Portuguese (pt-BR), but throughout the series I’ll also publish articles in English (en-US) so the content can reach more people — at least until the new courses in English are recorded and ready.

3️⃣ Important: this series is not certification prep and not a silver bullet. The goal here is to share structured knowledge, with a hands-on, accessible approach focused on:

Cloud beginners, Security enthusiasts, and Anyone looking to better understand how Azure actually handles security.

4️⃣ Microsoft has rebranded some of its products — for example, Azure Security Center is now Defender for Cloud, and Azure Active Directory is now Entra ID. Some lessons may still refer to the old names, but don’t worry — the core concepts, technical foundations, and functionalities remain the same. Focus on the architecture and principles being taught.

Hope you enjoy it! Big hug!

Gustavo Magella

🎬 Watch Episode #06 of 09 Now 🔗 Click here to watch on YouTube (And yes, hit that subscribe button. I’m watching… 👀)

[en-us] Beyond The Cloud – Spin-Off | Chapter 06: Cloud Governance in Azure

Hey, what’s up folks!? 🌹❤️🚀

Welcome to Chapter 06 of the Beyond The Cloud – Spin-Off series. It’s time to talk about something that makes many cloud engineers roll their eyes but secretly saves their jobs every day: Azure Governance.

We’re diving into Management Groups, Tags, Resource Locks, Azure Policy, and Blueprints. If you think this is boring admin stuff, wait until someone accidentally deletes your production environment because you skipped this chapter. 😉

🏗️ Azure Management Groups: Organizing Your Empire

Let’s start with a truth: as your cloud grows, so does the chaos. Management Groups are your hierarchical salvation.

Think of it as a family tree for your Azure resources:

Root Management Group
│
├── Marketing Group
│   ├── Social Media Sub
│   └── Content Creation Sub
│
└── IT Group
    ├── Development Sub
    └── Production Sub

These groups allow you to:

  • Apply policies at scale
  • Delegate access without losing sleep
  • Organize subscriptions logically
  • Inherit settings downward (the beauty of hierarchy)

The structure supports up to 6 levels deep (excluding root), giving you flexibility for even the most complex organizations.

Pro Tip: Design your hierarchy based on business units first, then refine by environment or geography. Start simple – you can always get more granular later.

🏷️ Azure Tags: When Names Aren’t Enough

Ever tried finding a specific VM among hundreds? Without tags, it’s like finding a needle in a digital haystack.

Tags are simple name-value pairs that make resources identifiable beyond their cryptic Azure-approved names:

Tag NameTag ValueOwnerMagellaDepartmentCloud TeamEnvironmentProductionCostCenterIT-12345

Key benefits:

  • Cost allocation: Track spending by team, project, or environment
  • Automation targeting: Run scripts against tagged resources
  • Lifecycle management: Find all “temporary” resources that somehow lived for 2 years
  • Access control: Apply permissions based on tags

Azure allows up to 50 tags per resource, so go wild – but stay consistent!

Real Talk: Create a tagging policy before you deploy. Trying to retroactively tag hundreds of resources is like organizing your garage after 10 years of throwing stuff in randomly. Not fun.

🔒 Resource Locks: The “Don’t Touch This” Button

Picture this: A new admin accidentally deletes your production SQL cluster with one click. Resource Locks are your insurance policy against “Oh crap” moments.

Two types of locks:

  • CannotDelete: Users can read and modify, but not delete
  • ReadOnly: Users can read, but not modify or delete

Apply them at three levels:

  • Subscription (the nuclear option)
  • Resource Group (ideal for production)
  • Individual Resource (targeted protection)

Remember – these locks override RBAC permissions. You could be God-Emperor Owner of the entire Azure universe, and you’d still be blocked by a lock.

Battle Story: I’ve seen clients lose production databases because someone thought “this SQL server doesn’t look important.” Five minutes to set up locks, weeks to recover data. Choose wisely.

📏 Azure Policy: Guardrails, Not Handcuffs

“Trust but verify” doesn’t work in the cloud. Azure Policy lets you enforce standards programmatically:

  • Restrict VM sizes to control costs
  • Ensure resources only deploy in approved regions
  • Require specific tags on all resources
  • Enforce encryption, backup, and security standards

The policy engine has different effects:

  • Deny: Blocks non-compliant deployments (strict but effective)
  • Audit: Flags violations without blocking (start here)
  • Append: Automatically adds properties like tags (incredibly useful)
  • Modify: Changes properties during creation (powerful but test carefully)
  • Disabled: Just reports what would happen (training wheels)

Pro Tips:

  1. Start with Audit before Deny
  2. Use initiative definitions (policy groups) even for single policies
  3. Apply at the highest scope possible (Management Group level is ideal)

📋 Azure Blueprints: Environment Templates on Steroids

Ever wished you could just click a button and deploy a compliant environment? That’s Blueprints.

Think of Blueprints as environment recipes with:

  • ARM templates for resources
  • Resource Groups with proper naming
  • Policy assignments baked in
  • RBAC assignments pre-configured
  • Built-in version control

Unlike ARM templates alone, Blueprints maintain relationships with deployed resources, track versions, and can be updated with controlled rollout.

Real Use Case: Create a “Standard Workload Environment” blueprint with networking, storage, key vault, and backup policies. Each new project gets a consistent, secure foundation with one click.

🪖 Practical Checklist

✅ Management Groups:

  • Design hierarchy before creating (sketch it out first)
  • Limit direct assignments at root level (that’s governance debt)
  • Don’t go crazy with depth – 3-4 levels is usually plenty (don’t turn it into inception)

✅ Tags:

  • Document your tagging schema (or nobody will follow it)
  • Consider auto-tagging with Azure Policy (humans forget)
  • Include at minimum: Owner, Environment, Project, CostCenter (the fab four)
  • Review untagged resources monthly (they multiply like rabbits)

✅ Resource Locks:

  • Always lock production RGs with CannotDelete (no excuses)
  • Lock critical infrastructure with ReadOnly (network, DNS, security)
  • Document your locks (or future you will curse past you)
  • Train your team on locks (or prepare for confused support tickets)

✅ Azure Policy:

  • Start with Audit mode (walk before you run)
  • Create custom initiatives for your compliance needs
  • Assign at Management Group level when possible (efficiency wins)
  • Review compliance state regularly (policies without review are just wishful thinking)

✅ Blueprints:

  • Version and document your blueprints
  • Test in non-production first (always)
  • Include governance artifacts (policies, RBAC, tags)
  • Update blueprints as standards evolve (they’re living documents)

📊 My Tech Two Cents

⭐ Management Groups are your org chart for Azure.
⭐ Tags are your search system when everything looks the same.
⭐ Resource Locks are your safety net when someone says “I’m just going to clean up a bit.”
⭐ Azure Policy is your automated security guard that never sleeps.
⭐ Blueprints are your easy button for consistent deployments.

Remember: Governance isn’t sexy until it saves your job. That day will come – be ready.

Next up: Chapter 07 – We’ll tackle the Cloud Adoption Framework, service lifecycle in Azure, and what “Cloud by Design” really means.

Much love and stay governance-compliant! 🌹❤️

Gustavo Magella

[pt-br] ⚠️ Um aviso importante!

1️⃣ Há um tempo, eu gravei um curso de segurança em nuvem focado em ambientes Microsoft para uma universidade brasileira chamada IGTI. Esse curso fazia parte de um bootcamp de Cloud Computing e, na época, ajudou muitos alunos que estavam começando suas jornadas na área. (Com o fechamento da instituição, o conteúdo acabou ficando indisponível.)

🎯 Sendo assim, resolvi remasterizar, sanitizar e re-lançar esse conteúdo gratuitamente no YouTube, com o objetivo de continuar ajudando quem está começando na área de Cloud e Cloud Security.

2️⃣ O curso original está em português (pt-BR), mas ao longo da série vou publicar também artigos em inglês (en-US), para que o conteúdo possa alcançar mais pessoas até que os novos cursos em inglês estejam gravados e disponíveis.

3️⃣ Importante: essa série não é preparatória para certificações e não é uma bala de prata. A proposta aqui é compartilhar conhecimento de forma estruturada, com uma pegada prática e acessível, voltada para:

Iniciantes em Cloud, Entusiastas de segurança, e quem busca entender melhor como o Azure trata segurança de verdade.

4️⃣ A Microsoft renomeou alguns de seus produtos — por exemplo, o Azure Security Center agora se chama Defender for Cloud, e o Azure Active Directory virou Entra ID. Em algumas aulas, os nomes antigos ainda aparecem, mas foquem nos conceitos e fundamentos técnicos, que continuam válidos e extremamente relevantes.

Espero que vocês gostem! Um forte Abraço!

Gustavo Magella

🎬 Assista o Capítulo 06 🔗 Assista agora no YouTube (E se inscreve no canal, senão vou saber que você pulou essa parte… rs)

[pt-br] Beyond The Cloud – Spin-Off | Capítulo 06: Governança no Azure

E aí seus trens bonitows!? 🌹❤️🚀

Seja bem-vindo ao Capítulo 06 da série Beyond The Cloud – Spin-Off. Hoje vamos falar sobre algo que faz muitos engenheiros de nuvem revirarem os olhos, mas que secretamente salva o emprego deles todos os dias: Governança no Azure.

Vamos mergulhar em Management Groups, Tags, Resource Locks, Azure Policy e Blueprints. Se você acha que isso é papo chato de administrador, espere até alguém deletar acidentalmente seu ambiente de produção porque você pulou este capítulo. 😉

🏗️ Azure Management Groups: Organizando seu Império

Vamos começar com uma verdade: conforme sua nuvem cresce, o caos também cresce. Management Groups são sua salvação hierárquica.

Pense nisso como uma árvore genealógica para seus recursos no Azure:

Root Management Group
│
├── Grupo de Marketing
│   ├── Subscription de Mídias Sociais
│   └── Subscription de Criação de Conteúdo
│
└── Grupo de TI
    ├── Subscription de Desenvolvimento
    └── Subscription de Produção

Esses grupos permitem:

  • Aplicar políticas em escala
  • Delegar acesso sem perder o sono
  • Organizar subscriptions de forma lógica
  • Herdar configurações de cima para baixo (a beleza da hierarquia)

A estrutura suporta até 6 níveis de profundidade (excluindo o root), dando flexibilidade até para as organizações mais complexas.

Dica Pro: Projete sua hierarquia baseada em unidades de negócio primeiro, depois refine por ambiente ou geografia. Comece simples – você sempre pode ficar mais granular depois.

🏷️ Azure Tags: Quando Nomes Não São Suficientes

Já tentou encontrar uma VM específica entre centenas? Sem tags, é como procurar agulha em palheiro digital.

Tags são pares simples de nome-valor que tornam os recursos identificáveis além dos seus nomes criptografados aprovados pelo Azure:

Nome da TagValor da Tag
ProprietárioMagella
DepartamentoTime de Cloud
AmbienteProdução
CentroDeCustoTI-12345

Benefícios principais:

  • Alocação de custos: Rastreie gastos por time, projeto ou ambiente
  • Alvo de automação: Execute scripts contra recursos com tags específicas
  • Gerenciamento de ciclo de vida: Encontre todos os recursos “temporários” que de alguma forma viveram por 2 anos
  • Controle de acesso: Aplique permissões baseadas em tags

O Azure permite até 50 tags por recurso, então vai fundo – mas mantenha a consistência!

Papo Reto: Crie uma política de tagging antes de implantar. Tentar taguear retroativamente centenas de recursos é como organizar sua garagem depois de 10 anos jogando coisas aleatoriamente lá dentro. Não é divertido.

🔒 Resource Locks: O Botão “Não Toque Nisso”

Imagine isso: Um novo administrador exclui acidentalmente seu cluster SQL de produção com um clique. Resource Locks são sua apólice de seguro contra momentos “Eita p#%@“.

Dois tipos de locks:

  • CannotDelete: Usuários podem ler e modificar, mas não excluir
  • ReadOnly: Usuários podem ler, mas não modificar nem excluir

Aplique-os em três níveis:

  • Subscription (a opção nuclear)
  • Resource Group (ideal para produção)
  • Recurso Individual (proteção direcionada)

Lembre-se – esses locks substituem permissões RBAC. Você pode ser o Dono Todo-Poderoso do universo Azure inteiro, e ainda assim seria bloqueado por um lock.

Caso de Guerra: Já vi clientes perderem bancos de dados de produção porque alguém pensou “esse servidor SQL não parece importante”. Cinco minutos para configurar locks, semanas para recuperar dados. Escolha sabiamente.

📏 Azure Policy: Trilhos de Proteção, Não Algemas

“Confie, mas verifique” não funciona na nuvem. O Azure Policy permite impor padrões programaticamente:

  • Restringir tamanhos de VM para controlar custos
  • Garantir que recursos sejam implantados apenas em regiões aprovadas
  • Exigir tags específicas em todos os recursos
  • Impor criptografia, backup e padrões de segurança

O motor de política tem efeitos diferentes:

  • Deny: Bloqueia implantações não conformes (rígido, mas eficaz)
  • Audit: Sinaliza violações sem bloquear (comece por aqui)
  • Append: Adiciona automaticamente propriedades como tags (incrivelmente útil)
  • Modify: Altera propriedades durante a criação (poderoso, mas teste cuidadosamente)
  • Disabled: Apenas relata o que aconteceria (rodinhas de treinamento)

Dicas Pro:

  1. Comece com Audit antes de Deny
  2. Use definições de iniciativa (grupos de políticas) mesmo para políticas únicas
  3. Aplique no escopo mais alto possível (nível de Management Group é ideal)

📋 Azure Blueprints: Templates de Ambiente com Esteroides

Já desejou poder simplesmente clicar em um botão e implantar um ambiente em conformidade? Isso são os Blueprints.

Pense nos Blueprints como receitas de ambiente com:

  • Templates ARM para recursos
  • Resource Groups com nomenclatura adequada
  • Atribuições de política incorporadas
  • Atribuições RBAC pré-configuradas
  • Controle de versão integrado

Diferente dos templates ARM sozinhos, os Blueprints mantêm relacionamentos com recursos implantados, controlam versões e podem ser atualizados com implantação controlada.

Caso de Uso Real: Crie um blueprint de “Ambiente de Carga de Trabalho Padrão” com rede, armazenamento, key vault e políticas de backup. Cada novo projeto recebe uma base consistente e segura com um clique.

🪖 Checklist Rápido

✅ Management Groups:

  • Projete a hierarquia antes de criar (faça um esboço primeiro)
  • Limite atribuições diretas no nível raiz (isso é dívida de governança)
  • Não exagere na profundidade – 3-4 níveis geralmente são suficientes (não transforme isso em inception)

✅ Tags:

  • Documente seu esquema de tagging (ou ninguém vai seguir)
  • Considere auto-tagging com Azure Policy (humanos esquecem)
  • Inclua no mínimo: Proprietário, Ambiente, Projeto, CentroDeCusto (os quatro fantásticos)
  • Revise recursos sem tag mensalmente (eles se multiplicam como coelhos)

✅ Resource Locks:

  • Sempre bloqueie RGs de produção com CannotDelete (sem desculpas)
  • Bloqueie infraestrutura crítica com ReadOnly (rede, DNS, segurança)
  • Documente seus locks (ou o você do futuro vai amaldiçoar o você do passado)
  • Treine sua equipe sobre locks (ou prepare-se para tickets de suporte confusos)

✅ Azure Policy:

  • Comece com modo Audit (ande antes de correr)
  • Crie iniciativas personalizadas para suas necessidades de conformidade
  • Atribua no nível Management Group quando possível (eficiência ganha)
  • Revise o estado de conformidade regularmente (políticas sem revisão são apenas pensamento positivo)

✅ Blueprints:

  • Versione e documente seus blueprints
  • Teste em não-produção primeiro (sempre)
  • Inclua artefatos de governança (políticas, RBAC, tags)
  • Atualize blueprints conforme os padrões evoluem (são documentos vivos)

📊 My Tech Two Cents

⭐ Management Groups são seu organograma para o Azure.
⭐ Tags são seu sistema de busca quando tudo parece igual.
⭐ Resource Locks são sua rede de segurança quando alguém diz “vou só dar uma arrumadinha.”
⭐ Azure Policy é seu segurança automatizado que nunca dorme.
⭐ Blueprints são seu botão fácil para implantações consistentes.

Lembre-se: Governança não é sexy (até salvar seu emprego – hahahaha). Esse dia vai chegar – esteja preparado.

No próximo capítulo: Capítulo 07 – Vamos abordar o Cloud Adoption Framework, ciclo de vida de serviços no Azure e o que “Cloud by Design” realmente significa.

Um bjo no coração e mantenha-se em conformidade com a governança! 🌹❤️

Gustavo Magella

Categorized in:

My Tech Two Cents,

Tagged in:

,