NHI Ownership Attribution

SailPoint Entro matches the ownership of every NHI by tailoring the process to each integration. Since owner can mean different things depending on the platform, we adapt our attribution logic to the type of NHI and the data we can collect from that integration. This integration-specific approach ensures ownership is accurate, actionable, and aligned with how each system defines responsibility.

There are 3 levels of ownership for each NHI. For each integration it is a bit different and dependent on the data we receive from the integration. Usually it is the direct ownership of the NHI, then the higher hierarchy levels of admin that have access to handle a risk related to that NHI, meaning revoke/rotate the token.

The next level of ownership is matching the owner to an employee (human identity). The 'Employee' column will pick the best candidate to match the owner we detected with an employee from the Employees inventory, where the human identities from the customer IDP are stored.

AWS Non-Human-Identities

Direct Ownership:

1. Human user who used the NHI Token via Audit log

2. Creator of NHI Token via Audit log

3. Modifier of the NHI

4. Name of NHI Token (Description / Token name) matched to employee name

   Higher Level Ownership Hierarchy:

   • We default to account owners with permissions over the NHI

GCP Service Account

Direct Ownership:

1. Human user who used the NHI Token via Audit log

2. Creator of NHI Token via Audit log

3. Creator of NHI Service account via Audit log

4. Modifier of the NHI

5. Owner of the Workload/CICD using the NHI

6. Name of NHI Token (Description / Token name) matched to employee name

   2^nd-Level Ownership Hierarchy:

   • SA.Key.Creator permission, binding (users and groups) from IAM policy of specific permissions on the project that the SA belongs to

   3^rd-Level Ownership Hierarchy:

   • SA.Key.Creator, binding (users and groups) from IAM policy of specific permissions on Folder and Organization that the SA and Project belongs to

Azure App Registrations

Direct Ownership:

1. Human user who used the NHI Token via Audit log

2. Creator of NHI Token via Audit log

3. Creator of NHI Service account (Azure app ownership)

4. Modifier of the NHI

5. Owner of the Workload/CICD using the NHI

6. Name of NHI Token (Description / Token name) matched to employee name

   2^nd-Level Ownership Hierarchy:

   • Azure Application owners

   3^rd-Level Ownership Hierarchy:

   • Cloud Application administrators

Okta Applications

Direct Ownership:

• Client secret creator

2^nd-Level Ownership Hierarchy:

• Application creator/owner

3^rd-Level Ownership Hierarchy:

• Super administrators

GitHub Personal Access Token

Direct Ownership:

• IAM username, email, or full name matched to employee name

2^nd-Level Ownership Hierarchy:

• Organization administrators

GitHub Fine-Grained Token

Direct Ownership:

• Token creator

Higher Level Ownership Hierarchy:

• Missing higher level ownership matching.

Google API Key

Direct Ownership:

• API Key creator

Higher Level Ownership Hierarchy:

• Missing higher level ownership matching.