Section 8 – Implement platform protection – Configure advanced security for compute – Serverless, App service and encryption

And the next section for AZ-500 study guide will cover the following topics:

• Configure security for serverless compute
• Configure security for an Azure App Service
• Configure encryption at rest
• Configure encryption in transit

Configure security for serverless compute

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.

Security considerations

To avoid sensitive data leakages from the cloud storage infrastructure, vendors can provide a set of security capabilities, like cloud storage configurations, multi-factor authentication, and encryption of data in transit and at rest. Organizations that use cloud storage should get familiar with the available storage
security controls that their cloud vendor provides.

Unwanted privileges and roles

Privileges should be assigned to a serverless application that requires access to a resource and
should be constrained to a limited time.
Granting permissions to a user beyond the scope required for an action can allow that user to obtain
or change information in unwanted ways. A careful delegation of access rights can limit attackers
from damaging a system. For example, a serverless function with Azure SQL Database will read the database and perform analysis on that data only when it’s granted “read” permissions on that specific SQL resource.

• Apply identity and access management (IAM) capabilities relevant to your platform, and make sure that each function has its own user role that runs with least privileges. Microsoft Azure currently does not provide per-function permissions and roles. But different Azure services offer access controls that you can deploy to reduce unnecessary privileges. For example, shared access signatures grant limited access to objects in your storage account to other clients.
• Use Privileged Identity Management with RBAC to manage, control, and monitor access to Azure resources.

Injection flow in Azure functions

When other applications try to access Azure functions, an HTTPS request is sent. When this request
is received, execution of the Azure function begins. After the execution of the Azure function, an
HTTPS response is returned to the application.

• Do not explicitly trust input or make any assumptions about its validity.
• Use safe APIs to authorize user input or APIs . This method provides a mechanism for binding variables for the underlying infrastructure.
• Validate and authorize user input before passing directly to any interpreter.
• Check that your code always runs with least privileges required to perform its task.
• Do not assume that input can arrive only from the expected event trigger.
• Always consider all possible event types and entry points into the system when you’re applying threat modeling in your development lifecycle.
• Use a web application firewall to inspect incoming HTTPS traffic to your serverless application.

Fragmented authentication

Do not build custom authentication schemes. Use authentication facilities that the
serverless environment provides.

• Azure App Service authentication/authorization. Azure App Service provides built-in authentication and authorization support, so you can sign in users and
• access data by writing minimal or no code in your Azure functions.
• Mobile authentication with a provider SDK.
• Mobile authentication without a provider SDK.
• Service-to-service authentication.
• Developers should use secure API keys, SAML assertions, client-side certificates, or similar authentication standards, because interactive user authentication is not an option.

Storage

Secrets can be any type of sensitive information that should not be handled in plain text. It’s
common to have application settings that are sensitive and must be protected, such as:

• Database connection strings
• Passwords
• Cryptographic keys

You should never store these secrets in source control. It’s too easy for them to leak—even if your
source code repository is private. It’s not just about keeping secrets from the public. On larger
projects, you might want to restrict which developers and operators can access the production
secrets. (Settings for test or development environments are different.)

• Store all application secrets in encrypted storage. Maintain encryption keys through a centralized infrastructure for encryption key management. Most server-wide architectures and cloud vendors perform this key maintenance. Developers should provide a secure API that can be easily integrated into a serverless environment.
• A more secure option is to store these secrets in Azure Key Vault. Key Vault is a cloud-hosted service for managing cryptographic keys and other secrets.

Securing serverless

Securing functions with Azure Active Directory

Azure Active Directory is the identity provider that verifies the identity of users and applications that
exist in an organization’s directory. It issues security tokens upon successful authentication of those
users and applications. Azure AD is used to authorize the users and applications.

Securing access to manage or edit logic apps

You can restrict access to management operations on a logic app so that only specific users or
groups can perform operations on the resource. Logic apps use the Azure RBAC feature, and can be
customized with the same tools. You can also assign members of your subscription to these built-in
roles:

• Logic App Contributor: Provides access to view, edit, and update a logic app. This role can’t remove the resource or perform admin operations.
• Logic App Operator: Can view the logic app and run history, and enable/disable. This role can’t edit or update the definition.

Securing Event Grid resources

Azure Event Grid is a service that raises events from anywhere to anywhere. Event
Grid supports events that come from Azure services at the subscription, resource group, and
resource levels. You can use Event Grid to build applications with event-based architectures. Event
Grid has three types of authentication that need to be secure at each level of authentication.

• Role-based access control is a method of regulation that’s defined according to job competency, authority, and responsibility within the enterprise.
• Webhook validation. Webhooks are one of the ways to receive events from Azure Event Grid. New webhooks need to be registered with Event Grid. Event Grid sends you a POST request with a simple validation code to prove endpoint ownership.
• Shared access signatures can be used like a username and password scheme, where the client is in immediate possession of an authorization rule name and a matching key.

Monitoring

Real-time incident response can help protect against attacks. This is especially true when the system
is successfully breached.
To avert successful attacks, organizations must have real-time monitoring and logging and eventing
to gain insights into how well a system is functioning. It’s also a crucial part of maintaining quality-of-service targets.

• Maintaining an inventory list of software packages and other dependencies and their versions.
• Scanning software for known vulnerable dependencies—especially when you’re adding new packages or upgrading package versions. Vulnerability scanning should be part of
• your ongoing continuous integration and delivery process.
• Removing unnecessary dependencies, especially when your serverless functions no longer need them.
• Consuming third-party packages only from trustworthy resources and making sure that the packages have not been compromised.
• Upgrading deprecated package versions to the latest versions and applying all relevant software patches.

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.

Configure encryption at rest

What is encryption at rest?

Encryption is the secure encoding of data used to protect confidentiality of data. The Encryption at Rest designs in Azure use symmetric encryption to encrypt and decrypt large amounts of data quickly according to a simple conceptual model:

• A symmetric encryption key is used to encrypt data as it is written to storage.
• The same encryption key is used to decrypt that data as it is readied for use in memory.
• Data may be partitioned, and different keys may be used for each partition.
• Keys must be stored in a secure location with identity-based access control and audit policies. Data encryption keys which are stored outside of secure locations are encrypted with a key encryption key kept in a secure location.

Microsoft Cloud services are used in all three cloud models: IaaS, PaaS, SaaS. Below you have examples of how they fit on each model:

• Software services, referred to as Software as a Server or SaaS, which have applications provided by the cloud such as Microsoft 365.
• Platform services in which customers use the cloud for things like storage, analytics, and service bus functionality in their applications.
• Infrastructure services, or Infrastructure as a Service (IaaS) in which customer deploys operating systems and applications that are hosted in the cloud and possibly leveraging other cloud services.

Content types

Content types	Encryption Technologies	Resources to learn more
Files on a device. These files can include email messages saved in a folder, Office documents saved on a computer, tablet, or phone, or data saved to the Microsoft cloud.	BitLocker in Microsoft datacenters. BitLocker can also be used on client machines, such as Windows computers and tablets Distributed Key Manager (DKM) in Microsoft datacenters Customer Key for Microsoft 365	Windows IT Center: BitLocker Microsoft Trust Center: Encryption Cloud security controls series: Encrypting Data at Rest How Exchange Online secures your email secrets Service encryption with Customer Key

Data encryption models

There are three scenarios for server-side encryption:

• Server-side encryption using Service-Managed keys
  • Azure Resource Providers perform the encryption and decryption operations
  • Microsoft manages the keys
  • Full cloud functionality
• Server-side encryption using customer-managed keys in Azure Key Vault
  • Azure Resource Providers perform the encryption and decryption operations
  • Customer controls keys via Azure Key Vault
  • Full cloud functionality
• Server-side encryption using customer-managed keys on customer-controlled hardware
  • Azure Resource Providers perform the encryption and decryption operations
  • Customer controls keys on customer-controlled hardware
  • Full cloud functionality

How each Azure service supports each encryption model?

Configure encryption in transit

In addition to protecting customer data at rest, Microsoft uses encryption technologies to protect customer data in transit. Data is in transit:

• When a client machine communicates with a Microsoft server;
• When a Microsoft server communicates with another Microsoft server; and
• When a Microsoft server communicates with a non-Microsoft server (for example, Exchange Online delivering email to a third-party email server).

Inter-data center communications between Microsoft servers take place over TLS or IPsec, and all customer-facing servers negotiate a secure session using TLS with client machines (for example, Exchange Online uses TLS 1.2 with 256-bit cipher strength is used (FIPS 140-2 Level 2-validated). (See Technical reference details about encryption for a list of TLS cipher suites supported by Office 365.) This applies to the protocols that are used by clients such as Outlook, Skype for Business, Microsoft Teams, and Outlook on the web (for example, HTTP, POP3, etc.).

All implementation details such as the version of TLS being used, whether Forward Secrecy (FS) is enabled, the order of cipher suites, etc., are available publicly. One way to see these details is to use a third-party website, such as Qualys SSL Labs. Below are the links to automated test pages from Qualys that display information for the following services:

• Office 365 Portal
• Exchange Online
• SharePoint Online
• Skype for Business (SIP)
• Skype for Business (Web)
• Exchange Online Protection
• Microsoft Teams

For Exchange Online Protection, URLs vary by tenant names; however, all customers can test Microsoft 365 using microsoft-com.mail.protection.outlook.com.

Content types

Content types	Encryption Technologies	Resources to learn more
Files in transit between users. These files can include Office documents or SharePoint list items shared between users.	TLS for files in transit	Data Encryption in OneDrive for Business and SharePoint Online Skype for Business Online: Security and Archiving
Email in transit between recipients. This email includes email hosted by Exchange Online.	Office 365 Message Encryption with Azure Rights Management, S/MIME, and TLS for email in transit	Office 365 Message Encryption (OME) Email encryption in Office 365 How Exchange Online uses TLS to secure email connections in Office 365
Chats, messages, and files in transit between recipients using Microsoft Teams.	Teams uses TLS and MTLS to encrypt instant messages. Media traffic is encrypted using Secure RTP (SRTP). Teams uses FIPS (Federal Information Processing Standard) compliant algorithms for encryption key exchanges.	Encryption for Teams

Encryption of data

In OneDrive for Business and SharePoint Online, there are two scenarios in which data enters and exits the datacenters.

• Client communication with the server – Communication to SharePoint Online and OneDrive for Business across the Internet uses TLS connections.
• Data movement between datacenters – The primary reason to move data between datacenters is for geo-replication to enable disaster recovery. For instance, SQL Server transaction logs and blob storage deltas travel along this pipe. While this data is already transmitted by using a private network, it is further protected with best-in-class encryption.

SharePoint Online and OneDrive for Business

Encryption

All customer files in SharePoint Online are protected by unique, per-file keys that are always exclusive to a single tenant. The keys are either created and managed by the SharePoint Online service, or when Customer Key is used, created and managed by customers. When a file is uploaded, encryption is performed by SharePoint Online within the context of the upload request, before being sent to Azure storage. When a file is downloaded, SharePoint Online retrieves the encrypted customer data from Azure storage based on the unique document identifier and decrypts the customer data before sending it to the user. Azure storage has no ability to decrypt, or even identify or understand the customer data. All encryption and decryption happen in the same systems that enforce tenant isolation, which are Azure Active Directory and SharePoint Online.

Several workloads in Microsoft 365 store data in SharePoint Online, including Microsoft Teams, which stores all files in SharePoint Online, and OneDrive for Business, which uses SharePoint Online for its storage. All customer data stored in SharePoint Online is encrypted (with one or more AES 256-bit keys) and distributed across the datacenter as follows. (Every step of this encryption process is FIPS 140-2 Level 2 validated.

Storage components

Each of these three storage components – the Azure blob store, the Content Database, and the Key Store – is physically separate. The information held in any one of the components is unusable on its own. Without access to all three, it is impossible to retrieve the keys to the chunks, decrypt the keys to make them usable, associate the keys with their corresponding chunks, decrypt each chunk, or reconstruct a document from its constituent chunks.

BitLocker and TDE

BitLocker certificates, which protect the physical disk volumes on machines in the datacenter, are stored in a secure repository (the SharePoint Online secret store) that is protected by the Farm key.

The TDE keys that protect the per-blob keys are stored in two locations:

• The secure repository, which houses the BitLocker certificates and is protected by the Farm Key; and
• In a secure repository managed by Azure SQL Database.

List Items in SharePoint Online

List Items are smaller chunks of customer data that are created ad-hoc or that can live more dynamically within a site, such as rows in a user-created list, individual posts in a SharePoint Online blog, or entries within a SharePoint Online wiki page. List items are stored in the Content Database (Azure SQL Database) and protected with TDE.

Microsoft Teams

Traffic type	Encrypted by
Server-to-server	MTLS
Client-to-server (ex. instant messaging and presence)	TLS
Media flows (ex. audio and video sharing of media)	TLS
Audio and video sharing of media	SRTP/TLS
Signaling	TLS

Media Encryption

Media traffic is encrypted using Secure RTP (SRTP), a profile of Real-Time Transport Protocol (RTP) that provides confidentiality, authentication, and replay attack protection to RTP traffic. SRTP uses a session key generated by using a secure random number generator and is exchanged using the signaling TLS channel. Client-to-client media traffic is negotiated through a client-to-server connection signaling but is encrypted using SRTP when going client-to-client directly.

Things to remember

Serverless

What are main components for Serverless

• Functions
• Logic Apps
• Event Grid

What are the recommendations for securing Serverless

App service

Different SKU’s and their security features

How to harden security for App services

Encryption in rest and transit

What means in rest and in transit

How different services encrypt data

Differences between Microsoft and customer managed keys and integration to Azure Managed HSM

Link to main post