Security Controls in Azure Security Center: Manage Access and Permissions

by Contributed | Sep 29, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

Continuing our Secure Score series of blog posts, this post will discuss how to manage access and permissions from an Azure Security Center perspective and walk through the respective recommendations.

Access management for cloud resources is a critical function for any organization that is using the cloud. Using Role-based access control (RBAC), an authorization system built on Azure Resource Manager, is the best way to manage access to resources by creating role assignments. Azure role-based access control helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.
In Azure Security Center, we have a dedicated security control named “Manage access and permissions”, which contains our best practices for different scopes.

Why manage access and permissions is so critical?

A core part of a security program is ensuring your users have the necessary access to do their jobs but no more than that: the least privilege access model. Instead of giving everybody unrestricted permissions in your Azure subscription or resources, you can allow only certain actions at a particular scope.
You can control access to your resources by creating role assignments with role-based access control (RBAC). A role assignment consists of three elements:

• Security principal: the object the user is requesting access to (for example, user or group)
• Role definition: their permissions based on built-in or custom roles (for example: owner or contributor)
• Scope: the set of resources to which the permissions apply (for example: subscription or management group)

As you learned in this blog post (blog series), recommendations are grouped in Security Controls.
In Azure Security Center, we have several recommendations based on 4 different scope: Subscriptions, Kubernetes, Storage accounts and Service Fabric resources. All of them are available as part of the “Manage access and permissions” security control which has the max score of 4 points.

What’s included within the Manage access and permissions security control?

Let’s dive into the available recommendations as part of this control. Each one is a built-in policy definition contained within the Azure Portal; all definitions are available in Azure Policy blade.

• External accounts with write permissions should be removed from your subscription
• External accounts with owner permissions should be removed from your subscription
• Deprecated accounts should be removed from your subscription
• Deprecated accounts with owner permissions should be removed from your subscription
• There should be more than one owner assigned to your subscription
• Service principals should be used to protect your subscriptions instead of Management Certificates [Preview]
• Role-Based Access Control (RBAC) should be used on Kubernetes Services
• Azure Policy Add-on for Kubernetes should be installed and enabled on your clusters [Preview]
• Privileged containers should be avoided [Preview]
• Least privileged Linux capabilities should be enforced for containers [Preview]
• Immutable (read-only) root filesystem should be enforced for containers [Preview]
• Usage of pod HostPath volume mounts should be restricted to a known list to restrict node access from compromised containers [Preview]
• Running containers as root user should be avoided [Preview]
• Containers sharing sensitive host namespaces should be avoided [Preview]
• Container with privilege escalation should be avoided [Preview]
• Service Fabric clusters should only use Azure Active Directory for client authentication
• Storage account public access should be disallowed [Preview]

As listed above, a subset of recommendations was recently released as “Preview”. Security Center no longer includes preview recommendations when calculating the Secure Score. Preview recommendations are still available to allow exploration and remediation of the unhealthy resources across your Azure subscriptions.

Category #1: Recommendations for Azure Subscriptions

An Azure subscription refers to the logical entity that provides entitlement to deploy and consume Azure resources. Like any other Azure service, a subscription is a resource which you can assign RBAC on. Azure Security Center provides access and permissions recommendations for subscriptions too. Those are breakdown to sub-categories: external accounts, deprecated accounts, and administrative accounts.

• External accounts with permissions – Extremal accounts in Azure AD are accounts having different domain names than the one which is being used corporate identities (such as Azure AD B2B collaboration, Microsoft Accounts, etc.). Usefully, those accounts are not managed or monitored by the organization and can be targets for attackers looking to find ways to access your data without being noticed. Recommendations will suggest to remove external account with either of the following permissions: owner/write/read (classic-administrators permissions are part of owner role).
  Deprecated accounts – Security Center consider deprecated accounts as the ones which are  stored in Azure AD and have been blocked from signing-in. The same as the external account, these accounts can be targets for attackers looking to find ways to access your data without being noticed.
  Such accounts could have owner permissions on the subscription.
• Administration accounts – One of our best practices is to have more than one owner assigned to a subscription in order to have administrator access redundancy and. Additionally, we recommend to have maximum of 3 owners, in order to reduce the potential for breach by a compromised owner.
  So, the recommendation is to have 2 owners per subscription. Currently, this recommendation check existence of direct assignment at the subscription and not the inherited ones by a management group. Moreover, security groups are currently not supported either. And lastly, to manage your subscriptions more securely, once you decide for the required owners, we recommend using user accounts or service principals rather than management certificates.

The following recommendations belong to this category:

• External accounts with write permissions should be removed from your subscription
• External accounts with owner permissions should be removed from your subscription
• Deprecated accounts should be removed from your subscription
• Deprecated accounts with owner permissions should be removed from your subscription
• There should be more than one owner assigned to your subscription
• Service principals should be used to protect your subscriptions instead of Management Certificates [Preview]

Category #2: Recommendations for Kubernetes

To ensure your Kubernetes workloads are secure by default, Security Center provided Kubernetes-level policies and hardening recommendations, including enforcement options with Kubernetes admission control. We recently announced the deprecation of preview AKS recommendation “Pod Security Policies should be defined on Kubernetes Services”. In favor, we replaced it with 13 new recommendations for AKS workload protection where 7 of them are part of the discussed security control. Those new recommendations allow you to audit or enforce them and are based on the Azure Policy Add-on for Kubernetes. This add-on extends Gatekeeper v3, to apply at-scale enforcements and safeguards on your clusters in a centralized, consistent manner.

The new recommendations allow you to:

• Provide granular filtering on the actions that users can perform by using RBAC to manage permissions in Kubernetes Service Clusters and configure relevant authorization policies.
• Reduce entry points for attacks and to spread malicious code or malware to compromised applications, hosts and networks.
• Reduce attack surface of container by restricting Linux capabilities and granting specific privileges to containers without granting all the privileges of the root user.
• Prevent unrestricted host access (privileged containers have all the root capabilities of a host machine).
• Protect containers from changes at run-time with malicious binaries being added to PATH.
• Prevent from an attacker to use root and exploit misconfigurations.
• Protect against privilege escalation outside the container by avoiding pod access to sensitive host namespaces in a Kubernetes cluster.

During the preview phase, few of the above recommendations will be disabled by default. To enable them or adjust the settings to your needs, modify the “ASC Default” initiative assignment:

The following recommendations belong to this category:

• Role-Based Access Control (RBAC) should be used on Kubernetes Services
• Azure Policy Add-on for Kubernetes should be installed and enabled on your clusters [Preview]
• Privileged containers should be avoided [Preview]
• Least privileged Linux capabilities should be enforced for containers [Preview]
• Immutable (read-only) root filesystem should be enforced for containers [Preview]
• Usage of pod HostPath volume mounts should be restricted to a known list to restrict node access from compromised containers [Preview]
• Running containers as root user should be avoided [Preview]
• Containers sharing sensitive host namespaces should be avoided [Preview]
• Container with privilege escalation should be avoided [Preview]

Category #3: Recommendation for Storage accounts

By default, a storage account is configured to allow a user with the appropriate permissions to enable public access to a container.
When public access is allowed, a user with the appropriate permissions can modify a container’s public access setting to enable anonymous public access to the data in that container. Frequently, anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but might present security risks. Disallowing public access for the storage account prevents anonymous access to all containers and blobs in that account. Moreover, it prevents data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it.

The following recommendation belong to this category:

• Storage account public access should be disallowed [Preview]

Category #4: Recommendation for Service Fabric

Azure Service Fabric allow few authentication options to secure the access to management endpoints from client  to cluster – to ensure that only authorized users can access the cluster and its management endpoint. Such options are certification authentication or Azure Active Directory authentication.
Azure Security Center recommend performing client authentication only via Azure Active Directory.

The following recommendation belong to this category:

• Service Fabric clusters should only use Azure Active Directory for client authentication

Next Steps

In this blog we all recommendations related to manage access and permissions security control; from protecting subscriptions down to PaaS services like Kubernetes, Service Fabric and Storage accounts. To gain credit and increase your overall Secure Score, you must remediate all recommendations within the control.

Additionally, few recommendations like the Kubernetes one, were automatically configured with default parameters – please make sure to review and customize its values via Security Policy tab.

I hope you enjoyed this blog post and learned how this speisific control can assist you to strengthen your Azure security posture.

• The main blog post to this series (found here)
• The DOCs article about Secure Score (this one) 

Reviewers

How to Change collation for production Azure SQL databases

by Contributed | Sep 29, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

In this article I will explain how to change the collation for your production Azure SQL Databases without loosing data/updates on the database with a minimum downtime.

Steps in brief:

• Take a copy of the production database to a higher service tier ex: P11 on the same server.
• Export the database to bacpac using SQLPackage. (It’s better to use a VM in the same region of the SQL server for less latency)
• Modify the collation by editing the model.xml file.
• Import the database again to a higher service tier ex: P11 by using SQLPackage and overriding the model.xml path.
• Change the database name, or modify app connection string to use the new database.

Things to consider:

• Azure SQL Database only supports changing collation by modifying the model.xml file for .bacpac files.
• Schedule a maintenance window for your application during the process and stop the workload to prevent loosing updates on your database.
• Do the export/import to/from databases with a higher service tier to boost the operation.
• Use a VM in the same region to save latency time.
• If your database is/was used for Data Sync Service, consider removing DSS object before exporting the database. Check: https://techcommunity.microsoft.com/t5/azure-database-support-blog/exporting-a-database-that-is-was-used-as-sql-data-sync-metadata/ba-p/369062
• If your database is a part of Geo-DR replication, consider removing the Geo link and delete secondary database before starting the operation in order to create a new Geo replication and sync the new database with the new collation to the secondary server.

Steps in details:

1. Make sure you have a modern version of SQLPackage.

• Latest SQLPackage version is here .
• Sqlpackage installs to the C:Program FilesMicrosoft SQL Server150DACbin directory.

2. Start the maintenance window for your application.

3. Make a copy of the production database to a higher service tier ex: P11.

    How to copy SQL databases: https://docs.microsoft.com/en-us/azure/azure-sql/database/database-copy?tabs=azure-powershell#copy-using-the-azure-portal

4. Export the copied database using SQLPackage from a VM on the same region of your SQL server.

• Open CMD > Navigate to SQLPackage location > ex: “C:Program FilesMicrosoft SQL Server150DACbin” .

• Run the below command to export the database:

         sqlpackage.exe /Action:Export /ssn:tcp:<ServerName>.database.windows.net,1433 /sdn:<DatabaseName> /su:<UserName> /sp:<Password> /tf:<TargetFile> /p:Storage=File

5. Change the database collation in the bacpac model.xml file:

• Open the .bacpac file using WinRAR without de-compress the file.

• Copy the model.xml to a local folder “C:Tempmodel.xml”.

• Edit the “C:Tempmodel.xml” with the desired collation and save the file.

For example:

From: <Property Name=”Collation” Value=”SQL_Latin1_General_CP1_CI_AS” />

To: <Property Name=”Collation” Value=”Hebrew_CI_AS” />

6. Run the import using sqlpackage.exe, and use the /ModelFilePath:C:Tempmodel.xml parameter to override the model.xml in the .bacpac.

For example:
sqlpackage.exe /Action:Import /tsn:<server>.database.windows.net /tdn:<database> /tu:<user> /tp:<password> /sf:”C:Tempdatabase.bacpac” /ModelFilePath:C:Tempmodel.xml /p:DatabaseEdition=Premium /p:DatabaseServiceObjective=P11

7. When the import operation completed, Change the database name, or modify the application connection string to use the new database.

8. Stop the maintenance window for your application and run workload.

9. Delete the copied and old databases.