In today’s rapidly evolving SaaS environment, the focus is on human users. This is one of the most compromised areas in SaaS security management and requires strict governance of user roles and permissions, monitoring of privileged users, their level of activity (dormant, active, hyperactive), their type (internal/ external), whether they are joiners, movers, or leavers, and more.
Not surprisingly, security efforts have mainly been human-centric. Configuration options include tools like MFA and SSO for human authentication. Role-based access control (RBAC) limits the level of access; password complexity guidelines block unauthorized humans from accessing the application.
Yet, in the world of SaaS, there is no shortage of access granted to non-human actors, or in other words, 3rd party connected apps.
Service accounts, OAuth authorizations, and API keys are just a few of the non-human identities that require SaaS access. When viewed through the lens of the application, non-human accounts are similar to human accounts. They must be authenticated, granted a set of permissions, and monitored. However, because they are non-human, considerably less thought is given to ensuring security.
Non-human Access Examples
Integrations are probably the easiest way to understand non-human access to a SaaS app. Calendly is an app that eliminates the back-and-forth emails of appointment-making by displaying a user’s availability. It integrates with a user’s calendar, reads the calendar to determine availability, and automatically adds appointments. When integrating with Google Workspace through an OAuth authorization, it requests scopes that enable it to see, edit, share, and delete Google Calendars, among other scopes. The integration is initiated by a human, but Calendly is non-human.
 |
| Figure 1: Calendly’s required permission scopes |
Other non-human accounts involve data sharing between two or more applications. SwiftPOS is a point-of-sale (POS) application and device for bars, restaurants, and retail outlets. Data captured by the POS is transferred to a business intelligence platform, like Microsoft Power BI, where it is processed and analyzed. The data is transferred from SwiftPOS to Power BI through a non-human account.
The Challenge of Securing Non-human Accounts
Managing and securing non-human accounts is not as simple as it sounds. For starters, every app has its own approach to managing these types of user accounts. Some applications, for example, disconnect an OAuth integration when the user who authorized it is deprovisioned from the app, while others maintain the connection.
SaaS applications also take different approaches to managing these accounts. Some include non-human accounts in their user inventory, while others store and display the data in a different section of the application, making them easy to overlook.
Human accounts can be authenticated via MFA or SSO. Non-human accounts, in contrast, are authenticated one time and forgotten about unless there is an issue with the integration. Humans also have typical behavior patterns, such as logging on to applications during working hours. Non-human accounts often access apps during off-peak time to reduce network traffic and pressure. When a human logs into their SaaS at 3 AM, it may trigger an investigation; when a non-human hits the network at 3 AM, it’s merely business as usual.
In an effort to simplify non-human account management, many organizations use the same API key for all integrations. To facilitate this, they grant broad permission sets to the API key to cover all the potential needs of the organization. Other times, a developer will use their own high-permission API key to grant access to the non-human account, enabling it to access anything within the application. These API keys function as all-access passes used by multiple integrations, making them incredibly difficult to control.
 |
| Figure 2: A Malicious OAuth Application detected through Adaptive Shield’s SSPM |
Sign up for THN’s upcoming Webinar: Reality Check: Identity Security for Human and Non-Human Identities
The Risk Non-human Accounts Add to SaaS Stack
Non-human accounts are largely unmonitored and have wide-ranging permission scopes. This makes them an attractive target for threat actors. By compromising any of these accounts, threat actors can enter the application undetected, leading to breaches, unauthorized modifications, or disruptions in service.
Taking Steps to Secure Non-human Accounts
Using a SaaS Security Posture Management (SSPM) platform in concert with Identity Threat Detection & Response (ITDR) solutions, organizations can effectively manage their non-human accounts and detect when they behave anomalously.
Non-human accounts require the same visibility by security teams as human accounts and should be managed in the same user inventory as their human counterparts. By unifying identity management, it is far easier to view access and permissions and update accounts regardless of who the owner is. It also ensures a unified approach to account management. Organizational policies, such as prohibiting account sharing, should be applied across the board. Non-human accounts should be limited to specific IP addresses that are pre-approved on an allow list, and should not be granted access through the standard login screens (UI login). Furthermore, permissions should be tailored to meet their specific needs as apps, and not be wide-ranging or matching their human counterparts.
ITDR plays an important role as well. Non-human accounts may access SaaS apps at all hours of the night, but they are usually fairly consistent in their interactions. ITDR can detect anomalies in behavior, whether it’s changes in schedule, the type of data being added to the application, or the activities being performed by the non-human account.
The visibility provided by SSPM into accounts and ITDR into non-human identity behavior is essential in managing risks and identifying threats. This is an essential activity for maintaining secure SaaS applications.
Read more about protecting against non-human identities
