Skip to main content

Describe Azure identity, access, and security

Describe Azure directory services

Entra ID is a directory service that enables users to sign in and access Azure cloud apps & services and maintain an on-premise Active Directory deployment.

Entra compliments Active Directory. AD doesn't monitor sign-in attempts, but connecting Entra to AD will detect suspicious sign-in attempts as part of the Entra offering.

Entra ID is for:

  • IT: admins can use Entra to control access to apps and resources
  • Dev: devs can use Entra for SSO functionality or enabling access to an app with a user's current credentials
  • Users: any user can manage their account data and do things like password resets
  • Subscribers: M365, O365, Azure, and Dynamics CRM already leverage Entra

Entra ID provides:

  • Authentication. It verifies a user's identity and provides functionality such as password reset, multifactor authentication, banned passwords (hunter2), and "smart lockout services" (too many failed logins)
  • Single sign-on aka SSO enables apps to require only one account's username and password to access multiple applications. A single identity is tied to a user, and that identity's access can be modified by admins.
  • Application & device management: access to cloud and on-premises apps can be managed with an account within Entra ID, and Entra can recognize devices.

Entra has a subproduct called Entra Domain Services, which brings the power and feature set of Entra to older & legacy applications that are either on-premises or were ported to Azure App Services. When you set up EDS, you define a unique namespace during setup which becomes the domain name. EDS then deploys two Windows Server domain controllers into your Azure region, and Azure manages these for you.

An issue with EDS is that if you create resources in EDS, they aren't synchronized back to your Entra ID instance. You can use Entra Connect Sync to do this.

Describe Azure authentication methods

Authentication is the process of establishing the identity of a person, service, or device. It requires the person, service, or device to provide some type of credential to prove who they are. It's like presenting ID when travelling in the real world; it proves that you are who you say you are.

Single Sign-On (SSO) enables a user to sign in one time and use that credential to access multiple resources and apps from different providers. Those apps and resources must trust the initial authenticator.

More identities = more passwords, and password policies change between resources & apps. SSO helps lower the complexity for the user in terms of tracking passwords and provide security by mitigating credential-related security vulnerabilities caused by juggling usernames & passwords.

SSO is only as secure as the initial authenticator because subsequent connections are all based on the security of the authenticator.

Multifactor Authentication (MFA) is the process of prompting a user for an extra form (aka factor) of identification during sign-in. MFA helps protect against users with compromised passwords by requiring separate and multiple entities to authenticate before a full authentication.

MFA entities fall into three categories:

  • Something the user knows, like a challenge question
  • Something the user has, like a code sent to a phone via text
  • Something the user is, like a biometric scan

Entra provides MFA as one of its services.

Passwordless Authentication is also available. It's a service that needs to be set up on a device of some kind, then registered with Entra before it can work. Some ways this is implemented are:

  • Windows Hello for Business
    • Service provided by Microsoft tied directly to a user's device via Windows. A user's pin and/or biometric info are stored in Windows Hello, preventing access from anyone except the owner
  • Microsoft Authenticator
    • Smartphone app. Users can access code challenges and respond to MFA requests from it.
  • FIDO2 Security Keys
    • These "are an unphishable standards-based passwordless authentication method that can come in any form factor." These are usually USB fobs that plug into a device, but can also be Bluetooth or NFC keys.

Describe Azure external identities

An external identity is a person, device, service, etc. that is outside an organization. Entra External ID refers to all the ways we can securely interact with users outside the organization.

Entra ExID is similar to SSO: external users/groups can "bring their own identity" and ExID relies on the service(s) they use to manage their identity to properly authenticate who they are. Basically, ExID is how Entra provides a way for external services to use SSO with your services on Azure.

There are three concrete capabilities of ExID:

  • Business to Business Collaboration (B2B): collaboration with external users by allowing them to sign in to your apps on Azure with their preferred identity. B2B Collaboration users are represented in our user directory, usually as guests.
  • B2B Direct Connect: mutual two-way trust between Entra instances at two separate organizations. B2B Direct Connect users aren't represented in our user directory.
  • Azure Active Directory Business to Consumer (AAD B2C): ExID connects with an instance of Azure Active Directory to allow customers to sign in to your apps on Azure

Describe Azure conditional access

Taken right from the introduction: Conditional Access is a tool that Microsoft Entra ID uses to allow (or 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.

With conditional access, you can gather signals like who a user is, where they are, etc., and make decisions based on those signals on how much access to provide, if any at all. Conditional access will then enforce the decision.

Conditional Access is useful when you need to:

  • Require MFA
  • Require access to services only through approved applications
  • Require user to access services only from managed devices
  • Block access from untrusted sources

Describe Azure role-based access control

The principle of least privilege says you should only grant access up to the level needed to complete a task. Azure lets you have fine-grained control of who in your org can access storage blobs, databases, etc. (your resources) with Azure Role-Based Access Control (Azure RBAC). RBAC provides built-in roles but you can define your own.

RBAC works via roles and scopes. A role is a level of access status. A scope is a resource or group of resources that have an access rule applied to them. 

There are four major types of scopes:

  • Management group
  • Subscription
  • Resource group
  • Resource

Azure RBAC is hierarchical: when you grant access at a parent scope, those permissions are inherited by all child scopes.

RBAC is enforced on any action that's initiated against an Azure resource that passes through Azure Resource Manager. In this context, ARM is a management service that provides a way to organize and secure your cloud resources (resource groups). RBAC is not enforced at the application or data level and app security must be handled by your app.

RBAC uses an "allow" model, i.e., you are allowed to do [x y z]. When a user is given a role, RBAC allows the user to perform actions within the scope of the assigned role. If one role grants read permissions to a resource, a user can view the content of that resource. If another gives write permissions, a user can edit it. In conjunction, the two roles give read-write permissions to a user.

Describe Zero Trust model

Module summarizes it best: Zero Trust is a security model that assumes the worst case scenario and protects resources with that expectation. Zero Trust assumes breach at the outset, and then verifies each request as though it originated from an uncontrolled network.

Zero Trust has three guiding principles:

  • Verify explicitly: always authenticate and authorize
  • Use least-privilege access: limit user access with JIT and JEA (Just Enough Access), risk-based adaptive policies, and data protection
  • Assume breach: always assume the worst has happened and minimize the amount of possible damage a hacker could inflict by segmenting access. Verify e2e encryption and use analytics to watch your IT perimeter.

Describe defense-in-depth

From the module: The objective of defense-in-depth is to protect information and prevent it from being stolen by those who aren't authorized to access it. A defense-in-depth strategy uses a series of mechanisms to slow the advance of an attack that aims at acquiring unauthorized access to data.

DID is best visualized as layers of defense:

  • Physical Security
  • Identity and Access Layer
  • Perimeter (DDOS protection)
  • Network (limiting communication between resources through segmentation and access control)
  • Compute (controls access to virtual machines)
  • Application (coverage of vulnerabilities and sanitizing of incoming data)
  • Data (the big thing to protect)

Describe Microsoft Defender for Cloud

This is a shill module for another Azure service. The module summary is enough:

Defender for Cloud is a monitoring tool for security posture management and threat protection. It monitors your cloud, on-premises, hybrid, and multicloud environments to provide guidance and notifications aimed at strengthening your security posture. 

Defender for Cloud provides the tools needed to harden your resources, track your security posture, protect against cyber attacks, and streamline security management. Deployment of Defender for Cloud is easy, it’s already natively integrated to Azure.

Back to top