/AZ-500

Study guide that maps the Exam AZ-500: Microsoft Azure Security Technologies - Skills Measured PDF

Study Guide for Exam AZ-500: Microsoft Azure Security Technologies

Updated June 2022 - Note that sections denoted with xxx are incomplete.

Manage identity and access (30-35%)

Manage Azure Active Directory identities

Term Description
Azure Active Directory (AD) Directories, subscriptions, and users - Microsoft offers several cloud-based offerings today - all of which can use Azure AD to identify users and control access. When a company or organization signs up to use one of these offerings, they are assigned a default directory, an instance of Azure AD. This directory holds the users and groups that will have access to each of the services the company has purchased. This default directory can be referred to as a tenant. A tenant represents the organization and the default directory assigned to it.

Subscriptions in Azure are 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. If your organization wants a subscription billed to another account, you can transfer the subscription. A subscription is associated with a single Azure AD directory. Multiple subscriptions can trust the same directory, but a subscription can only trust one directory.

Users and groups can be added to multiple subscriptions - this allows the user to create, control, and access resources in the subscription. When you add a user to a subscription, the user must be known to the associated directory as shown in the following image.
Conceptual art showing users, directories, and subscriptions in Azure.
If you belong to multiple directories, you can switch the current directory you are working in through the Directory + subscription button in the Azure portal header.
Screenshot showing the Directory selection dialog in Azure portal.
You can also decide how the default directory is selected: last visited or a specific directory. You can also set the default filter for displayed subscriptions. Default filters are useful if you have access to several subscriptions but typically only work in a few of them.
Built-in Azure AD roles Azure AD provides several built-in roles to cover the most common security scenarios. To understand how the roles work, let's examine three roles that apply to all resource types:

Owner, which has full access to all resources, including the right to delegate access to others.
Contributor, which can create and manage all types of Azure resources but can’t grant access to others.
Reader, which can view existing Azure resources.

Each role is a set of properties defined in a JavaScript Object Notation (JSON) file. This role definition includes a Name, ID, and Description. It also includes the allowable permissions (Actions), denied permissions (NotActions), and scope (for example, read access) for the role. For the Owner role, that means all actions, indicated by an asterisk (*); no denied actions; and all scopes, indicated by a forward slash (/).

A role definition is a collection of permissions. A role definition lists the operations that can be performed, such as read, write, and delete. It can also list the operations that can't be performed or operations related to underlying data and has the following structure.
Id = Unique identifier for the role, assigned by Azure.
IsCustom = True if a custom role, False if a built-in role.
Description = A readable description of the role.
Actions [] = Allowed permissions, * indicates all.
NotActions [] = Denied permissions.
DataActions [] = Specific allowed permissions as applied to data, for example: Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
NotDataActions [] = Specific denied permissions as applied to data.
AssignableScopes [] = Scopes where this role applies. / indicates global, but can reach into a hierarchical tree.
Azure AD users Typically, Azure AD defines users in three ways:
1 - Cloud identities - These users exist only in Azure AD. Examples are administrator accounts and users that you manage yourself. Their source is Azure Active Directory or External Azure Active Directory if the user is defined in another Azure AD instance but needs access to subscription resources controlled by this directory. When these accounts are removed from the primary directory, they are deleted.
2 - Directory-synchronized identities - These users exist in an on-premises Active Directory. A synchronization activity that occurs via Azure AD Connect brings these users in to Azure. Their source is Windows Server AD.
3 - Guest users - These users exist outside Azure. Examples are accounts from other cloud providers and Microsoft accounts, such as an Xbox LIVE account. Their source is Invited user. This type of account is useful when external vendors or contractors need access to your Azure resources. Once their help is no longer necessary, you can remove the account and all of their access.

You can add cloud identities to Azure AD in multiple ways:

• Syncing an on-premises Windows Server Active Directory
• Using the Azure portal
• Using the command line

Azure AD Connect is a separate service that allows you to synchronize a traditional Active Directory with your Azure AD instance. This is how most enterprise customers add users to the directory. The advantage to this approach is users can use single sign-on (SSO) to access local and cloud-based resources.
Group and membership An Azure AD group helps organize users making it easier to manage permissions. Using groups lets the resource owner (or Azure AD directory owner), assign a set of access permissions to all the members of the group, instead of having to provide the rights one-by-one. Groups allow us to define a security boundary and then add and remove specific users to grant or deny access with a minimum amount of effort. Even better, Azure AD supports the ability to define membership based on rules - such as what department a user works in, or the job title they have.

Azure AD allows you to define two different types of groups.
1 - Security groups. These are the most common and are used to manage member and computer access to shared resources for a group of users. For example, you can create a security group for a specific security policy. By doing it this way, you can give a set of permissions to all the members at once, instead of having to add permissions to each member individually. This option requires an Azure AD administrator.
2 - Microsoft 365 groups. These groups provide collaboration opportunities by giving members access to a shared mailbox, calendar, files, SharePoint site, and more. This option also lets you give people outside of your organization access to the group. This option is available to users as well as admins.

Screenshot of the Create Group feature in the Azure portal.
Group "membership type" can be of the following 3 types:
1. Assigned (static). The group will contain specific users or groups that you select.
2. Dynamic user. You create rules based on characteristics to enable attribute-based dynamic memberships for groups. For example, if a user’s department is Sales, that user will be dynamically assigned to the Sales group. Security groups can be used for either devices or users, but Microsoft 365 Groups can be only used for user groups. If the user's department changes in the future, they are automatically removed from the group. This feature requires an Azure AD Premium P1 license.
3. Dynamic device. You create rules based on characteristics to enable attribute-based dynamic memberships for groups. For example, if a user’s device is associated with the Service department, that device will be dynamically assigned to the Service group. Security groups can be used for either devices or users, but Microsoft 365 Groups can be only used for user groups. If the device's association with a particular department changes in the future, it is automatically removed from the group. This feature requires an Azure AD Premium P1 license.
Administrative Units in Azure AD An administrative unit is an Azure AD resource that can be a container for other Azure AD resources. An administrative unit can contain only users, groups, or devices. Administrative units restrict permissions in a role to any portion of your organization that you define.

For example, a large university that's made up of many autonomous schools (School of Business, School of Engineering, and so on). Each school has a team of IT admins who control access, manage users, and set policies for their school.

A central administrator could:
- Create an administrative unit for the School of Business.
- Populate the administrative unit with only students and staff within the School of Business.
- Create a role with administrative permissions over only Azure AD users in the School of Business administrative unit.
- Add the business school IT team to the role, along with its scope.

Screenshot of Devices and Administrative units page with Remove from administrative unit option.
Authentication options decision tree Identity is the new control plane of IT security, so authentication is an organization’s access guard to the new cloud world. Organizations need an identity control plane that strengthens their security and keeps their cloud apps safe from intruders.
Azure AD authentication decision tree
Details on decision questions:
1. Azure AD can handle sign-in for users without relying on on-premises components to verify passwords.
2. Azure AD can hand off user sign-in to a trusted authentication provider such as Microsoft’s AD FS.
3. If you need to apply, user-level Active Directory security policies such as account expired, disabled account, password expired, account locked out, and sign-in hours on each user sign-in, Azure AD requires some on-premises components.
4. Sign-in features not natively supported by Azure AD:
  - Sign-in using smartcards or certificates.
  - Sign-in using on-premises MFA Server.
  - Sign-in using third-party authentication solution.
  - Multi-site on-premises authentication solution.
5. Azure AD Identity Protection requires Password Hash Sync regardless of which sign-in method you choose, to provide the Users with leaked credentials report. Organizations can fail over to Password Hash Sync if their primary sign-in method fails and it was configured before the failure event.
Hybrid identity Hybrid identity referes to an identity solution that allows users both on-premises and in the cloud to authenticate using a single common user identity.

Three hybrid authentication models exist within Azure:
Password hash synchronization (PHS) - Password hash synchronization is one of the sign-in methods used to accomplish hybrid identity. Azure AD Connect synchronizes a hash, of the hash, of a user's password from an on-premises Active Directory instance to a cloud-based Azure AD instance.
Pass-through authentication (PTA) - Azure Active Directory (Azure AD) pass-through authentication allows your users to sign in to both on-premises and cloud-based applications by using the same passwords. Pass-through authentication signs users in by validating their passwords directly against on-premises Active Directory.
Federated authentication - Federation is a collection of domains that have established trust. The level of trust may vary, but typically includes authentication and almost always includes authorization.

Azure AD Connect provides a simplified method to enable these hybrid solutions and allow users to log into Azure AD resources using their on-premises password.
Different external identity types (Guest Users) With External Identities in Azure AD, you can allow people outside your organization to access your apps and resources, while letting them sign in using whatever identity they prefer. Within this framework, Azure AD supports a variety of scenarios from business-to-business (B2B) collaboration to access management for consumer/customer- or citizen-facing applications (business-to-customer, or B2C). Azure AD External Identities focuses less on a user's relationship to your organization and more on how the user wants to sign in to your apps and resources.
John Saville YouTube

To allow guest to have the same permissions as members:
Azure Portal >> Azure AD > External Identities > External collaboration settings

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/B2B_external_collab_settings.png
What is a device identity? A device identity is an object in Azure Active Directory (Azure AD). This device object is similar to users, groups, or applications. A device identity gives administrators information they can use when making access or configuration decisions.

There are three ways to get a device identity:
• Azure AD registration
• Azure AD join
• Hybrid Azure AD join

Device identities are a prerequisite for scenarios like device-based Conditional Access policies and Mobile Device Management with Microsoft Endpoint Manager.
Enable password hash synchronization To use password hash synchronization (PHS) in your environment, you need to:
- Install Azure AD Connect.
- Configure directory synchronization between your on-premises Active Directory instance and your Azure Active Directory instance.
- Enable password hash synchronization.
Passwordless Microsoft offers the following three passwordless authentication options that integrate with Azure Active Directory (Azure AD):
1 - Microsoft Authenticator app - turns any iOS or Android phone into a strong, passwordless credential by allowing users to sign into any platform or browser.
2- FIDO2-compliant security keys - useful for users who sign in to shared machines like kiosks, in situations where use of phones is restricted, and for highly privileged identities.
3 - Windows Hello for Business - best for users on their dedicated Windows computers.
Passwordless Phone <-- How to guide on enabling passwordless sign-in with the Microsoft Authenticator app
Passwordless Security Key <-- How to guide on enabling passwordless security key sign-in
Passwordless Launch Blog Misc information and visuals on the launch of passwordless logon
Microsoft Identity Platform The Microsoft identity platform helps you build applications your users and customers can sign in to using their Microsoft identities or social accounts, and provide authorized access to your own APIs or Microsoft APIs like Microsoft Graph.
There are several components that make up the Microsoft identity platform:
OAuth 2.0 and OpenID Connect standard-compliant authentication service enabling developers to authenticate several identity types, including:
 • Work or school accounts, provisioned through Azure AD
 • Personal Microsoft account, like Skype, Xbox, and Outlook.com
 • Social or local accounts, by using Azure AD B2C
Open-source libraries: Microsoft Authentication Libraries (MSAL) and support for other standards-compliant libraries
Application management portal: A registration and configuration experience in the Azure portal, along with the other Azure management capabilities.
Application configuration API and PowerShell: Programmatic configuration of your applications through the Microsoft Graph API and PowerShell so you can automate your DevOps tasks.
Developer content: Technical documentation including quickstarts, tutorials, how-to guides, and code samples.

For developers, the Microsoft identity platform offers integration of modern innovations in the identity and security space like passwordless authentication, step-up authentication, and Conditional Access. You don’t need to implement such functionality yourself: applications integrated with the Microsoft identity platform natively take advantage of such innovations.
Metro map showing several application scenarios in Microsoft identity platform
Azure AD pricing Free = This provides user and group management in Azure and provides on-premeis directory synchronization, basic reports and self-service password changes for cloud users.

Premium P1 ($6/user/mo) = Designed to empower organizations with more demanding identity and access management needs, Azure Active Directory Premium edition adds feature-rich enterprise-level identity management capabilities and enables hybrid users to seamlessly access on-premises and cloud capabilities (dynamic groups, cloud write-back, and self-service password reset for on-premesis users). This edition includes everything you need for information worker and identity administrators in hybrid environments across application access, self-service identity and access management (IAM), and security in the cloud.

Premium P2 ($9/user/mo) = Azure Active Directory Premium P2 includes every feature of all other Azure Active Directory editions enhanced with Advanced Identity Protection (AIP) and Privileged Identity Management (PIM) capabilities.

Feature comparisons for each tier located on Active Directory documentation.

Configure secure access by using Azure AD

Term Description
Privileged Identity Management (PIM) Privileged Identity Management (PIM) is a service in Azure Active Directory (Azure AD) that enables you to manage, control, and monitor access to important resources in your organization. These resources include resources in Azure AD, Azure, and other Microsoft Online Services such as Microsoft 365 or Microsoft Intune.

PIM Capabilities
• Just-In-Time (JIT) priveleged access to Azure AD and Azure resource
• You can assign time-bound access to resources using start and end dates (useful for guests/contractors)
• Require approval to activate privileged roles
• Enforcement of MFA to activate role
• Text box for user justification on their need to access a resources, which assists with internal / external audits. (This may also include a ITSM ticket number.)
• Automated notifications (alert / SOC team)
• Downloadable audit history for internal / external audits.
• Prevents removal of the last active Global Administrator role assignment
• Access Reviews - Create access reviews to determine whether a users still needs access. This is sometimes referred to as an attestation campaign and can be delegated to groups or users to perform. Access reviews can also be automated to fail secure and remove access.

PIM works with all built in and custom Azure AD Roles and Azure Resource Roles and is a CLOUD ONLY identity management solution.

Capabilities of Privileged Identity Management (PIM)
Getting started in PIM 💻 Read the referenced URL for additional information 💻

Licensing Prerequisites
To use Privileged Identity Management, you must have one of the following licenses:
• Azure AD Premium P2
• Enterprise Mobility + Security (EMS) E5

Permissions
• Global administrators and Privileged Role administrators can create reviews on role-assignable groups.
• (Preview) Microsoft 365 and Security group owner.
PIM configuration settings 💻 Read the referenced URL for additional information 💻

For Assignment duration you can choose ONE eligible assignment duration and ONE active assignment duration

Eligible assignment duration options:
1 - Allow permanent eligible assignment = Global admins and Privileged role admins can assign permanent eligible assignment.
2 - Expire eligible assignment after = Global admins and Privileged role admins can require that all eligible assignments have a specified start and end date.

Active assignment duration options:
1 - Allow permanent active assignment = Global admins and Privileged role admins can assign permanent active assignment.
2 - Expire active assignment after = Global admins and Privileged role admins can require that all active assignments have a specified start and end date.

Note: All assignments that have a specified end date can be renewed by Global admins and Privileged role admins. Also, users can initiate self-service requests to extend or renew role assignments.

Additional options confugrations include:
  • Require multifactor authentication - On activation
  • Require multifactor authentication - On active assignment
  • Activation maximum duration
  • Require justification
  • Require ticket information on activation
  • Require approval to activate
  • Notifications
Assign Azure AD roles in PIM 💻 Read the referenced URL for additional information 💻

Azure Portal >> Privileged Identity Management >> Manage: Azure AD Roles
Activate and configure PIM - demo 💻 Read the referenced URL for additional information 💻

Azure Portal >> Privileged Identity Management

Update:
If a user who is logged in as a Global Admin or sufficiently privileged role in an Azure AD organization with a Premium P2 license goes to Roles and administrators in Azure AD and just visits Privileged Identity Management:
1 - PIM is automatically enabled for the organization
2 - Their experience is now that they can either assign a "regular" role assignment or an eligible role assignment

When PIM is enabled it doesn't have any other effect on your organization that you need to worry about. It gives you additional assignment options such as active vs eligible with start and end time. PIM also enables you to define scope for role assignments using Administrative Units and custom roles. If you are a Global Administrator or Privileged Role Administrator, you might start getting a few additional emails like the PIM weekly digest. You might also see MS-PIM service principal in the audit log related to role assignment. This is an expected change that should have no effect on your workflow.

Note that when selecting "Azure Resources" under "Management", you're not delegating Azure AD roles, but rather delegating roles associated with your Azure resources.
Conditional Access Conditional Access is a feature of Azure AD that provides an extra layer of security before allowing authenticated users to access data or other assets. Conditional Access is implemented through policies that are created and managed in Azure AD. A Conditional Access policy analyses signals including user, location, device, application, and risk to automate decisions for authorizing access to resources (apps and data). What is Conditional Access?

You can also provide acces to users based on signals available when creating the CA policy.
Common signals include:
• User or group membership = Will only apply policies to certain users and groups
• IP location = Block or allow access from certain IP addresses
• Device = Block or allow access based on how the device is managed
• Real-time and calculated risk detection - Azure Identity Protection can be used to identiy the sign-in risk behavior. The policy can then be used to block or allow access based on risk severity.
Uses and benefits of conditional access When the Conditional Access policy has been applied, an informed decision is reached on whether to grant access, block access, or require extra verification. The decision is referred to as the access controls portion of the Conditional Access policy and defines how a policy is enforced. Common decisions
• Block access
     • Most restrictive decision
          • Grant access
               • Least restrictive decision, can still require one or more of the following options:
               • Require multi-factor authentication
               • Require device to be marked as compliant
               • Require Hybrid Azure AD joined device
               • Require approved client app
               • Require app protection policy (preview)

Many organizations have common access concerns that Conditional Access policies can help with such as:
• Requiring multi-factor authentication for users with administrative roles
• Requiring multi-factor authentication for Azure management tasks
• Blocking sign-ins for users attempting to use legacy authentication protocols
• Requiring trusted locations for Azure AD Multi-Factor Authentication registration
• Blocking or granting access from specific locations
• Blocking risky sign-in behaviors
• Requiring organization-managed devices for specific applications
Building a Conditional Access policy 💻 Read the referenced URL for additional information 💻
Azure Multi-Factor Authentication Multi-factor authentication (MFA) provides additional security for your identities by requiring two or more elements for full authentication. These elements fall into three categories:
• Something you know
• Something you possess
• Something you are

Multi-Factor Authentication comes as part of the following offerings:
• Azure Active Directory Premium or Microsoft 365 Business - Both of these offerings support Azure AD Multi-Factor Authentication using security defaults to require multi-factor authentication.
• Azure AD Free or standalone Microsoft 365 licenses - Use security defaults that require multi-factor authentication for your users and administrators.
• Azure Active Directory Global Administrators - A subset of Azure AD Multi-Factor Authentication capabilities are available as a means to protect global administrator accounts.
Access reviews in Azure AD 💻 Read the referenced URL for additional information 💻
Azure Portal >> Identity Governance >> Access reviews
Access review in PIM 💻 Read the referenced URL for additional information 💻
Azure Portal >> Privileged Identity Management >> Manage: Azure AD Roles
Azure Portal >> Privileged Identity Management >> Manage: Azure resources

Manage application access

Term Description
App registration Azure portal -> App registrations -> New application

An app registration includes these details:
• Name. This value identifies the registration and application.
• Application type. Use the Web app/API type for websites or web APIs that are accessed through the HTTP protocol. Use the Native type for applications that are installed on a user's device or computer.
• Sign-on URL. This value is the location of the sign-on page in the published application.
• Application ID. This generated GUID is unique to the registration. Configure your application to send the same GUID to Azure AD whenever it authenticates a user.

1 - Tutorial: Register an app with Azure Active Directory
2 - Security best practices for application properties in Azure Active Directory
Azure AD consent framework Multi-tenant applications allow sign-ins by user accounts from Azure AD tenants other than the tenant in which the app was initially registered. The Microsoft identity platform consent framework enables a tenant administrator or user in these other tenants to consent to (or deny) an application's request for permission to access their resources.

For example, perhaps a web application requires read-only access to a user's calendar in Microsoft 365. It's the identity platform's consent framework that enables the prompt asking the user to consent to the app's request for permission to read their calendar. If the user consents, the application is able to call the Microsoft Graph API on their behalf and get their calendar data.
Managed identities in Azure Azure AD identities include the following:

User - A user identity is a representation of something that's managed by Azure AD. Employees and guests are represented as users in Azure AD. If you have several users with the same access needs, you can create a group. You use groups to give access permissions to all members of the group, instead of having to assign access rights individually.

Service principal - A service principal is a security identity used by applications or services to access specific Azure resources. You can think of it as an identity for an application that is commonly reffered to by its Service Principal Name (SPN).

Device - A device is a piece of hardware, such as mobile devices, laptops, servers, or printer. Device identities can be set up in different ways in Azure AD, to determine properties such as who owns the device.

Managed identity - Managed identities are typically used to manage the credentials for authenticating a cloud application with an Azure service. Managed identities are automatically managed in Azure AD and may be user assigned or system assigned.

There are several benefits to using managed identities, including:
• Application developers can authenticate to services that support managed identities for Azure resources.
• Any Azure service that supports Azure AD authentication can use managed identities to authenticate to another Azure service; for example, accessing Azure Key Vault. Managed identities can be used without any extra cost.

https://github.com/RickKotlarz/media-files/blob/main/media/Azure-managed-identity-types.png?raw=true

Resources that support system assigned managed identities allow you to:
• Enable or disable managed identities at the resource level.
• Use role-based access control (RBAC) to grant permissions.
• View the create, read, update, and delete (CRUD) operations in Azure Activity logs.
• View sign in activity in Azure AD sign in logs.

If you choose a user assigned managed identity instead:
• You can create, read, update, and delete the identities.
• You can use RBAC role assignments to grant permissions.
• User assigned managed identities can be used on more than one resource.
• CRUD operations are available for review in Azure Activity logs.
• View sign in activity in Azure AD sign in logs.

Operations on managed identities can be performed by using an Azure Resource Manager template, the Azure portal, Azure CLI, PowerShell, and REST APIs.

Regardless of the type of identity chosen, a managed identity is a service principal of a special type that can only be used with Azure resources. When the managed identity is deleted, the corresponding service principal is automatically removed.

Manage access control

Term Description
Role-based access control (RBAC) Azure RBAC is a newer authorization system that provides fine-grained access management to Azure resources. RBAC includes many built-in roles, can be assigned at different scopes, and allows you to create your own custom roles. The way you control access to resources using RBAC is to create role assignments. This is a key concept to understand – it’s how permissions are enforced.

Role assignments control access to resources and require three elements:
1 - Security principal ("who" // user, group, app)
2 - Role definition ("what" // collection of permissions)
3 - Scope ("where" // access given)

Azure RBAC is an allow model. What this means is that when you are assigned a role, Azure RBAC allows you to perform certain actions, such as read, write, or delete. So, if one role assignment grants you read permissions to a resource group and a different role assignment grants you write permissions to the same resource group, you will have read and write permissions on that resource group.

Difference between Azure RBAC and Azure Policy
Azure RBAC manages who has access to Azure resources, what area they have access to, and what they can do with those resources.
Azure Policies focus on resoure properties during deployment and for already existing resources.
RBAC scope Scope is "where" the access applies and can be specefied at multiple levels:
  management group
  subscription
  resource group
  resource

Scopes are structured in a parent-child relationship. When you grant access at a parent scope, those permissions are inherited by the child scopes. For example, if you assign the Contributor role to a group at the subscription scope, that role is inherited by all resource groups and resources in the subscription.

https://docs.microsoft.com/en-us/learn/modules/secure-azure-resources-with-rbac/media/2-rbac-scope.png

IMPORTANT:
Azure AD roles allow you to grant granular permissions to your admins, abiding by the principle of least privilege. Azure AD built-in and custom roles operate on concepts similar to those you will find in the role-based access control system for Azure resources (Azure roles). The difference between these two role-based access control systems is:

• Azure AD roles - control access to Azure AD resources such as users, groups, and applications using the Microsoft Graph API. These are applied at the tenant level ONLY.
• Azure roles - control access to Azure resources such as virtual machines or storage using Azure Resource Management. These can be applied at the subscription or resource level.
https://docs.microsoft.com/en-us/azure/active-directory/roles/custom-overview
Built-in Azure RBAC roles Azure includes several built-in roles that you can use. The following lists four fundamental built-in roles:

• 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 can’t grant access to others.
• Reader - Can view existing Azure resources but not make changes.
• User Access Administrator - Lets you manage user access to Azure resources.
Create or update Azure custom roles 💻 Read the referenced URL for additional information 💻
Azure RBAC has something called NotActions permissions. Use NotActions to create a set of not allowed permissions. The access granted by a role, the effective permissions, is computed by subtracting the NotActions operations from the Actions operations.

Azure Portal >> Access control (IAM) >> Role asignment >>
  • Create a custom role
  • Grant access to this resource
  • View access to this resource
>> View / Edit the RBAC data elements within the JSON data as needed
Configure custom RBAC roles - demo 💻 Read the referenced URL for additional information 💻

List custom roles
Get-AzRoleDefinition ¦ FT Name, IsCustom

List a custom role definition
Get-AzRoleDefinition "Virtual Machine Operator" ¦ ConvertTo-Json ¦ out-file ".\newCustomeRole.json"
  (edit the JSON to your liking)

Create a new role with the new JSON file
New-AzRoleDefinition -InputFile ".\newCustomeRole.json"
Update a custom role with the PSRoleDefinition object
$role = Get-AzRoleDefinition "Virtual Machine Operator"
$role.Actions.Add("Microsoft.Insights/diagnosticSettings/*")
$role.AssignableScopes.Add("/subscriptions/22222222-2222-2222-2222-222222222222")
$role.AssignableScopes.Add("/providers/Microsoft.Management/managementGroups/{groupId1}")
Set-AzRoleDefinition -Role $role
Resource locks As an administrator, you can lock a subscription, resource group, or resource to prevent other users in your organization from accidentally deleting or modifying critical resources. The lock overrides any permissions the user might have.

You can set the lock level to CanNotDelete or ReadOnly. In the portal, the locks are called Delete and Read-only respectively.
CanNotDelete means authorized users can still read and modify a resource, but they can't delete the resource.
ReadOnly means authorized users can read a resource, but they can't delete or update the resource. Applying this lock is similar to restricting all authorized users to the permissions granted by the Reader role.

Locks can be applied at the resource level, resource group level or at the subscription level.

Implement platform protection (15-20%)

Implement advanced network security

Term Description
Virtual Network Peering Azure supports the following types of peering:
1 - Virtual network peering: Connecting virtual networks within the same Azure region.
2 - Global virtual network peering: Connecting virtual networks across Azure regions.

The benefits of using virtual network peering, whether local or global, include:
• A low-latency, high-bandwidth connection between resources in different virtual networks.
• The ability for resources in one virtual network to communicate with resources in a different virtual network.
• The ability to transfer data between virtual networks across Azure subscriptions, Azure Active Directory tenants,
• deployment models, and Azure regions.
• The ability to peer virtual networks created through the Azure Resource Manager.
• The ability to peer a virtual network created through Resource Manager to one created through the classic deployment model. To learn more about Azure deployment models, see Understand Azure deployment models.
• No downtime to resources in either virtual network when creating the peering, or after the peering is created.

Security reasons to use virtual peering:
• Network traffic between peered virtual networks is private.
• Traffic between the virtual networks is kept on the Microsoft backbone network.
• No public Internet, gateways, or encryption is required in the communication between the virtual networks.

Service chaining
• Service chaining enables you to direct traffic from one virtual network to a virtual appliance or gateway in a peered network through user-defined routes.
• To enable service chaining, configure user-defined routes that point to virtual machines in peered virtual networks as the next hop IP address. User-defined routes could also point to virtual network gateways to enable service chaining.

Gateways and on-premises connectivity
• Each virtual network, including a peered virtual network, can have its own gateway.
• A virtual network can use its gateway to connect to an on-premises network.
• You can also configure VNET-to-VNET connections by using gateways, even for peered virtual networks.
• When you configure both options for virtual network interconnectivity, the traffic between the VNETs flow through the peering configuration and the traffic uses the Azure backbone.

Why create a VNet-to-VNet connection
• Cross region geo-redundancy and geo-presence
• Regional multi-tier applications with isolation or administrative boundary
Site-to-Site VPN • Connects your on-premises network to an Azure virtual network endpoint over an IPsec/IKE (IKEv1 or IKEv2) VPN tunnel.
Point-to-Site connection This is a classic deployment model and is not recommended. It supports Windows VPN clients only, uses the Secure Socket Tunneling Protocol (SSTP), an SSL-based VPN protocol.
ExpressRoute ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a private connection with the help of a connectivity provider. With ExpressRoute, you can establish connections to Microsoft cloud services, such as Microsoft Azure and Microsoft 365.
Network security groups (NSGs) NSGs operate at layers 3 & 4, and provide a list of allowed and denied communication to and from network interfaces and subnets. NSGs are fully customizable, and give you the ability to fully lock down network communication to and from your Azure resources (e.g. virtual machines) in an Azure virtual network. By using NSGs, you can isolate applications between environments, tiers, and services.

Note: NSGs uses static IP addresses and as your network scales this may become difficult to maintain.

For each rule, you can specify source and destination, port, and protocol.

Network security groups are evaluated and applied based on the five-tuple (properties):
• Name = Unique name within the NSG
• Priority = A number between 100 and 4096 used to priorities rules (lower has higher priority)
• Source / Destination = Any, or an individual IP address, classless inter-domain routing (CIDR) block, service tag, or ASG.
• Protocol = TCP, UDP, ICMP, ESP, AH, or Any.
• Direction = Whether the rule applies to inbound, or outbound traffic
• Port range = Single port or range of ports
• Action = Allow or deny

Azure creates the following default rules in each NSG that is created:

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/Default-NSG-rules.png
NSG deployment scenarios 💻 Read the referenced URL for additional information 💻
Virtual network service tags A service tag represents a group of IP address prefixes from a given Azure service. It helps to minimize the complexity of frequent updates on network security rules. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change, minimizing the complexity of frequent updates to network security rules.

You can use service tags to define network access controls on:
• Network security groups
• Azure Firewall
• User-defined routes
Application security groups (ASGs) • Application Security Groups (ASG) are a feature within Azure that helps simplify the management of Network Security Group (NSG) rules.
• Application security groups enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. Application Security Groups (ASG) supplemental
Configure NSGs and ASGs - demo 💻 Read the referenced URL for additional information 💻
Azure Firewall • Azure Firewall is a managed, cloud-based, network security service that protects your Azure Virtual Network resources, has built-in high availability and unrestricted cloud scalability.
• It is a fully stateful firewall meaning that inspects and maintains data on the entire context of the network connection and makes a decision based on current state.
• Azure Firewall provides inbound protection for non-HTTP/S protocols. (e.g. RDP, SSH, FTP)
• It also provides outbound, network-level protection for all ports and protocols, and application-level protection for outbound HTTP/S. Azure Firewall Overview

Azure Firewall is offered in two SKUs:
1 - Azure Firewall Standard provides L3-L7 filtering and threat intelligence feeds directly from Microsoft Cyber Security. Threat intelligence-based filtering can alert and deny traffic from/to known malicious IP addresses and domains which are updated in real time to protect against new and emerging attacks.
2 - Azure Firewall Premium provides advanced capabilities include signature-based Intrusion Detection and Prevention System (IDPS) to allow rapid detection of attacks by looking for specific patterns. These patterns can include byte sequences in network traffic, or known malicious instruction sequences used by malware.

Azure Firewall Concepts

Application FQDN filtering rules
• You can limit outbound HTTP/S traffic or Azure SQL traffic to a specified list of fully qualified domain names (FQDN) including wild cards. This feature doesn't require TLS termination.

Network traffic filtering rules
• You can centrally create allow or deny network filtering rules by source and destination IP address, port, and protocol. Azure Firewall is fully stateful, so it can distinguish legitimate packets for different types of connections. Rules are enforced and logged across multiple subscriptions and virtual networks.
• Azure Firewall supports stateful filtering of Layer 3 and Layer 4 network protocols. Layer 3 IP protocols can be filtered by selecting Any protocol in the Network rule and select the wild-card * for the port.

FQDN tags
• FQDN tags make it easy for you to allow well-known Azure service network traffic through your firewall. For example, say you want to allow Windows Update network traffic through your firewall. You create an application rule and include the Windows Update tag. Now network traffic from Windows Update can flow through your firewall.

Service tags
• A service tag represents a group of IP address prefixes to help minimize complexity for security rule creation. You can't create your own service tag, nor specify which IP addresses are included within a tag. Microsoft manages the address prefixes encompassed by the service tag, and automatically updates the service tag as addresses change.

Outbound SNAT support
• Source Network Address Translation (SNAT) ensures all outbound virtual network traffic IP addresses are translated to the Azure Firewall public IP. You can identify and allow traffic originating from your virtual network to remote Internet destinations. Azure Firewall doesn't SNAT when the destination IP is a private IP range per IANA RFC 1918.
• If your organization uses a public IP address range for private networks, Azure Firewall will SNAT the traffic to one of the firewall private IP addresses in AzureFirewallSubnet. You can configure Azure Firewall to not SNAT your public IP address range.

Inbound DNAT support
• Destination Network Address Translation (DNAT) ensures inbound Internet network traffic to your firewall public IP address is translated and filtered to the private IP addresses on your virtual networks.

Forced tunneling
• You can configure Azure Firewall to route all Internet-bound traffic to a designated next hop instead of going directly to the Internet. For example, you may have an on-premises edge firewall or other network virtual appliance (NVA) to process network traffic before it's passed to the Internet.

Multiple static public IP addresses
• You can associate multiple public IP addresses (up to 250) with your firewall.
• Resides within its own subnet
Azure Firewall Manager Firewall Manager can provide security management for two network architecture types:
1 - Secured virtual hub = An Azure Virtual WAN Hub is a Microsoft-managed resource that lets you easily create hub and spoke architectures. When security and routing policies are associated with such a hub, it is referred to as a secured virtual hub.
2 - Hub virtual network = This is a standard Azure virtual network that you create and manage yourself. When security policies are associated with such a hub, it is referred to as a hub virtual network.

Firewall Manager
• Leverages firewall policies to apply a common set of network/application rules and configurations to the firewalls and secured virtual hubs within your tenant.
• Supports deployment and configuration of multiple Azure Firewall instances that span different Azure regions and subscriptions.
• Can be integrated with third-party security-as-a-service providers
• Easily route traffic to your secured hub for filtering and logging without the need to manually set up User Defined Routes (UDR) on spoke virtual networks. (UDRs are used to override Azure system default routes.)
• Supports firewalls in both VNet and Virtual WANs (Secure Virtual Hub) environments. Secure Virtual Hubs use the Virtual WAN route automation solution to simplify routing traffic to the firewall with a few clicks.
Deploy and configure Azure Firewall 💻 Read the referenced URL for additional information 💻
Web Application Firewall Web applications are increasingly targeted by malicious attacks that exploit commonly known vulnerabilities. SQL injection and cross-site scripting are among the most common attacks.

Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities. A centralized WAF helps make security management simpler, improves the response time to a security threat, and allows patching a known vulnerability in one place, instead of securing each web application. A WAF also gives application administrators better assurance of protection against threats and intrusions. WAF can be deployed with Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN) service from Microsoft.

Introduction to Azure Web Application Firewalls
Azure Application Gateway Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. Traditional load balancers operate at the transport layer (OSI layer 4 - TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port. Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers.

Azure Application Gateway features support the following:

• Secure Sockets Layer (SSL/TLS) termination
• Autoscaling with sizing support
• Zone redundancy
• Static VIP
• Web Application Firewall
• Ingress Controller for AKS
• URL-based routing
• Multiple-site hosting
• Redirection
• OSession affinity
• Websocket and HTTP/2 traffic
• Connection draining
• Custom error pages
• Rewrite HTTP headers and URL
Azure Front Door Azure Front Door is Microsoft’s modern cloud Content Delivery Network (CDN)
• Natively support end-to-end IPv6 connectivity and the HTTP/2 protocol.
• Optimized so that client requests are routed to the fastes and most available application backend.
• Application backends can be any Internet facing service that is hosted inside or outside of Azure.
• Allows for use of Front Door’s anycast network and split TCP connections.
• SSL offloading at the edge
• Free, autorotation managed SSL certificates
• Built-in layer 3-4 DDoS protection
• Easily attached Web Application Firewall (WAF), and Azure DNS to protect your domains.

Azure Front Door is offered in 3 different tiers
1 - Classic
2 - Standard
3 - Premium (Standard + Microsoft managed rule set, Bot protection, and Private link support)

Azure Front Door Standard and Premium tier combines capabilities of Azure Front Door (classic), Azure CDN Standard from Microsoft (classic), and Azure WAF into a single secure cloud CDN platform with intelligent threat protection.

Front Door (classic)
• Operates on Layer 7 or HTTP/HTTPS
• Accelerated application performance by using split TCP-based anycast protocol.
• Intelligent health probe monitoring for backend resources.
• URL-path based routing for requests.
• Enables hosting of multiple websites for efficient application infrastructure.
• Cookie-based session affinity.
• SSL offloading and certificate management.
• Define your own custom domain.
• Application security with integrated Web Application Firewall (WAF).
• Redirect HTTP traffic to HTTPS with URL redirect.
• Custom forwarding path with URL rewrite.
• Native support of end-to-end IPv6 connectivity and HTTP/2 protocol.
Azure Bastion Azure Bastion provides secure and seamless RDP/SSH connectivity to your virtual machines directly from the Azure portal using Transport Layer Security (TLS). When you connect via Azure Bastion, your virtual machines don't need a public IP address, agent, or special client software.

Key features of Azure Bastion include:
• RDP and SSH directly in Azure portal
• Remote session over TLS and firewall traversal for RDP/SSH: Use an HTML5-based web client that's automatically streamed to your local device.
• No Public IP required on the Azure VM
• No hassle of managing NSGs as you don't need to apply any NSGs on an Azure Bastion subnet
• Protection against port scanning
• Protect against zero-day exploits
Create an Azure Bastion host Azure portal >> Resource Groups >> YourRG >> YourVMsVNET >> Subnets >> then add the subnet

• The bastion subnet name MUST be "AzureBastionSubnet" and have a subnet mask /26 or larger
Service endpoints Virtual Network (VNet) service endpoints provide secure and direct connectivity to Azure services over an optimized route over the Azure backbone network rather than the Internet

To enable a service endpoint, you must:
1 - Turn off public access to the service.
2 - Add the service endpoint to a virtual network.

Private Link – The umbrella Azure service under which you can make your PaaS resources available privately on a virtual network.

Private Endpoint – The logical Azure resource, a private endpoint, that is mapped to a private IP address. This is the interface that will be connected to while accessing PaaS resources over your private virtual network.

Private Link Service – The service you make available over private network peering to other business units or customers. The service uses an internal Azure standard load balancer to map the Private Link Service IP to the load balancer front end. You can reference this service via a private endpoint to gain access to these resources without ever interacting with the Internet. This can be accomplished across Azure AD tenants.
Distributed denial of service (DDoS) protection DDoS Protection leverages the scale and elasticity of Microsoft’s global network to bring DDoS mitigation capacity to every Azure region. The Azure DDoS Protection service protects your Azure applications by scrubbing traffic at the Azure network edge before it can impact your service's availability. Within a few minutes of attack detection, you are notified using Azure Monitor metrics.

Comes in two versions:
Azure DDoS Protection Basic (Free)
Azure DDoS Protection Standard (provides SLAs for Application and Cost Protection)

Every property in Azure is protected by Azure's infrastructure DDoS (Basic) Protection at no additional cost and requires no user configuration or application changes.


DDoS Protection Standard can mitigate the following types of attacks:
Volumetric attacks: These attacks flood the network layer with a substantial amount of seemingly legitimate traffic. They include UDP floods, amplification floods, and other spoofed-packet floods. DDoS Protection Standard mitigates these potential multi-gigabyte attacks by absorbing and scrubbing them, with Azure's global network scale, automatically.
Protocol attacks: These attacks render a target inaccessible, by exploiting a weakness in the layer 3 and layer 4 protocol stack. They include SYN flood attacks, reflection attacks, and other protocol attacks. DDoS Protection Standard mitigates these attacks, differentiating between malicious and legitimate traffic, by interacting with the client, and blocking malicious traffic.
Resource (application) layer attacks: These attacks target web application packets, to disrupt the transmission of data between hosts. They include HTTP protocol violations, SQL injection, cross-site scripting, and other layer 7 attacks. Use a Web Application Firewall, such as the Azure

PowerShell for managing network security groups

### Create a network security group
New-AzNetworkSecurityGroup -Name "nsg1" -ResourceGroupName "rg1"  -Location  "westus"

### View all network security groups
Get-AzNetworkSecurityGroup -Name nsg1 -ResourceGroupName "rg1"

### Change a network security group
Get-AzNetworkSecurityGroup -Name "Nsg1" -ResourceGroupName "Rg1" | Add-AzNetworkSecurityRuleConfig -Name "Rdp-Rule" -Description "Allow RDP" -Access "Allow" -Protocol "Tcp" -Direction "Inbound" -Priority 100 -SourceAddressPrefix "Internet" -SourcePortRange "*" -DestinationAddressPrefix "*" -DestinationPortRange "3389" | Set-AzNetworkSecurityGroup

### Delete a network security group
Remove-AzNetworkSecurityGroup -Name "NSG-FrontEnd" -ResourceGroupName "TestRG"

### Create a security rule - Allow RDP
$rule1 = New-AzNetworkSecurityRuleConfig -Name rdp-rule -Description "Allow RDP" `
    -Access Allow -Protocol Tcp -Direction Inbound -Priority 100 -SourceAddressPrefix `
    Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 3389

### Create a security rule - Allow HTTP
$rule2 = New-AzNetworkSecurityRuleConfig -Name web-rule -Description "Allow HTTP" `
    -Access Allow -Protocol Tcp -Direction Inbound -Priority 101 -SourceAddressPrefix `
    Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 80

### View all security rules - Retrieving a network security rule config
Get-AzNetworkSecurityGroup -Name nsg1 -ResourceGroupName rg1 
    | Get-AzNetworkSecurityRuleConfig -Name AllowInternetOutBound -DefaultRules
	
### View all security rules - Retrieving a network security rule config using only the name
Get-AzNetworkSecurityGroup -Name nsg1 -ResourceGroupName rg1 
    | Get-AzNetworkSecurityRuleConfig -Name "rdp-rule"
	
### Change a security rule - Example 1
Set-AzNetworkSecurityRuleConfig -Access Allow -DestinationAddressPrefix * -DestinationPortRange 3389 -Direction Inbound -Name 'rdp-rule' -NetworkSecurityGroup <PSNetworkSecurityGroup> -Priority 1 -Protocol Tcp -SourceAddressPrefix 'Internet' -SourcePortRange *

### Delete a security rule
$rule1 = New-AzNetworkSecurityRuleConfig -Name "rdp-rule" -Description "Allow RDP" -Access "Allow" -Protocol "Tcp" -Direction "Inbound" -Priority 100 -SourceAddressPrefix "Internet" -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 3389
$nsg = New-AzNetworkSecurityGroup -ResourceGroupName "TestRG" -Location "westus" -Name "NSG-FrontEnd" -SecurityRules $rule1

### Remove-AzNetworkSecurityRuleConfig -Name "rdp-rule" -NetworkSecurityGroup $nsg
$nsg | Set-AzNetworkSecurityGroup

### Delete an application security group
Remove-AzApplicationSecurityGroup -Name "MyApplicationSecurityGrouo" -ResourceGroupName "MyResourceGroup"

### Configure advanced security for compute
Term Description
Endpoint protection Defender for Cloud supports various third party endpoint protection solutions.

Use the PowerShell Get-MpComputerStatus CMDlet to identify the health status of endpoint protection configurations and address these issues if...
  AMServiceEnabled = false
  AntispywareEnabled = false
  RealTimeProtectionEnabled = false
  BehaviorMonitorEnabled = false
  IoavProtectionEnabled = false
  OnAccessProtectionEnabled = false
  AntispywareSignatureAge >= 7
  AntivirusSignatureAge >= 7
Vulnerability management with Microsoft Defender for Cloud Microsoft Defender for Endpoint's threat and vulnerability management tools
Microsoft's threat and vulnerability management is a built-in module in Microsoft Defender for Endpoint that can:
• Discover vulnerabilities and misconfigurations in real time with sensors, and without the need of agents or periodic scans.
• Prioritizes vulnerabilities based on the threat landscape, detections in your organization, sensitive information on vulnerable devices, and business context.

Integrated vulnerability assessment solution (powered by Qualys)
Defender for Cloud includes vulnerability scanning for your machines at no extra cost. You don't need a Qualys license or even a Qualys account - everything's handled seamlessly inside Defender for Cloud. This page provides details of this scanner and instructions for how to deploy it.
Update Management Azure Portal >> VM >> Operations (Updates)
Note that the current version of Update Management uses Azure Automation to manage updates and patching for virtual machines.

You can use Update Management in Azure Automation to manage operating system updates for your Windows and Linux virtual machines in Azure, physical or VMs in on-premises environments, and in other cloud environments. You can quickly assess the status of available updates and manage the process of installing required updates for your machines reporting to Update Management.

As a service provider, you may have onboarded multiple customer tenants to Azure Lighthouse. Update Management can be used to assess and schedule update deployments to machines in multiple subscriptions in the same Azure Active Directory (Azure AD) tenant, or across tenants using Azure Lighthouse.

Automatic VM guest patching for Azure VMs
Enabling automatic VM guest patching for your Azure VMs helps ease update management by safely and automatically patching virtual machines to maintain security compliance.
• Patches classified as Critical or Security are automatically downloaded and applied on the VM.
• Patches are applied during off-peak hours in the VM's time zone.
• Patch orchestration is managed by Azure and patches are applied following availability-first principles.
• Virtual machine health, as determined through platform health signals, is monitored to detect patching failures.
• Works for all VM sizes.

Azure virtual machine scale set automatic OS image upgrades
Enabling automatic OS image upgrades on your scale set helps ease update management by safely and automatically upgrading the OS disk for all instances in the scale set. Automatic OS upgrade has the following characteristics:
• Once configured, the latest OS image published by image publishers is automatically applied to the scale set without user intervention.
• Upgrades batches of instances in a rolling manner each time a new image is published by the publisher.
• Integrates with application health probes and Application Health extension.
• Works for all VM sizes, and for both Windows and Linux images including custom images through Azure Compute Gallery.
• You can opt out of automatic upgrades at any time (OS Upgrades can be initiated manually as well).
• The OS Disk of a VM is replaced with the new OS Disk created with latest image version. Configured extensions and custom data scripts are run, while persisted data disks are retained.
• Extension sequencing is supported.
• Can be enabled on a scale set of any size.
Azure App Service Azure App Service is fully managed platform as a service (PaaS) HTTP-based service offering for developers used to host web applications, REST APIs, and mobile back ends. You can develop in your favorite language, be it .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python. Applications run and scale with ease on both Windows and Linux-based environments.

App Service not only adds the power of Microsoft Azure to your application, such as security, load balancing, autoscaling, and automated management. You can also take advantage of its DevOps capabilities, such as continuous deployment from Azure DevOps, GitHub, Docker Hub, and other sources, package management, staging environments, custom domain, and TLS/SSL certificates.
Adding a TLS/SSL certificate in Azure App Service Methods for adding certificates in App Service:
• Create a free App Service managed certificate - A private certificate that's free of charge and easy to use if you just need to secure your custom domain in App Service.
• Purchase an App Service certificate - A private certificate that's managed by Azure. It combines the simplicity of automated certificate management and the flexibility of renewal and export options.
• Import a certificate from Key Vault - Useful if you use Azure Key Vault to manage your PKCS12 certificates. See Private certificate requirements.
• Upload a private certificate - If you already have a private certificate from a third-party provider, you can upload it. See Private certificate requirements.
• Upload a public certificate - Public certificates are not used to secure custom domains, but you can load them into your code if you need them to access remote resources.
Microsoft Defender for Containers Defender for Containers helps with the core aspects of container security:

• Environment hardening - Defender for Containers protects your Kubernetes clusters whether they're running on Azure Kubernetes Service, Kubernetes on-premises/IaaS, or Amazon EKS. By continuously assessing clusters, Defender for Containers provides visibility into misconfigurations and guidelines to help mitigate identified threats.
• Vulnerability assessment - Vulnerability assessment and management tools for images stored in ACR registries and running in Azure Kubernetes Service.
• Run-time threat protection for nodes and clusters - Threat protection for clusters and Linux nodes generates security alerts for suspicious activities.

Security considerations for Azure Container Instances
Azure Kubernetes Service Components Azure managed resources (Control plane):
• kube-apiserver - Used to provide interaction for managment tools
• etcd - Used to maintain the state of the Kubernetes cluster and configuration. This is a key value store.
• kube-scheduler - This determins which noes can be used to run workloads and then starts workloads accordingly.
• kube-controller-manager - This hanles the controllers that are used to contol the replication of pods and node operations.

Customer managed resource (Nodes and node pools):
• kubelet - Used to take control from the control plane and schedules the running of requested containers
• container runtime (containerd) - Used to run the containers and helps containers interact with network and storage resources
• kube-proxy - Used to route network traffic and manages the IP addressing for the services and pods.
• Pods - Used to run an instance of the application. Each pod represents a single instance of the app. Normally each pod is mapped to a single container.
• Deployment - Deployement is used to represent the deployment of one or more idential pods. If the the Scheduler discovers that a any pods or nodes encountered issues, additional pods are created on healthy nodes.
Azure Container Registry service • Azure Container Registry is a managed registry service based on the open-source Docker Registry 2.0. Create and maintain Azure container registries to store and manage your container images and related artifacts.
• This service can be used to store private Docker container images and can be integrated with the Azure Kubernetes service

Authentication with an Azure container registry via:
• Individual AD identity
• AD service principal
• Managed identity for Azure resources
• AKS cluster managed identity
• AKS cluster service principal
• Admin user
• Repository-scoped access token
Access and identity options for Azure Kubernetes Service (AKS) • Using Kubernetes role-based access control (Kubernetes RBAC), you can grant users, groups, and service accounts access to only the resources they need.
• With Azure Kubernetes Service (AKS), you can further enhance the security and permissions structure via Azure Active Directory and Azure RBAC.

Azure Container Registry Roles:
Owner / Contributor = Can do everything EXCEPT sign images
Reader = Can pull an image from the reigstry
ArcPush = Can push AND pull an image from the registry
AcrPull = Can only pull an image from the registry
ArcImageSigner = Allows signing of images

AKS_roles.png
Configure security for container registry Microsoft provides Azure security baseline for Container Registry in the form of Azure Security Benchmarks that provide guidance which are directly applicable to the Container Registry.

Content Trust
• Enable content trust to sign and push images to the registry
• If client side consumers enable content trust, they will only see signed images
• Signed images are considered genuine and free from tampering.

Integration with Security Center
• Azure Security Center (standard SKU) can integrate with Azure container registry
• Security Center will then scan all images pushed to the Azure container registry
Network concepts for applications in AKS Services
To simplify the network configuration for application workloads, Kubernetes uses Services to logically group a set of pods together and provide network connectivity.

Azure virtual networks
In AKS, you can deploy a cluster that uses one of the following two network models:
  1. Kubenet networking - The network resources are typically created and configured as the AKS cluster is deployed.
  2. Azure Container Networking Interface (CNI) networking - The AKS cluster is connected to existing virtual network resources and configurations.

Ingress controllers
 • When you create a LoadBalancer-type Service, you also create an underlying Azure load balancer resource. The load balancer is configured to distribute traffic to the pods in your Service on a given port.
 • The LoadBalancer only works at layer 4. At layer 4, the Service is unaware of the actual applications, and can't make any more routing considerations.
 • Ingress controllers work at layer 7, and can use more intelligent rules to distribute application traffic. Ingress controllers typically route HTTP traffic to different applications based on the inbound URL. With the Application Gateway Ingress Controller (AGIC) add-on, AKS customers leverage Azure's native Application Gateway level 7 load-balancer to expose cloud software to the Internet.

Network policies
 • By default, all pods in an AKS cluster can send and receive traffic without limitations. To improve security, define rules that control the flow of traffic to only resources that must have that traffic.
 • Network policy is a Kubernetes feature available in AKS that lets you control the traffic flow between pods. You allow or deny traffic to the pod based on settings such as assigned labels, namespace, or traffic port. While network security groups are better for AKS nodes, network policies are a more suited, cloud-native way to control the flow of traffic for pods. As pods are dynamically created in an AKS cluster, required network policies can be automatically applied.

Manage security operations (25-30%)

Monitor security by using Azure Monitor

Term Description
Azure Monitor Azure Monitor maximizes the availability and performance of your applications and services by delivering a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments (assumes you install the Log Analytics Agent). It helps you understand how your applications are performing and proactively identifies issues affecting them and the resources they depend on.

Just a few examples of what you can do with Azure Monitor include:

• Detect and diagnose issues across applications and dependencies with Application Insights.
• Correlate infrastructure issues with VM insights and Container insights.
• Drill into your monitoring data with Log Analytics for troubleshooting and deep diagnostics.
• Support operations at scale with automated actions.
• Create visualizations with Azure dashboards and workbooks.
• Collect data from monitored resources by using Azure Monitor Metrics.
• Investigate change data for routine monitoring or for triaging incidents by using Change Analysis.

Types of data collected include:
• Application monitoring data = Data collected with regards to the perforamance and functionality of application code
• Guest OS monitoring data = Data collected about the underlying operating system (Windows / Linux event logs) on which the app runs. The OS can be running in Azure, another cloud or on-premises.
• Azure resource monitoring data = Data about the operation of an Azure resource
• Azure subscription monitoring data: Data about the operation and management of an Azure subscription, and data about the health and operation of Azure itself.
• Azure tenant monitoring data = Data about the operation of tenant-level Azure services, such as Azure Active Directory
• Azure resource change data = Data about changes within your Azure resources and how to address and triage incidents and issues.

Azure Monitor Overview
Azure Monitor Alerts
A data type will be a metric, a log, or both a metric and a log:

• The focus for metric-based data types is the numerical time-sensitive values that represent some aspect of the target resource.
• The focus for log-based data types is the querying of content data held in structured, record-based log files that are relevant to the target resource.


Three signal types that you can use to monitor your environment:

1 - Metric alerts provide an alert trigger when a specified threshold is exceeded. For example, a metric alert can notify you when CPU usage is greater than 95 percent.
2 - Activity log alerts notify you when Azure resources change state. For example, an activity log alert can notify you when a resource is deleted.
3 - Log alerts are based on things written to log files. For example, a log alert can notify you when a web server has returned a number of 404 or 500 responses.
Create, view, and manage log alerts using Azure Monitor Azure Monitor log alerts allow users to use a Log Analytics query to evaluate resource logs at a set frequency and fire an alert based on the results. Rules can trigger one or more actions using alert processing rules and action groups. Learn the concepts behind log alerts here.

Azure portal >> Resource, RG, or Subscription >> (Monitoring) "Alerts" >> Create

- OR -

Azure portal >> Resource, RG, or Subscription >> Logs
    >> Select existing rule or create one >> New Rule Alert

You create an alert rule by combining:
1 - The resource(s) to be monitored.
2 - The signal or telemetry from the resource
3 - Conditions

And then defining these elements of the triggered alert:
1 - Alert processing rules
2 - Action groups
Configuring diagnostic logging and log retention
First - Create a Log Analytics Workspaces
• Azure Portal >> Log Analytics Workspaces >> Create a new Log Analytics Workspace

• Log Analytics Workspaces >> (Workspace Data Sources) Select data source you want to view
• To deploy the agent to a new source simply select that source followed by "Connect"

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/Log_anlytics_workspace.png

Azure Portal >> Log Analytics Workspaces >> Settings (Agents management)
• Agents management = Allows you to download Log Analytics agents

Azure Portal >> Log Analytics Workspaces >> Settings (Agents configuration)
• Agents configuration = Allows you to customize data that is collected

Second - Navigate to that the resource you want to monitor and enable logging

SaaS = ResourceYouWantToMonitor >> Monitoring >> Diagnostics settings >> "Add diagnostic setting"

Destination options
  • Send to Log Analytics workspace
  • Archive to a storage account
  • Stream to an event hub
  • Send to partner solution

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/Diagnostic_Settings_SaaS.png

VMs = Azure Portal >> ResourceYouWantToMonitor >> Monitoring >> Diagnostics settings >> Custom

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/Diagnostic_Settings_VM.png

Note that the VM has to be on, a data store configured and the Log Analtyics Engine connected.

Note that while you're able to configure additional custom logs platform metrics are sent automatically to Azure Monitor Metrics via the deployed agent by default and without configuration. Platform logs provide detailed diagnostic and auditing information for Azure resources and the Azure platform they depend on.

• Resource logs are not collected until they are routed to a destination.
• The Activity Log exists on its own but can be routed to other locations.

Each Azure resource requires its own diagnostic setting, which defines the following criteria:

• Sources - The type of metric and log data to send to the destinations defined in the setting. The available types vary by resource type.
• Destinations - One or more destinations to send to.

A single diagnostic setting can define no more than one of each of the destinations. If you want to send data to more than one of a particular destination type (for example, two different Log Analytics workspaces), then create multiple settings. Each resource can have up to 5 diagnostic settings.

Monitor security by using Azure Security Center

Term Description
Overview of Azure Security Center xxx
Monitor security with Azure Security Center xxx
Centralized policy management xxx
Configure security settings by using Azure Policy xxx
Vulnerability scanner xxx
Enable JIT VM access Just-in-time VM access enables you to lock down your VMs in the network level by blocking inbound traffic to specific ports. It enables you to control the access and reduce the attack surface to your VMs, by allowing access only upon a specific need.

Upon a user request, based on Azure RBAC, Defender for Cloud will decide whether to grant access. If a request is approved, Defender for Cloud automatically configures the NSGs to allow inbound traffic to these ports, for the requested amount of time, after which it restores the NSGs to their previous states.

To enable JIT for VM's:
Azure Portal >> Defender for Cloud >> (Cloud Security) Workload protections, (Advanced) JIT VM Access

To access:
Azure Portal >> VMs >> Connect >> Request Access
Azure Security Center - demo xxx

Monitor security by using Azure Sentinel

Term Description
Azure Sentinel Microsoft Sentinel is a scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution. Microsoft Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response.

Key features include:
Collect data at cloud scale across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds.
Detect previously undetected threats, and minimize false positives using Microsoft's analytics and unparalleled threat intelligence.
Investigate threats with artificial intelligence, and hunt for suspicious activities at scale, tapping into years of cyber security work at Microsoft.
Respond to incidents rapidly with built-in orchestration and automation of common tasks.
Create and customize alerts in Azure Sentinel xxx
Connect data sources xxx
Create incidents from alerts xxx
Investigate incidents with Azure Sentinel xxx
Configure a playbook for a security event xxx

Configure security policies

Term Description
Azure Policy and describe its use cases Azure Policy is a service in Azure that enables you to create, assign, and manage policies that control or audit your resources. These policies enforce different rules across all of your resource configurations so that those configurations stay compliant with corporate standards. In the context of configuration compliance, provides tracking, enforcement, and even remediation.

Common use cases for Azure Policy include implementing governance for resource consistency, regulatory compliance, security, cost, and management. Policy definitions for these common use cases are already available in your Azure environment as built-ins to help you get started.

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 can also prevent noncompliant resources from being created.

Azure Policy Overview
Create and manage policies to enforce compliance
💻 Read the referenced URL for additional information 💻
Watch: YouTube: AZ-500 Microsoft Azure Security Technologies Study Cram
Create a custom policy definition
💻 Read the referenced URL for additional information 💻
Watch: YouTube: AZ-500 Microsoft Azure Security Technologies Study Cram
Deploy an Azure Policy - demo
💻 Read the referenced URL for additional information 💻
Watch: YouTube: AZ-500 Microsoft Azure Security Technologies Study Cram
Azure Blueprint Azure Blueprints enable quick creation of governed subscriptions by enabling cloud architects to define a repeatable set of Azure resources that implements and adheres to an organization's standards, best practices, and requirements. Azure Blueprints makes it possible for development teams to rapidly build and start up new environments with trust they're building within organizational compliance with a set of built-in components, such as networking, to speed up development and delivery.

Blueprints are a declarative way to orchestrate the deployment of various resource templates and other artifacts such as:
• Role Assignments
• Policy Assignments
• Azure Resource Manager templates (ARM templates)
• Resource Groups.
Create and assign blueprints
💻 Read the referenced URL for additional information 💻
Watch: YouTube: AZ-500 Microsoft Azure Security Technologies Study Cram

How Blueprints are different from ARM templates

The service is designed to help with environment setup. This setup often consists of a set of resource groups, policies, role assignments, and ARM template deployments. A blueprint is a package to bring each of these artifact types together and allow you to compose and version that package, including through a continuous integration and continuous delivery (CI/CD) pipeline. Ultimately, each is assigned to a subscription in a single operation that can be audited and tracked.

Nearly everything that you want to include for deployment in Azure Blueprints can be accomplished with an ARM template. However, an ARM template is a document that doesn't exist natively in Azure - each is stored either locally or in source control or in Templates (preview). The template gets used for deployments of one or more Azure resources, but once those resources deploy there's no active connection or relationship to the template.

With Azure Blueprints, the relationship between the blueprint definition (what should be deployed) and the blueprint assignment (what was deployed) is preserved. This connection supports improved tracking and auditing of deployments. Azure Blueprints can also upgrade several subscriptions at once that are governed by the same blueprint.

There's no need to choose between an ARM template and a blueprint. Each blueprint can consist of zero or more ARM template artifacts. This support means that previous efforts to develop and maintain a library of ARM templates are reusable in Azure Blueprints.

How Blueprints are different from Azure Policy

A blueprint is a package or container for composing focus-specific sets of standards, patterns, and requirements related to the implementation of Azure cloud services, security, and design that can be reused to maintain consistency and compliance.

A policy is a default allow and explicit deny system focused on resource properties during deployment and for already existing resources. It supports cloud governance by validating that resources within a subscription adhere to requirements and standards.

Including a policy in a blueprint enables the creation of the right pattern or design during assignment of the blueprint. The policy inclusion makes sure that only approved or expected changes can be made to the environment to protect ongoing compliance to the intent of the blueprint.

A policy can be included as one of many artifacts in a blueprint definition. Blueprints also support using parameters with policies and initiatives.

Secure data and applications (25–30%)

Configure security for storage

Term Description
Azure Storage overview The Azure Storage platform is Microsoft's cloud storage solution for modern data storage scenarios. Azure Storage offers highly available, massively scalable, durable, and secure storage for a variety of data objects in the cloud. Azure Storage data objects are accessible from anywhere in the world over HTTP or HTTPS via a REST API.

The Azure Storage platform includes the following data services:

Azure Blobs: A massively scalable object store for text and binary data. Also includes support for big data analytics through Data Lake Storage Gen2.
Azure Files: Managed file shares for cloud or on-premises deployments.
Azure Queues: A messaging store for reliable messaging between application components.
Azure Tables: A NoSQL store for schemaless storage of structured data.
Azure Disks: Block-level storage volumes for Azure VMs.
Authorization options for Azure Storage Each time you access data in your storage account, your client application makes a request over HTTP/HTTPS to Azure Storage. By default, every resource in Azure Storage is secured, and every request to a secure resource must be authorized.

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/azure_storage_auth.png

• Shared Key authorization for blobs, files, queues, and tables. A client using Shared Key passes a header with every request that is signed using the storage account access key. Microsoft recommends that you disallow Shared Key authorization for your storage account. When Shared Key authorization is disallowed, clients must use Azure AD or a user delegation SAS to authorize requests for data in that storage account.

• Shared access signatures for blobs, files, queues, and tables. Shared access signatures (SAS) provide limited delegated access to resources in a storage account via a signed URL. The signed URL specifies the permissions granted to the resource and the interval over which the signature is valid. A service SAS or account SAS is signed with the account key, while the user delegation SAS is signed with Azure AD credentials and applies to blobs only.

• Azure Active Directory (Azure AD) integration for authorizing requests to blob, queue, and table resources. Microsoft recommends using Azure AD credentials to authorize requests to data when possible for optimal security and ease of use.

• Azure Active Directory Domain Services (Azure AD DS) authentication for Azure Files. Azure Files supports identity-based authorization over Server Message Block (SMB) through Azure AD DS. You can use Azure RBAC for fine-grained control over a client's access to Azure Files resources in a storage account.

• On-premises Active Directory Domain Services (AD DS, or on-premises AD DS) authentication for Azure Files. Azure Files supports identity-based authorization over SMB through AD DS. Your AD DS environment can be hosted in on-premises machines or in Azure VMs. SMB access to Files is supported using AD DS credentials from domain joined machines, either on-premises or in Azure. You can use a combination of Azure RBAC for share level access control and NTFS DACLs for directory/file level permission enforcement.

• Anonymous public read access for containers and blobs. When anonymous access is configured, then clients can read blob data without authorization. You can disallow anonymous public read access for a storage account. When anonymous public read access is disallowed, then users cannot configure containers to enable anonymous access, and all requests must be authorized.

• Storage Local Users can be used to access blobs with SFTP or files with SMB. Storage Local Users support container level permissions for authorization.
Azure AD Storage Authentication With Azure AD, access to a resource is a two-step process. First, the security principal's identity is authenticated and an OAuth 2.0 token is returned. Next, the token is passed as part of a request to the Blob service and used by the service to authorize access to the specified resource.

The authentication step requires that an application request an OAuth 2.0 access token at runtime. If an application is running from within an Azure entity such as an Azure VM, a virtual machine scale set, or an Azure Functions app, it can use a managed identity to access blob data.

Authorizing requests against Azure Storage with Azure AD provides superior security and ease of use over Shared Key authorization. Microsoft recommends using Azure AD authorization with your blob applications when possible to assure access with minimum required privileges.

Azure Active Directory (Azure AD) authorizes access rights to secured resources through Azure RBAC. Azure Storage defines a set of built-in RBAC roles that encompass common sets of permissions used to access blob data.

You can also define custom roles for access to blob data.

• Storage Blob Data Owner: Use to set ownership and manage POSIX access control for Azure Data Lake Storage Gen2. For more information, see Access control in Azure Data Lake Storage Gen2.
• Storage Blob Data Contributor: Use to grant read/write/delete permissions to Blob storage resources.
• Storage Blob Data Reader: Use to grant read-only permissions to Blob storage resources.
• Storage Blob Delegator: Get a user delegation key to use to create a shared access signature that is signed with Azure AD credentials for a container or blob.
Shared access signature (SAS) A shared access signature (SAS) is a Uniform Resource Identifier (URI) that grants restricted access rights to Azure Storage resources. You can provide a shared access signature to clients who should not be trusted with your storage account key but to whom you wish to delegate access to certain storage account resources. As such, it provides secure delegated access to resources within a storage account. With a SAS, you have granular control over how a client can access your data. With a SAS you have granular control over what resources the client may access, what permissions they have to those resources, and for how long.


Azure Storage supports three types of shared access signatures:
•User delegation SAS
•Service SAS
•Account SAS
User delegation SAS

• A user delegation SAS is secured with Azure Active Directory (Azure AD) credentials and also by the permissions specified for the SAS. A user delegation SAS applies to Blob storage only.

Service SAS
• A service SAS is secured with the storage account key. A service SAS delegates access to a resource in only one of the Azure Storage services: Blob storage, Queue storage, Table storage, or Azure Files.

Account SAS
• An account SAS is secured with the storage account key. An account SAS delegates access to resources in one or more of the storage services. All of the operations available via a service or user delegation SAS are also available via an account SAS.

You can also delegate access to the following:
• Service-level operations (For example, the Get/Set Service Properties and Get Service Stats operations).
• Read, write, and delete operations that aren't permitted with a service SAS.

A shared access signature can take one of the following two forms:

1 - Ad hoc SAS. When you create an ad hoc SAS, the start time, expiry time, and permissions are specified in the SAS URI. Any type of SAS can be an ad hoc SAS.

2 - Service SAS with stored access policy. A stored access policy is defined on a resource container, which can be a blob container, table, queue, or file share. The stored access policy can be used to manage constraints for one or more service shared access signatures. When you associate a service SAS with a stored access policy, the SAS inherits the constraints—the start time, expiry time, and permissions—defined for the stored access policy.

Shared Access Signatures (SAS) Overview
Create a user delegation SAS You can secure a shared access signature (SAS) token for access to a container, directory, or blob by using either Azure Active Directory (Azure AD) credentials or an account key.

Azure Portal >> Storage browser >> (select storage type) >> (three dots to the right) >> Generate SAS

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/GUI_shared_access_signature_SAS_access_1.png
https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/GUI_shared_access_signature_SAS_access_2.png

Overview of user delegation SAS process:

• Use RBAC to grant the desired permissions to the security principal who will request the user delegation key.
• Acquire an OAuth 2.0 token from Azure AD.
• Use the token to request the user delegation key by calling the Get User Delegation Key operation.
• Use the user delegation key to construct the SAS token with the appropriate fields.

PowerShell - Read the following URL associated with the PowerShell User delegation SAS process:
Create a user delegation SAS for a container or blob with PowerShell
Azure AD Domain Services Blobs - Link
Queues - Link
Tables - Link
Files - While Azure Files supports both SMB and NFS, it only supports identity-based authentication over Server Message Block (SMB) through on-premises Active Directory Domain Services (AD DS) and Azure Active Directory Domain Services (Azure AD DS). Link
Azure Storage Service Encryption (SSE) Azure Storage Service Encryption helps to protect data-at-rest by automatically encrypting before persisting it to Azure-managed disks, Azure Blob Storage, Azure Files, or Azure Queue Storage, and decrypts the data before retrieval. Data in Azure Storage is encrypted and decrypted transparently using 256-bit AES encryption and enabled for all storage accounts, including both Resource Manager and classic storage accounts, by default. Azure Storage encryption cannot be disabled.

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/Azure_Storage_encryption_SES_key_management_options.png

Infrastructure encryption
Customers who require high levels of assurance that their data is secure can also enable 256-bit AES encryption at the Azure Storage infrastructure level. When infrastructure encryption is enabled, data in a storage account is encrypted twice — once at the service level and once at the infrastructure level — with two different encryption algorithms and two different keys. Double encryption of Azure Storage data protects against a scenario where one of the encryption algorithms or keys may be compromised.
Configure encryption key management Read the following:
Provide an encryption key on a request to Blob storage
Encryption scopes for Blob storage

Encryption on Azure

Microsoft Azure provides many different ways to secure your data, each depending on the service or usage required.

  • Azure Storage Service Encryption helps to protect data at rest by automatically encrypting before persisting it to Azure-managed disks, Azure Blob Storage, Azure Files, or Azure Queue Storage, and decrypts the data before retrieval.
  • Azure Disk Encryption helps you encrypt Windows and Linux IaaS virtual machine disks. Azure Disk Encryption uses the industry-standard BitLocker feature of Windows and the dm-crypt feature of Linux to provide volume encryption for the OS and data disks.
  • Transparent data encryption (TDE) helps protect Azure SQL Database and Azure Data Warehouse against the threat of malicious activity. It performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application.

Configure security for databases

Term Description
Enable database auditing Review link to the left
Server-level vs. database-level auditing policy • An auditing policy can be defined for a specific database or as a default server policy in Azure (which hosts SQL Database or Azure Synapse):

•A server policy applies to all existing and newly created databases on the server.

• If server auditing is enabled, it always applies to the database. The database will be audited, regardless of the database auditing settings.

• When auditing policy is defined at the database-level to a Log Analytics workspace or an Event Hub estination, the following operations will not keep the source database-level auditing policy:
  • Database copy
  • Point-in-time restore
  • Geo-replication (Secondary database will not have database-level auditing)

• Enabling auditing on the database, in addition to enabling it on the server, does not override or change any of the settings of the server auditing. Both audits will exist side by side. In other words, the database is audited twice in parallel; once by the server policy and once by the database policy.
Configure Azure SQL Database Advanced Threat Protection (ATP) Review link to the left
Advanced Data Security (ADS) Advanced Data Security (aka Defender for SQL servers) is a unified security package that includes Vulnerability Assessment and Advanced Threat Protection for your SQL server.
Enable ADS via PowerShell
Advanced Threat Protection Advanced Threat Protection detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. Advanced Threat Protection is part of the Microsoft Defender for SQL offering, which is a unified package for advanced SQL security capabilities. Advanced Threat Protection can be accessed and managed via the central Microsoft Defender for SQL portal.
Enable ATP via Powershell
SQL Database authentication Azure SQL Database supports two methods for authentication

1 - SQL authentication = With this authentication method, the user submits a user account name and associated password to establish a connection. This password is stored in the master database for user accounts linked to a login or stored in the database containing the user accounts not linked to a login.

2 - Azure Active Directory Authentication = With this authentication method, the user submits a user account name and requests that the service use the credential information stored in Azure Active Directory (Azure AD).
Note that the admin login name can't be changed after it has been created, however the password can be reset from the portal.
Implement database encryption through transparent data encryption (TDE) Transparent data encryption (TDE) helps protect Azure SQL Database and Azure Data Warehouse against the threat of malicious activity. It performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application.
Configure Always Encrypted by using Azure Key Vault Review link to the left

|

What is Azure Key Vault?

Azure Key Vault is a centralized cloud service for storing your application secrets. Key Vault helps you control your applications' secrets by keeping them in a single, central location and by providing secure access, permissions control, and access logging capabilities. It's useful for different kinds of scenarios:

  • Secrets management. You can use Key Vault to store securely and tightly control access to tokens, passwords, certificates, Application Programming Interface (API) keys, and other secrets.
  • Key management. You can use Key Vault as a key management solution. Key Vault makes it easier to create and control the encryption keys used to encrypt your data.
  • Certificate management. Key Vault lets you provision, manage, and deploy your public and private Secure Sockets Layer/ Transport Layer Security (SSL/ TLS) certificates for Azure, and internally connected, resources more easily.
  • Store secrets backed by hardware security modules (HSMs). The secrets and keys can be protected either by software or by FIPS 140-2 Level 2 validated HSMs.

Configure and manage Azure Key Vault

Term Description
Implement and configure Key Vault xxx - https://docs.microsoft.com/en-us/learn/modules/manage-secrets-with-azure-key-vault/2-what-is-key-vault
Key rotation xxx
Key Vault access and permissions xxx
Key Vault Parameters Files Rather than passing parameters as inline values in your script, you can use a JSON file that contains an "id" reference to a key vault instance and the the "secret name". This allows secrets (e.g. credentials, tokens, and keys) to be securely referenced and retrieved during deployment, rather than stored in clear text.

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/Keyvault_demo_parameters_file.png

In situations where you need to dynmaically create resource IDs you can do so using dynamic IDs.

https://raw.githubusercontent.com/RickKotlarz/media-files/main/media/key_vault_dynamic_id.png
Management plane and access plane for Key Vault - demo xxx

Supplemental Links:

Microsoft AZ-500 page that includes free training, skills measured PDF, and exam details

Microsoft Enterprise Skills Initiative Study Guide for AZ-500

WhizLabs AZ-500

Microsoft Learning - Microsoft Certified Trainer (MCT) lab for AZ-500

Microsoft Learning - Microsoft Certified Trainer (MCT) labs for all exams




4 spaces =   test
Pipe symbol: ¦
Bold: CanNotDelete
Bold + Italitcs initiatives
Basic writing and formatting syntax
💻 Read the referenced URL for additional information 💻