Entitlement data discovery

Here's a revised and improved version of your documentation content, focusing on clarity, conciseness, and a user-friendly structure for a customer-facing page.

---

Understanding Access & Entitlements: Entities and Entity Relations

This section guides you through how BalkanID helps you discover and manage accesses and entitlements across all your integrated applications. Our system organizes the vast amount of data extracted from your applications into foundational building blocks called Entities.

What are Entities?

In BalkanID, Entities are fundamental representations of identities, resources, connections, and insights within your system. They are designed to be flexible and can be extended to cover new data types (like logs) in the future.

We categorize the data extracted from your application integrations into the following core entity types:

• Identity:

  • Represents a user or service account in your system.

  • Extracted directly from your application integrations.

  • Examples include individual users (e.g., "Alice Smith"), customer profiles, or different types of service accounts, each with unique access rights.

• Resource:

  • Represents the assets or services that users can access.

  • Extracted directly from your application integrations.

  • Can be anything from documents, databases, or reports to specific features within your applications.

  • Examples: a premium feature, a cloud storage bucket, an API service, or a specific repository.

• Connection:

  • Represents the access provider that grants an Identity access to a Resource.

  • Derived from entities granted through your application integrations.

  • Often represents roles, groups, or memberships.

  • Example: If a user gains access to admin resources because they are part of an "Admin" role, then the "Admin" role serves as the Connection.

• Insight:

  • Provides valuable, actionable information about how resources are being accessed.

  • Generated by BalkanID's analysis of your data (unlike Identities, Resources, and Connections, which are directly extracted).

  • Insights are derived from the relationships and data captured by other entities, helping you understand access patterns and potential risks.

Understanding Entity Relations

Entity relations describe how two entities are connected and interact with each other. They provide the context for how identities gain access to resources within your environment.

To illustrate, let's consider a GitHub integration example:

Scenario:

A user, "alicegh" (Identity) within a GitHub integration, belongs to the "Engineering" group (Connection). Because of her membership in "Engineering", Alice has access to two repositories: "customer-application" (Resource) and "admin-application" (Resource).

Entities Involved:

• alicegh (Identity)

• Engineering (Connection)

• customer-application (Resource)

• admin-application (Resource)

Entity Relations:

1. alicegh → Engineering

   • Meaning: Alice is a member of the Engineering group. This is a direct relationship.

2. Engineering → customer-application

   • Meaning: The Engineering group has access to the customer-application repository.

3. Engineering → admin-application

   • Meaning: The Engineering group has access to the admin-application repository.

4. alicegh → customer-application (Connection Provider: Engineering)

   • Meaning: Alice has access to customer-application because she is part of the Engineering group.

5. alicegh → admin-application (Connection Provider: Engineering)

   • Meaning: Alice has access to admin-application because she is part of the Engineering group.

Key Metadata for Entity Relations

Entity relations also carry important metadata that provides deeper context:

• Connection Provider:

  • What it is: This optional field identifies the entity that causes two other entities to be related. It's the "reason" or "path" through which access is granted.

  • Example from above: In the relations alicegh → customer-application and alicegh → admin-application, Engineering is the Connection Provider. This signifies that Alice gains access to these repositories only by virtue of being in the Engineering group. If she wasn't part of Engineering, she wouldn't have this access.

  • When it's absent: Direct relationships (like alicegh → Engineering) typically do not have a Connection Provider.

• Project:

  • What it is: This field is used to denote the specific account number, domain, or tenant to which entities belong, especially when a single integration manages multiple accounts.

  • Purpose: It clarifies the organizational context within an integration. For example, if a single AWS integration connects to two different AWS accounts, the Project field specifies which account the entities and their relations belong to.

• Privileges:

  • What it is: This field describes the specific permissions or level of access that a parent entity has on a resource it can access.

  • Example from above: For alicegh → customer-application, Alice might have "Read/Write" privileges. However, for alicegh → admin-application (still through the Engineering group), she might only have "Read" privilege. This field details those specific permissions.

By understanding these entities and their relations, you gain a powerful, granular view of all access within your BalkanID tenant, enabling more effective security and compliance management.

The Entity Discovery section provides essential guidance for configuring entity management. It includes discovering entities across various application integrations to ensure comprehensive visibility and control. Additionally, it covers how to work with filters to refine data and perform impact analysis to assess the effects of changes on access and security.

1. Applications Integration Discovery

2. Identities Discovery

3. Connection Discovery

4. Resource Discovery

5. Working filters

6. Creating filters