Help stop data leaks with the Forseti External Project Access Scanner

Editor’s note: This is the second post in a series about Forseti Security, an open-source security toolkit for Google Cloud Platform (GCP) environments . In our last post, ClearDATA told us about a serverless alternative to the usual way of deploying Forseti in a dedicated VM. In this post, we learn about Forseti’s new External Project Access Scanner.

With data breaches or leaks a common headline, cloud data security is a constant concern for organizations today. But securing cloud-based data is no easy feat. In particular, it can be hard to identify and secure the routes by which data can leave the organization—so called data exfiltration.

Consider the following scenario: a GCP user has permissions in projects across different organizations, the root note in a GCP resource hierarchy. As a member of Organization A, they have permissions in a project under Organization A’s GCP organization node. This user also has permissions in a project under Organization B’s GCP organization node.

However, nowhere in Organization A’s Cloud Identity and Access Management (IAM) console does it indicate that the user has permissions to a project in Organization B. There is also no evidence of this in Organization A’s G Suite admin console, so the user can move data between organizations virtually unnoticed.

This kind of exfiltration vector is difficult to detect. Fortunately, the Forseti Security toolkit includes an External Project Access Scanner that can help.

What does the Forseti scanner do?

In GCP, the best practice is to use service accounts to perform actions where a GCP user isn’t directly involved. For example, if an application in a VM needs to connect to Google Cloud Storage, the application uses a service account for that interaction. Following this best practice, Forseti also uses service accounts to make API calls when it scans for permissions.

Each project in GCP has an ancestry known as a Resource Hierarchy.  This ancestry will always start at an organization node (e.g. Organization A).  Under the organization there will be zero or more folders. A GCP project may either be a child of a folder or the organization itself.

The challenge here is that a service account only has permissions in the organization where Forseti is deployed. In other words, if Forseti is deployed in Organization A, it can’t see what projects a user has to in Organization B.

This is where the concept of “delegated credentials” becomes incredibly useful. Delegated credentials allow a service account to temporarily act as a user. After compiling a list of users in the organization, the service account impersonates each user with these delegated credentials. The scanner then obtains the list of projects to which each user has access, regardless of the organization node.

Having the list of projects, and still using each user’s delegated credentials, the scanner obtains the project ancestry of each project.

This scanner is configured via whitelist rules (details discussed later). When you first deploy Forseti, the only rule that exists is to permit users to have access to projects in the organization where Forseti is deployed. In other words, if Forseti is deployed in a project in Organization A, then users in Organization A have access to projects in Organization A and only Organization A.

A violation occurs when none of the ancestors of a project are whitelisted in the External Project Access Scanner Rules.

To sum up the operation of the External Access Project Scanner, it:

• Obtains a list of all the users in a GCP organization

• For each user

• Obtains delegated credentials from that user

• Obtains a list of projects to which the user has access

• Iterates over each project, obtaining the project’s ancestry

• Determines which ancestries are in violation of the whitelist rules

• Reports the violations

How to configure and run the External Project Access Scanner

The first step is to install and configure Forseti; you can find some great instructions on forsetisecurity.org.

Then, you need to configure your whitelist rules.  As mentioned previously, the External Project Access Scanner is configured by whitelist rules in the external_project_access_rules.yaml file. The first time you open this file, there’s only one entry that whitelists the organization in which you’ve deployed Forseti. For example:

A resource in GCP is identified by the resource type/resource number ID.  Each rule may list multiple type/ID pairs as long as they are organizations or folders types..

Once the desired rules are in place, you can run the scanner. At this point, it is important to note that the scanner does not run in a cron job, like the other Forseti scanners, but must be manually invoked. This is because, depending on the size of the organization, this scanner has the potential to execute for a long time. Remember that the scanner iterates over every user in an organization and calls the GCP API to obtain a list of all projects. Then, for each project, the scanner obtains the ancestry, again via the API. This can amount to a lot of API calls that take a long time to execute.

After selecting the Forseti model, here’s how to run it via the CLI.

When the scanner completes, it stores violations in at least two locations:

• Forseti’s CloudSQL database in the violations table
• A GCS bucket in the project where Forseti is deployed
• An e-mail notification if you configured the Forseti server to do so

The violation data itself is worth discussion. Violation data is in the form of a JSON string and resembles the following.

A violation entry is generated for each project (‘full_ name’) and per user (‘member’) where the project’s ancestry is in violation. The ‘rule_ancestors’ field lists all the ancestors that were listed in an External Project Access Scanner rule.

Future work

With the External Project Access Scanner you can now identify projects in organizations or folders that aren’t whitelisted by the scanner rules. As of Forseti v2.9.0, the whitelist rules apply to all users in an organization. This means that all users in an organization may have the ability to access projects in another organization if such a rule existed. Going forward, one improvement would be to enhance the rule definition to allow each rule to be applied to specific users or groups.

Additionally, the External Project Access Scanner returns a violation regardless of the permissions level a user has on a project in another organization. Whether the user has viewer, editor or project owner roles, the scanner reports a violation all the same. The rule could be further improved by allowing the specification of an allowed permission for each whitelisted organization or folder.

Conclusion

Migrating your workloads to the cloud brings increased flexibility, but also an expanded threat domain. Thankfully, tools like Forseti can greatly mitigate that risk, with a powerful suite of security analysis, notification, and enforcement tools for GCP. When trying to secure data in the cloud, the External Project Access Scanner affords insight into an often overlooked data exfiltration path.  To get started with Forseti and the External Project Access Scanner, visit forsetisecurity.org.