Skip to main content

How to secure access to Azure Management Portal

Migrating an existing system to Microsoft Azure can be a challenge when strong security requirements need to be in place. There are multiple tools and services that help us to provide a secure environments that it is not in our own datacenter.
Often we are focusing to secure the application and systems that are running inside Azure and forgetting about the Azure Portal itself. We can have the most secure application inside Azure if our subscription is compromised and someone is able to access it as admin.
In this post, we will look on some basic mechanisms and policies that enable us to secure access to the Azure Portal and subscription.

Channels
There two ways to access an Azure Subscription and to any kind of changes.
1. Azure Portal: The main dashboard used to administrate our Azure Subscription
2. SMAPI: Over the Rest API exposed by Microsoft, command-line interfaces like PowerShell, Batch can be used with success or even custom applications

Multi-factor authentication
One of the first things that can be done to the accounts that are accessing Azure Subscription is to activate multi-factor authentication. Additional to the password, the use will be required to do a second authentication step using SMS, phone number and so on.

Smart Cards
Account can be secured using a Smart Card or similar devices that are based on TPM (Trusted Platform Module) chips. They are using an asymmetric key pair or certificate where the secret (private key) is stored on the device.

Azure Management Certificates
These certificates are generated by Azure and can be used by different system to access and manage Azure Subscription. These certificates enable us to manage the subscription without having to enter a username and password.
They are very powerful especially when you want to use in combination with a Remote Desktop Gateway hosted inside Azure and a VPN.

Connection Authorization Policies
These policies can be used when Remote Desktop Gateway is used and can ensure that the machine that connect to it, it is part of a specific domain and even check and validate the machine name. 

Point-to-Site VPN
To ensure a more secure connection between client machines and Azure, a P2S VPN connection can be used to a machine hosted inside Azure. This would enable us to have a more communication channels between them. This is similar with having a Jump Box machine inside Azure.
Don’t forget that all communication with Azure management endpoints are over TLS.

Site-to-Site VPN
By using S2S VPN, your on-premises system is connected with your VNET network from Azure. As P2S VPN, this offers us a secure tunnel that can be used to communicate with Azure. A jump-box is not needed anymore; it is enough to configure traffic to Azure to goes over the S2S VPN directly.

NSG (Network Security Groups) and IP Restrictions
When a jump box with(out) a VPN connection it is used, NGS and IP Restrictions can be used to restrict access to the jump box.
Express Route
Express route is offering a dedicated and secure communication channel between your on-premises system and Azure. The private connection with Azure ensures are that there are no man in the middles.

Restrict number of users
Try to keep the number of users that have access to the subscription as low as possible. Many times 2-3 people are more than enough to have admin/co-admin rights.

Jump-box with Azure Management Certificates
This enable us to provide limited access to the Azure Portal through Remote Desktop Gateway without sharing with the user the credentials. The certificate that it is installed on the jump-box will provide access to Azure Management API.
This requires of course extra security measure at jump-box level.

Conclusion
Many feature and capabilities enable us to secure access to Azure Portal and Management API. Beside these, don’t forget that in the most of the cases people are the breach and not the system itself.

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see