The more points of access you have with your customer database and the more ways you leverage the data, the more potential you have for unintended exposure. This advancing of customers’ personal data throughout your systems and beyond is known as PII sprawl. 

Containing the sprawl

Identity Cloud provides a database and tooling that are architected to securely store and manage your customers’ identities. However, it is up to you to leverage the right tools for your use cases. That’s why we provide a broad spectrum of built-in data security features to cover each potential point of vulnerability.

The Identity Cloud Console

The Identity Cloud Console is a gated web application that provides administrative access to necessary credentials, configurations, and data stores for your CIAM solution.

The Identity Cloud Console includes an interface for viewing and managing your customer profile data directly, as well as viewing and managing client credentials that can connect to the database via the API. As such, it is important to tightly control access to the Console and grant appropriate permissions. 

Console access

Access to the Identity Cloud Console is granted on a per-environment basis. Environments are divided among regions. For example, if you have an Identity Cloud development environment in the EU region, access to this is completely separate from access to the production environment in the same region, which is completely separate from access to the production environment in the US region.

This is the base level of Console access control — granting access to an environment in the Console means that data in any other environment is not at risk for exposure to that user.

Console roles and permissions

When a user is granted access to an environment in the Console, they are assigned one or more roles.

There are 15 different roles in the Console. The Application Admin roll has the highest permissions and can view and edit all data and configurations in the Console. The other 14 roles have some subset of permissions, and the particular permissions for each role depend on the purpose of the role. Roles typically have a general purpose, such as working with user profiles or configuring properties, and then a particular level of access within that purpose, such as view-only or edit access.

As a general rule, we recommend being thoughtful and security-minded when granting access to the Console. Permissions should be granted using the principle of least privilege, meaning: grant the lowest level of permissions necessary for each user to perform their duties.

Scoping data access in the Console

Some roles in the Console have access to view or edit customer profiles. For these roles, it is possible to further scope access to a subset of profiles and a subset of data within the profile.

First, access to customer profiles is granted on a per–data store basis. This applies if you have more than one profile data store within an environment. For example, a pharmaceutical company might separate their customer profiles into two data stores — one for health care providers and another for patients. Depending on a user’s realm of work, they can be granted access to only one or the other set of profiles, or to both.

Second, within a profile data store, access can be scoped to only profiles that match a configured data filter. For example, within the health care provider data store, a user can be granted access only to profiles whose country of practice is France.

Third, for the customer profiles that a user has access to, the data that is visible can be limited to a subset of the full data profile. For example, your customer care agents can be restricted to only see the customer name, contact information, and verification status, even if quite a bit more data is stored in the profile.

System integrations

When you’re utilizing a CIAM solution like Identity Cloud, you’ll likely need to sync the customer profile data with other systems you use. For example, if you use an email marketing platform to communicate with your customers, you may need that platform to retrieve data from the CIAM profile, such as name, email address, and communication consent.

One way (but not the best way) to do this would be to provision a client in Identity Cloud that has full access to all customer profiles and use those client credentials to pull the data into the marketing platform. However, you now have a set of keys exposed within your system architecture that has unfettered access to all your customer data. 

A better way to go about this is to provision a client in Identity Cloud that has limited access to customer profiles and is scoped to only the specific pieces of data necessary for the marketing platform to effectively perform its duties. This can be done in Identity Cloud using our broad spectrum of client features and scoped access schemas. You can also block the outside use of these client credentials with an IP allowlist.

Client features

When a client is created in Identity Cloud, it is assigned one or more features. Client features define a base-level of access and functions for the client. For data integrations, one of the following features is typically used:

• direct_access — Has read and write access to all customer profiles

• direct_read_access — Has read-only access to all customer profiles

We strongly recommend that you assign the direct_read_access feature when a data integration simply needs to retrieve profile data. Only when a data integration requires the ability to directly edit customer profile data in the Identity Cloud database should the direct_access feature be assigned.

Access schemas

The profile data a client has access to can be scoped down to a specific subset of data attributes. We call this scoped set of attributes an “access schema.” If applicable, a client can have read access to one set of attributes and write access to a different set of attributes.

For the example of an email marketing platform discussed above, you could scope data access by applying a read access schema to the client with the following subset of attributes allowed: ["givenName", "familyName", "email", "/consents.communication"]

Access schemas also allow you to set read and write permissions per profile data store. So, for example, if the email marketing platform should only communicate with health care providers, you could block access to the patient profile data store by applying a read access schema to the client for the patients data store with no attributes allowed: []

As you can see, the level of access granted for a client in Identity Cloud can be scoped down to an exacting degree. This is a great asset that proactively minimizes damage in the unfortunate event that a client key falls into the wrong hands.

IP allowlist

Each client in Identity Cloud can have an “IP allowlist” that specifies the IP addresses of the devices allowed to make API calls with that client. By default, a client can be used from any IP address. This is preferable for clients used in your customer-facing applications.

If you’d like to prevent outside users from abusing an internal client, you can add one or more IP addresses to the allowlist that match your internal system locations.

Customer applications

In order for your customers to register, login, and manage their profile, your public-facing websites and applications must have access to your customer database. For this particularly sensitive operation, a special limited-purpose client should always be used, and you can scope the data returned to your application.

Client features

When a client is created in identity Cloud to be used in your public-facing applications, a single feature is typically applied to it:

• login_client — Has read and write access to a customer profile only if the correct authentication is provided (for example, the email address and password combination that match the profile) 

If a client with this feature winds up in the wrong hands, there’s no risk of data exposure unless the malicious user knows the login credentials of your customers.

Data scoping

When a login client is used to authenticate a customer, their profile data is returned to the customer application. But public applications typically do not need access to the entire profile in order to provide services to the customer. As such, it’s recommended to scope the profile data returned only to the necessary attributes.

In Identity Cloud, the way scopes are defined is different depending on whether you’re integrating APIs directly into your application or integrating the Hosted Login UI. In either case, the end result can be the same.

Summary

Identity Cloud provides a multitude of essential tools to prevent your customer data from unnecessary sprawl. In general, we recommend that you follow best practices when it comes to user data access:

• Only grant access to people or systems if absolutely necessary for their function
  

• When generating access credentials, make sure the base-level permission is appropriate for the purpose of access, and scope to the minimal set of data required
  

• Never let two different systems share the same access credentials. Generating a unique set of credentials for each system or point of access allows you to:

  • Distinguish and audit access events per system

  • Scope access individually to align with each system
    

• Always use the principle of least privilege, whether you’re granting access to a person, an internal system, or a public application

Treating your customer identities with care is a no-brainer in the modern age of malicious actors and is an asset for your business. Now, with Identity Cloud Console’s features and fine-tuned permissions control, it’s easier than ever to do the right thing.