Skip to content

Identity - Security - Governance

Microsoft Entra ID

Microsoft Entra ID is a cloud-based identity and access management service that enables your employees access external resources. Example resources include Microsoft 365, the Azure portal, and thousands of other SaaS applications.

Though they once shared a similar name, Microsoft Entra ID is not a cloud version of Windows Server Active Directory. It's also not intended as a complete replacement for an on-premises Active Directory.

Instead, if you're already using a Windows AD server, you can connect it to Microsoft Entra ID to extend your directory into Azure. This approach allows users to use the same credentials to access local and cloud-based resources.

Directories, subscriptions, and users

Microsoft offers several cloud-based offerings today, all of which can use Microsoft Entra ID to identify users and control access: Microsoft Azure, Microsoft 365, Microsoft Dynamics 365 ...
When a company or organization signs up to use one of these offerings, they're assigned a default directory, an instance of Microsoft Entra ID.

This directory holds the users and groups that will have access to each of the services the company has purchased.
You can refer to this default directory as a tenant. A tenant represents the organization and the default directory assigned to it.

An organization (tenant) has one associated default Microsoft Entra directory. However, owners can create additional directories.

A subscription in Azure is both a billing entity and a security boundary. Resources such as virtual machines, websites, and databases are associated with a single subscription.
Each subscription also has a single account owner responsible for any charges incurred by resources in that subscription.

A subscription is associated with a single Microsoft Entra directory. Multiple subscriptions can trust the same directory, but a subscription can only trust one directory.

Design IAM - Azure Active Directory

Azure AD is the Azure solution for identity and access management. Azure AD is a multitenant, cloud-based directory and identity management service.

It combines core directory services, application access management and identity protection into a single solution. Azure AD can be used in cloud or hybrid environments.

You can implement Azure AD as a cloud-only identity solution that provides both identity management and protection for your accounts, including role-based access control (RBAC), conditional access and access reviews.

Azure AD also offers a hybrid identity solution for identity management. In hybrid environments, Azure AD extends on-premises Active Directory to the cloud.

AD Tenant

Global Administrator role is required to manage all aspects of Azure AD and Ms services that use AD identities.
This role can manage groups across tenants and assign other administrator roles.

User administrators role can also manage some of Azure AD. But It cannot assign admin roles.

Use Azure AD roles to manage Azure AD-related resources like users, groups, billing, licensing, application registration and more.

  • User : Represents a staff member, uses credentials.
    • Three types of user account : cloud , directory-synchronized and guests user/identity.
  • Application : Represents an app in use within the tenant, uses a secret token or certificate for authentification, can include apps running in Azure or elsewhere.
  • Managed Identity : Represents a service within the Azure subscription, leverages the Azure platform for authentification, only supports services running in Azure.
    • Azure managed identity is a feature of Azure AD that you can use free of charge. Its automatically creates identities to allow apps to authenticate with Azure resources and services.

You can add individual user accounts through the Azure portal, Azure PowerShell, or the Azure CLI.

When you use the Bulk create users operation, you must specify four things : displayName, userPrincipalName, passwordProfile and accountEnabled.

When you delete a user, the account remains in a suspended state for 30 days. During that 30-day window, the user account can be restored.

The AD supports two key types of group memberships

  • Assigned : Group admin/owner determine memberships.
  • Dynamic : User/device attributes determine membership.
    • Only users who are assigned an Azure P1 license can be a member of a dynamic group.

External identities help to provide customers and parteners with access to resources.

AD B2B

  • Supported External Partner Identities : Work/school accounts, Gmail, SAML...
  • Partner Users invited as Guests : Provides seamless, licenses access to resources.
  • Similar to Normal user Accounts : Partners users are discoverable and can be managed by access reviews.

AD B2C

  • B2C Tenant : Identity information is stored whithin a dedicated B2C tenant.
  • Supported Identities : Social Identities, SAML, local ...
  • Self-Managed users : users are self-managed and private and branding can be customized.

Azure AD Connect

  • Identity Sycnhronization : Sycnhronize identities facilitates SSO for accessing resources.
  • Authentification Management : AD Connect can alter where authentifcation occurs.
  • AD Connect Methods : AD Connect Sync & AD Connect cloud sync.

Things to consider when using Azure AD identity management

  • Consider benefits of centralized identity management. (Microsoft recommended) Integrate your on-premises and cloud directories when you're working in a hybrid identity scenario.
  • Consider using a single Azure AD instance. Use a single authoritative source and consistency to increase clarity and reduce security risks from human errors and configuration complexity.

  • Consider limiting account synchronization. Don't synchronize accounts to Active Directory that have high privileges in your existing Azure AD.

    • By default, Azure AD Connect filters out these high privileged accounts. This configuration mitigates the risk of adversaries pivoting from cloud to on-premises assets.

  • Consider password hash synchronization. Enable password hash synchronization to sync user password hashes from an on-premises Azure AD instance to a cloud-based Azure AD instance.

  • Consider single sign-on (SSO). Enable SSO to reduce the need for multiple passwords.
  • Consider overhead of managing separate identities.

Azure Active Directory SSPR

SSPR

The Azure Active Directory self-service password reset (SSPR) feature lets you give users the ability to bypass helpdesk and reset their own passwords.

In Azure AD, any user can change their password if they're already signed in. But if they're not signed in and forgot their password or it's expired, they'll need to reset their password.

Examine the following characteristics and requirements of the SSPR features :

  • SSPR requires an Azure AD account with Global Administrator privileges to manage SSPR options.
  • SSPR uses a security group to limit the users who have SSPR privileges.
  • All user accounts in your organization must have a valid license (P1/P2) to use SSPR.

To ensure that users can reset their AD DS password from the Azure portal :

  • Run Azure AD Connect and select Password writeback.
  • From Password reset in the Azure portal, configure the Authentication methods settings.
    • A user is considered registered for SSPR when they've registered at least the number of methods that you've required to reset a password.

Active Directory DS VS Azure AD

Active Directory Domain Services (AD DS) is the traditional deployment of Windows Server-based Active Directory on a physical or virtual server.

AD DS is commonly considered to be primarily a directory service, but it's only one component of the Windows Active Directory suite of technologies.
The suite also includes Active Directory Certificate Services (AD CS)/Lightweight Directory Services (AD LS)/Federation Services (AD FS) / Rights Management Services (AD RMS).

Although you can deploy and manage AD DS in Azure VM, MS recommend you use Azure Active Directory, unless your configuration targets IaaS workloads that depend specifically on AD DS.

Things to consider when using Azure AD rather than AD DS

Azure AD is similar to AD DS, but there are significant differences.
Consider the following characteristics that distinguish Azure AD from AD DS.

* Identity solution : AD DS is primarily **a directory service**, while Azure AD is **a full identity solution**.
    * Azure AD is designed for internet-based applications that use HTTP and HTTPS communications.

* REST API queries : AD DS supports LDAP.
    * Azure AD tenants can't be queried by using LDAP, It uses the REST API over HTTP(S).

* Communication protocols : Because Azure AD is based on HTTP(S), **it doesn't use Kerberos authentication**.
    * Azure AD implements HTTP(S) protocols such as SAML, WS-Federation and OpenID Connect for authentication (and OAuth for authorization).
    *  **AD DS supports Kerberos authentification**.

* Federation services : Azure AD includes federation services and many third-party services like Facebook.

* Flat structure : Azure AD users and groups are created in a flat structure. There are no organizational units (OUs) or group policy objects (GPOs).

* Managed service : Azure AD is a managed service. You manage only users, groups and policies.
    * If you deploy AD DS with virtual machines by using Azure, you manage many other tasks configuration/patching...

Design Governance

The term governance describes the general process of establishing rules and policies and ensuring that those rules and policies are enforced.
When running in the cloud, a good governance strategy helps you maintain control over the applications and resources that you manage in the cloud.

Governance is most beneficial when you have :

  • Multiple engineering teams working in Azure.
  • Multiple subscriptions to manage.
  • Regulatory requirements that must be enforced.
  • Standards that must be followed for all cloud resources.

The five disciplines of Cloud Governance.

  • Cost Management.
  • Security Baseline.
  • Resource Consistency.
  • Identity Baseline.
  • Deployment Acceleration.

Organizing Azure Resources

Resource Hierachy : Management groups > Subscriptions > Resource Groups > Resource

Resource - RG - RM

  • Resources : A manageable item that's available through Azure. VM, Storage accounts, SQL data are examples of resources.

  • Resource groups act as a logical container into which Azure resources like web apps and storage accounts are deployed and managed.

  • All resources must be in a resource group and a resource can only be a member of a single resource group.

  • Resource Groups cannot be renamed, nested.
  • Resource Groups can have resources from many different regions.
  • Resource can be moved from one resource group to another group/subscription/region.
    • When moving resources, both the source group and the target group are locked during the operation.
    • Write and delete operations are blocked on the resource groups until the move completes.
  • If you delete a resource group, all resources contained within it are also deleted.

Things to consider when creating resource groups

  • Consider group by department, group by location and group by billing. Review other grouping strategies that aren't common but might be useful in your situation.
  • Consider a combination of organizational strategies.
  • Consider resource life cycle. Design your resource groups according to life cycle requirements.
  • Consider administration overhead. Include overhead planning in your strategy. How many resource groups would you like to manage?
  • Consider resource access control. Implement access control for your resource groups. At the resource group level, you can assign Azure policies, Azure roles and resource locks
  • Consider compliance requirements. Do you need to ensure your resource group metadata is stored in a particular region?

Azure Resource Manager

Azure Resource Manager (ARM) is the deployment and management service for Azure. It provides a management layer that enables you to create, update and delete resources in your Azure account.
You use management features like access control, locks and tags to secure and organize your resources after deployment.

When a user sends a request from any of the Azure tools, APIs or SDKs, ARM receives the request. It authenticates and authorizes the request. ARM sends the request to the Azure service which takes the requested action.

With Resource Manager, You can

  • Manage your infrastructure through declarative templates rather than scripts. A ARM template is a JSON file that defines what you want to deploy to Azure.
  • Deploy, manage and monitor all the resources for your solution as a group, rather than handling these resources individually.

  • Redeploy your solution throughout the development life cycle and have confidence your resources are deployed in a consistent state.

  • Define the dependencies between resources so they're deployed in the correct order.

  • Apply access control to all services because RBAC is natively integrated into the management platform.
  • Apply tags to resources to logically organize all the resources in your subscription.
  • Clarify your organization's billing by viewing costs for a group of resources that share the same tag.

Azure Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety and support for code reuse.
You can use Bicep instead of JSON to develop your ARM templates. Bicep is a transparent abstraction over ARM template JSON and doesn't lose any of the JSON template capabilities.

Bicep provides many improvements over JSON for template authoring, including :

  • Simpler syntax : Bicep provides a simpler syntax for writing templates. You can reference parameters and variables directly, without using complicated functions.
  • Modules : You can break down complex template deployments into smaller module files and reference them in a main template.
  • Automatic dependency management : In most situations, Bicep automatically detects dependencies between your resources.
  • Type validation and IntelliSense : The Bicep extension for Visual Studio Code features rich validation and IntelliSense for all Azure resource type API definitions

Azure Quickstart Templates are Azure Resource Manager templates provided by the Azure community.

Subscriptions - Management Groups

Subscriptions

A logical unit of Azure services that links to an Azure account.
An account can have one subscription or multiple subscriptions that have different billing models and to which you apply different access-management policies.

There are two types of subscription boundaries that you can use :

  • Billing boundary : This subscription type determines how an Azure account is billed for using Azure. You can create multiple subscriptions for different types of billing requirements.
    • Azure generates separate billing reports and invoices for each subscription so that you can organize and manage costs.
  • Access control boundary : Azure applies access-management policies at the subscription level and you can create separate subscriptions to reflect different organizational structures.

You might want to create additional subscriptions for resource or billing management purposes. For example, you might choose to create additional subscriptions to separate :

  • Environments : When managing your resources, you can choose to create subscriptions to set up separate environments for development and testing, security or to isolate data for compliance reasons.
  • Organizational structures : You can create subscriptions to reflect different organizational structures.
  • Billing : You might want to also create additional subscriptions for billing purposes.
  • Subscription limits : Subscriptions are bound to some hard limitations. Exthe max number of Azure ExpressRoute circuits per subscription is 10.

Things to consider when creating subscriptions

  • Treat subscriptions as a democratized unit of management.

  • Group subscriptions together under management groups.

  • Consider a dedicated shared services subscription. Use a shared services subscription to ensure all common network resources are billed together and isolated from other workloads.

  • Consider subscription scale limits. Subscriptions serve as a scale unit for component workloads. Large, specialized workloads like high-performance computing, IoT and SAP are all better suited to use separate subscriptions.

  • Consider administrative management. Subscriptions provide a management boundary, which allows for a clear separation of concerns.

  • Consider how to assign Azure policies. Both management groups and subscriptions serve as a boundary for the assignment of Azure policies.

  • Consider network topologies. Virtual networks can't be shared across subscriptions. Resources can connect across subscriptions with different technologies, such as VNet Peering or VPNs.

  • Consider making subscription owners aware of their roles and responsibilities. Conduct a quarterly or biannual access review by using Azure AD Privileged Identity Management.

Management Groups

If your organization has many subscriptions, you might need a way to efficiently manage access, policies and compliance for those subscriptions. Azure management groups provide a level of scope above subscriptions.
You organize subscriptions into containers called management groups and apply your governance conditions to the management groups.

All subscriptions within a single management group must trust the same Azure AD tenant.

Important facts about management groups :

  • 10,000 management groups can be supported in a single directory.
  • A management group tree can support up to six levels of depth. This limit doesn't include the root level or the subscription level.
  • Each management group and subscription can support only one parent.
  • Each management group can have many children.
  • All subscriptions and management groups are within a single hierarchy in each directory.

Azure Blueprints

Govern multiple subscriptions by using Azure Blueprints

What happens when your cloud environment starts to grow beyond just one subscription?
How can you scale the configuration of these features, knowing they need to be enforced for resources in new subscriptions?

Instead of having to configure features like Azure Policy for each new subscription with Azure Blueprints you can define a repeatable set of governance tools and standard Azure resources that your organization requires.
Azure Blueprints orchestrates the deployment of various resource templates and other artifacts, such as :

  • Role assignments.
  • Policy assignments.
  • Azure Resource Manager templates.
  • Resource groups.

Azure Blueprints in action

Implementing a blueprint in Azure Blueprints involves these three steps:

  1. Create an Azure blueprint.
  2. Assign the blueprint.
  3. Track the blueprint assignment.

With Azure Blueprints, the relationship between the blueprint definition (what should be deployed) and the blueprint assignment (what was deployed) is preserved.
Blueprints are also versioned. Versioning enables you to track and comment on changes to your blueprint.

What are blueprint artifacts?

Each component in the blueprint definition is known as an artifact.
It is possible for artifacts to have no additional parameters (configurations).

A blueprint is composed of different artifacts. When you begin designing your blueprint, you need to specify artifacts and their related parameters. Below are the artifacts from a blueprint.

  • The RBAC that will be applied.
  • The Azure policies that you would like to create to enforce business rules.
  • The Resource groups that will be created to store the Azure resources.
  • The ARM template you would like to deploy in order to automate resource creation.

Blueprint definition locations

When creating a blueprint definition, you'll define where the blueprint is saved. Blueprints can be saved to a management group or subscription.
If the location is a management group, the blueprint is available to assign to any child subscription of that management group.

Azure Tags

Organize resources by using Azure Tags

One way to organize related resources is to place them in their own subscriptions. You can also use resource groups to manage related resources.

Resource tags are another way to organize resources. Tags provide extra information or metadata about your resources.
A resource or resource group can have a maximum of 50 tag name/value pairs.

This metadata is useful for

  • Resource management Tags enable you to locate and act on resources that are associated with specific workloads, environments, business units and owners.
  • Cost management and optimization Tags enable you to group resources so that you can report on costs, allocate internal cost centers, track budgets.

  • Security Tags enable you to classify data by its security level, such as public or confidential.

  • Operations management Tags enable you to group resources according to how critical their availability is to your business.

  • Workload optimization and automation Tags can help you visualize all of the resources that participate in complex deployments.
  • Governance and regulatory compliance Tags enable you to identify resources that align with governance or regulatory compliance requirements.

When you apply tags to a resource group, those tags aren't automatically applied to the resources within that resource group.
You can use Azure Policy to ensure that a resource inherits the same tags as its parent resource group.

Azure RBAC

Securing Access by using Azure RBAC

Role-based access control (RBAC) is a mechanism that can help you manage who can access your Azure resources.
It lets you determine what operations specific users can do on specific resources and control what areas of a resource each user can access.

RBAC is an authorization system built on Azure Resource Manager and provides fine-grained access management of resources in Azure.
Use custom roles to follow the principle of the least privilege if a built-in role provides too much access.

Azure RBAC concepts :

  • Security Principal : Represents the access requestor : user, group, service principal...
  • Role definition : A set of permissions that lists the allowed operations.
    • Azure RBAC comes with built-in role definitions, but you can also create your own custom role definitions.
  • Scope : The boundary for the requested level of access or "how much" access is granted.
    • Management groups, Subscription, resource groups, resource.
  • Assignement : An assignment attaches a role definition to a security principal at a particular scope.

Role Definition

A role definition consists of sets of permissions that are defined in a JSON file.
Each permission set has a name, such as Actions or NotActions that describes the purpose of the permissions.

Some examples of permission sets include :

  • Actions permissions identify what actions are allowed.
  • NotActions permissions specify what actions aren't allowed.
  • DataActions permissions indicate how data can be changed or used.
  • notDataActions specifies the actions that are excluded from the allowed DataActions.
  • AssignableScopes permissions list the scopes where a role definition can be assigned.

Things to know about role definitions

  • Azure RBAC provides built-in roles and permissions sets. You can also create custom roles and permissions.
  • The Owner built-in role has the highest level of access privilege in Azure.
  • The system subtracts NotActions permissions from Actions permissions to determine the effective permissions for a role.
  • The AssignableScopes permissions for a role can be management groups, subscriptions, resource groups, or resources.

Role permissions

Use the Actions and NotActions permissions together to grant and deny the exact privileges for each role.
The Actions permissions can provide the breadth of access and the NotActions permissions can narrow the access.

Ex: for the role Contributor, all actions are allowed except write or delete role assignment.
Actions=* and NotActions= [Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write]

Resource Lock

Prevent accidental changes by using Resource Lock

A resource lock prevents resources from being accidentally deleted or changed.

Even with Azure RBAC policies in place, there's still a risk that people with the right level of access could delete critical cloud resources.

Think of a resource lock as a warning system that reminds you that a resource should not be deleted or changed.

What levels of locking are available?

You can apply locks to a subscription, a resource group or an individual resource. You can set the lock level to CanNotDelete or ReadOnly.

  • CanNotDelete means authorized people can still read and modify a resource, but they can't delete the resource without first removing the lock.
  • ReadOnly means authorized people can read a resource, but they can't delete or change the resource.
    • Applying this lock is like restricting all authorized users to the permissions granted by the Reader role in Azure RBAC.

How do I delete or change a locked resource?

  • To modify a locked resource, you must first remove the lock. After you remove the lock, you can apply any action you have permissions to perform.
  • Resource locks apply regardless of RBAC permissions. Even if you're an owner of the resource, you must still remove the lock before you can perform the blocked activity.

Azure Policy

Control - Audit resources by using Azure Policy

Azure Policy is a service in Azure that enables you to create, assign and manage policies that control or audit your resources.

Azure Policy enables you to define both individual policies and groups of related policies, known as initiatives. Azure Policy evaluates your resources and highlights resources that aren't compliant with the policies you've created.

Azure Policy comes with built-in policy and initiative definitions for Storage, Networking, Compute, Security Center and Monitoring.

Following are the steps to create azure policy.

  1. Create Policy Definitions : A policy definition expresses a condition to evaluate and the actions to perform when the condition is met.
  2. Create an Initiative definition : An initiative definition is a set of policy definitions that help you track your resource compliance state to meet a larger goal.
  3. Scope the Initiative : Control how your initiative definitions are applied to resources. Scope can be MG, subscriptions or RGs.
  4. Determines Compliance : After you assign an initiative definition, you can evaluate the state of compliance for all your resources.

Consider these characteristics of Azure Policy

  • Azure Policy lets you define both individual policies and groups of related policies, called initiatives.

    • Azure Policy comes with many built-in policy and initiative definitions suchas Allowed locations, Allowed virtual machine size SKUs...

  • Azure policies are inherited down the hierarchy.

  • You can scope and enforce Azure policies at different levels in the organizational hierarchy.

  • Azure Policy evaluates all resources in Azure and Arc-enabled resources (specific resource types that are hosted outside of Azure).

  • Azure Policy highlights resources that aren't compliant with the current policies.

  • Use Azure Policy to prevent noncompliant resources from being created and automatically remediate noncompliant resources.

  • Azure Policy integrates with Azure DevOps by applying pre-deployment and post-deployment policies.

Design For Identity Security

Conditional Access

Protecting Resources with Azure AD Conditional Access

Conditional Access is a tool that Azure AD uses to allow/deny access to resources based on identity signals.
These signals include who the user is, where the user is and what device the user is requesting access from.

When a user signs in, Conditional Access examines who the user is, where the user is and from what device the user is requesting access. Based on these signals, Conditional Access can allow access, enforce MFA or deny access.

Things to know about Conditional Access

  • MFA supports granular control. You can use MFA selectively and require it for certain users only.

  • Azure AD allows named locations to be used with app policies to control access.

  • Service access can be restricted through approved client apps only.

  • Access to apps can be limited to managed devices that meet your security and compliance standards.

  • Untrusted sources can be blocked, such as sources from an unknown or unexpected location.

  • Report-only mode helps admins evaluate the impact of Conditional Access policies before enabling them in their environment.

Privileged Identity Management

Protecting Privileges with Azure AD PIM

PIM (privileged Identity Management) protects privileges for Azure AD and Azure roles.

PIM Features

  • Protect : Enforce additional workflow-like tasks for users to be provide with their privilges.
    • Just-in-time access : Privilges are only assigned but not activated until they are required.
    • Time-bound access : Privilegies are deactivated after a set of period of time using start/end dates.
    • Approval : Users who assigned privileges must request approval before they will be activated.
    • MFA : Enforce the use of MFA to activate any role.
  • Audit : Provide an audit trail with information on privileged usage and justification.
    • Audit history : download and access logs that detail all PIM activities.
  • Review : Simplify and automate the ability to review whether privilges are still required by users.
    • Access reviews : periodically review access to ensure users only have roles they rently require.
    • Notification : Notify when any privileged roles are activated.

PIM Deployment and Configuration

  1. PIM requires Azure AD Premium P2 or EMS E5 licensing.
  2. PIM is automatically enabled for an organization when a user with privileged role first accesses it.
  3. Configure role settings for Azure and Azure AD roles (Azure requires role discovery).

Access Reviews

Identity Governance with Access Reviews

To remove privileges where they are no longer required.

  • Manage and conduct access reviews for groups, apps and roles.
  • Schedule reviews to be performed on a regular basis as part of good identity governance.
  • Automate changes (deny/approve) to access based on the outcome of a review.

Things to know

  • Requirements for Use : Requires Azure AD P2 licensing for reviewers, Azure resources must be discovered.
  • Azure Portal Capabilities : Configure access reviews, review/apply access review results.
  • Access Panel Capabilities : Separate interface for reviewers.

Identity Protection

Securing Identies with Azure AD Identity Protection

Identity Protection is a tool that allows organizations to accomplish three key tasks :

  • Automate the detection and remediation of identity-based risks.
  • Investigate risks by using data in the Azure portal.
  • Export risk detection data to other tools such as SIEM tools.

Identity Protection provides risk policy detection that includes any identified suspicious actions related to user accounts in the directory.
Riks policies define what action to take if risk has been found to be associated with an identity.

Risk Policies

Two risk policies are evaluated : user risk and sign-in risk.

  • User risk represents the probability that a given identity or account is compromised. An example is when a user's valid credentials are leaked. User risks are calculated offline by using Microsoft's internal and external threat intelligence sources.

    • Leaked credentials : Microsoft checks for leaked credentials from the dark web, paste sites or other sources. These leaked credentials are checked against Azure AD users' current valid credentials for valid matches.
    • Azure AD threat intelligence : This risk detection type indicates user activity that's unusual for the given user or is consistent with known attack patterns.

  • Sign-in risk represents the probability that a given sign-in (authentication request) isn't authorized by the identity owner. Sign-in risk can be calculated in real time or offline. Here are some sign-in risks that can be identified:

    • Anonymous IP address : A sign-in attempt from an anonymous IP address like a Tor browser or an anonymized VPN.
    • Atypical travel : Two sign-ins from the same user that originate from a geographically distant location. Given past behavior, at least one of the locations might also be atypical for the user.
    • Malware-linked IP address: A sign-in from an IP address that's infected with malware and the malware is known to actively communicate with a bot server.
    • Password spray : A password spray attack where a bad actor tries to defeat lockout and detection by attempting sign-in with different user names and the same password.

Things to consider when using Identity Protection

  • Consider High threshold for user risk policy : A high setting can detect for leaked credentials and unusual activity for a user and check for known attack patterns.
  • Consider Medium and above threshold for sign-in risk policy : This setting supports the Identity Protection self-remediation options. Self-remediation like password changes and MFA, have less impact than blocking users.
  • Consider investigating risks in the Azure portal : Investigate risk events in the Azure portal and identify any weak areas in your security implementation.
  • Consider exporting your risk detection data : Export the risk detection data by using the Microsoft Sentinel data connector for Identity Protection.

Design Security for Apps

Service Principals

When a user or application requests access to a resource that's secured by an Azure AD tenant, the user or app must be represented by a security principal. The security principal defines the access policy and permissions for the user (user principal) or app (service principal) in the Azure AD tenant.
A service principal can authentificate using a client token/certificate which is a smilar to a password for a user.

There are three types of service principals that you can use for your organization: application, managed identity and legacy.

Service Principals Types

An application service principal is a local representation of a global app object in a single tenant or directory. This service principal is a concrete instance created from the app object that inherits certain properties from the object.

  • An app can have at most one app object, which is registered in a home directory.
  • An app can have one or more service principal objects that represent instances of the app in every directory in which it acts.
  • An app object has a 1:1 relationship with the software app and a 1:many relationship with its service principal object(s).
  • A service principal must be created in each tenant where the app is used, to establish an identity for sign-in and access to resources secured by the tenant.

This type of service principal represents a managed identity, which eliminates the need to manage credentials.
Managed identity service principals can be granted access and permissions but they can't be updated or modified directly.

A legacy service principal represents a legacy app that was created before app registrations were introduced or an app created through a legacy configuration experience.

  • A legacy service principal can have credentials, service principal names, reply URLs and other properties that an authorized user can edit. A legacy service principal doesn't have an associated app registration.
  • Legacy service principals can only be used in the tenant where they're created.

To access a protected resource like email or calendar data, your application needs the resource owner's authorization. The resource owner can consent to or deny your app's request.

Permissions

In Delegated access scenario, a user has signed into a client application. The client application accesses the resource on behalf of the user. Delegated access requires delegated permissions. Both the client and the user must be authorized separately to make the request.

  • For the client app, the correct delegated permissions must be granted. Delegated permissions can also be referred to as scopes.
  • For the user, the authorization relies on the privileges that the user has been granted for them to access the resource. For example, the user could be authorized to access directory resources by Azure AD RBAC.

In App-only access scenario, the application acts on its own with no user signed in. The application will be able to access any data that the permission is associated with.

Azure Key Vault

Azure Key Vault provides a secure storage area so you can manage all your app secrets and properly encrypt your data in transit or while it's being stored.

Key Vault is available in two service tiers:

  • Standard tier lets you encrypt your data with a software key.
  • Premium tier offers hardware security module (HSM)-protected keys.

Things to consider when using Azure Key Vault

  • Consider shared access signatures for clients. Implement shared access signatures to provide secure delegated access to resources.
  • Consider user read and write access to your storage account. Enable users to read and write their own data to your storage account by using shared access signatures in Key Vault.
  • Consider a hybrid approach. Many real-world services can benefit from a hybrid approach for secure access.

Imporant Components

  • Key Vault : Secure storage accessible by a REST API.
  • Secret Information : Supports secrets, keys, certificates and some management capabilities.
  • Access Control : Data plane access can be controlled with access policies or RBAC.