We tend to think of public clouds as repositories of resources where people – usually employees or customers – can access information or perform transactions. This picture is far from complete.

In fact, the resources in clouds are accessed ten times more frequently by workload identitiesthan they are by human users, (also known as Service Principals, service accounts, or machine identities) such as virtual machines, apps, and service accounts. Like humans, these identities have permissions that are all too often over-privileged and represent one of the largest attack surfaces and enablers of lateral movement in the cloud.

The Source of Over-Privileged Accounts

These over-privileged service accounts are often created during development because developers don’t always know in advance what privileges will be required for the application to function. Granting full access is an easy way to prevent unforeseen snags that will slow the process of getting a new functionality working, tested, and into production.

Even security professionals with significant cloud experience are prone to over-provision permissions in their cloud environment, because they lack awareness of the applications function or the tools to determinean appropriate least privileged policy. Provisioning an over permissive environment is the path of least resistance, and application developers are focused on functionality, not security.

Also, in DevOps organizations, often no one has final responsibility for overseeing the security of service identities. This should be the responsibility of DevSecOps, but not many organizations have these roles in place.

There’s another reason why over-privileged non-human users are so common. These “lost children” are not easy to find manually, and organizations lack the tools to bring them to light. There is no dearth of IAM solutions, and organizations tend to think that if they have IAM tools and processes in place they are covered. In fact, these solutions fall short on security in important ways.

The Shortcomings of IAM

To begin with, IAM professionals often focus on policies, strategies and tools for human identities, e.g. user provisioning and roles, while workload identities are allowed to proliferate without any real oversight. Meanwhile, enterprise IAM tools generallydon’tprovide visibility into third party accounts such as contractors, or third-party workload identities, which may have access privileges to development or sandbox projects that allow them to move laterally and gain entitlements into production environments. They also don’t cover workload identities such as applications, virtual machines, workloads and service accounts.

Another fundamental barrier preventing organizations from properly securing service identities: the dev culture itself. Dev teams are focused on functionality. Their success is measured by the speed and efficiency with which they take projects from concept to production. They typically have a circular methodology that begins with planning, moves on to design, development, testing and deployment, and then goes back to planning. All too often, security has no place in this cycle.

To sum up, most organizations don’t have the tools, best practices or formal designation of responsibility for non-human accounts that are necessary for properly securing cloud deployments (and often on-premise deployments as well). They lack visibility into these accounts, and the result is a class of threats most organizations aren’t even aware of.

Best Practices

To ensure that security extends across non-human as well as human users, the following best practices should be in place.

• Review each machine identity and its entitlements, as well as its actual usage of those entitlements
• Based on this review, identify unwarranted (risky) or unused permissions, and create new least privilege policies
• Build entitlement reviews and assessments into the development lifecycle
• Periodically review machine identity permissions to prune excessive permissions

Manually reviewing code to determine which privileges are genuinely required by service accounts and other non-human workload identities is a time-consuming process. It makes sense to use automation to accomplish this task. Ultimately, organizations moving workloads to the cloud need to extend the same level of control over privileges and access rights assigned to machine identities as they do to human identities.