Section 3 – Design a Zero Trust strategy and architecture – Design an identity security strategy

And onward to the next section in my SC-100 study guide:

Note: includes hybrid and multi-cloud scenarios!

• Design a strategy for access to cloud resources
• Recommend an identity store (tenants, B2B, B2C, hybrid)
• Recommend an authentication strategy
• Recommend an authorization strategy
• Design a strategy for conditional access
• Design a strategy for role assignment and delegation
• Design security strategy for privileged role access to infrastructure including identity-based firewall rules, Azure PIM
• Design security strategy for privileged activities including PAM, entitlement management, cloud tenant administration

Design a strategy for access to cloud resources

Cloud resources can be messy if not designed and maintained correctly. So here some tips for managing them.

Subscription

Limitations

Resource	Limit
Subscriptions associated with an Azure Active Directory tenant	Unlimited
Coadministrators per subscription	Unlimited
Resource groups per subscription	980
Azure Resource Manager API request size	4,194,304 bytes
Tags per subscription1	50
Unique tag calculations per subscription2	80,000
Subscription-level deployments per location	8003
Locations of Subscription-level deployments	10

¹You can apply up to 50 tags directly to a subscription. However, the subscription can contain an unlimited number of tags that are applied to resource groups and resources within the subscription. The number of tags per resource or resource group is limited to 50.

²Resource Manager returns a list of tag name and values in the subscription only when the number of unique tags is 80,000 or less. A unique tag is defined by the combination of resource ID, tag name, and tag value. For example, two resources with the same tag name and value would be calculated as two unique tags. You still can find a resource by tag when the number exceeds 80,000.

³Deployments are automatically deleted from the history as you near the limit. For more information, see Automatic deletions from deployment history.

Moving subscriptions to another tenant

Before you can associate or add your subscription, do the following tasks:

• Review the following list of changes that will occur after you associate or add your subscription, and how you might be affected:
  • Users that have been assigned roles using Azure RBAC will lose their access.
  • Service Administrator and Co-Administrators will lose access.
  • If you have any key vaults, they’ll be inaccessible and you’ll have to fix them after association.
  • If you have any managed identities for resources such as Virtual Machines or Logic Apps, you must re-enable or recreate them after the association.
  • If you have a registered Azure Stack, you’ll have to re-register it after association.
  • For more information, see Transfer an Azure subscription to a different Azure AD directory.
• Sign in using an account that:
  • Has an Owner role assignment for the subscription. For information about how to assign the Owner role, see Assign Azure roles using the Azure portal.
  • Exists in both the current directory and in the new directory. The current directory is associated with the subscription. You’ll associate the new directory with the subscription. For more information about getting access to another directory, see Add Azure Active Directory B2B collaboration users in the Azure portal.

You can also move your subscription to a different tenant but keeping the billing ownership in one.

Just open your subscription and choose change the directory. You have to have access (account) in the target tenant.

If you want to completely change the sub to a different tenant, you can also transfer the billing ownership when the sub has been moved.

But for CSP managed subscriptions this isn’t possible.

Limitations

There is also limitation, some of them recoverable and some not.

Service or resource	Impacted	Recoverable	Are you impacted?	What you can do
Role assignments	Yes	Yes	List role assignments	All role assignments are permanently deleted. You must map users, groups, and service principals to corresponding objects in the target directory. You must re-create the role assignments.
Custom roles	Yes	Yes	List custom roles	All custom roles are permanently deleted. You must re-create the custom roles and any role assignments.
System-assigned managed identities	Yes	Yes	List managed identities	You must disable and re-enable the managed identities. You must re-create the role assignments.
User-assigned managed identities	Yes	Yes	List managed identities	You must delete, re-create, and attach the managed identities to the appropriate resource. You must re-create the role assignments.
Azure Key Vault	Yes	Yes	List Key Vault access policies	You must update the tenant ID associated with the key vaults. You must remove and add new access policies.
Azure SQL databases with Azure AD authentication integration enabled	Yes	No	Check Azure SQL databases with Azure AD authentication	You cannot transfer an Azure SQL database with Azure AD authentication enabled to a different directory. For more information, see Use Azure Active Directory authentication.
Azure Storage and Azure Data Lake Storage Gen2	Yes	Yes		You must re-create any ACLs.
Azure Data Lake Storage Gen1	Yes	Yes		You must re-create any ACLs.
Azure Files	Yes	Yes		You must re-create any ACLs.
Azure File Sync	Yes	Yes		The storage sync service and/or storage account can be moved to a different directory. For more information, see Frequently asked questions (FAQ) about Azure Files
Azure Managed Disks	Yes	Yes		If you are using Disk Encryption Sets to encrypt Managed Disks with customer-managed keys, you must disable and re-enable the system-assigned identities associated with Disk Encryption Sets. And you must re-create the role assignments i.e. again grant required permissions to Disk Encryption Sets in the Key Vaults.
Azure Kubernetes Service	Yes	No		You cannot transfer your AKS cluster and its associated resources to a different directory. For more information, see Frequently asked questions about Azure Kubernetes Service (AKS)
Azure Policy	Yes	No	All Azure Policy objects, including custom definitions, assignments, exemptions, and compliance data.	You must export, import, and re-assign definitions. Then, create new policy assignments and any needed policy exemptions.
Azure Active Directory Domain Services	Yes	No		You cannot transfer an Azure AD Domain Services managed domain to a different directory. For more information, see Frequently asked questions (FAQs) about Azure Active Directory (AD) Domain Services
App registrations	Yes	Yes

Naming

Naming convention should be consistent even if you have multi-cloud environments.

In example it could be:

Azure-production-service-01 or AWS-test-service-01

But there is also limitations on the naming.

Entity	Scope	Length	Casing	Valid characters	Suggested pattern	Example
Resource group	Subscription	1-90	Case insensitive	Alphanumeric, underscore, parentheses, hyphen, and period except at end	<service-short-name>-<environment>-rg	profx-prod-rg
Availability set	Resource group	1-80	Case insensitive	Alphanumeric, underscore, and hyphen	<service-short-name>-<context>-as	profx-SQL-as
Tag	Associated entity	512 (name), 256 (value)	Case insensitive	Alphanumeric, spaces, and Unicode characters except for angle brackets, percent symbol, ampersand, forward or back slashes, question mark, or period	key : value	Department : Central IT ☺

You can also use an external tool to create a naming convention.

And Microsoft also has an excel that you can use to design your own naming standards and document them https://raw.githubusercontent.com/microsoft/CloudAdoptionFramework/master/ready/naming-and-tagging-conventions-tracking-template.xlsx

Resource tags

Adding resource tasks to define where a service belongs to can also be used.

Microsoft has an excellent doc for this one also.

How to add tags

In example open a resource group and add a tag.

And you can see that tag inside the resource

Using Management groups

If not enabled already, you an do it inside Azure portal https://portal.azure.com/#view/Microsoft_Azure_ManagementGroups/ManagementGroupBrowseBlade/~/MGBrowse_overview

But remember the differences with Resource groups and Management groups. I wrote a post about this one, read it to deepen your understanding and make good choice for the future.

Limitations

Resource	Limit
Management groups per Azure AD tenant	10,000
Subscriptions per management group	Unlimited.
Levels of management group hierarchy	Root level plus 6 levels1
Direct parent management group per management group	One
Management group level deployments per location	8002
Locations of Management group level deployments	10

¹The 6 levels don’t include the subscription level.

²If you reach the limit of 800 deployments, delete deployments from the history that are no longer needed. To delete management group level deployments, use Remove-AzManagementGroupDeployment or az deployment mg delete.

Service tags

Supported Inbound tags

Supported Outbound tags

In and Outbound

How to add tags?

Let’s say we have scenario that we need to block all internet access but allow other Services.

You can add rules directly from Virtual machine and networking

Virtual machine networking

Or from Network Security Group (NSG)

From NSG Outbound rules

When You add a new Outbound rule, You will see any, IP Adddresses, Service tags and ASG’s

And under Destination service tags You will choose nothing less than Internet.

Set service to custom, destination ports to * and protocol Any with action Deny.

Now Your Internet is broke but Microsoft Backbone works. Next You could add some Service Your want as allow rule.

Let’s use as an example Azure Key Vault only in North Europe.

Now we have One deny and one Allow rule inside the NSG.

And You can see the same rules inside Your virtual mcash

Service tags for on-premises

You can obtain the current service tag and range information to include as part of your on-premises firewall configurations. This information is the current point-in-time list of the IP ranges that correspond to each service tag. You can obtain the information programmatically or via a JSON file download.

Use the Service Tag Discovery API

You can programmatically retrieve the current list of service tags together with IP address range details:

• REST
• Azure PowerShell
• Azure CLI

Discover service tags by using downloadable JSON files

You can download JSON files that contain the current list of service tags together with IP address range details. These lists are updated and published weekly. Locations for each cloud are:

• Azure Public
• Azure US Government
• Azure China
• Azure Germany

That’s one way You can use Service tags, other way could be with Azure Firewall.

Azure Firewall

Recommend an identity store (tenants, B2B, B2C, hybrid)

When choosing an way to provide your identities there is a question your need to ask your self.

1. Do I need Social accounts (LinkedIn, Facebook etc.)?
2. Do I have an On-premises AD that I need to maintain and synchronize users from?
3. Do I need Guest accounts to be invited to my Azure AD?
4. Can I use B2B and not to create accounts inside my tenant?

External identities

• B2B collaboration – Collaborate with external users by letting them use their preferred identity to sign in to your Microsoft applications or other enterprise applications (SaaS apps, custom-developed apps, etc.). B2B collaboration users are represented in your directory, typically as guest users.
• B2B direct connect – Establish a mutual, two-way trust with another Azure AD organization for seamless collaboration. B2B direct connect currently supports Teams shared channels, enabling external users to access your resources from within their home instances of Teams. B2B direct connect users aren’t represented in your directory, but they’re visible from within the Teams shared channel and can be monitored in Teams admin center reports.
• Azure AD B2C – Publish modern SaaS apps or custom-developed apps (excluding Microsoft apps) to consumers and customers, while using Azure AD B2C for identity and access management.

B2B collaboration

With B2B collaboration, you can invite anyone to sign in to your Azure AD organization using their own credentials so they can access the apps and resources you want to share with them. Use B2B collaboration when you need to let external users access your Office 365 apps, software-as-a-service (SaaS) apps, and line-of-business applications, especially when the partner doesn’t use Azure AD or it’s impractical for administrators to set up a mutual connection through B2B direct connect. There are no credentials associated with B2B collaboration users. Instead, they authenticate with their home organization or identity provider, and then your organization checks the guest user’s eligibility for B2B collaboration.

B2B direct connect

B2B direct connect is a new way to collaborate with other Azure AD organizations. This feature currently works with Microsoft Teams shared channels. With B2B direct connect, you create two-way trust relationships with other Azure AD organizations to allow users to seamlessly sign in to your shared resources and vice versa. B2B direct connect users aren’t added as guests to your Azure AD directory.

Azure AD B2C

Azure AD B2C is a Customer Identity and Access Management (CIAM) solution that lets you build user journeys for consumer- and customer-facing apps. If you’re a business or individual developer creating customer-facing apps, you can scale to millions of consumers, customers, or citizens by using Azure AD B2C. Developers can use Azure AD B2C as the full-featured CIAM system for their applications.

With Azure AD B2C, customers can sign in with an identity they’ve already established (like Facebook or Gmail). You can completely customize and control how customers sign up, sign in, and manage their profiles when using your applications.

Comparison

B2B collaboration	B2B direct connect	Azure AD B2C
Primary scenario	Collaborate with external users by letting them use their preferred identity to sign in to resources in your Azure AD organization. Provides access to Microsoft applications or your own applications (SaaS apps, custom-developed apps, etc.). Example: Invite an external user to sign in to your Microsoft apps or become a guest member in Teams.	Collaborate with users from other Azure AD organizations by establishing a mutual connection. Currently can be used with Teams shared channels, which external users can access from within their home instances of Teams. Example: Add an external user to a Teams shared channel, which provides a space to chat, call, and share content.	Publish apps to consumers and customers using Azure AD B2C for identity experiences. Provides identity and access management for modern SaaS or custom-developed applications (not first-party Microsoft apps).
Intended for	Collaborating with business partners from external organizations like suppliers, partners, vendors. These users may or may not have Azure AD or managed IT.	Collaborating with business partners from external organizations that use Azure AD, like suppliers, partners, vendors.	Customers of your product. These users are managed in a separate Azure AD directory.
User management	B2B collaboration users are managed in the same directory as employees but are typically annotated as guest users. Guest users can be managed the same way as employees, added to the same groups, and so on. Cross-tenant access settings can be used to determine which users have access to B2B collaboration.	No user object is created in your Azure AD directory. Cross-tenant access settings determine which users have access to B2B collaboration. direct connect. Shared channel users can be managed in Teams, and users’ access is determined by the Teams shared channel’s policies.	User objects are created for consumer users in your Azure AD B2C directory. They’re managed separately from the organization’s employee and partner directory (if any).
Identity providers supported	External users can collaborate using work accounts, school accounts, any email address, SAML and WS-Fed based identity providers, and social identity providers like Gmail and Facebook.	External users collaborate using Azure AD work accounts or school accounts.	Consumer users with local application accounts (any email address, user name, or phone number), Azure AD, various supported social identities, and users with corporate and government-issued identities via SAML/WS-Fed-based identity provider federation.
Single sign-on (SSO)	SSO to all Azure AD-connected apps is supported. For example, you can provide access to Microsoft 365 or on-premises apps, and to other SaaS apps such as Salesforce or Workday.	SSO to a Teams shared channel.	SSO to customer owned apps within the Azure AD B2C tenants is supported. SSO to Microsoft 365 or to other Microsoft SaaS apps isn’t supported.
Licensing and billing	Based on monthly active users (MAU), including B2B collaboration and Azure AD B2C users. Learn more about External Identities pricing and billing setup for B2B.	Based on monthly active users (MAU), including B2B collaboration, B2B direct connect, and Azure AD B2C users. Learn more about External Identities pricing and billing setup for B2B.	Based on monthly active users (MAU), including B2B collaboration and Azure AD B2C users. Learn more about External Identities pricing and billing setup for Azure AD B2C.
Security policy and compliance	Managed by the host/inviting organization (for example, with Conditional Access policies and cross-tenant access settings).	Managed by the host/inviting organization (for example, with Conditional Access policies and cross-tenant access settings). See also the Teams documentation.	Managed by the organization via Conditional Access and Identity Protection.
Branding	Host/inviting organization’s brand is used.	For sign-in screens, the user’s home organization brand is used. In the shared channel, the resource organization’s brand is used.	Fully customizable branding per application or organization.

Recommendations

• Treat identity as the primary security perimeter
• Centralize identity management
• Manage connected tenants
• Enable single sign-on
• Turn on Conditional Access
• Plan for routine security improvements
• Enable password management
• Enforce multi-factor verification for users
• Use role-based access control
• Lower exposure of privileged accounts
• Control locations where resources are located
• Use Azure AD for storage authentication

Like you can see from the chart, B2C could be used in many cases, it will support many application types and is completely customizable but also free until 50k users when connected to a linked Subscription.

So choose wisely, there is a lot of possibilities.

Recommend an authentication strategy

Methods

Authentication method	Security	Usability	Availability
Windows Hello for Business	High	High	High
Microsoft Authenticator app	High	High	High
FIDO2 security key	High	High	High
OATH hardware tokens (preview)	Medium	Medium	High
OATH software tokens	Medium	Medium	High
SMS	Medium	High	Medium
Voice	Medium	Medium	Medium
Password	Low	High	High

How they work?

Method	Primary authentication	Secondary authentication
Windows Hello for Business	Yes	MFA
Microsoft Authenticator app	Yes	MFA and SSPR
FIDO2 security key	Yes	MFA
OATH hardware tokens (preview)	No	MFA and SSPR
OATH software tokens	No	MFA and SSPR
SMS	Yes	MFA and SSPR
Voice call	No	MFA and SSPR
Password	Yes

Categories

Authentication methods can also be broken down into categories, or types, such as:

• Sign-in authentication
• Password reset authentication
• Multi-factor authentication

Authentication method	Sign-in authentication	SSPR and MFA
Password	Yes
Windows Hello for Business	Yes
Microsoft Authenticator app	Yes (Preview)	MFA and SSPR
FIDO2 security keys	Yes (Preview)	MFA-only
SMS	Yes (Preview)	MFA and SSPR
Voice call	No	MFA and SSPR
Security questions	No	SSPR-only
Email address	No	SSPR-only

How to enable MFA?

I wrote a post to my SC-300 study guide of enabling MFA and the considerations.

How to use combined registration?

Recommend an authorization strategy

• Use a mix of role-based and resource-based authorization. Start with the principle of least privilege and add more actions based on your needs.
• Define clear lines of responsibility and separation of duties for application roles and the resources it can manage. Consider the access levels of each operational function, such as permissions needed to publish production release, access customer data, manipulate database records.
• Do not provide permanent access for any critical accounts. Elevate access permissions that are based on approval and is time bound using Azure AD Privileged Identity Management (Azure AD PIM).|

Role Based Access Control

RBAC (Azure roles)

Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management to Azure resources, such as compute and storage. Azure RBAC includes over 70 built-in roles. There are four fundamental Azure roles. The first three apply to all resource types:

Azure role	Permissions	Notes
Owner	Full access to all resourcesDelegate access to others	The Service Administrator and Co-Administrators are assigned the Owner role at the subscription scope Applies to all resource types.
Contributor	Create and manage all of types of Azure resourcesCreate a new tenant in Azure Active DirectoryCannot grant access to others	Applies to all resource types.
Reader	View Azure resources	Applies to all resource types.
User Access Administrator	Manage user access to Azure resources

RBAC limitations

Resource	Limit
Azure role assignments per Azure subscription The role assignments limit for a subscription is currently being increased. For more information, see Troubleshoot Azure RBAC.	2,000
Azure role assignments per management group	500
Size of description for Azure role assignments	2 KB
Size of condition for Azure role assignments	8 KB
Azure custom roles per tenant	5,000
Azure custom roles per tenant (for Azure Germany and Azure China 21Vianet)	2,000

All built-in roles

Best practices

• Just-in-time privileged access to Azure AD and Azure resources.
• Time-bound access.
• Approval-based access.
• Break glass for emergency access process to gain access.
• Limit write access to production systems to service principals. No user accounts should have regular write-access.
• Ensure there’s a process for disabling or deleting administrative accounts that are unused.

• Use Break the Glass account

Create and manage break-glass accounts

Emergency access accounts are:

• Assigned Global Administrator rights in Azure AD
• Aren’t used on a daily basis
• Are protected with a long complex password

Why to create the account?

It’s important to avoid accidentally being locked out of your Azure Active Directory (Azure AD) organization. You can mitigate the impact of accidentally losing administrative access by creating two or more emergency access accounts in your organization. Emergency access accounts are highly privileged and are not assigned to any particular individual. Emergency access accounts are limited to emergency or Break-the-glass scenarios where regular administrator accounts cannot be used. Microsoft recommends that you maintain your goal of limiting the use of your emergency account to the time you absolutely need.

Requirements

• You need a username that is complicated and difficult to guess.
• Requires a complex password.
• You need a list of approved administrators who can use your break-the-glass account. In general, these administrators should of course also have the role of global administrator.
• Monitor your break-the-glass account in Azure AD sign-in and audit logs to respond to unexpected activity.

How to create

• You must permanently assign the Global Administrator role.
• The password must be set indefinitely.
• Do not configure MFA. Must be excluded from all conditional access policies. It may not be assigned to a specific person.
• Must be a cloud-only account.
• It may not be federated.
• Do not synchronize with On-premises AD.
• Do not connect to mobile phones or hardware tokens provided by employees.

Monitoring

User your Log analytics instance for automatic monitoring

And choose Custom log search

An create a new rule with GUID from your user

and for the Alert logic the following

Then add an Action group

Choose Email / SMS accordingly and add the information needed.

Now you can also test the action group created, excellent!

So now you have the action rule inside the query

Next to enable it upon creation

And find the create alert inside Log analytics

Resource-based authorization

Resource based authorization occurs whenever the authorization depends on a specific resource that will be affected by an operation. In the Tailspin Surveys application, every survey has an owner and zero-to-many contributors.

• The owner can read, update, delete, publish, and unpublish the survey.
• The owner can assign contributors to the survey.
• Contributors can read and update the survey.

Note that “owner” and “contributor” are not application roles; they are stored per survey, in the application database. To check whether a user can delete a survey, for example, the app checks whether the user is the owner for that survey.

You’ll need to implement custom logic for resource-based authorization. That logic might be a mapping of resources, Azure AD object (like role, group, user), and permissions.

Design a strategy for conditional access

What is Conditional access?

Conditional Access is based on conditions for a location, devices used, risks discovered.

Here is an excellent picture from Microsoft which explain the flow.

Licensing

You need at least Azure AD Premium P1 to enable Conditional Access.

What could be enabled?

• Identity and device templates for easier deployment
• Terms Of use
• GPS locations
• MFA
• Location based controls
• Risk based controls
• Group-based assignment
• Block or grant

How to Enable MFA with Conditional Access?

Conditional Access and MFA is much more convenient than MFA by itself. There is policies the user will get if they fall to the scope.

CA policies

Search for Conditional Access inside Azure portal.

Once there, create a new policy

You will se the policy editor, give a name and choose Users or workloads.

In here You can choose to include on exclude users, roles or groups. A nice option is also to Enable something with Conditional Access only to Guest and External users that reside or will be invited to Your tenant.

I will keep it simple in my example and choose only one user. But You really could fiddle around with these an make Your own kind of policy.

Next You can choose Cloud Apps or actions. In my example I will choose Office 365 which includes all Office 365 Services.

For the user actions You could choose the following.

User Actions

User actions

User actions are tasks that can be performed by a user. Currently, Conditional Access supports two user actions:

• Register security information: This user action allows Conditional Access policy to enforce when users who are enabled for combined registration attempt to register their security information. More information can be found in the article, Combined security information registration.
• Register or join devices: This user action enables administrators to enforce Conditional Access policy when users register or join devices to Azure AD. It provides granularity in configuring multi-factor authentication for registering or joining devices instead of a tenant-wide policy that currently exists. There are three key considerations with this user action:
  • Require multi-factor authentication is the only access control available with this user action and all others are disabled. This restriction prevents conflicts with access controls that are either dependent on Azure AD device registration or not applicable to Azure AD device registration.
  • Client apps, Filters for devices and Device state conditions aren’t available with this user action since they’re dependent on Azure AD device registration to enforce Conditional Access policies.
  • When a Conditional Access policy is enabled with this user action, you must set Azure Active Directory > Devices > Device Settings – Devices to be Azure AD joined or Azure AD registered require Multi-Factor Authentication to No. Otherwise, the Conditional Access policy with this user action isn’t properly enforced. More information about this device setting can found in Configure device settings.

Conditions

Then choose Conditions, in here You will define the conditions that will trigger the policy.

In example if the user has risk of Medium they would be Enforced for the policy.

In the Grant section You will define to block the user matching the policy or Grant with controls.

To keep it simple I will choose only require MFA

In Sessions You will have the following. In here You can control App restrictions, disable persistent sessions and Continuous Access Evaluation (CAE) but You really shouldn’t. These are excellent and relatively new features inside Conditional Access policies.

Design a strategy for role assignment and delegation

Best practices

• Use least privilege
• Use Privileged Identity Management to grant just-in-time access (JIT)
• Turn on multi-factor authentication for all your administrator accounts
• Configure recurring access reviews to revoke unneeded permissions over time

• Limit the number of Global Administrators to less than 5
• Use groups for Azure AD role assignments and delegate the role assignment
• Activate multiple roles at once using privileged access groups
• Use cloud native accounts for Azure AD roles

Azure AD built-in roles differ in where they can be used, which fall into the following three broad categories.

• Azure AD-specific roles: These roles grant permissions to manage resources within Azure AD only. For example, User Administrator, Application Administrator, Groups Administrator all grant permissions to manage resources that live in Azure AD.
• Service-specific roles: For major Microsoft 365 services (non-Azure AD), we have built service-specific roles that grant permissions to manage all features within the service. For example, Exchange Administrator, Intune Administrator, SharePoint Administrator, and Teams Administrator roles can manage features with their respective services. Exchange Administrator can manage mailboxes, Intune Administrator can manage device policies, SharePoint Administrator can manage site collections, Teams Administrator can manage call qualities and so on.
• Cross-service roles: There are some roles that span services. We have two global roles – Global Administrator and Global Reader. All Microsoft 365 services honor these two roles. Also, there are some security-related roles like Security Administrator and Security Reader that grant access across multiple security services within Microsoft 365. For example, using Security Administrator roles in Azure AD, you can manage Microsoft 365 Defender portal, Microsoft Defender Advanced Threat Protection, and Microsoft Defender for Cloud Apps. Similarly, in the Compliance Administrator role you can manage Compliance-related settings in Microsoft 365 Compliance Center, Exchange, and so on.

• Use Custom security attributes

Design security strategy for privileged role access to infrastructure including identity-based firewall
rules, Azure PIM

Privileged Identity Management (PIM) provides a time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions to important resources. These resources include resources in Azure Active Directory (Azure AD), Azure, and other Microsoft Online Services such as Microsoft 365 or Microsoft Intune.

PIM enables you to allow a specific set of actions at a particular scope. Key features include:

• Provide just-in-time privileged access to resources
• Assign eligibility for membership or ownership of privileged access groups
• Assign time-bound access to resources using start and end dates
• Require approval to activate privileged roles
• Enforce multifactor authentication to activate any role
• Use justification to understand why users activate
• Get notifications when privileged roles are activated
• Conduct access reviews to ensure users still need roles
• Download audit history for internal or external audit

How to enable PIM?

There are two types of assignment – eligible and active. If a user has been made eligible for a role, that means they can activate the role when they need to perform privileged tasks.

You can also set a start and end time for each type of assignment. This addition gives you four possible types of assignments:

• Permanent eligible
• Permanent active
• Time-bound eligible, with specified start and end dates for assignment
• Time-bound active, with specified start and end dates for assignment

In case the role expires, you can extend or renew these assignments.

To use Privileged Identity Management, you must have one of the following licenses:

• Azure AD Premium P2
• Enterprise Mobility + Security (EMS) E5

PIM roles

Task + Manage	Description
My roles	Displays a list of eligible and active roles assigned to you. This is where you can activate any assigned eligible roles.
Pending requests	Displays your pending requests to activate eligible role assignments.
Approve requests	Displays a list of requests to activate eligible roles by users in your directory that you are designated to approve.
Review access	Lists active access reviews you are assigned to complete, whether you’re reviewing access for yourself or someone else.
Azure AD roles	Displays a dashboard and settings for Privileged role administrators to manage Azure AD role assignments. This dashboard is disabled for anyone who isn’t a privileged role administrator. These users have access to a special dashboard titled My view. The My view dashboard only displays information about the user accessing the dashboard, not the entire organization.
Azure resources	Displays a dashboard and settings for Privileged role administrators to manage Azure resource role assignments. This dashboard is disabled for anyone who isn’t a privileged role administrator. These users have access to a special dashboard titled My view. The My view dashboard only displays information about the user accessing the dashboard, not the entire organization.

Design security strategy for privileged activities including PAM, entitlement management, cloud tenant administration

PAM

Privileged Access Management accomplishes two goals:

• Re-establish control over a compromised Active Directory environment by maintaining a separate bastion environment that is known to be unaffected by malicious attacks.
• Isolate the use of privileged accounts to reduce the risk of those credentials being stolen.

Components for MIM and PAM

• MIM Service: implements business logic for performing identity and access management operations, including privileged account management and elevation request handling.
• MIM Portal: an optional SharePoint-based portal, hosted by SharePoint 2013 or later, which provides an administrator management and configuration UI.
• MIM Service Database: stored in SQL Server 2012 or later, and holds identity data and meta-data required for MIM Service.
• PAM Monitoring Service and if needed the PAM Component Service: two services that manage the lifecycle of privileged accounts and assists the PRIV AD in group membership lifecycle.
• PowerShell cmdlets: for populating MIM Service and PRIV AD with users and groups that correspond to the users and groups in the CORP forest for PAM administrators, and for end users requesting just-in-time (JIT) use of privileges on an administrative account.
• PAM REST API: for developers integrating MIM in the PAM scenario with custom clients for elevation, without needing to use PowerShell or SOAP. The use of the REST API is demonstrated with a sample web application.

PAM offers the following advantages:

• Isolation/scoping of privileges: Users do not hold privileges on accounts that are also used for non-privileged tasks like checking email or browsing the Internet. Users need to request privileges. Requests are approved or denied based on MIM policies defined by a PAM administrator. Until a request is approved, privileged access is not available.
• Step-up and proof-up: These are new authentication and authorization challenges to help manage the lifecycle of separate administrative accounts. The user can request the elevation of an administrative account and that request goes through MIM workflows.
• Additional logging: Along with the built-in MIM workflows, there is additional logging for PAM that identifies the request, how it was authorized, and any events that occur after approval.
• Customizable workflow: The MIM workflows can be configured for different scenarios, and multiple workflows can be used, based on the parameters of the requesting user or requested roles.

Once installed and configured, each group created by the migration procedure in the PRIV forest is a foreign principal group mirroring the group in the original CORP forest. The foreign principal group provides users who are members of that group with the same SID in their Kerberos token as the SID of the group in the CORP forest. Furthermore, when the MIM Service adds members to these groups in the PRIV forest, those memberships will be time limited.

What is Entitlement management?

Azure AD entitlement management is an identity governance function that automates access request workflows, access assignments, reviews, and expiration, allowing companies to manage identity and access lifecycles at scale.

To do their jobs, employees in companies require access to a variety of groups, applications, and websites. Managing this access is difficult as requirements change, such as the installation of new applications or the need for increased access rights for users. When you collaborate with other organizations, this scenario becomes more problematic since you may not know who in the other organization needs access to your resources, and they may not know what applications, groups, or sites your organization uses.

Azure AD entitlement management can help you manage access to groups, applications, and SharePoint Online sites for internal users as well as external users who require access to those resources.

How many licenses must you have?

Ensure that your directory has at least as many Azure AD Premium P2 licenses as you have:

• Member users who can request an access package.
• Member users who request an access package.
• Member users who approve requests for an access package.
• Member users who review assignments for an access package.
• Member users who have a direct assignment to an access package.

For guest users, licensing needs will depend on the licensing model you’re using. However, the below guest users’ activities are considered Azure AD Premium P2 usage:

• Guest users who request an access package.
• Guest users who approve requests for an access package.
• Guest users who review assignments for an access package.
• Guest users who have a direct assignment to an access package.

Azure AD Premium P2 licenses are not required for the following tasks:

• No licenses are required for users with the Global Administrator role who set up the initial catalogs, access packages, and policies, and delegate administrative tasks to other users.
• No licenses are required for users who have been delegated administrative tasks, such as catalog creator, catalog owner, and access package manager.
• No licenses are required for guests who have a privilege to request access packages but they do not choose to request them.

Summary of terminology

To better understand entitlement management and its documentation, you can refer back to the following list of terms.

Term	Description
access package	A bundle of resources that a team or project needs and is governed with policies. An access package is always contained in a catalog. You would create a new access package for a scenario in which users need to request access.
access request	A request to access the resources in an access package. A request typically goes through an approval workflow. If approved, the requesting user receives an access package assignment.
assignment	An assignment of an access package to a user ensures the user has all the resource roles of that access package. Access package assignments typically have a time limit before they expire.
catalog	A container of related resources and access packages. Catalogs are used for delegation, so that non-administrators can create their own access packages. Catalog owners can add resources they own to a catalog.
catalog creator	A collection of users who are authorized to create new catalogs. When a non-administrator user who is authorized to be a catalog creator creates a new catalog, they automatically become the owner of that catalog.
connected organization	An external Azure AD directory or domain that you have a relationship with. The users from a connected organization can be specified in a policy as being allowed to request access.
policy	A set of rules that defines the access lifecycle, such as how users get access, who can approve, and how long users have access through an assignment. A policy is linked to an access package. For example, an access package could have two policies – one for employees to request access and a second for external users to request access.
resource	An asset, such as an Office group, a security group, an application, or a SharePoint Online site, with a role that a user can be granted permissions to.
resource directory	A directory that has one or more resources to share.
resource role	A collection of permissions associated with and defined by a resource. A group has two roles – member and owner. SharePoint sites typically have 3 roles but may have additional custom roles. Applications can have custom roles.

Cloud tenant administration

Build a strategy

• Stage 1 (24-48 hours): Critical items that we recommend you do right away
• Stage 2 (2-4 weeks): Mitigate the most frequently used attack techniques
• Stage 3 (1-3 months): Build visibility and build full control of administrator activity
• Stage 4 (six months and beyond): Continue building defenses to further harden your security platform

Stage 1

Setup Break the Glass accounts

Enable MFA for All global admin accounts

Use Azure AD Privileged Identity Management

Stage 2

If using on-premises, setup PHS

Use Azure Identity Protection

Define service owners

Stage 3

Use Privileged Access Workstations (PAWs) for admins

Enable JIT (Just In time) to give rights when needed

Enable SIEM solution

Stage 4

Build a plan for emergency situations

Review admin role permissions

Review compliance of the environment with Azure Policy

Use Entra multi-cloud permissions management

Permissions Management is a cloud infrastructure entitlement management (CIEM) solution that provides comprehensive visibility into permissions assigned to all identities. For example, over-privileged workload and user identities, actions, and resources across multi-cloud infrastructures in Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).

Things to remember

Difference with Hybrid and Multi-cloud environments

Subscription, Management group and resource group functions and limitations

Naming and tagging your resources in multi-cloud envinronment

B2B = External accounts that will use your resources, normally invited as Guests

B2B direct = External accounts not in your tenant but using resources

B2C = External social or Azure AD accounts that use services you publish, totally customizable

Authentication methods for Multi-factor authentication

How and why to use Conditional Access and Dynamic groups

PAM = on-premises and integrated with MIM

PIM = Azure AD role provisioning service

Access reviews = Conduct a planned review of rights and roles

Entitlement Management = Giving access thru access packages to B2B or internal users

Entra Permissions Management = Multi-cloud permission management with a Creep index

That’s it, long post but didn’t want to split it to pieces. Then to the next one!

Link to main post