1.2: Design authentication and authorization solutions Flashcards
What are the 3 main principles of Zero Trust?
There are three main principles of zero trust:
Verify explicitly - Access requests must be authenticated and authorized based on all available information, including user identity, location, device health, resource or service being accessed, and data classification.
Use least privileged access Limit user access to just what they need to complete their task. Apply policies that adjust based on risk and secure data. The goal is to ensure security without affecting user productivity.
Assume breach - Use isolated access, end-to-end encryption, and threat intelligence for protection.
What solutions are there for securing resources with role-based access control (RBAC)?
Some key concepts and terminology of Azure RBAC:
Security principal - this can be a user, a group, a service principal, or a managed identity.
Role or role definition - A role is basically a set of permissions—like read, write, and delete—for a specific resource. A role can also be a set or collection of permissions to work with the data plane of a resource like a Key Vault, an Azure Storage account, and so on. A role definition can be broad—as with Owner, Contributor, or Reader roles—or it can be granular, as with roles such as Storage Blob Data Reader, Key Vault Administrator, and so on.
Describe some Azure Built-in Roles and Custom Roles?
Scope - Tags can be assigned to various Azure resources, such as management groups, subscriptions, resource groups, VMs, Azure Storage accounts, managed databases, etc.
Role assignment -Role assignment links a user with a role definition. Users can be assigned multiple roles at different scopes. For example, a user can be a Contributor for one resource group and an Owner for another.
Groups - Group security principals with similar permissions. Use groups to manage access, make it easier and more secure. Nest groups to create hierarchies. Assign roles to parent groups, and child groups inherit permissions.
Deny assignments - Deny assignments are the opposite of role assignments. While a role assignment grants permissions, a deny assignment denies them. Deny assignments take priority over role assignments, meaning if a user has both, the deny assignment overrides the role assignment.
Azure Active Directory (AAD) roles: Global administrator
This is the default AAD role assigned to the user who signs up for the AAD tenant.
Manage access to all administrative features in AAD by assigning administrative roles to others.
Manage administrative access for services that federate to AAD, like M365, Azure DevOps, Power BI, and so on.
Reset passwords for all users and administrators.
Azure Active Directory (AAD) roles: User Administrator
Create and manage all aspects of users and groups.
Manage support tickets, monitor service health.
Change passwords for all non-administrator users and specific administrators (help-desk administrators and other user administrators).
Azure Active Directory (AAD) roles: Billing administrator
Make purchases.
Manage subscriptions in the AAD tenant.
Manage support tickets and monitor service health.
What is the Azure Identity Management (IDAM) Solution
Azure Identity Management (IDAM) is a solution that helps organizations manage user identities and access to resources in Azure. It includes the following services:
Azure Active Directory (Azure AD): A cloud-based identity and access management service that provides single sign-on, multi-factor authentication, and directory synchronization.
Azure AD B2C: A customer identity and access management service that enables user sign-ups, sign-ins, and profile management.
Azure AD B2BA service that enables organizations to collaborate with external partners and grant them access to their applications and resources.
Azure AD Domain Services: A managed domain service that provides domain join, group policy, and domain-joined VM support for Azure applications.
Azure AD Identity Protection: A service that helps organizations detect and prevent identity-related risks and attacks.
What is Azure Active Directory (AAD)?
Azure Active Directory (AAD) is a comprehensive IDAM solution in Azure that secures access to LOB applications, services, and SaaS applications in Azure and M365, and can be extended to secure LOB applications, services, and SaaS applications deployed anywhere.
Application registration offloads an application’s IDAM functions to AAD, creating a unique identity called an application object. To register, provide the name, account type, and URL for successful login redirection.
AAD and service principal objects?
To access protected resources in AAD, you need a service principal object which can be a user or service principal. Both are types of security principals that authenticate and authorize users, applications, and services.
Service principals can be of the following types:
Application - App registration in Azure Portal creates an application object and its service principal object. The service principal object controls access, capabilities, and Azure resource access for the app.
Managed identities - Azure resources can have managed identities that create a service principal in AAD. Enable managed identities for Azure services using the Azure Portal. Use the managed identity to grant access permissions to other Azure services. Two types of managed identities are available.
System-assigned managed identity - follow the lifecycle of the resource they are enabled for, and are removed when the resource is removed. They are limited for use only by the specific Azure service they are enabled for.bled.
User-assigned managed identity - A user-assigned managed identity in Azure is assigned to the Azure resource itself, like any other Azure resource. You can assign it to multiple Azure services. Note that it is not automatically deleted when its associated resources are deleted - you must remove it explicitly.
What are Azure AD External Identities?
Azure AD External Identities provides for scenarios in which an external user can use their own identity. This might be their organizational identity or a social identity such as the one they use on Google or Facebook.
Scenario
B2B collaboration
Provides access to external users while allowing them to bring their own identities. Access can be given to Microsoft applications or your applications (SaaS apps, custom-developed apps, and so on), which are protected by your organization’s AAD tenant.
AAD B2C
Allows external consumers and customers to access your published application, which could be a SaaS application or a custom developed application. This application cannot be a Microsoft 365 application like Teams, SharePoint, Office, and so on.
Type of Users
B2B collaboration
Business partners from various organizations, like suppliers, partners, or vendors. These organizations may or may not have AAD.
AAD B2C
End customers or consumers of products and services.
User Directory and Management
B2B collaboration
B2B users are onboarded or invited as guest users and appear as guest users in the organization’s AAD in which the organization’s employee identities are managed. These external user identities can be managed similarly to employee identities.
AAD B2C
These users are managed in an AAD B2C directory that is separate from the organization’s AAD and any other partner’s AAD.
Identity Providers Supported
B2B collaboration
Work accounts, school accounts, email addresses, identities from SAML or WS-Fed based identity providers, and social identity providers like Google and Facebook.
AAD B2C
Local application accounts (any email address, user name, or phone number), AAD, various supported social identities and consumer identities.
Single Sign-On (SSO) Support
B2B collaboration
Supported for all applications that are connected to AAD. These could be Microsoft 365 applications, applications running on-premises, or other SaaS applications.
AAD B2C
Supported only for the application registered in AAD B2C. This application cannot be a Microsoft 365 application.
What is Azure AD Connect?
Azure AD Connect helps organizations sync their on-premises Active Directory to AAD.
It requires the deployment of an Azure AD Connect application in an on-premises environment. This enables users to employ the same identity and password to access applications and workloads on-premises or in Azure Cloud.
The three available authentication methods are as follows:
Password hash synchronization (PHS) - When you use this sign-in option with Azure AD Connect, your password is hashed and synced with AAD. This allows AAD to authenticate your cloud account without any dependencies, using the same password you use on-premises.
Pass-through authentication (PTA) -PTA is a sign-in option that enables users to access both on-premises and cloud applications with a single password. It requires a lightweight on-premises agent to validate passwords against the on-premises Active Directory. PTA is useful to enforce on-premises Active Directory password policies.
Federation - Federation enables trust between authentication systems. Authentication is handled by a trusted system like ADFS. AAD passes authentication requests to the federated system for validation. Authentication happens on-premises if ADFS is deployed on-premises.
What is Azure AD Connect Cloud Sync?
This service is also a solution for hybrid identity. In addition to being used independently for synchronization, Azure AD Connect Cloud Sync can be used in conjunction with Azure AD Connect.
https://learn.microsoft.com/en-us/azure/active-directory/cloud-sync/what-is-cloud-sync.”
Azure and Multi-factor authentication
In AAD, you can apply MFA using the per-user MFA configuration. However, a better way to configure MFA is by using conditional access policies in addition to password-based authentication. The methods by which to do MFA are as follows:
- Microsoft Authenticator
- Windows Hello for Business
- FIDO2 security key
- OATH hardware token
- OATH software token
- SMS
- Voice call
AAD also has a preconfigured set of conditional access policies called security defaults that can serve as a starting point for an organization to improve its security. These policies are as follows:
- Requiring all users to register for AAD MFA
- Requiring administrators to perform MFA
- Blocking legacy authentication protocols
- Requiring users to perform MFA when necessary, based on identified risks
- Protecting privileged activities like access to the Azure Portal
Azure Password reset
You can set up self-service password reset (SSPR) for users only if MFA is configured for them. You can also establish one or two additional methods for identifying users before they can reset their password.
Azure Identity Protection
AAD Identity Protection has built-in policies for user and sign-in risk. You can block access or require password changes. Reports are available in Azure Portal.
Identity Protection reports risky users, sign-ins, and risks. It exports data to Microsoft Sentinel for SIEM and SOAR.
Configuring conditional access policies includes specifying the following settings:
User or Workload Identities - Use this setting to trigger the policy for specific users, groups, or work-load identities. You can also configure exclusion options—for example, by applying the policy to all groups except for a particular one or in a break-glass scenario.
Cloud App or Actions - Use this setting to select the cloud application or user action for policy evaluation. Choose apps registered in AAD or other apps like Project Online, Teams, etc. User actions can be security information registration or device joining. You can also exclude specific cloud apps from the policy.
Condition - Policy enforcement requires meeting specific conditions. These conditions can be set for various signals, such as when a user attempts to access a cloud application or perform an action. The signals used as conditions are:
User Risk - Specify the level of user risk—High, Medium, or Low—that will cause the condition to evaluate as true.
Sign-In Risk - Specify the level of sign-in risk—High, Medium, or Low—that will cause the condition to evaluate as true.
Device platform - Specify the device platform for which the condition will evaluate as true. Options include iOS, Android, Windows, macOS, Windows Phone, and Linux.
Location - Specify a named location for IP ranges or country IPs for which the[…]
Client App - Specify the use of which client apps—including browsers, native mobile apps, or desktop clients—for which the condition will evaluate as true.
Grant - Define the action for a selected user, workload, app, or user action when the condition is met. It can be to block access or allow access with additional verifications.
