Azure Security Glossary: Core Terms for a Hands-On PoC

The hardest part of a first Azure security lab is rarely finding the right button. It is knowing which boundary owns an identity, a resource, a policy, or an alert.

Azure security becomes much easier once the platform is separated into three connected areas:

Identity and access     -> Microsoft Entra
Resources and governance -> Azure Resource Manager
Detection and response -> Defender for Cloud + Microsoft Sentinel

This glossary condenses the terms that matter most before a hands-on proof of concept. AWS comparisons are included as learning aids, not as one-to-one service mappings.

1. Start with the boundaries

Microsoft Entra tenant and directory

A Microsoft Entra tenant is an independent identity boundary containing users, groups, devices, applications, and identity policies. In Azure portal language, directory usually refers to this same tenant from the perspective of its identity data.

A work or school account is an identity inside a tenant. It is not the same thing as an AWS account, which is primarily a resource and billing boundary.

Azure subscription

An Azure subscription is a billing and resource-management scope. It is also one of the scopes at which Azure roles can be assigned.

Every subscription trusts one Microsoft Entra tenant for identities. One tenant can supply identities to multiple subscriptions. That relationship is important because a tenant administrator does not automatically become an Owner of every subscription, and a subscription Owner does not automatically become a Global Administrator of the tenant.

Management group, resource group, and resource

The resource hierarchy is:

Management group
  -> Subscription
    -> Resource group
      -> Resource

• A management group applies governance and access decisions across subscriptions.
• A resource group collects resources that share a management purpose or lifecycle.
• A resource is an actual service instance such as a virtual machine, virtual network, Key Vault, or Log Analytics workspace.

A resource group is useful for lifecycle management, but it is not automatically a network or security isolation boundary.

2. Separate authentication from authorization

Authentication answers, “Who are you?” Authorization answers, “What are you allowed to do?”

Microsoft Entra ID can authenticate a user and issue a token. Azure role-based access control then decides whether that identity can read a storage account, restart a virtual machine, or modify a Key Vault.

This distinction leads to another important pair:

Control	What it manages	Typical role
Microsoft Entra role	Directory objects and identity configuration	User Administrator
Azure RBAC role	Azure resources at a defined scope	Reader, Contributor, Owner

An Azure role assignment is easiest to remember as:

security principal + role definition + scope

The scope can be a management group, subscription, resource group, or individual resource. Assign the narrowest role and scope that meet the task.

3. Protect sign-in and privileged access

Multifactor authentication

Multifactor authentication (MFA) requires two or more distinct verification factors. It is not simply asking for the same kind of secret twice, and it can include passwordless authentication methods.

Conditional Access

Conditional Access is Microsoft Entra’s Zero Trust policy engine. It evaluates signals such as the user, target resource, device, location, client, and risk, then decides whether to allow access, require a control such as MFA, restrict the session, or block access.

For a PoC, begin with a dedicated pilot group and report-only evaluation. Do not start with every user and every resource. An enforcement change should follow observed sign-in results, emergency access testing, and a documented rollback.

Privileged Identity Management

Privileged Identity Management (PIM) reduces standing administrative access. Eligible users can activate a privileged role only when needed, with controls such as a limited duration, justification, MFA, or approval where configured and licensed.

Emergency access account

An emergency access account, sometimes called a break-glass account, provides a recovery route when ordinary administrative sign-in fails. It should be cloud-only, tightly monitored, excluded from policies that could cause total lockout, and tested on a schedule rather than used for routine work.

4. Do not confuse governance with posture management

Azure Policy

Azure Policy evaluates resources against organizational standards. A policy definition describes a rule, an assignment applies it to a scope, and an effect determines whether Azure audits, denies, modifies, or deploys a required configuration.

Examples include auditing resources outside approved regions or denying public network exposure for a particular service. Azure Policy is closer to a combination of AWS Organizations service control policies and AWS Config than to either service alone.

Microsoft Defender for Cloud

Microsoft Defender for Cloud evaluates cloud security posture and, when the relevant plans are enabled, protects supported workloads. Its recommendations identify configuration and risk-reduction opportunities. They are not automatically proof of an active attack.

The Defender for Cloud secure score summarizes posture improvement opportunities. A higher score can guide remediation, but it does not prove that an environment is breach-free or that the highest-risk attack path has been removed.

The short version is:

Azure Policy            -> What configuration should be allowed or required?
Defender for Cloud      -> What posture risks and workload threats should we prioritize?

5. Follow the path from platform event to investigation

Activity Log, diagnostic setting, and DCR

The Azure Activity Log records subscription-level control-plane events, including administrative operations, Policy activity, service health, and resource health events.

A diagnostic setting routes supported platform logs and metrics to destinations such as Log Analytics, Storage, or Event Hubs. A data collection rule (DCR) defines supported collection pipelines, transformations, and destinations for sources such as Azure Monitor Agent and custom logs. The two mechanisms overlap in purpose but are not interchangeable.

Log Analytics workspace and KQL

A Log Analytics workspace stores and queries log data used by Azure Monitor and Microsoft Sentinel. Kusto Query Language (KQL) is the query language used to filter, correlate, summarize, and investigate that data.

AzureActivity
| where TimeGenerated > ago(1h)
| summarize Operations = count() by ActivityStatusValue

This example summarizes recent Activity Log records by status without exposing a real caller or resource identifier.

Microsoft Sentinel

Microsoft Sentinel is Microsoft’s cloud-native SIEM and security operations platform. It connects security data, runs detections, supports hunting and investigation, and coordinates response across cloud and on-premises sources.

The core detection flow is:

Data connector
  -> Log Analytics data
    -> Analytics rule
      -> Alert
        -> Incident

• An analytics rule evaluates data for suspicious conditions.
• An alert is an individual signal produced by a rule or connected security product.
• An incident groups related alerts and evidence into an investigation unit.
• An entity is a mapped user, host, IP address, file, or other object that analysts can investigate.

For response, an automation rule decides when supported incident or alert triggers should cause an action. A playbook is the response workflow, implemented with Azure Logic Apps. High-impact actions such as disabling an account should normally include explicit approval and rollback criteria in a learning PoC.

6. Prefer workload identity over stored secrets

A service principal is the local security principal that represents an application in a tenant. A managed identity is an Azure-managed identity for a resource, allowing that workload to request tokens without storing a client secret in code.

Azure Key Vault stores and controls access to secrets, cryptographic keys, and certificates. The preferred order is:

Use managed identity when possible
  -> grant only the required Key Vault access
    -> retrieve a secret at runtime only when a secret is unavoidable

Do not place credentials in Terraform state, Git history, pipeline logs, screenshots, or published lab evidence.

7. A careful AWS comparison

Azure concept	Closest AWS learning analogy	Important caveat
Microsoft Entra tenant	IAM Identity Center directory plus organization context	AWS has no identical single tenant object
Azure subscription	AWS account	Billing, identity trust, and hierarchy differ
Management group	Organizations OU	Policy and inheritance models differ
Resource group	Resource Groups, tags, and a stack	AWS has no identical mandatory parent container
Azure RBAC	IAM roles, policies, and permission sets	Evaluation and resource-policy models differ
Azure Policy	SCP plus AWS Config	Deny and audit responsibilities are split in AWS
Defender for Cloud	Security Hub CSPM, GuardDuty, Inspector, and related services	Azure combines posture and workload protection under one product family
Microsoft Sentinel	Security Lake, Security Hub, automation, and a SIEM	There is no single native one-to-one counterpart
Managed identity	Instance profile, task role, or Lambda execution role	Attachment and token flows are service-specific

These comparisons help transfer a mental model, but architecture decisions must follow each cloud’s actual permission and resource model.

8. Ten lines to remember

1. A tenant is an identity boundary; a subscription is a resource and billing scope.
2. A directory usually means the Entra tenant in portal context.
3. Microsoft Entra roles manage the directory; Azure roles manage Azure resources.
4. Authentication proves identity; authorization grants an allowed action.
5. Conditional Access evaluates sign-in signals; PIM reduces standing privilege.
6. Azure Policy evaluates standards; Defender for Cloud prioritizes posture and workload risk.
7. Activity Log records control-plane events; diagnostic settings and DCRs route supported telemetry.
8. Log Analytics stores queryable logs; KQL turns those logs into evidence.
9. Analytics rules produce alerts; related alerts can become an incident.
10. Automation rules orchestrate response; playbooks execute Logic Apps workflows.

A safe first PoC sequence

Confirm the correct tenant and subscription first. Then create bounded resource groups, tags, a budget, and audit-focused governance. Test identity policies with a pilot group and report-only mode. Establish a minimal log path before writing a KQL detection, and only then connect the detection to an incident and a reversible response workflow.

The goal is not to memorize product names. It is to explain which risk each control reduces, where it operates, and what evidence proves that it worked.

References

• How Azure subscriptions are associated with Microsoft Entra ID
• Microsoft Entra Conditional Access overview
• Azure role-based access control overview
• Azure Policy overview
• Defender for Cloud secure score
• Microsoft Sentinel overview