When enterprise wants to use somebody else's computer, yes cloud/Azure is essentially just somebody else's computer, they want to make sure it is secure same to their on-premise environment. At least enterprise wants to delay the attack. Never think any security solution is final. Security measures are just about 'when' the attack will happen.
Multi-tenancy and Enterprise
Cloud is all about multi-tenancy. We have to share with others and enterprise always have doubt on it. When we share, will the other guy stole our assets or attack me? Whatever the cloud vendors assure that the cloud is secure and nothing gets leaked between the tenants, enterprise don't want to be just another tenant. They want their own space.
One way is to setup private cloud infrastructure inside enterprise. But it has upfront investment and lose the glory of auto scaling. So that is not the best options unless the security is the first concern.
Enter virtual networks
In order to give own space to enterprise or anybody who don't want to be another tenant, cloud providers started giving virtual networks. It ensures that our cloud resources are accessible only within the boundary of vNet and to have external communication separate gateways/tunnels are needed. They also support seamless connection to the enterprise's on premise network via VPN. That way enterprise can just lift and shift their classic virtual machine based solutions to Cloud and slowly adopt the cloud native features
In Amazon, it is called as VPC (Virtual Private Cloud) and in Azure it is simply virtual network or vNet for short.
vNet limits in Azure
Though there is vNet in Azure not all platform services are vNet ready. For example, we can put a virtual machine easily into vNet but Storage Account cannot. (Feature to limit Storage Account access to vNet is beta at the time of writing). Platform service such as AppService can be hosted inside vNet using a costly feature called AppServiceEnvironment.
Authenticating to platform services
Enterprise normally don't want to keep any secrets in application configuration. eg: Password to database connection should never be kept in web.config in case of an ASP.Net web application. Instead the app has to run under a specific IIS application pool and app pool user will be added to the database server hence app can use windows authentication. Or the authenticated user can be delegated to database directly. Again depends on the nature of application. We can ask then, what is the login password of app pool user? Is one or persons knowing it not a problem in enterprise?
In enterprise people changes often. If the identity is with people, it is easier to manage than keeping password in config. There are chances that someone in support may send the config file in mail or keep in \\shared drive etc... If it is app pool user and the password is with single team who installs the application, it is relatively safe. At least that is what enterprise believe.
Coming back to Azure. Not all Azure resources/platform services(PaaS) support windows/active directory based authentication. The application must preset password when it authenticate against the PaaS. So it demands apps to keep secrets such as passwords and connection strings with password in it.
Enter KeyVault
Microsoft suggests to use a PaaS called KeyVault to keep secrets. It has HSM (Hardware Security Modules) and much more features. Then the question from enterprise turns out to be "Does KeyVault support vNet?" Answer is No.
Should we keep the KeyVault's connection string with password in application's config? Then what is the difference between keeping database's connection string with password v/s KeyVault connction string with password in application's config?
So how do we protect KeyVault. If enterprise needs to be just another tenant in KeyVault, how to ensure the security? This post is about one way how can we protect connection to KeyVault which will protect other resources.
Architecture
The key message is simple here.
In order to connect to KeyVault use certificate instead of password in application's config.
Rest is circus we do to get all working together. We can use Azure Function to talk to KeyVault and vNet to protect that function so that nobody from outside can access that Function. Only that Function needs to know the certificate and registered as Azure AD App etc...
Diagram
This is the diagram which shows how the things are put together.
How it works
KeyVault
Since all the Azure resources are not compatible with vNet and Active Directory based authentication, we cannot avoid keep the passwords and secrets. It is advised to keep the secrets in the KeyVault than in app or web.config.
This way the secrets will always be with one team who installs the application.
Azure AD App
In order to access KeyVault we need to have an Azure Active Directory Application. KeyVault accepts the AD token to get authenticated.
KeyVault Function/Web App
This is the only component which knows how to connect to Azure KeyVault via Azure AD. It is called by other components in the system whenever they need any secret. This must be the only one registered with AzureAD App.
Alternative is to register all the components as Azure AD App and have the certificate with them. So they can access KeyVault directly
ASE
ASE is required to make sure that the KeyVault Azure Function is accessible within the boundary of enterprise's private area ie vNet. This makes the KeyVault Function secure without accepting security credential in every http request.
No comments:
Post a Comment