Section 6 – Design security for infrastructure – Design a strategy for securing SaaS, PaaS, and IaaS services

Time for the next section to my SC-100 study guide:

• Specify security baselines for SaaS, PaaS, and IaaS services
• Specify security requirements for IoT workloads
• Specify security requirements for data workloads, including SQL, Azure SQL Database, Azure Synapse and Azure Cosmos DB
• Specify security requirements for web workloads, including Azure App Service
• Specify security requirements for storage workloads, including Azure Storage
• Specify security requirements for containers
• Specify security requirements for container orchestration

Specify security baselines for SaaS, PaaS, and IaaS services

Security baselines can be understood better once you see the big picture thru the shared responsibility model.

Azure security baseline

Best practices

• Enable Defender for Cloud – Open Defender for Cloud in the Azure portal for the first time or if you enable it through the API, Defender for Cloud is enabled for free on all your Azure subscriptions. By default, Defender for Cloud provides the secure score, security policy and basic recommendations, and network security assessment to help you protect your Azure resources.
• Store your keys and secrets in Azure Key Vault (and not in your source code). Key Vault is designed to support any type of secret: passwords, database credentials, API keys and, certificates.
• Install a web application firewall. Web application firewall (WAF) is a feature of Application Gateway that provides centralized protection of your web applications from common exploits and vulnerabilities.
• Enforce multi-factor verification for users, especially your administrator accounts. Azure Multi-Factor Authentication (Azure MFA) helps administrators protect their organizations and users with additional authentication methods.
• Encrypt your virtual hard disk files to help protect your boot volume and data volumes at rest in storage, along with your encryption keys and secrets.
• Connect Azure virtual machines and appliances to other networked devices by placing them on Azure virtual networks. Virtual machines connected to an Azure virtual network can connect to devices on the same virtual network, different virtual networks, the internet, or your own on-premises networks.
• Mitigate and protect against DDoS. Distributed denial of service (DDoS) is a type of attack that tries to exhaust application resources. Azure has two DDoS service offerings that help protect your network from attacks. DDoS Protection Basic is automatically enabled as part of the Azure platform. DDoS Protection Standard provides additional mitigation capabilities— beyond those of the Basic service tier—that are tuned specifically to Azure Virtual Network resources.

Operational security practices for every day use

• Manage your VM updates. Azure VMs, like all on-premises VMs, are meant to be user managed. Azure doesn’t push Windows updates to them. Ensure you have solid processes in place for important operations such as patch management and backup.
• Enable password management and use appropriate security policies to prevent abuse.
• Review your Security Center dashboard regularly to get a central view of the security state of all of your Azure resources and take action on the recommendations.

Optimize identity and access management

• Treat identity as the primary security perimeter
• Centralize identity management
• Enable single sign-on
• Turn on conditional access
• Enable password management
• Enforce multi-factor verification for users
• Use role-based access control
• Lower exposure of privileged accounts
• Control locations where resources are located

Technical capabilities

How Azure is built?

Another great read is how Microsoft secures your data inside Azure, from physical to firmware level security.

Specify security requirements for IoT workloads

Best practices

Device identity

Use strong device identity is delivered through tightly integrated capabilities of IoT devices and services, including:

• A hardware root of trust
• Strong authentication using techniques such as certificates, multi-factor auth, or password-less authentication
• Renewable credentials
• Organizational IoT device registry

When possible, use a hardware root of trust (RoT) with the following attributes:

• Secure storage of the credentials proving the identity in a dedicated, tamper-resistant hardware.
• Immutable onboarding identity tied to the physical device.
• Unique per-device renewable operational credentials for regular device access.

The onboarding identity represents the physical device, and is inseparable from it. It can’t be changed for the device’s lifetime, and is typically created and installed during manufacturing.

Password-less authentication

Usually using standard x509 certificates to prove a device’s identity, offers greater protection than secrets such as passwords and symmetric tokens shared between both parties.

Certificates are a strong, standardized mechanism that provides renewable, password-less authentication.

Organizational IoT device registry

Use a centralized Organizational IoT device registry for your organization’s IoT devices to manage their lifecycle and audit device access. This approach is similar to the way you secure the user identities of an organization’s workforce to achieve Zero Trust security. Use a cloud-based identity registry to handle the scale, management, and security of an IoT solution.

Least-privileged access control

helps to limit any impact from authenticated identities that may have been compromised or that are running unapproved workloads. For IoT scenarios, this means granting access to solution operators, devices, and their workloads using:

• Device and workload access control, to provide access control to the scoped workloads running on the device.
• Access only from secure locations and systems, granting just-in-time access, and implementing strong authentication mechanisms such as multi-factor auth, password-less authentication.
• Conditional access, to conditionally grant access based on the device’s context. Examples include:
  • Location (IP address, GPS location)
  • Uniqueness (access from one location at a time)
  • Time of the day
  • Network traffic patterns

Services can also use the device’s context to conditionally deploy workloads.

Monitoring

As recommended by CISA, security monitoring includes:

• Generating an as-is asset inventory and network map of all IoT/OT devices.
• Identifying all communication protocols used across IoT/OT networks.
• Cataloging all external connections to and from IoT/OT networks.
• Identifying vulnerabilities in IoT/OT devices and using a risk-based approach to mitigate them.
• Implementing a vigilant monitoring program with anomaly detection to detect malicious cyber tactics such as living off the land techniques within IoT/OT systems. The program should monitor for unauthorized changes to controllers, unusual behavior from devices, and audit access and authorization attempts.

Most IoT attacks follow a familiar kill chain pattern in which adversaries establish an initial foothold, elevate their privileges, and move laterally across the network.

Data protection

Data that’s ingested into the IoT solution should be protected with the guidance in the overall Azure Well-Architecture. For IoT solutions, these principles extend to the devices too. It’s critical to ensure that communication from the device to the cloud is secure and encrypted using the latest Transport Layer Security (TLS) standards. If data is stored on devices (data at rest), use standard encryption algorithms to encrypt the data.

Make sure devices are well protected physically. Turn-off or disable any features that aren’t needed on the device, such as physical ports (USB, UART) and connectivity (WIFI, BT). Perform physical removal or covering/blocking when necessary.

When possible, use a firewall on the device to restrict the network access.

Specify security requirements for data workloads, including SQL, Azure SQL Database, Azure Synapse and Azure Cosmos DB

Comparison chart

If you want to	Use this
Build apps that scale with managed and intelligent SQL database in the cloud	Azure SQL Database
Managed, always up-to-date SQL instance in the cloud	Azure SQL Managed Instance
Migrate your SQL workloads to Azure while maintaining complete SQL Server compatibility and operating system-level access	SQL Server on Azure Virtual Machines
Build scalable, secure, and fully managed enterprise-ready apps on open-source PostgreSQL, scale out single-node PostgreSQL with high performance, or migrate PostgreSQL and Oracle workloads to the cloud	Azure Database for PostgreSQL
Deliver high availability and elastic scaling to open-source mobile and web apps with a managed community MySQL database service, or migrate MySQL workloads to the cloud	Azure Database for MySQL
Deliver high availability and elastic scaling to open-source mobile and web apps with a managed community MariaDB database service	Azure Database for MariaDB
Build applications with guaranteed low latency and high availability anywhere, at any scale, or migrate Cassandra, MongoDB, and other NoSQL workloads to the cloud	Azure Cosmos DB
Power fast, scalable applications with an open-source-compatible in-memory data store	Azure Cache for Redis
Accelerate your transition to the cloud using a simple, self-guided migration process	Azure Database Migration Service
Modernize existing Cassandra data clusters and apps, and enjoy flexibility and freedom with managed instance service	Azure Managed Instance for Apache Cassandra

And the different types and a picture. We will be learning from the marked ones.

What you get with SQL Server on Azure virtual machines?

So if you just want to lift you DB’s to the cloud as-is then it will be SQL Server on Azure Virtual Machines, then you have to maintain the server like before, you have to get more capacity to the virtual server underneath, so not the best option, but sometimes it has to be used example for compatibility reasons.

But you will get automated backup, Disaster recovery and many other features when you install SQL Server IaaS Agent extension https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/sql-server-iaas-agent-extension-automate-management?tabs=azure-powershell#feature-benefits

What you get with Azure SQL Managed Instance?

You will get Azure Active Directory authentication inside the DB, how cool is that. Not anymore the manually created users inside the database. So you can allow users created in your Azure to access to the database and maintain only one identity with the security and identity protection features inside Azure Identity.

You will also get all the security benefits

Isolated environment (VNet integration, single tenant service, dedicated compute and storage)
Transparent data encryption – TDE performs real-time I/O encryption and decryption of the data at the page level.
Azure AD server principals (logins) – https://docs.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure?tabs=azure-powershell#provision-azure-ad-admin-sql-managed-instance
SQL auditing – https://docs.microsoft.com/en-us/azure/azure-sql/managed-instance/auditing-configure
Advanced Threat Protection – https://docs.microsoft.com/en-us/azure/azure-sql/managed-instance/auditing-configure

Then you will get almost the same compatibility as with old-school SQL instance, but you don’t have to update anything. All the software and hardware under you DB engine has been taken care-off.

Overview of the service https://docs.microsoft.com/en-us/azure/azure-sql/managed-instance/sql-managed-instance-paas-overview

What you get with Azure SQL Database?

All the the features mentioned above, but also Elastic Pools. So the deployment options are:

• As a single database with its own set of resources managed via a logical SQL server. A single database is similar to a contained database in SQL Server. This option is optimized for modern application development of new cloud-born applications. Hyperscale and serverless options are available.
• An elastic pool, which is a collection of databases with a shared set of resources managed via a logical SQL server. Single databases can be moved into and out of an elastic pool. This option is optimized for modern application development of new cloud-born applications using the multi-tenant SaaS application pattern. Elastic pools provide a cost-effective solution for managing the performance of multiple databases that have variable usage patterns.

Elastic databases was release in 2016 and it was an really nice addition for Azure SQL services. Serverless db cluster that is expanding as your usage goes up.

With Elastic Pool you don’t have to over-allocate the service, it will find the resources inside the pool and distribute them to the DB that doesn’t have too much use.

Enable database authentication by using Azure AD

Trust architecture

• Only the cloud portion of Azure AD, SQL Database, SQL Managed Instance, and Azure Synapse is considered to support Azure AD native user passwords.
• To support Windows single sign-on credentials (or user/password for Windows credential), use Azure Active Directory credentials from a federated or managed domain that is configured for seamless single sign-on for pass-through and password hash authentication. For more information, see Azure Active Directory Seamless Single Sign-On.
• To support Federated authentication (or user/password for Windows credentials), the communication with ADFS block is required.

Azure AD features and limitations

• The following members of Azure AD can be provisioned for Azure SQL Database:
  • Native members: A member created in Azure AD in the managed domain or in a customer domain. For more information, see Add your own domain name to Azure AD.
  • Members of an Active Directory domain federated with Azure Active Directory on a managed domain configured for seamless single sign-on with pass-through or password hash authentication. For more information, see Microsoft Azure now supports federation with Windows Server Active Directory and Azure Active Directory Seamless Single Sign-On.
  • Imported members from other Azure AD’s who are native or federated domain members.
  • Active Directory groups created as security groups.
• Azure AD users that are part of a group that has db_owner server role cannot use the CREATE DATABASE SCOPED CREDENTIAL syntax against Azure SQL Database and Azure Synapse. You will see the following error:SQL Error [2760] [S0001]: The specified schema name 'user@mydomain.com' either does not exist or you do not have permission to use it.Grant the db_owner role directly to the individual Azure AD user to mitigate the CREATE DATABASE SCOPED CREDENTIAL issue.
• These system functions return NULL values when executed under Azure AD principals:
  • SUSER_ID()
  • SUSER_NAME(<admin ID>)
  • SUSER_SNAME(<admin SID>)
  • SUSER_ID(<admin name>)
  • SUSER_SID(<admin name>)

Connect by using Azure AD identities

Azure Active Directory authentication supports the following methods of connecting to a database using Azure AD identities:

• Azure Active Directory Password
• Azure Active Directory Integrated
• Azure Active Directory Universal with Multi-Factor Authentication
• Using Application token authentication

The following authentication methods are supported for Azure AD server principals (logins):

• Azure Active Directory Password
• Azure Active Directory Integrated
• Azure Active Directory Universal with Multi-Factor Authentication

SQL Managed Instance

• Azure AD server principals (logins) and users are supported for SQL Managed Instance.
• Setting Azure AD server principals (logins) mapped to an Azure AD group as database owner is not supported in SQL Managed Instance.
  • An extension of this is that when a group is added as part of the dbcreator server role, users from this group can connect to the SQL Managed Instance and create new databases, but will not be able to access the database. This is because the new database owner is SA, and not the Azure AD user. This issue does not manifest if the individual user is added to the dbcreator server role.
• SQL Agent management and jobs execution are supported for Azure AD server principals (logins).
• Database backup and restore operations can be executed by Azure AD server principals (logins).
• Auditing of all statements related to Azure AD server principals (logins) and authentication events is supported.
• Dedicated administrator connection for Azure AD server principals (logins) which are members of sysadmin server role is supported.
  • Supported through SQLCMD Utility and SQL Server Management Studio.
• Logon triggers are supported for logon events coming from Azure AD server principals (logins).
• Service Broker and DB mail can be setup using an Azure AD server principal (login).

How to enable?

Add Azure AD admin

Open your SQL servers and Azure Active Directory page, from there you will choose Set admin

Choose your admin and hit save

You can also disable SQL authentication and enable Only Azure AD authentication.

Azure AD-only authentication with Azure SQL

Azure AD-only authentication is a feature within Azure SQL that allows the service to only support Azure AD authentication, and is supported for Azure SQL Database and Azure SQL Managed Instance.

Azure AD-only authentication is also available for dedicated SQL pools (formerly SQL DW) in standalone servers. Azure AD-only authentication can be enabled for the Azure Synapse workspace. For more information, see Azure AD-only authentication with Azure Synapse workspaces.

SQL authentication is disabled when enabling Azure AD-only authentication in the Azure SQL environment, including connections from SQL server administrators, logins, and users. Only users using Azure AD authentication are authorized to connect to the server or database.

Azure AD-only authentication can be enabled or disabled using the Azure portal, Azure CLI, PowerShell, or REST API. Azure AD-only authentication can also be configured during server creation with an Azure Resource Manager (ARM) template.

Permissions

Azure AD-only authentication can be enabled or disabled by Azure AD users who are members of high privileged Azure AD built-in roles, such as Azure subscription Owners, Contributors, and Global Administrators. Additionally, the role SQL Security Manager can also enable or disable the Azure AD-only authentication feature.

The SQL Server Contributor and SQL Managed Instance Contributor roles won’t have permissions to enable or disable the Azure AD-only authentication feature. This is consistent with the Separation of Duties approach, where users who can create an Azure SQL server or create an Azure AD admin, can’t enable or disable security features.

Configure dynamic masking on SQL workloads

Dynamic data masking limits sensitive data exposure by masking it to non-privileged users. Dynamic data masking automatically discovers potentially sensitive data in Azure SQL Database and SQL Managed Instance and provides actionable recommendations to mask these fields, with minimal impact to the application layer. It works by obfuscating the sensitive data in the result set of a query over designated database fields, while the data in the database is not changed.

Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics support dynamic data masking. Dynamic data masking limits sensitive data exposure by masking it to non-privileged users.

Dynamic data masking helps prevent unauthorized access to sensitive data by enabling customers to designate how much of the sensitive data to reveal with minimal impact on the application layer. It’s a policy-based security feature that hides the sensitive data in the result set of a query over designated database fields, while the data in the database is not changed.

Masking function	Masking logic
Default	Full masking according to the data types of the designated fields • Use XXXX or fewer Xs if the size of the field is less than 4 characters for string data types (nchar, ntext, nvarchar). • Use a zero value for numeric data types (bigint, bit, decimal, int, money, numeric, smallint, smallmoney, tinyint, float, real). • Use 01-01-1900 for date/time data types (date, datetime2, datetime, datetimeoffset, smalldatetime, time). • For SQL variant, the default value of the current type is used. • For XML the document <masked/> is used. • Use an empty value for special data types (timestamp table, hierarchyid, GUID, binary, image, varbinary spatial types).
Credit card	Masking method, which exposes the last four digits of the designated fields and adds a constant string as a prefix in the form of a credit card. XXXX-XXXX-XXXX-1234
Email	Masking method, which exposes the first letter and replaces the domain with XXX.com using a constant string prefix in the form of an email address. aXX@XXXX.com
Random number	Masking method, which generates a random number according to the selected boundaries and actual data types. If the designated boundaries are equal, then the masking function is a constant number.
Custom text	Masking method, which exposes the first and last characters and adds a custom padding string in the middle. If the original string is shorter than the exposed prefix and suffix, only the padding string is used.

Permissions

These are the built-in roles to configure dynamic data masking is:

• SQL Security Manager
• SQL DB Contributor
• SQL Server Contributor

These are the required actions to use dynamic data masking:

Read/Write:

• Microsoft.Sql/servers/databases/dataMaskingPolicies/* Read:
• Microsoft.Sql/servers/databases/dataMaskingPolicies/read Write:
• Microsoft.Sql/servers/databases/dataMaskingPolicies/write

Implement database encryption for Azure SQL Database

Always encrypted

In SQL Server 2019 (15.x), Always Encrypted with secure enclaves uses Virtualization-based Security (VBS) secure memory enclaves (also known as Virtual Secure Mode, or VSM enclaves) in Windows.

Azure SQL Database, Always Encrypted with secure enclaves uses Intel Software Guard Extensions (Intel SGX) enclaves. Intel SGX is a hardware-based trusted execution environment technology supported in databases that use the DC-series hardware configuration.

Encryption

Transport Layer Security (Encryption-in-transit)

SQL Database, SQL Managed Instance, and Azure Synapse Analytics secure customer data by encrypting data in motion with Transport Layer Security (TLS).

SQL Database, SQL Managed Instance, and Azure Synapse Analytics enforce encryption (SSL/TLS) at all times for all connections. This ensures all data is encrypted “in transit” between the client and server irrespective of the setting of Encrypt or TrustServerCertificate in the connection string.

Transparent Data Encryption (Encryption-at-rest)

Transparent data encryption (TDE) for SQL Database, SQL Managed Instance, and Azure Synapse Analytics adds a layer of security to help protect data at rest from unauthorized or offline access to raw files or backups. Common scenarios include data center theft or unsecured disposal of hardware or media such as disk drives and backup tapes. TDE encrypts the entire database using an AES encryption algorithm, which doesn’t require application developers to make any changes to existing applications.

In Azure, all newly created databases are encrypted by default and the database encryption key is protected by a built-in server certificate. Certificate maintenance and rotation are managed by the service and require no input from the user. Customers who prefer to take control of the encryption keys can manage the keys in Azure Key Vault.

Azure Cosmos DB

Azure Synapse Link

Benefits

To analyze large operational datasets while minimizing the impact on the performance of mission-critical transactional workloads, traditionally, the operational data in Azure Cosmos DB is extracted and processed by Extract-Transform-Load (ETL) pipelines. ETL pipelines require many layers of data movement resulting in much operational complexity, and performance impact on your transactional workloads. It also increases the latency to analyze the operational data from the time of origin.

Security

Synapse Link enables you to run near real-time analytics over your mission-critical data in Azure Cosmos DB. It is vital to make sure that critical business data is stored securely across both transactional and analytical stores.

• Network isolation using private endpoints – You can control network access to the data in the transactional and analytical stores independently. Network isolation is done using separate managed private endpoints for each store, within managed virtual networks in Azure Synapse workspace
• Data encryption with customer-managed keys – You can seamlessly encrypt the data across transactional and analytical stores using the same customer-managed keys in an automatic and transparent manner. Azure Synapse Link only supports configuring customer-managed keys using your Azure Cosmos DB account’s managed identity. You must configure your account’s managed identity in your Azure Key Vault access policy before enabling Azure Synapse Link on your account.
• Secure key management – Accessing the data in analytical store from Synapse Spark and Synapse serverless SQL pools requires managing Azure Cosmos DB keys within Synapse Analytics workspaces. Instead of using the Azure Cosmos DB account keys inline in Spark jobs or SQL scripts, Azure Synapse Link provides more secure capabilities:
  • When using Synapse serverless SQL pools, you can query the Azure Cosmos DB analytical store by pre-creating SQL credentials storing the account keys and referencing these in the OPENROWSET function.
  • When using Synapse Spark, you can store the account keys in linked service objects pointing to an Azure Cosmos DB database and reference this in the Spark configuration at runtime.

Azure Cosmos keys

Put your secrets to a Key vault

Customer-managed keys

Encrypt your data with your own keys and with key vault

Managed identities

To set up managed identities, your account needs to have the DocumentDB Account Contributor role.

System managed

User assigned

Defender for cloud

Or you can enable Defender for cloud integration

And follow the recommendations it gives

And go ahead and enable firewall

Managed private endpoints

Managed private endpoints are private endpoints created in a Managed Virtual Network associated with your Azure Synapse workspace. Managed private endpoints establish a private link to Azure resources. Azure Synapse manages these private endpoints on your behalf.

A private endpoint connection is created in a “Pending” state when you create a Managed private endpoint in Azure Synapse. An approval workflow is started. The private link resource owner is responsible to approve or reject the connection. If the owner approves the connection, the private link is established. 

How to?

A managed private endpoint connection request is sent to the workspace’s primary Data Lake Storage Gen2 account for Spark pools to access data. This must be approved by an owner of the storage account.

All outbound traffic will go through private endpoints that connect to Azure resources in approved Azure AD tenants.

Authentication

Use RBAC

And managed identities

Workspace will have network access to your Data Lake Storage Gen2 account using the workspace’s system assigned identity.

And Customer managed keys

Azure Synapse Analytics (private link hubs)

Azure Synapse Analytics Private link hubs allow you to connect to Azure Synapse Studio using a private endpoint. Network traffic between clients in your Azure VNet and Synapse Studio traverses over the private link on the Microsoft backbone network, eliminating exposure from the public Internet.

How to?

And once registered, you are free to go

On the next page you will choose the Synapse workspace you created

And on the Virtual Network page you can create an Vnet and Application Security Group

On the DNS page you will create a private DNS entry

Specify security requirements for web workloads, including Azure App Service

Serverless computing key components are

Functions

Azure Functions is a serverless compute service that enables you to run code on demand without
having to provision or manage infrastructure. You can see Azure Functions run a script or piece of
code in response to a variety of events.
Azure Functions is a solution for running small pieces of code, or functions. You write just the code
that you need for the problem at hand, without worrying about an entire application. Use the
development language of your choice: C#, F#, Node.js, Python, or PHP.

Azure functions are built on the same underlying core components as Azure App Service, so you can
turn on some features more or less “for free” without writing extra code. Authentication is one of
those features

Logic apps

The Logic Apps feature of Azure App Service provides a way to implement scalable integrations and
workflows. It provides a visual designer and the ability to model and automate your process as a
series of steps called a workflow. There are many connectors across cloud and on-premises services
to quickly connect a serverless app to other APIs.

A logic app begins with a trigger (like “When an account is added to Dynamics CRM”) and then can
begin combinations of actions, conversions, and condition logic. Logic Apps is an option for
orchestrating various functions in a process—especially when the process requires interacting with
an external system or API.

There is currently 638 connectors inside Logic apps, so there is a lot of options for choose from.

You can use the Logic Apps feature to orchestrate and connect the functions and APIs of your
application. There are many tools available to help you secure your logic apps.

Event grid

You can use Azure Event Grid to build applications with event-based architectures. Select the Azure
resource that you want to subscribe to, and give the event handler or webhook endpoint to send the
event to.

Event Grid has built-in support for events coming from Azure services, like Azure Storage blobs and
resource groups. Event Grid also has custom support for application and partner events, by using
custom topics and custom webhooks.

Configure security for an Azure App Service

Plan types

Dev / Test

Production

Isolated

Creating an App service

When you choose your level of SKU, you can enable continuous deployments with GitHub

And hardware isolation

And to make it private, using Azure DNS Private zones.

Azure Private DNS provides a reliable and secure DNS service for your virtual network. Azure Private DNS manages and resolves domain names in the virtual network without the need to configure a custom DNS solution. 

No isolation

If you are not making and Isolated environment, you could use Network injection (Preview)

It will control the access to Apps with NSG (Network Security Group)

Once enabled, you can enable Inbound and Outbound access

Then then create Private Endpoint for Inbound access

And create Route table (Maybe a Firewall) or NSG to secure Outbound access.

Security recommendations

Identity and access management

Recommendation	Comments
Disable anonymous access	Unless you need to support anonymous requests, disable anonymous access. For more information on Azure App Service authentication options, see Authentication and authorization in Azure App Service.
Require authentication	Whenever possible, use the App Service authentication module instead of writing code to handle authentication and authorization. See Authentication and authorization in Azure App Service.
Protect back-end resources with authenticated access	You can either use the user’s identity or use an application identity to authenticate to a back-end resource. When you choose to use an application identity use a managed identity.
Require client certificate authentication	Client certificate authentication improves security by only allowing connections from clients that can authenticate using certificates that you provide.

Data protection

Recommendation	Comments
Redirect HTTP to HTTPs	By default, clients can connect to web apps by using both HTTP or HTTPS. We recommend redirecting HTTP to HTTPs because HTTPS uses the SSL/TLS protocol to provide a secure connection, which is both encrypted and authenticated.
Encrypt communication to Azure resources	When your app connects to Azure resources, such as SQL Database or Azure Storage, the connection stays in Azure. Since the connection goes through the shared networking in Azure, you should always encrypt all communication.
Require the latest TLS version possible	Since 2018 new Azure App Service apps use TLS 1.2. Newer versions of TLS include security improvements over older protocol versions.
Use FTPS	App Service supports both FTP and FTPS for deploying your files. Use FTPS instead of FTP when possible. When one or both of these protocols are not in use, you should disable them.
Secure application data	Don’t store application secrets, such as database credentials, API tokens, or private keys in your code or configuration files. The commonly accepted approach is to access them as environment variables using the standard pattern in your language of choice. In Azure App Service, you can define environment variables through app settings and connection strings. App settings and connection strings are stored encrypted in Azure. The app settings are decrypted only before being injected into your app’s process memory when the app starts. The encryption keys are rotated regularly. Alternatively, you can integrate your Azure App Service app with Azure Key Vault for advanced secrets management. By accessing the Key Vault with a managed identity, your App Service app can securely access the secrets you need.
Secure application code	Follow the steps to ensure the application code is secured.
Static Content	When authoring a web application serving static content, ensure that only the intended files/folders are processed. A configuration/code which serves out all files may not be sure by default. Follow application runtime/framework’s best practices to secure the static content.
Hidden Folders	Ensure hidden folders like .git, bin, obj, objd, etc., doesn’t get accidentally included as part of deployment artifact. Take adequate steps to ensure deployment scripts only deploy required files and nothing more.
In-place deployments	Understand nuances of in place deployment in local Git deployment. In-place deployment results in the creation and storage of the .git folder in the content root of the web application. Local Git deployment can activate in-place deployments automatically in some scenarios, even if in-place deployment isn’t explicitly configured (for example, if the web app contains previously-deployed content when the local Git repository is initialized). Follow application runtime/framework’s best practices to secure the content.

Networking

Recommendation	Comments
Use static IP restrictions	Azure App Service on Windows lets you define a list of IP addresses that are allowed to access your app. The allowed list can include individual IP addresses or a range of IP addresses defined by a subnet mask. For more information, see Azure App Service Static IP Restrictions.
Use the isolated pricing tier	Except for the isolated pricing tier, all tiers run your apps on the shared network infrastructure in Azure App Service. The isolated tier gives you complete network isolation by running your apps inside a dedicated App Service environment. An App Service environment runs in your own instance of Azure Virtual Network.
Use secure connections when accessing on-premises resources	You can use Hybrid connections, Virtual Network integration, or App Service environment’s to connect to on-premises resources.
Limit exposure to inbound network traffic	Network security groups allow you to restrict network access and control the number of exposed endpoints. For more information, see How To Control Inbound Traffic to an App Service Environment.

Monitoring

Send logs to Log analytics

And use Microsoft Defender for Cloud

Recommendation

Comments

Use Microsoft Defender for Cloud’s Microsoft Defender for App Service

Microsoft Defender for App Service is natively integrated with Azure App Service. Defender for Cloud assesses the resources covered by your App Service plan and generates security recommendations based on its findings. Use the detailed instructions in these recommendations../security-center/recommendations-reference.md#appservices-recommendations) to harden your App Service resources. Microsoft Defender for Cloud also provides threat protection and can detect a multitude of threats covering almost the complete list of MITRE ATT&CK tactics from pre-attack to command and control. For a full list of the Azure App Service alerts, see Microsoft Defender for App Service alerts.

Service-to-service authentication

When authenticating against a back-end service, App Service provides two different mechanisms depending on your need:

Service identity – Sign in to the remote resource using the identity of the app itself. App Service lets you easily create a managed identity, which you can use to authenticate with other services, such as Azure SQL Database or Azure Key Vault. For an end-to-end tutorial of this approach, see Secure Azure SQL Database connection from App Service using a managed identity.

On-behalf-of (OBO) – Make delegated access to remote resources on behalf of the user. With Azure Active Directory as the authentication provider, your App Service app can perform delegated sign-in to a remote service, such as Microsoft Graph API or a remote API app in App Service. For an end-to-end tutorial of this approach, see Authenticate and authorize users end-to-end in Azure App Service.

Specify security requirements for storage workloads, including Azure Storage

Different Storage Accounts types

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.

Blob storage is ideal for:

• Serving images or documents directly to a browser.
• Storing files for distributed access.
• Streaming video and audio.
• Storing data for backup and restore, disaster recovery, and archiving.
• Storing data for analysis by an on-premises or Azure-hosted service.

Objects in Blob storage can be accessed from anywhere in the world via HTTP or HTTPS. Users or client applications can access blobs via URLs, the Azure Storage REST API, Azure PowerShell, Azure CLI, or an Azure Storage client library.

Azure Files

Managed file shares for cloud or on-premises deployments.

One thing that distinguishes Azure Files from files on a corporate file share is that you can access the files from anywhere in the world using a URL that points to the file and includes a shared access signature (SAS) token. You can generate SAS tokens; they allow specific access to a private asset for a specific amount of time.

File shares can be used for many common scenarios:

• Many on-premises applications use file shares. This feature makes it easier to migrate those applications that share data to Azure. If you mount the file share to the same drive letter that the on-premises application uses, the part of your application that accesses the file share should work with minimal, if any, changes.
• Configuration files can be stored on a file share and accessed from multiple VMs. Tools and utilities used by multiple developers in a group can be stored on a file share, ensuring that everybody can find them, and that they use the same version.
• Resource logs, metrics, and crash dumps are just three examples of data that can be written to a file share and processed or analyzed later.

Azure Queues

A messaging store for reliable messaging between application components.

The Azure Queue service is used to store and retrieve messages. Queue messages can be up to 64 KB in size, and a queue can contain millions of messages. Queues are generally used to store lists of messages to be processed asynchronously.

Azure Tables

A NoSQL store for schemaless storage of structured data.

Azure Table storage is now part of Azure Cosmos DB. To see Azure Table storage documentation, see the Azure Table Storage Overview. In addition to the existing Azure Table storage service, there is a new Azure Cosmos DB Table API offering that provides throughput-optimized tables, global distribution, and automatic secondary indexes.

Azure Disks

Block-level storage volumes for Azure VMs.

An Azure managed disk is a virtual hard disk (VHD). You can think of it like a physical disk in an on-premises server but virtualized. Azure-managed disks are stored as page blobs, which are a random IO storage object in Azure. We call a managed disk ‘managed’ because it is an abstraction over page blobs, blob containers, and Azure storage accounts. With managed disks, all you have to do is provision the disk, and Azure takes care of the rest.

And each service is accessed through a storage account.

Different types

Type of storage account	Supported storage services	Redundancy options	Usage
Standard general-purpose v2	Blob Storage (including Data Lake Storage1), Queue Storage, Table Storage, and Azure Files	Locally redundant storage (LRS) / geo-redundant storage (GRS) / read-access geo-redundant storage (RA-GRS) Zone-redundant storage (ZRS) / geo-zone-redundant storage (GZRS) / read-access geo-zone-redundant storage (RA-GZRS)2	Standard storage account type for blobs, file shares, queues, and tables. Recommended for most scenarios using Azure Storage. If you want support for network file system (NFS) in Azure Files, use the premium file shares account type.
Premium block blobs3	Blob Storage (including Data Lake Storage1)	LRS ZRS2	Premium storage account type for block blobs and append blobs. Recommended for scenarios with high transaction rates or that use smaller objects or require consistently low storage latency. Learn more about example workloads.
Premium file shares3	Azure Files	LRS ZRS2	Premium storage account type for file shares only. Recommended for enterprise or high-performance scale applications. Use this account type if you want a storage account that supports both Server Message Block (SMB) and NFS file shares.
Premium page blobs3	Page blobs only	LRS	Premium storage account type for page blobs only. Learn more about page blobs and sample use cases.

Security for Storage

Defender for storage

Azure storage accounts are billed hourly. Applies to Blob containers, File shares and Data lakes Gen2.

Threat protection alerts – Advanced behavioral analytics and the Microsoft Intelligent Security Graph provide an edge over evolving cyber-attacks. Built-in behavioral analytics and machine learning can identify attacks and zero-day exploits. Monitor networks, machines, data stores (SQL servers hosted inside and outside Azure, Azure SQL databases, Azure SQL Managed Instance, and Azure Storage) and cloud services for incoming attacks and post-breach activity. Streamline investigation with interactive tools and contextual threat intelligence.

You can find the recommendations also from Storage accounts -> Security

Explore security anomalies

When storage activity anomalies occur, you receive an email notification with information about the suspicious security event. Details of the event include:

• The nature of the anomaly
• The storage account name
• The event time
• The storage type
• The potential causes
• The investigation steps
• The remediation steps

Encryption

Storage service encryption protects your data at rest. Azure Storage encrypts your data as it’s written in our datacenters, and automatically decrypts it for you as you access it. Note that after enabling Storage Service Encryption, only new data will be encrypted, and any existing files in this storage account will retroactively get encrypted by a background encryption process.

You can encrypt your data with your own key. It can be stored in Key vault.

Usage	Microsoft-managed keys	Customer-managed keys	Customer-provided keys
Encryption/decryption operations	Azure	Azure	Azure
Azure Storage services supported	All	Blob storage, Azure Files	Blob storage
Key storage	Microsoft key store	Azure Key Vault	Azure Key Vault or any other key store
Key rotation responsibility	Microsoft	Customer	Customer
Key usage	Microsoft	Azure portal, Storage Resource Provider REST API, Azure Storage management libraries, PowerShell, CLI	Azure Storage REST API (Blob storage), Azure Storage client libraries
Key access	Microsoft only	Microsoft, Customer	Customer only

Networking

By default the access is allowed from all networks.

You can choose the network you have already defined or create new ones. It’s also possible to add exceptions to these rules.

Or you can use private endpoints.

The type of sub-resource for the resource selected above that your private endpoint will be able to access.

and Private Link is created.

Azure Private Link is a security feature that will flow the traffic inside Microsoft Backbone network.

Secure and public access

Disable public access if not needed and enable Secure access (https) if not already enabled. For new provisions it’s already enabled by default.

Data protection

Microsoft offers data protection controls for Storage accounts. You can find them under Data proctection.

Azure AD

Enable Azure AD authentication for Storage services. It the following I enabled it to Azure Files.

This feature is currently in Preview.

Managed identities

Use managed identities to authenticate your usage instead of normal users. You can use the below Managed identity types.

Specify security requirements for containers

Container versus Virtual machine

A container is a pre-built software environment in which application code and its dependencies are preloaded into an image. There are some fundamental differences in technology.

Machine virtualization works at the hardware level and provides a way to run multiple instances of an operating system, while containers share a host operating system and run in separate processes.

Configure security for container services

Authentication

Method	How to authenticate	Scenarios	Azure role-based access control (Azure RBAC)	Limitations
Individual AD identity	az acr login in Azure CLI Connect-AzContainerRegistry in Azure PowerShell	Interactive push/pull by developers, testers	Yes	AD token must be renewed every 3 hours
AD service principal	docker login az acr login in Azure CLI Connect-AzContainerRegistry in Azure PowerShell Registry login settings in APIs or tooling Kubernetes pull secret	Unattended push from CI/CD pipeline Unattended pull to Azure or external services	Yes	SP password default expiry is 1 year
Managed identity for Azure resources	docker login  az acr login in Azure CLI Connect-AzContainerRegistry in Azure PowerShell	Unattended push from Azure CI/CD pipeline Unattended pull to Azure services	Yes	Use only from select Azure services that support managed identities for Azure resources
AKS cluster managed identity	Attach registry when AKS cluster created or updated	Unattended pull to AKS cluster in the same or a different subscription	No, pull access only	Only available with AKS cluster Can’t be used for cross-tenant authentication
AKS cluster service principal	Enable when AKS cluster created or updated	Unattended pull to AKS cluster from registry in another AD tenant	No, pull access only	Only available with AKS cluster
Admin user	docker login	Interactive push/pull by individual developer or tester Portal deployment of image from registry to Azure App Service or Azure Container Instances	No, always pull and push access	Single account per registry, not recommended for multiple users
Repository-scoped access token	docker login az acr login in Azure CLI Connect-AzContainerRegistry in Azure PowerShell Kubernetes pull secret	Interactive push/pull to repository by individual developer or tester Unattended pull from repository by individual system or external device	Yes	Not currently integrated with AD identity

RBAC-roles

Role/Permission	Access Resource Manager	Create/delete registry	Push image	Pull image	Delete image data	Change policies	Sign images
Owner	X	X	X	X	X	X
Contributor	X	X	X	X	X	X
Reader	X			X
AcrPush			X	X
AcrPull				X
AcrDelete					X
AcrImageSigner							X

Node security

AKS nodes are Azure digital machines which you control and maintain. Linux nodes run an optimized Ubuntu distribution the use of the Moby field runtime. Windows Server nodes run an optimized Windows Server 2019 launch and additionally use the Moby field runtime. When an AKS cluster is created or scaled up, the nodes are robotically deployed with the trendy OS protection updates and configurations.

The Azure platform robotically applies OS protection patches to Linux nodes on a nightly basis. If a Linux OS protection replace calls for a number reboot, that reboot isn’t robotically performed. You can manually reboot the Linux nodes, or a not unusualplace technique is to apply Kured, an open-supply reboot daemon for Kubernetes. Kured runs as a DaemonSet and video display units every node for the presence of a document indicating that a reboot is required. Reboots are controlled throughout the cluster the use of the identical cordon and drain procedure as a cluster upgrade.

For Windows Server nodes, Windows Update does not automatically run and apply the latest updates. On a regular schedule around the Windows Update release cycle and your own validation process, you should perform an upgrade on the Windows Server node pool(s) in your AKS cluster. This upgrade process creates nodes that run the latest Windows Server image and patches, then removes the older nodes. Nodes are deployed into a private virtual network subnet, with no public IP addresses assigned. For troubleshooting and management purposes, SSH is enabled by default. This SSH access is only available using the internal IP address.

Specify security requirements for container orchestration

Terminology

Master security

In AKS, the Kubernetes master component is part of a managed service provided by Microsoft. Each AKS cluster has a dedicated single-tenant Kubernetes master to provide API servers, schedulers, and more. This master is managed and maintained by Microsoft. By default, the Kubernetes API server uses a public IP address and a fully qualified domain name (FQDN). You can control access to API servers using Kubernetes and Azure Active Directory role-based access control.

Nodes and node pools

To run your applications and supporting services, you need a Kubernetes node. An AKS cluster has one or more nodes, which is an Azure virtual machine (VM) that runs the Kubernetes node components and container runtime:

• The kubelet is the Kubernetes agent that processes the orchestration requests from the control plane and scheduling of running the requested containers.
• Virtual networking is handled by the kube-proxy on each node. The proxy routes network traffic and manages IP addressing for services and pods.
• The container runtime is the component that allows containerized applications to run and interact with additional resources such as the virtual network and storage. In AKS, Moby is used as the container runtime.

Services

To simplify the network configuration for application workloads, Kubernetes uses Services to logically group a set of pods together and provide network connectivity. The following Service types are available:

• Cluster IP – Creates an internal IP address for use within the AKS cluster. Good for internal-only applications that support other workloads within the cluster.
• NodePort – Creates a port mapping on the underlying node that allows the application to be accessed directly with the node IP address and port.
• LoadBalancer – Creates an Azure load balancer resource, configures an external IP address, and connects the requested pods to the load balancer backend pool. To allow customers’ traffic to reach the application, load balancing rules are created on the desired ports.
• ExternalName – Creates a specific DNS entry for easier application access.

Security recommendations

BYOK with Azure disks in Azure Kubernetes Service (AKS)

Azure Storage encrypts all data in a storage account at rest. By default, data is encrypted with Microsoft-managed keys. For additional control over encryption keys, you can supply customer-managed keys to use for encryption at rest for both the OS and data disks for your AKS clusters

Limitations

• Data disk encryption support is limited to AKS clusters running Kubernetes version 1.17 and above.
• Encryption of OS disk with customer-managed keys can only be enabled when creating an AKS cluster.

Prerequisites

• You must enable soft delete and purge protection for Azure Key Vault when using Key Vault to encrypt managed disks.
• You need the Azure CLI version 2.11.1 or later.

RBAC-roles

Role/Permission	Access Resource Manager	Create/delete registry	Push image	Pull image	Delete image data	Change policies	Sign images
Owner	X	X	X	X	X	X
Contributor	X	X	X	X	X	X
Reader	X			X
AcrPush			X	X
AcrPull				X
AcrDelete					X
AcrImageSigner							X

Use a private registry

A publicly available container image does not guarantee security. Container images consist of multiple software layers, and each software layer might have vulnerabilities. To help reduce the threat of attacks, you should store and retrieve images from a private registry, such as Azure Container Registry or Docker Trusted Registry. In addition to providing a managed private registry, Azure Container Registry supports service principal-based authentication through Azure Active Directory for basic authentication flows. This authentication includes role-based access for read-only (pull), write (push), and other permissions.

Monitor and scan container images

For example, Azure Container Registry optionally integrates with Microsoft Defender for Cloud to automatically scan all Linux images pushed to a registry. Microsoft Defender for Cloud’s integrated Qualys scanner detects image vulnerabilities, classifies them, and provides remediation guidance.

Security monitoring and image scanning solutions such as Twistlock and Aqua Security are also available through the Azure Marketplace.

Protect credentials

Containers can spread across several clusters and Azure regions. So, you must secure credentials required for logins or API access, such as passwords or tokens. Ensure that only privileged users can access those containers in transit and at rest. Inventory all credential secrets, and then require developers to use emerging secrets-management tools that are designed for container platforms. Make sure that your solution includes encrypted databases, TLS encryption for secrets data in transit, and least-privilege Azure role-based access control (Azure RBAC). Azure Key Vault is a cloud service that safeguards encryption keys and secrets (such as certificates, connection strings, and passwords) for containerized applications.

Scan for vulnerabilities

New vulnerabilities are discovered all the time, so scanning for and identifying vulnerabilities is a continuous process. Incorporate vulnerability scanning throughout the container lifecycle:

• As a final check in your development pipeline, you should perform a vulnerability scan on containers before pushing the images to a public or private registry.
• Continue to scan container images in the registry both to identify any flaws that were somehow missed during development and to address any newly discovered vulnerabilities that might exist in the code used in the container images.

Enforce least privileges in runtime

The concept of least privileges is a basic security best practice that also applies to containers. When a vulnerability is exploited, it generally gives the attacker access and privileges equal to those of the compromised application or process.

Monitor container activity and user access

As with any IT environment, you should consistently monitor activity and user access to your container ecosystem to quickly identify any suspicious or malicious activity. Azure provides container monitoring solutions including:

• Azure Monitor for containers monitors the performance of your workloads deployed to Kubernetes environments hosted on Azure Kubernetes Service (AKS). Azure Monitor for containers gives you performance visibility by collecting memory and processor metrics from controllers, nodes, and containers that are available in Kubernetes through the Metrics API.
• The Azure Container Monitoring solution helps you view and manage other Docker and Windows container hosts in a single location. For example:
  • View detailed audit information that shows commands used with containers.
  • Troubleshoot containers by viewing and searching centralized logs without having to remotely view Docker or Windows hosts.
  • Find containers that may be noisy and consume excess resources on a host.
  • View centralized CPU, memory, storage, and network usage and performance information for containers.

Monitor container resource activity

Monitor your resource activity, like files, network, and other resources that your containers access. Monitoring resource activity and consumption is useful both for performance monitoring and as a security measure.

Azure Monitor enables core monitoring for Azure services by allowing the collection of metrics, activity logs, and diagnostic logs. For example, the activity log tells you when new resources are created or modified.

Log all container administrative user access for auditing

Maintain an accurate audit trail of administrative access to your container ecosystem, including your Kubernetes cluster, container registry, and container images. These logs might be necessary for auditing purposes and will be useful as forensic evidence after any security incident.

Microsoft Defender for Containers

What are the benefits of 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-prem / IaaS, or Amazon EKS. By continuously assessing clusters, Defender for Containers provides visibility into misconfigurations and guidelines to help mitigate identified threats. Learn more in Hardening.
• Vulnerability assessment – Vulnerability assessment and management tools for images stored in ACR registries and running in Azure Kubernetes Service. Learn more in Vulnerability assessment.
• Run-time threat protection for nodes and clusters – Threat protection for clusters and Linux nodes generates security alerts for suspicious activities. Learn more in Run-time protection for Kubernetes nodes, clusters, and hosts.

Scanning images in ACR registries

Defender for Containers includes an integrated vulnerability scanner for scanning images in Azure Container Registry registries.

There are four triggers for an image scan:

• On push – Whenever an image is pushed to your registry, Defender for Containers automatically scans that image. To trigger the scan of an image, push it to your repository.
• Recently pulled – Since new vulnerabilities are discovered every day, Microsoft Defender for Containers also scans, on a weekly basis, any image that has been pulled within the last 30 days. There’s no extra charge for these rescans; as mentioned above, you’re billed once per image.
• On import – Azure Container Registry has import tools to bring images to your registry from Docker Hub, Microsoft Container Registry, or another Azure container registry. Microsoft Defender for container Containers scans any supported images you import. Learn more in Import container images to a container registry.
• Continuous scan– This trigger has two modes:
  • A Continuous scan based on an image pull. This scan is performed every seven days after an image was pulled, and only for 30 days after the image was pulled. This mode doesn’t require the security profile, or extension.
  • (Preview) Continuous scan for running images. This scan is performed every seven days for as long as the image runs. This mode runs instead of the above mode when the Defender profile, or extension is running on the cluster.

Things to remember

Responsibility model and best practices:

• Enable Defender for Cloud – Open Defender for Cloud in the Azure portal for the first time or if you enable it through the API, Defender for Cloud is enabled for free on all your Azure subscriptions. By default, Defender for Cloud provides the secure score, security policy and basic recommendations, and network security assessment to help you protect your Azure resources.
• Store your keys and secrets in Azure Key Vault (and not in your source code). Key Vault is designed to support any type of secret: passwords, database credentials, API keys and, certificates.
• Install a web application firewall. Web application firewall (WAF) is a feature of Application Gateway that provides centralized protection of your web applications from common exploits and vulnerabilities.
• Enforce multi-factor verification for users, especially your administrator accounts. Azure Multi-Factor Authentication (Azure MFA) helps administrators protect their organizations and users with additional authentication methods.
• Encrypt your virtual hard disk files to help protect your boot volume and data volumes at rest in storage, along with your encryption keys and secrets.
• Connect Azure virtual machines and appliances to other networked devices by placing them on Azure virtual networks. Virtual machines connected to an Azure virtual network can connect to devices on the same virtual network, different virtual networks, the internet, or your own on-premises networks.
• Mitigate and protect against DDoS. Distributed denial of service (DDoS) is a type of attack that tries to exhaust application resources. Azure has two DDoS service offerings that help protect your network from attacks. DDoS Protection Basic is automatically enabled as part of the Azure platform. DDoS Protection Standard provides additional mitigation capabilities— beyond those of the Basic service tier—that are tuned specifically to Azure Virtual Network resources.

Best practices for IOT security

• Device identity
• Password-less authentication
• Organizational IoT device registry
• Least-privileged access control
• Monitoring
• Data protection

SQL

Azure AD features and limitation for SQL

Supported Azure AD identities

• Azure Active Directory Password
• Azure Active Directory Integrated
• Azure Active Directory Universal with Multi-Factor Authentication
• Using Application token authentication

And authentication methods

• Azure Active Directory Password
• Azure Active Directory Integrated
• Azure Active Directory Universal with Multi-Factor Authentication

What happens when you enable Azure AD as only identity provider for SQL.

What is dynamic masking and how it works?

How Always encrypted and TDE works in SQL, what is the difference?

Synapse and Cosmos

What is Azure Synapse Link and how to use it?

• Network isolation using private endpoints – You can control network access to the data in the transactional and analytical stores independently. Network isolation is done using separate managed private endpoints for each store, within managed virtual networks in Azure Synapse workspace
• Data encryption with customer-managed keys – You can seamlessly encrypt the data across transactional and analytical stores using the same customer-managed keys in an automatic and transparent manner. Azure Synapse Link only supports configuring customer-managed keys using your Azure Cosmos DB account’s managed identity. You must configure your account’s managed identity in your Azure Key Vault access policy before enabling Azure Synapse Link on your account.
• Secure key management – Accessing the data in analytical store from Synapse Spark and Synapse serverless SQL pools requires managing Azure Cosmos DB keys within Synapse Analytics workspaces.

App service

Recommendation	Comments
Disable anonymous access	Unless you need to support anonymous requests, disable anonymous access. For more information on Azure App Service authentication options, see Authentication and authorization in Azure App Service.
Require authentication	Whenever possible, use the App Service authentication module instead of writing code to handle authentication and authorization. See Authentication and authorization in Azure App Service.
Protect back-end resources with authenticated access	You can either use the user’s identity or use an application identity to authenticate to a back-end resource. When you choose to use an application identity use a managed identity.
Require client certificate authentication	Client certificate authentication improves security by only allowing connections from clients that can authenticate using certificates that you provide.

Storage

What are the different storage types and what encryption models can you use?

Usage	Microsoft-managed keys	Customer-managed keys	Customer-provided keys
Encryption/decryption operations	Azure	Azure	Azure
Azure Storage services supported	All	Blob storage, Azure Files	Blob storage
Key storage	Microsoft key store	Azure Key Vault	Azure Key Vault or any other key store
Key rotation responsibility	Microsoft	Customer	Customer
Key usage	Microsoft	Azure portal, Storage Resource Provider REST API, Azure Storage management libraries, PowerShell, CLI	Azure Storage REST API (Blob storage), Azure Storage client libraries
Key access	Microsoft only	Microsoft, Customer	Customer only

How to use Azure Private Link?

Containers and orchestration

Security recommendations for containers:

• Use a private registry
• Monitor and scan container images
• Protect credentials
• Scan for vulnerabilities
• Enforce least privileges in runtime
• Monitor container activity and user access
• Monitor container resource activity
• Log all container administrative user access for auditing
• Use Microsoft Defender for Containers

Link to main post