Application Security (part 3 of 3)

By Ashwin Venugopal -

 


To read part 1 please click here
To read part 2 please click here


Managed Identities

Managed Identities for Azure resources is the new name for the service formerly known as Managed Service Identity (MSI) for Azure resources feature in Azure AD and provides Azure services with an automatically managed identity in Azure AD. You can use the identity to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials in your code.

The managed identities for Azure resources feature is free with Azure AD for Azure subscriptions, there's no additional cost.

How managed identities for Azure resources works?

There are two type of managed identities:

  • A system-assigned managed identity is enabled directly on an Azure service instance and when the identity is enabled, azure creates an identity for the instance in the Azure AD tenant that's trusted by the subscription of the instance. The lifecycle of a system-assigned managed identity is directly tied to the Azure service instance that it's enabled on and if the instance is deleted, Azure automatically cleans up the credentials and the identity in Azure AD.
  • A user-assigned managed identity is created as a standalone Azure resource and after the identity is created, it can be assigned to one or more Azure service instances. The lifecycle of a user-assigned manged identity is managed separately from the lifecycle of the Azure service instances to which it is assigned.     

Internally, managed identities are service principles of a special type, which are locked to only be used with Azure resources. Also, when a user-assigned or system-assigned identity is created, the Managed Identity Resource Provider (MSRP) issues a certificate internally to that identity.

Your code can use a managed identity to request access tokens for services that supports Azure AD authentication. Azure takes care of rolling the credentials that are used by the service instance. 

How a system-assigned managed identity works with an Azure VM?

  1. Azure Resource Manager receives request to enable the system-assigned managed identity on a VM.
  2. Azure Resource Manager creates a service principle in the Azure AD tenant for the identity of the VM that's trusted by the subscription.
  3. Azure Resource Manager configures the identity on the VM by updating the Azure Instance Metadata Service identity endpoint with the service principle client ID and certificate.
  4. After the VM has an identity, use the service principle information to grant the VM access to Azure resources. 
  5. Your code that's running on the VM can request a token from the Azure Instance Metadata service endpoint, accessible only from within the VM: http://169.254.169.254/metadata/identity/oauth2/token
  • The resource parameter specifies the service to which the token is sent.
  • API version parameter specifies the IMDS version, use api-version=2018-02-01 or greater.          

      6. A call is made to Azure AD to request an access token by using the client ID and certificate                      configured in step 3. Azure AD returns a JSON Web Token (JWT) access token.

      7. Your send the access token on a call to a service that supports Azure AD authentication.

Web App Certificates

You can restrict access to your Azure App Service app by enabling different types of authentications for it. One way to do it is to request a client certificate when the client request is over TLS/SSL and validate the certificate. This mechanism is called TLS mutual authentication or client certificate authentication.

Enable client certificates

To set up your app to require client certificates, you can switch on the Require incoming certificate by selecting configuration > General Settings from the Azure Portal or you need to set the clientCertEnabled setting for your app to be true.

Exclude paths from requiring authentication

To allow certain paths to remain open for anonymous access, you can define exclusion paths as a part of your application configuration. Exclusion paths can be configured by selecting Configuration > General Settings and defining an exclusion path. 

Access client certificate

When forwarding a request to your app code with client certificates enabled, App Service injects an X-ARR-ClientCert request header with the client certificate. App service does not do anything with this client certificate other than forwarding it to your app. Your app code is responsible for validating the client certificate.


To read part 1 please click here
To read part 2 please click here





Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different groups of computers, re
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more