Unit 2: Cloud Governance and Manage Identities

1. Authentication vs. Authorisation

These two terms are foundational to security and are often confused, but they represent distinct, sequential steps in an access control process.

1.1 Authentication (AuthN) - "Who are you?"

Authentication is the process of verifying the identity of a user, service, or device. It's about proving that you are who you claim to be. The system asks for credentials and checks if they are valid.

• Purpose: To establish and verify identity.
• Question Answered: "Who are you?"
• Process: A user presents credentials (something they know, have, or are). The system validates these credentials against a trusted directory or identity provider.
• Common Factors of Authentication:
  • Something you know: Password, PIN, security question answer.
  • Something you have: A physical token, a one-time password (OTP) from a mobile app (e.g., Microsoft Authenticator), a smart card.
  • Something you are: Biometrics like a fingerprint, facial scan, or iris scan.
• Multi-Factor Authentication (MFA): A security enhancement that requires users to provide two or more different authentication factors. This provides layered security, making it much harder for unauthorized users to gain access.

1.2 Authorisation (AuthZ) - "What are you allowed to do?"

Authorisation is the process that occurs after successful authentication. It determines what level of access an authenticated user, service, or device has to specific resources.

• Purpose: To grant or deny permissions to resources.
• Question Answered: "What are you allowed to do?"
• Process: Once a user is authenticated, the system checks their assigned permissions (roles, policies, access control lists) to decide if they can perform the requested action (e.g., read a file, delete a virtual machine, access a database).
• Implementation: In the cloud, this is commonly handled by systems like Role-Based Access Control (RBAC).

1.3 Analogy: Airport Security

1. Authentication: You arrive at the airport and show your passport and boarding pass to the agent. They verify that your face matches the passport photo and that the name on the ticket matches the passport. You have been authenticated as a legitimate passenger for that flight.
2. Authorisation: Your boarding pass has a zone number printed on it. This authorises you to board the plane at a specific time. You are also authorised to access the departures lounge but not the cockpit or the baggage handling area.

2. Zero Trust

Zero Trust is a modern security model founded on the principle of "never trust, always verify." It assumes that the traditional corporate network perimeter is no longer a reliable security boundary and that breaches are inevitable.

2.1 Core Principles of Zero Trust

1. Verify Explicitly: Always authenticate and authorize based on all available data points. This includes user identity, location, device health, service or workload, data classification, and anomalies. Every access request is treated as if it originates from an untrusted network.
2. Use Least Privileged Access: Limit user access with Just-In-Time (JIT) and Just-Enough-Access (JEA) policies. Grant only the permissions needed to complete a task, for the shortest time necessary. This minimizes the potential damage if an account is compromised.
3. Assume Breach: Segment access by network, user, device, and application. Minimize the "blast radius" of an attack by assuming a breach has already occurred. All sessions are encrypted end-to-end, and analytics are used to get visibility, detect threats, and improve defenses.

2.2 Traditional vs. Zero Trust Model

3. Cloud Security

Cloud security is a collection of policies, technologies, and controls designed to protect cloud-based data, applications, and infrastructure from threats. A key concept is the Shared Responsibility Model.

3.1 Shared Responsibility Model

This model delineates the security obligations of the cloud provider (e.g., Microsoft, AWS) and the customer. The responsibility shifts depending on the service model (IaaS, PaaS, SaaS).

• IaaS (Infrastructure as a Service): The customer is responsible for the most, including the OS, middleware, runtime, data, and applications. The provider is responsible for the physical security of the data center, network, and hosts.
• PaaS (Platform as a Service): The provider manages the underlying infrastructure, including the OS and middleware. The customer is responsible for their applications and data.
• SaaS (Software as a Service): The provider manages almost everything. The customer is primarily responsible for their data and managing user access.

In all models, the customer is ALWAYS responsible for:

• Data: Classification and accountability.
• Endpoints: Security of PCs, mobile phones, etc.
• Accounts and Identities: Proper management of users, groups, and permissions. This is where topics like Entra ID and RBAC are critical.

4. Understand Microsoft Entra ID

Microsoft Entra ID (formerly Azure Active Directory or Azure AD) is Microsoft's cloud-based identity and access management (IAM) service. It is the backbone for authentication and authorisation for Microsoft cloud services like Azure, Microsoft 365, and Dynamics 365, as well as thousands of third-party SaaS applications.

4.1 Core Features

• Authentication and Authorisation: The core engine that verifies user identities and enforces access policies.
• Single Sign-On (SSO): Allows users to sign in once with a single set of credentials to access multiple applications and services.
• Multi-Factor Authentication (MFA): Provides an additional layer of security by requiring a second form of verification.
• Conditional Access: A powerful policy engine that enforces access controls based on specific conditions (signals).
• Identity Management: Manages the lifecycle of users, groups, and devices.
• Business-to-Business (B2B): Allows collaboration with external users (guests) by letting them use their own credentials to access your resources.
• Business-to-Consumer (B2C): A separate service that provides identity management for customer-facing applications.

4.2 Key Concepts

• Tenant: A dedicated and trusted instance of Microsoft Entra ID. When an organization signs up for a Microsoft cloud service, a new tenant is created. It's a secure container for your organization's users, groups, and apps.
• Directory: The Entra ID instance itself, containing all the identity objects for a tenant.
• User Principal Name (UPN): The primary sign-in name for a user (e.g., user@yourtenant.onmicrosoft.com).

4.3 Entra ID vs. Active Directory Domain Services (AD DS)

Organizations often use Microsoft Entra Connect to synchronize their on-premises AD DS identities to Entra ID, creating a hybrid identity environment.

5. Configure User and Group Accounts

Effective identity management starts with properly configuring user and group objects in Microsoft Entra ID.

5.1 User Accounts

• Cloud-only users: Created directly in Entra ID. Their identity exists only in the cloud.
• Directory-synchronized users: Created in an on-premises AD DS and synchronized to Entra ID. These are the most common in hybrid environments.
• Guest users (B2B): External users invited into your tenant to collaborate. They are authenticated by their home directory but are authorized to access resources in your tenant.

Creating a User (Azure Portal):

1. Navigate to Microsoft Entra ID > Users.
2. Select + New user.
3. Choose to Create user or Invite external user.
4. Fill in the identity details like User principal name, Display name, and initial password.
5. Assign properties, groups, and roles as needed.

5.2 Group Accounts

Groups are used to simplify management by bundling users (or other objects) together. It's best practice to assign permissions and application access to groups rather than individual users.

Group Types:

• Security: The primary type used for granting access to resources (e.g., assigning an RBAC role to a group).
• Microsoft 365: A special type of group used for collaboration services like Teams, SharePoint, and a shared mailbox. It also functions as a security group.

Membership Types:

• Assigned: The most basic type. An administrator manually adds and removes members.
• Dynamic User: Membership is determined automatically based on user attributes (e.g., department, location). You define a rule, and Entra ID automatically keeps the membership up to date.
• Dynamic Device: Similar to dynamic user, but membership is based on device attributes (e.g., OS type).

Example of a Dynamic User Group Rule:
To create a group of all users in the "Marketing" department:

(user.department -eq "Marketing")

(user.department -eq "Marketing") -and (user.country -eq "USA")

6. Configure Role-Based Access Control (Azure RBAC)

Azure Role-Based Access Control (Azure RBAC) is the authorisation system used to manage access to Azure resources. It allows you to grant specific permissions to users, groups, and services at a defined scope. This is a core part of implementing the principle of least privilege.

6.1 The Components of an RBAC Assignment

An RBAC role assignment consists of three parts:

1. Security Principal (Who?): The object that is receiving the permissions.

   • User: An individual with a profile in Microsoft Entra ID.
   • Group: A set of users created in Microsoft Entra ID.
   • Service Principal: An identity used by applications or services to access specific Azure resources.
   • Managed Identity: An identity for an Azure resource (like a VM or Function App) that allows it to authenticate to other services that support Entra ID authentication without needing credentials in code.

2. Role Definition (What permissions?): A collection of permissions. A permission defines an action that can be performed, such as read, write, or delete.

   • Built-in Roles: Azure provides many pre-defined roles. The most common are:
     • Owner: Has full access to all resources, including the right to delegate access to others.
     • Contributor: Can create and manage all types of Azure resources, but cannot grant access to others.
     • Reader: Can view existing Azure resources.
     • User Access Administrator: Can manage user access to Azure resources.
   • Custom Roles: You can create your own roles if the built-in roles don't meet your specific needs.

3. Scope (Where?): The set of resources that the access applies to. In Azure, you can specify a scope at four levels:

   • Management Group: A collection of subscriptions. Permissions apply to all subscriptions within the group.
   • Subscription: Permissions apply to all resource groups and resources within the subscription.
   • Resource Group: Permissions apply to all resources within the resource group.
   • Resource: Permissions apply only to a specific resource.

Inheritance: RBAC permissions are inherited. A role assigned at a parent scope (e.g., a Subscription) is inherited by child scopes (e.g., Resource Groups and Resources within that subscription).

7. Secure Your Azure Resources with Azure RBAC (Best Practices)

Applying RBAC effectively is crucial for securing your cloud environment.

• Assign roles to groups, not users: This simplifies management. To grant a new user access, you simply add them to the appropriate group. To revoke access, you remove them. This is much easier than managing individual role assignments.
• Use the principle of least privilege: Assign the minimum permissions required for a user or service to perform its job. Start with the Reader role and add permissions as needed. Avoid using the Owner role unless absolutely necessary.
• Assign roles at the narrowest scope possible: If a developer only needs access to a single resource group, assign the Contributor role at the resource group scope, not the subscription scope.
• Use built-in roles whenever possible: These roles are maintained and updated by Microsoft. Only create custom roles when you have a specific need that a built-in role cannot meet.
• Regularly audit access: Use tools like Azure's Access control (IAM) blade and Activity Log to review who has access to what and what changes have been made. Use Access Reviews (part of Identity Governance) to automate this process.

8. Identity Governance and Conditional Access Policies

These are advanced features in Microsoft Entra ID (often requiring Premium licenses) that provide finer-grained control and automated management of identities and access.

8.1 Identity Governance

Identity Governance helps organizations balance the need for security and employee productivity by ensuring the right people have the right access to the right resources at the right time.

• Entitlement Management: Streamlines access requests and lifecycle management. You can bundle resources (group memberships, application access, SharePoint sites) into an Access Package. Users can then request access to this package, which can go through an approval workflow. Access can also be set to expire automatically.
• Access Reviews: An automated way to review and recertify user access to resources. You can configure reviews that ask users to re-justify their own access or have managers review their team's access on a recurring basis. This helps eliminate "permission creep."
• Privileged Identity Management (PIM): Manages, controls, and monitors access to important resources. It provides Just-In-Time (JIT) privileged access, meaning users must request and justify activation of a high-privilege role (like Global Administrator or Owner). Access is granted for a limited time, and all activations are audited.
• Terms of Use (ToU): Allows you to present users with terms and conditions that they must accept before gaining access. This is often used for legal or compliance disclaimers.

8.2 Conditional Access Policies

Conditional Access is the core policy engine of the Zero Trust model in the Microsoft ecosystem. It uses an If-Then logic to make access decisions.

If a user tries to access a resource, Then enforce a specific action.

Components of a Conditional Access Policy:

1. Assignments (The "IF" part - Signals):

   • Users and groups: Who the policy applies to. You can include specific users/groups and exclude others (e.g., apply to all users except emergency access accounts).
   • Cloud apps or actions: Which applications or user actions (e.g., registering security information) the policy protects.
   • Conditions (Context):
     • Sign-in risk: The likelihood that a sign-in is not from the legitimate user (requires Entra ID Protection).
     • Device platforms: The operating system of the device (e.g., Windows, iOS, Android).
     • Locations: The IP address location of the user (e.g., trusted corporate network vs. an untrusted country).
     • Client apps: The type of application used for access (e.g., browser, mobile app, legacy clients).
     • Device state: Whether the device is compliant with policies or Hybrid Entra joined.

2. Access Controls (The "THEN" part - Decision):

   • Block access: The most restrictive control.
   • Grant access: Allows access but requires the user to satisfy one or more grant controls:
     • Require multi-factor authentication: The most common and effective control.
     • Require device to be marked as compliant: Device must meet Intune or other MDM compliance policies.
     • Require Hybrid Azure AD joined device: Device must be joined to both on-premises AD and Entra ID.
     • Require approved client app: Requires the use of a specific application (e.g., Outlook mobile).
     • Require app protection policy: Part of Intune's mobile application management.

Example Policy:

• Name: Require MFA for all Admins
• IF:
  • Users: Directory Role is 'Global Administrator'
  • Apps: Any cloud app
  • Conditions: Any
• THEN:
  • Grant access: Require multi-factor authentication

What If Tool: A powerful tool in the Azure portal that allows you to simulate the impact of your Conditional Access policies on a specific user under specific conditions, helping you test policies before deployment.