AZ-500: Microsoft Azure Security Technologies

Role-Based Access Control (RBAC) is the core permission system in Azure. Microsoft provides built-in role definitions such as Owner, Contributor, and Reader that define which actions an identity can perform. These roles are applied at scopes like a management group, subscription, resource group, or individual resource. Permissions inherit downward through the hierarchy, so a role assigned at the subscription level automatically applies to all nested resource groups and resources.

Enterprise applications in Microsoft Entra ID use OAuth permission grants to control how apps access protected data. There are two main types of permissions that serve different authorization purposes. Delegated permissions allow an application to act on behalf of a signed-in user, meaning the application can only access resources that the user themselves has permission to see. In contrast, application permissions let an application run with its own identity without any signed-in user context, which is the standard choice for background services or automated tasks. Delegated permissions can be approved by either users or administrators depending on the scope risk, while application permissions always require an administrator to grant consent.

To protect data as it travels over the internet, you must configure secure transport layer security (TLS) for services like Azure App Service and API Management. Administrators must set the minimum TLS version to TLS 1.2 or higher and disable older, insecure versions like TLS 1.0 and TLS 1.1. This configuration can be done through the Azure Portal or automated with the Azure CLI. Additionally, selecting modern, strong cipher suites for the connection further secures the channel against cryptographic attacks.

Azure Virtual Network Service Endpoints provide a secure way to connect your virtual network directly to supported Azure platform-as-a-service (PaaS) resources. They work by extending the identity of your virtual network and its subnets into the Azure service. Traffic between your virtual network and the service then flows over the secure Microsoft backbone network, bypassing the public internet entirely. This design keeps your traffic private, improves network security, and optimizes routing by following the most direct path within Azure's infrastructure.

Network Security Groups (NSGs) act as a stateful firewall for Azure resources, filtering traffic at either the subnet or NIC (network interface) level. Each NSG contains a set of inbound and outbound security rules. Every rule must include a priority number between 100 and 4096; rules are evaluated from lowest to highest priority, and once a match occurs, no further rules are processed. Because of this evaluation order, you should place explicit Deny rules at a lower priority than broad Allow rules to block specific traffic while permitting the general flow. Service tags simplify rule creation by representing a group of Azure service IP address prefixes, such as VirtualNetwork, Internet, or AzureLoadBalancer, so you do not need to manage changing IP ranges yourself. Using a "deny by default, permit by exception" model ensures that only explicitly allowed traffic passes through the NSG, reducing the risk of unintended access.

Microsoft Entra ID (formerly Azure Active Directory) provides a central way to manage who can access Azure SQL Database and Azure SQL Managed Instance. Instead of creating separate SQL logins for each user, organizations can connect their existing identity system to the database, which means users sign in with the same credentials they use for email and other Microsoft services. When a user authenticates through Entra ID, the database receives a token that proves their identity, and the database engine then checks what permissions that user has been granted. This approach reduces the number of passwords teams must manage and makes it easier to revoke access when someone leaves the organization, because the change happens in one central place rather than in every database. Database administrators grant permissions to Entra ID users or groups the same way they grant permissions to SQL logins, using standard SQL commands like GRANT and REVOKE.

Managing remote access to virtual machines requires minimizing public exposure while keeping administrative connections secure. Just-In-Time (JIT) VM access acts as a temporary gatekeeper, blocking management ports by default using Network Security Groups (NSGs). When an authorized user requests access, Azure modifies the NSG rules to open specific ports, such as 3389 for RDP, for a limited time window. To avoid exposing public IP addresses entirely, Azure Bastion provides secure access directly through the Azure Portal over SSL. Traffic flows from the user’s browser to a dedicated AzureBastionSubnet, which then proxies the connection to the target VM over its private IP.

Azure Storage offers two primary ways to control who can access data: Shared Key and Azure Active Directory (Azure AD). Shared Key access uses account keys that grant full administrative rights to the storage account—anyone with a key can read, write, and delete any data in the account. Azure AD integration ties access to user identities, allowing fine-grained permissions through Role-Based Access Control (RBAC), so administrators can assign specific roles like "Storage Blob Data Reader" to specific users or groups. When you enable Azure AD authentication for a storage account, requests must include a valid OAuth token, and the identity must have an RBAC role that permits the requested operation. The control plane (management operations like creating containers) and the data plane (reading/writing blobs) can each use different authentication methods, giving teams flexibility in how they secure different types of access.

Azure Policy is a governance service that enforces rules on Azure resources. A policy definition specifies a condition (for example, "resource must be in a specific region") and an effect (such as deny, audit, or append). Multiple policy definitions can be grouped into an initiative (also called a policy set) to enforce a broader compliance goal, like "ensure all resources meet security baseline." To apply a policy or initiative, you create an assignment at a management group, subscription, or resource group scope. The assignment evaluates existing resources and applies the effect to new resources during creation or update. When a resource violates a policy, Azure Policy can block the operation (deny), log the violation (audit), or add missing tags (append). You interpret compliance by viewing the policy's compliance state on the Azure portal or via Azure Resource Graph, which shows which resources are compliant, non-compliant, or excluded. The relationship between definition, initiative, and assignment is hierarchical: definitions are reusable, initiatives combine them, and assignments tie them to a scope.

Microsoft Defender for Cloud uses a feature called Secure Score to measure how well a cloud environment is protected. The score is calculated by checking security controls across subscriptions and resources, giving a percentage that shows the current security posture. Higher scores mean fewer vulnerabilities and better protection. The Inventory feature provides a complete list of all resources in Azure, AWS, or GCP, allowing security teams to see what exists and assess each item's security status.

Microsoft Defender for Cloud is a cloud-native security platform that protects Azure workloads from threats. To enable protection, you first enable Microsoft Defender for Cloud on your Azure subscription, which activates the security posture management capabilities. After enabling the core platform, you then enable individual workload protection plans such as Defender for Servers, Defender for Databases, and Defender for Storage. Each workload protection plan enables specific threat detection sensors and security alerts tailored to that workload type. The protection plans build on each other, so enabling the core Defender for Cloud is the first step before any workload-specific protection becomes active.

Microsoft Defender for Cloud generates security alerts when it detects potential threats to your Azure resources. These alerts appear in the Defender for Cloud portal and are prioritized by severity, helping you focus on the most critical issues first. The alert details explain what was detected, which resource is involved, and the potential impact, providing the context needed for investigation. Responding to an alert typically involves reviewing the evidence, taking remediation steps like isolating a compromised virtual machine, and then closing the alert to indicate the issue has been resolved.