If you talk to a very large organizations, they never only have one cloud provider. More likely, they might have at least two or even three big ones or they may be maintaining a private cloud somewhere else. So, they understand that the management of machine identities across clouds is very important. And part of the success of their multi cloud strategy is having a quick and easy way to change between cloud providers when the need arises.
But if you ask them what that means for their machine identities, many have not thought deeply enough about that subject. When you ask them what happens if they want to move away from one provider—say AWS—and have this instance hosted by another—like Azure, for instance—they tend to oversimplify the answer. More often than not, their answer may be something like this, "We’ll just get another instance at Azure." But what they are not thinking about is that they will not be able to use the certificate they got from AWS on Azure or any other cloud provider.
For example, a previous colleague of mine told me of meeting with a large retailer who was working on a plan to outsource to a cloud datacenter. He began the meeting by asking questions to understand how well they were identifying and addressing the full impact and exposure of outsourcing machine identities as part of the program. He posed questions such as, “Would you feel comfortable giving your credentials or private keys to somebody that you don't really know? What if you want to change providers in a year or so because they aren’t doing the job right? Will you have access to all of those machine identities?” All great questions.
But the real question (and the question that he didn’t ask) was whether the organization should feel comfortable outsourcing machine identity management to a third-party cloud provider. To proceed securely in a multi-cloud strategy, they would first need to think seriously about how they could maintain control of the management of their machine identities across cloud providers.
In many ways, changing cloud provider is like changing Certificate Authorities (CAs). You need to be able to identify all certificates associated with cloud instances in a given cloud provider, revoke them and reissue them on the new cloud provider. You can make this process relatively pain-free if you are able to automate it. But most organizations never get that far in their thinking.
It's important for these organizations to know that they are not alone. The majority of companies are faced with the same issue and they have not solved it. The easiest advice to follow is that you should treat machine identities for cloud instances in exactly the same way that you treat them in on-premises environments.
In the cloud, as on premises, you need to have a complete and accurate inventory of all machine identities and you have to continually monitor them. It’s the only way that you will know whether the certificate is still on the AWS instance when it should be. And that it does not remain on AWS the next day when you're no longer there. So, you have to monitor machine identities across cloud instances and you have to renew them when necessary changes occur. This is especially important in the cloud, where the renewal period should be even shorter than on premises.
It’s critical that you treat the cloud as just another component of your overall machine identity management program. It's simply one more infrastructure you need to plug into for global visibility and machine identity intelligence. Ultimately, it's got the same rules and the same issues as every other infrastructure. And you should be prepared to be just as agile in the cloud as you are on premises.
- Moving to the Cloud Doesn’t Mean You Can Forget about Key Management
- The “Egregious 11” Have Spoken: Machine Identities in the Cloud Need to Evolve
- Why Zero Trust in the Cloud Requires On-demand Machine Identity Protection
- Dynamism in the Cloud Complicates the Task of Securing Machine Communication