The shift to the remote work model has accelerated the push to the cloud for critical applications and workloads — for startups and enterprises alike. Many of these newer services are focused on improving productivity and collaboration.
But once implemented, IT and DevOps teams are forced to grapple with the problem of managing access for this ever-expanding horizon of applications and workloads. While it was previously possible to restrict access based on IP addresses, ports, and similar network-centric strategies, with applications and workloads running in the cloud, these network-based controls have become ineffective.
That’s where identity and access management solutions come in.
What Makes a Good Identity and Access Management Solution?
A good identity and access management (IAM) solution helps a company implement the principles of zero-trust security across all its applications, infrastructure, workloads, and data resources. In practice, this means all requests for access are authenticated and authorized based on the identity of the user, device, or service.
Essential properties of a good IAM solution also include the ability to guarantee non-repudiation of identity through SAML (security assertion markup language) tokens, enforce multi-factor authentication checks, and support granular policies to authorize API and data access.
Picking the Right IAM Tool
There are a number of popular IAM providers to pick from — Okta, Google Workspace (formerly G Suite), Auth0, OneLogin, and ForgeRock, to name a few. Given the heterogeneity of resources and the myriad ways they are accessed across an organization, no one solution will likely serve all your needs. Organizations typically end up using multiple tools to govern access to their critical resources.
First, let’s look at the two different kinds of IAM providers available:
- Identity Providers: These authenticate a user and provide identity and access tokens for accessing other services. They typically support SAML and OpenID Connect (OIDC) protocols for clients to interact with and are often backed by a directory service storing user information such as OpenLDAP and Active Directory. Examples are AWS IAM, Okta, Google Workspace, and Active Directory Federation Services (ADFS).
- Federation Services: These have the added ability to delegate authentication and authorization decisions to one or more identity providers, thus acting as a unified abstraction layer between the clients and multiple identity providers. Examples include Auth0 and Keycloak services.
The choice of an IAM provider will typically be driven by the kind of resource being governed. Here are four examples of resources to govern and IAM recommendations for each.
Third-Party SaaS Applications
These resources include online documents (Office, Box, DocuSign) as well as customer relationship management (CRM) platforms like Salesforce, internal wikis like Confluence, issue and product tracking software like JIRA and Trello, and business intelligence (BI) platforms like Looker and Tableau.
Recommendations
- Streamline sign-up and sign-in steps in third-party services by connecting them with your existing IAM provider, so user provisioning and de-provisioning can be managed centrally within that provider. While third-party services may allow user creation and deletion, as well as enable signing in using separate credentials, it leads to bad security hygiene. This is because it becomes extremely hard to keep track of taking permissions away as users leave the organization or change roles, and results in excessive permissions, which can be exploited by hackers.
- For companies using Google Workspace to collaborate on documents, spreadsheets, and presentations with colleagues, one can simply use Google Workspace accounts as the central identity and leverage its in-built IAM capabilities to grant and govern access to all such corporate data.
- For organizations using a mix of collaboration services (like Box or Dropbox), consider using cloud access security broker (CASB) services like Netskope to centralize access control policies for documents everywhere.
Homegrown Applications
Homegrown applications include web portals, data service APIs, and CMS software that provide internal employees (and partners, in some cases) access to sensitive customer or partner data for support and business-related reasons.
Recommendations
- Consider using an IAM federation service such as Auth0, OneLogin, or Keycloak. These services have the ability to delegate the actual authentication and authorization to your IAM provider. By abstracting away the IAM provider interaction details, they allow you to build your internal applications without being tied up to a specific provider.
- Leverage these services to delegate authentication to multiple IAM providers simultaneously. This will be useful for supporting multi-tenant scenarios where each tenant (a customer or a partner) must be authenticated using a different IAM provider.
Infrastructure Servers
These include cloud-hosted virtual servers running Linux or Windows-based operating systems and that are accessed using Secure Shell (SSH) and Remote Desk Protocol (RDP).
Currently, there aren’t too many good ways to integrate SSH and RDP services with an IAM provider. Using public and private keys or client certificates is the way to go for infrastructure access.
Recommendations
- For companies already using Okta, consider using their ASA (advanced server access) offering for centrally managing access to servers based on identity information kept within Okta.
- For teams steeped in the HashiCorp ecosystem, there is a new tool called Boundary that aims to integrate seamlessly with their other services like Vault and Sentinel, making the process of access grants, recertifications, and secrets management seamless.
Operational and BI Data
This includes structured and semi-structured data in databases, data warehouses, persistent message pipelines, and S3 (simple storage service) buckets.
This is a particularly difficult problem because many of the popular data repositories — like Amazon S3, MongoDB, PostgreSQL, Redshift, and Kafka — don’t directly support identity management protocols like SAML and OIDC.
Recommendations
- Use your cloud provider’s IAM if any of the data stores are supported. For example, on AWS, the RDS, Redshift, Aurora, and S3 endpoints allow IAM-based authentication using AWS’s Security Token Service (STS). This will allow you to get rid of passwords from your environment and enforce good security hygiene for your users.
The Importance of IAM Automation
While picking a good IAM solution is important, it is equally important for developer teams to automate access management when running application workloads in the cloud. With the adoption of popular infrastructure-as-code frameworks, it’s increasingly trivial to spin up new services, such as virtual machines, databases, and storage endpoints on the cloud. It’s very easy for a developer to create an RDS endpoint or an S3 bucket and inadvertently leave them openly accessible to the public, and, therefore, hackers.
The situation is exacerbated by bad hygiene around credentials management — not rotating keys periodically, not using secrets managers, sharing privileged account credentials among teams.
As these services proliferate, the risk of compromises also increases. This is especially true for modern cloud and DevOps teams that are hyper-focused on agility, to the extent that security practices require any manual intervention, they are often actively neglected. This can cause conflict between security and these DevOps teams, leading to operational challenges and burnout.
A typical example of this arises when on-call engineers need to log into production databases for troubleshooting purposes. These databases may contain private information of consumers and may have been recently spun up as part of a new application. Security teams would want to mandate that such systems may be accessed only by a small, designated group of engineers and require explicit approvals based on policy checks.
An incident may, however, occur at any time (like 2 a.m.) and multiple people may be needed to troubleshoot it. Relying on manual policy checks and approvals can cause delays and frustration for the engineers who are responsible for maintaining these services. Teams need to make sure they have automated policy checks in place that can grant approvals for a limited time to folks on an as-needed basis and enforce constraints on what an engineer may be allowed to do when inside the database.
As such, having such a scalable and automated identity-based access management strategy becomes critical from both a security and operational perspective.
