IAM for Multi-Cloud Security
Multicloud.11 IAM is challenging and one of your biggest cloud security risks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Multi-Cloud Security | AWS Security | Azure Security | GCP & Google Security | AWS IAM
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post I wrote about how Drift Detection might help you with multi-cloud security and also some of the pitfalls.
In this post I am going to do a really brief explanation of Identity and Access Management (IAM) for cloud as it’s a topic that could warrant a book in AWS, Azure, or GCP.
In any cloud environment, stolen and abused credentials are your number one risk and source of attack. Those credentials may be stolen by way of misconfigured or abused web applications, checked into source control, captured via phishing, or a keylogger in malware deployed via a vulnerability in software installed on a developer’s laptop — as was the case in a recent LastPass breach.
Identity Management and Passwords
The first part of IAM is identity. When a user or application wants access to something they need to prove who they are. You need to identify them. Where do you store those identities?
If you store identities in every different cloud product you access, users need to remember a bunch of different credentials, or use a password manager which may become the target of an attack. Storing separate identities in every single cloud system means when a person leaves the company, you have to log into each and every system to remove or disable that identity if you don’t manage those identities in a central location. Like a password manager, the central location where you store your identities becomes a key target for an attack.
In the past the majority of companies stored those identities in a system called Active Directory. All the on-premises actions required users to login and authenticate, or prove who they are. Typically when performing a penetration test of an on-premises environment attackers try to get what is called “domain admin” or access to control the Active Directory server. Once they have access to the active directory server they control everything because they can create new users with permissions to anything they want.
What attackers will target these days depends on where your identities are stored. Some companies are moving identities from on-premises Active Directory servers to a similar service in Azure called Azure Active Directory, now being rebranded Entra ID.
https://azure.microsoft.com/en-us/updates/azure-ad-is-becoming-microsoft-entra-id/
I remember teaching a class on Azure and just a month or so later a customer was asking me what all the links with Entra in the name were. They were totally confused. So was I. I did a quick web search and found information about the service which later became a complete rename. This constant churn of naming and branding by Microsoft is a bit perplexing.
One reason why Microsoft may be rebranding is because Azure AD and Active Directory are really very different. Azure AD doesn’t use Kerberos in the traditional sense. Kerberos was added to Azure AD but was re-architected in the process. You can read about that here:
You can deploy an Active Directory server in the cloud. I helped the team at Capital One who did just that in AWS years back — and it was a royal pain. Now managed Active Directory services exist where the cloud provider will deploy a directory for you and help you manage it. Make sure you evaluate the automagically deployed networking rules if you do that and understand what your requirements are for keeping your systems up to date — is it you or the cloud provider?
Or, you could use a service like Azure AD now Entra ID. All users across all cloud providers must authenticate to your Azure AD / Entra ID deployment using something like SAML or OIDC.
Risks associated with SSO and consolidation of authentication
Consolidation of Identities makes them easier to manage but it also creates a risk. What happens when someone gets into your single identity management system? What access will they have and what can they do? Separation of duties is key and something I have written a lot about as I build out an architecture on AWS.
What if you host all your identites in Azure? Then someone at Microsoft who competes with AWS might obtain access to your AWS account. How carefully have you evaluated that threat and whether it is possible with your current architecture. I also mentioned Google Identity in a prior post which can offer similar SSO functionality and access to all your other systems.
Separation of duties via separation of vendor concerns
What if you could move your Identity management to a specific vendor that specializes in that specific area? What if you could separate identity management to that vendor and access management to the cloud providers themselves? That’s a topic I’ve been exploring in my series on Okta.
Okta has been focusing on Identity management for a while and the number of different cloud products with which they integrate is quite impressive.
I’ve mentioned some pros and cons of using Okta and there are a few gaps I wish they would close in their architecture and implementation. But with Okta, I was able separate the identity and password creation from the provisioning of permissions on AWS. You can separate those two things to different groups within your organization potentially, or require two party access to grant certain permissions using the strategies I described and implemented.
You can use Terraform with Okta as well to automate deployments, but then you have some risk associated with that additional layer as I mentioned in another post. It may be beneficial but evaluate how it works carefully in terms of caching, drift detection, and if it supports enforcement of MFA, separation of duties, and requiring two people to carry out sensitive actions.
Okta has an API which cuts out the need for this additional layer. Even though I would prefer templates, I’m going to stick with working directly with Okta for now.
The unfortunate thing, as I wrote about in my Okta series, is that Okta does not support a private connection to AWS, Azure, or GCP from the documentation I have read using features such as AWS PrivateLink, Azure PrivateLink, or GCP Private Service Connect. I find this hard to believe but I can’t find documentation to the contrary. I hope that gets added in the near future as I’m sure for some organizations that will eliminate Okta as an option.
Where are the credentials stored?
If you were following along in my AWS automation posts, I had some challenges trying to enforce non-repudiation by disallowing an AWS IAM admin from seeing a user’s password upon creation. I wrote about how using a multi-step process with separation between Okta and AWS can prevent an administrator from creating a new user and granting themselves access to things they shouldn’t be able to access. Also, the credentials are never stored on AWS so if AWS itself becomes compromised, credentials to login at Okta cannot be accessed.
Now, that was AWS IAM.
Last time I tried to completely federate Azure to Okta, it was not possible. Azure forces you to “sync” rather than completely federate passwords and identities. That process would not be possible on Azure. I know some additional steps are taken to protect passwords but the inability to complete federate to Okta was a bit frustrating.
I thought I had found a work around. I was trying to use a new service in preview while preparing for a class to see if I could get it working with a Azure AD B2B (business to business) instance but it took me over a month to convince Azure there was a bug in that service. Then I gave up. Maybe I’ll revisit that since some new features came out.
Why would Azure not support federation to Okta to authenticate identities? They might tell you it’s too great of a risk. But who have you all been using for years to authenticate users that access every other system in your environment? It seems obvious to me why they would not support that option. Everyone else has to federate to Microsoft AD or Azure AD because that’s what everyone uses but Microsoft doesn’t support federation to anyone else (at least last time I tried.)
By the way, is Azure AD B2B going to become Entra ID B2B? I presume so. B2B is a way to connect to external business partner identity stores. There’s also an option called Azure B2C which is used to create a directory for customers accessing applications which is separate from your corporate directory. I also mentioned that you can create separate tenants in Azure which are essentially separate directories and Azure just came out with a new Enterprise multi-tenant related offering.
I am also not sure if you can completely federate using AWS SSO. It seems like AWS SSO attempts to force the use of SCIM, which has both some benefits and risks as I wrote about in this post. Are you federating, or are you syncing identities and passwords? There’s a difference.
I would prefer to maintain a bit more control in interactions with cloud providers and third parties than you might allow for internal syncing of identities on private networks. Be careful with the keys to your kingdom.
Also read my posts on OKTA to understand the different types of integration and how it affects where your passwords are stored.
- One method involves a private OKTA directory and you federate requests to authenticate users to OKTA.
- You can federate to some other IdP.
- Or you can use a mechanism to share or sync the username and password between two systems.
Spreading the password around seems like an exponential the risk factor, but unfortunately that’s the only way to connect certain systems (like logging into Azure from Okta— and not the other way around, to be clear — which is possible).
You might add a requirement to your cloud assessments to ensure that the cloud provider someone wants to use supports federation to your organization’s primary directory, without syncing or copying identities and credentials to the third party cloud provider.
MFA when switching identities
The other thing you’ll want to understand is at what point you can enforce MFA. If you are using an SSO system and a user wants to switch to a different identity or role, can you enforce MFA at that point? (Preferably hardware MFA for websites or a code from an authentication application for non-browser logins.)
Lack of ability to enforce MFA when switching roles is currently a weakness of AWS SSO. I’m hoping they fix that. There’s no way to force a user to enter a second factor to switch to a different role like I do using AWS IAM on the command line. That seemed to be possible with Okta but I need to do a bit more testing to verify that option works as advertised.
Make sure you can see who the original identity is when someone has assumed a role to perform some tasks. If you see actions by that role in the logs, you need to be able to tie back that role to the specific identity that assumed that specific role instance in a way that supports non-repudiation. This is something I have to explore further with Okta integration.
Different types of identities
I’m going to go into all the variations of identities in cloud environments, but there are two big distinctions.
- Identities or roles exist that humans use to take actions in your cloud environment.
- Other types of identities or roles exist that allow machines, applications, or cloud services to take action in your cloud environment.
Does your identity management system handle all those types of identities? Do you understand all the different types of identities that can be created and exist in the cloud environments in which you operate?
Part of the reason for the SolarWinds malware allowed attackers to breach government systems is that access to credentials on the hosts running SolarWinds provided the ability to create application permissions in Azure environments. Once attackers had those credentials set up they could use their new credentials to carry out their objectives via applications deployed to the environment. I wonder how many Azure AD administrators even knew that was possible.
You can read more about that in part 2 of my series on the SolarWinds breach.
No matter what mechanism you use to manage identities, understand all the different types of identities that can be created to access your cloud systems and where they exist.Logging and alerting for IAM
Authorization and policies
Once an identity has authenticated to a cloud environment, the policies or other mechanisms used by a particular cloud provider will allow or disallow actions that the identity wants to perform. There are many different types of policies in AWS, Azure, and GCP and you’ll want to understand all of them.
- Organizational policies applied at the organizational level. We reviewed some of those in the last few posts.
- IAM Policies applied to identities that specify what that identity is allowed to do. You can often use a built in cloud provider role with a set amount of access or build your own custom role with very granular permissions and apply it to a user, group, or role.
- Resource policies that specify which Identities can access those resources. When you look in the left menu for any Azure resource (like an Azure storage account), there are typically links to apply networking and IAM controls to that resource. Other cloud providers allow you to apply resource policies in different ways.
- Role Assumption Policies that allow an identity to assume a different role or level of access. On AWS those are called trust policies.
There will be other types of policies as well, depending on the cloud provider. Most of them can be managed programmatically but you’ll want to test that out. The same process I went through to show you how to manage organizational policies can be used to evaluate your options for other types of policy deployment and management for a particular cloud provider.
What about Software as a Service (SAAS) cloud providers? They may only allow you to use specifically defined roles with set permissions in a particular SAAS application. Think about GitHub. You used to have to give someone access to a repository or not. You couldn’t get very granular with the permissions. That has changed. Now you can give someone access to read only, or to write and check in code but not administer the repository, for example. Every SAAS cloud provider is going to have different options and mechanisms for granting access to what they can do on that SAAS platform.
You may want to define the granularity of control you need when granting permissions within a cloud application and add that to your security assessment. Can you create custom roles? Can you separate read, write, and administrative access? Does the cloud provider offer a way to programmatically create permissions and monitor for drift, as I wrote about in the last post?
Consider how you might develop a standard pipeline for deployment of permissions within your organization. Would the new vendor work within the context of the IAM deployment pipeline? Well, conceivably you could do this for AWS, Azure, and GCP. You could use a tool like Terraform potentially, but then you are granting a lot of permission to that tool. Consider the risk and you will probably want to require MFA when making changes to authorization within your organization at the point the changes are made. You may even want to require two people for certain actions.
Monitoring IAM in a multi-cloud environment
Monitoring the creation of new identities — especially highly privileged identities — is one of the keys to your cloud security. Additionally, understanding when high-privileged identities or roles take actions may be another factor. What sort of logs does the cloud provider offer that someone is asking you to use? Can those logs feed into your SIEM or the process by which you monitor for risky behavior?
Ideally you can do that and view at a glance all the permissions a user has across the organization. I know some vendors do that because I used to have a boss that would send me the report from one of those systems when it was his time to review and validate that my access was correct. Instead of validating it himself he sent it to me and told me to tell him if anything was wrong with it. I’m not sure if that was the intent of the process but it was an interesting approach to potentially shift the liability. I’m not sure it would work.
There are a number of vendors that want to help you consolidate logs for different types of cloud accounts. I will mention Sumo Logic simply because I know a really great guy over there who also happens to be a fellow IANS faculty member. These products aim to let you connect all your different cloud environment, application, and systems logs into their logging platform for better visibility and response to security incidents.
Of course there are others. I am cannot tell you which one is best without doing a proper assessment. You should do that for yourself or hire someone to do an assessment if you are considering buying a product. You may also pose a poll to the faculty at IANS Research if you are a client.
Be mindful of the access required to use a tool that advertises the ability to monitor IAM actions and changes in your cloud environment. I just saw a tool that claims to monitor your IAM Policies in AWS by checking logs into GitHub and monitoring versions. I took a quick glance at the instructions and it required two things:
- Admin access to your Github account.
- Admin access to your AWS account.
Sorry but I will not be using that tool in its current iteration in this lifetime. But, I suggested that perhaps the owner of that tool could re-architect it using the strategies I’ve been using throughout my automation series above and could probably fix that. I’m pretty sure the tool could achieve the same results with far less access and separation of concerns for different components. It’s actually a pretty cool concept and I hope they can fix it.
This was a very high level overview with a few ideas for making Identity and Access Management easier and some caveats. How do you make management of IAM easier in your cloud environment? Do you have questions? Information to share? Come join me at the IANS Research Event in Atlanta in October. Sorry, vendors are not allowed in my session but you can contact IANS about sponsoring or hosting your own session at this or an alternate event.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
