0 / 5 MODULES
Cloud Identity Discovery

Secure Every Identity
Across Every Cloud

An end-to-end product demo and hands-on lab module covering Delinea's Cloud Identity Discovery capability — from connecting cloud environments to remediating over-permissioned identities at scale.

5 Modules · Demo + Lab
~60 min estimated time
AWS · Azure · GCP
Intermediate level
🌐
Cloud Identity Discovery — Overview
What it is, why it matters, and how Delinea solves the problem

🎯 Learning Objectives

After completing this module you will be able to: (1) explain the cloud identity sprawl problem, (2) describe how Delinea scans multi-cloud environments, (3) differentiate human vs. non-human identities, and (4) articulate the least-privilege violation lifecycle.

🔍
Automatic Discovery
Delinea continuously scans connected AWS, Azure, and GCP tenants to enumerate every identity — no manual inventory required.
🗺
Effective Permission Mapping
Beyond listing policies, Delinea computes effective permissions by resolving role inheritance, policy boundaries, and group memberships.
⚠️
Least-Privilege Gap Analysis
Flags every entitlement that exceeds what the identity actually used in the past 90 days — surfacing the exact over-permission delta.
🤖
Human & Non-Human Identities
Covers users, service accounts, IAM roles, Lambda execution roles, managed identities, workload identities, and API keys.
🔗
Cross-Cloud Correlation
Links identities across providers to detect shadow access — e.g., an Azure AD service principal with unexplained AWS AssumeRole rights.
✅
Guided Remediation
Generates targeted right-sizing recommendations and access reviews directly within Delinea — one click to initiate a certify/revoke workflow.
🏗
The Identity Sprawl Problem
Why cloud environments create unprecedented identity risk

⚡ The Attack Surface

The average enterprise runs 3–5 cloud platforms with thousands of IAM roles, service accounts, and API keys — 80% of which have never been audited. Over-permissioned non-human identities are now the leading initial-access vector in cloud breaches.

📈 The Growth Rate

Non-human identities (service accounts, bots, pipelines) now outnumber human identities 45:1 in most cloud-native organizations — yet receive a fraction of the governance attention of user accounts.

IDENTITY TAXONOMY — WHAT DELINEA DISCOVERS
Human Identities HUMAN
IAM Users (AWS) · Entra ID Users (Azure) · Cloud Identity Users (GCP) USER
Federated / SSO identities mapped to cloud roles FED
Non-Human Identities NHI
Service Accounts · Managed Identities · Workload Identities SVC ACCT
Lambda Execution Roles · Cloud Run SA · Azure Function Identity FUNCTION
CI/CD Pipeline Identities (GitHub Actions, ADO, Jenkins) PIPELINE
IAM Roles & Groups ROLE
AWS IAM Roles · Azure RBAC Roles · GCP IAM Bindings ROLE
Policies & Permissions POLICY
Inline Policies · Managed Policies · Permission Boundaries POLICY
🧠
Knowledge Check · Module 1
QUESTION 1 OF 1 — OVERVIEW
Which statement best describes why non-human identities represent a disproportionate cloud security risk compared to human user accounts?
A Non-human identities are created by developers and are therefore less privileged than admin user accounts.
B They are assigned static long-lived credentials that rarely rotate and often carry broader permissions than needed, yet receive minimal governance review.
C Non-human identities vastly outnumber human accounts, hold persistent credentials, and are rarely revoked — creating a large, under-governed attack surface.
D Cloud providers do not support MFA for service accounts, making them inherently less secure.
🔌
Connecting Cloud Accounts
Onboard AWS, Azure, and GCP tenants into Delinea's discovery engine

📋 Prerequisites

Before connecting, ensure you have: (1) Delinea Platform admin or Connector Manager role, (2) Read-only IAM credentials in the target cloud account (minimum required permissions listed per provider below), (3) Network line-of-sight or API endpoint access from the Delinea connector host.

✅ AWS — Required IAM Permissions

Create a read-only IAM role in the target AWS account. Delinea uses cross-account role assumption (STS AssumeRole) — no long-lived access keys required.

// Delinea Discovery Policy — attach to the cross-account IAM role { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:List*", "iam:Get*", "sts:GetCallerIdentity", "organizations:Describe*", "access-analyzer:List*" ], "Resource": "*" } ] }
1

Navigate to Delinea → Connectors → Cloud Accounts → Add Account

Select Amazon Web Services from the provider dropdown. Choose your connection method: Cross-Account Role (recommended) or Access Keys (legacy).

2

Create the cross-account IAM role in AWS Console

In AWS IAM, create a new role with Another AWS Account as the trusted entity. Enter Delinea's AWS Account ID (provided in the UI) and require the ExternalId condition to prevent confused-deputy attacks.

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::DELINEA_ACCT_ID:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "YOUR_EXTERNAL_ID" } } }] }
3

Attach the discovery policy and paste the Role ARN into Delinea

Copy the Role ARN (arn:aws:iam::123456789:role/DelineaDiscovery) into the Delinea connector form. Click Validate Connection — Delinea will perform an sts:GetCallerIdentity check to confirm access.

4

Configure scan scope and save

Optionally restrict discovery to specific regions or tag-filtered resources. Set scan frequency (default: daily). Click Save & Enable.

✅ Azure — App Registration & RBAC

Delinea connects via an Entra ID App Registration with a client secret or certificate. Assign the Reader role at the Management Group or Subscription level.

1

Register an application in Microsoft Entra ID

In Azure Portal → Entra ID → App Registrations → New Registration. Name it Delinea-CloudDiscovery. Copy the Application (client) ID and Tenant ID into Delinea.

2

Create a client secret or upload a certificate

Under Certificates & Secrets, create a client secret with a 12-month or 24-month expiry. Copy the secret value immediately — it is not shown again. Certificate-based auth is preferred for production.

3

Assign Reader + Directory.Read API permissions

Assign the Reader RBAC role at the subscription scope. Additionally, grant the API permission Microsoft Graph → Directory.Read.All (application permission) and have a Global Admin grant admin consent.

✅ GCP — Service Account & Workload Identity

Delinea uses a GCP Service Account with key-based or Workload Identity Federation authentication. Assign it the Security Reviewer and Browser predefined roles.

1

Create a service account in GCP IAM

In GCP Console → IAM & Admin → Service Accounts → Create. Name it delinea-discovery@PROJECT_ID.iam.gserviceaccount.com.

2

Grant required roles at the Organization level

gcloud organizations add-iam-policy-binding ORG_ID \ --member="serviceAccount:delinea-discovery@PROJECT.iam.gserviceaccount.com" \ --role="roles/iam.securityReviewer" gcloud organizations add-iam-policy-binding ORG_ID \ --member="serviceAccount:delinea-discovery@PROJECT.iam.gserviceaccount.com" \ --role="roles/browser"
3

Download key JSON and paste into Delinea

Create and download a JSON key for the service account. In Delinea → Cloud Accounts → Add Account → Google Cloud Platform, paste the JSON key content. Click Validate.

🧠
Knowledge Check · Module 2
QUESTION 1 OF 1 — CLOUD ACCOUNT CONNECTION
When connecting an AWS account to Delinea using cross-account role assumption, what is the purpose of the ExternalId condition in the trust policy?
A It encrypts the data transmitted between Delinea and AWS during the discovery scan.
B It prevents the confused-deputy problem by ensuring only Delinea — not any other party using the same account ID — can assume the role.
C It restricts which AWS regions the discovery scan can access.
D It is a legacy field required for backwards compatibility with older IAM APIs.
🔬
Running the Discovery Scan
Initiate, monitor, and understand what the scanner collects
DISCOVERY ENGINE — LIVE VIEW
SCANNING
0
IDENTITIES FOUND
0
POLICIES ANALYZED
0
CLOUD PROVIDERS
0
RISKS FLAGGED
0
CRITICAL SEVERITY
0
UNUSED PERMISSIONS
⚙️
What the Scanner Does — Step by Step
1

Phase 1 — Identity Enumeration

Delinea calls cloud-provider APIs (iam:ListUsers, iam:ListRoles, Graph API, GCP IAM list) to build a complete inventory of every principal. For organizations with multiple accounts, it fans out across all connected sub-accounts in parallel.

2

Phase 2 — Policy & Permission Collection

For each identity, Delinea retrieves all attached policies (inline, managed, group-inherited, resource-based, SCPs). It then resolves the full policy document — including JSON — so it can evaluate actual Allow/Deny statements, not just policy names.

3

Phase 3 — Effective Permission Computation

Using a policy evaluation engine that mirrors the cloud provider's own logic, Delinea computes the effective permissions for each identity. This reveals what's possible — not just what's listed.

4

Phase 4 — Usage Data Correlation

Delinea ingests CloudTrail / Azure Monitor / GCP Audit Logs to determine which permissions were actually used in the last 30/60/90 days. The delta between granted and used permissions is the over-permission score.

5

Phase 5 — Risk Scoring & Finding Generation

Findings are generated for permissions that: (a) violate least privilege, (b) grant admin/wildcard access, (c) allow privilege escalation paths, (d) expose sensitive data stores, or (e) have never been used. Each finding is scored Critical / High / Medium / Low.

⏱ Scan Duration

Initial scans typically complete in 15–90 minutes depending on the number of accounts and identities. Subsequent incremental scans run in 5–15 minutes as Delinea only processes delta changes. Large organizations with 50+ AWS accounts should expect the first scan to take 2–4 hours.

🧠
Knowledge Check · Module 3
QUESTION 1 OF 1 — DISCOVERY SCAN
Delinea computes "effective permissions" rather than simply listing attached policies. What key problem does this solve?
A It reduces the number of API calls needed during the scan, improving performance.
B It allows Delinea to create new IAM policies on behalf of the administrator.
C An identity may have 10 policies attached, but deny rules, SCPs, and permission boundaries mean only a subset are actually usable — effective-permission computation reveals what the identity can actually do.
D It replaces the cloud provider's own IAM evaluation engine with a more permissive one.
📊
Interpreting Risk Findings
Reading the dashboard, understanding severity, and prioritizing action

📐 Severity Definitions

Critical — Admin/root-level wildcard access, privilege escalation paths, or data-exfiltration-capable permissions on production resources. Remediate within 24 hours.   High — Broad service-level write access or sensitive-data access granted to non-human identities. Remediate within 7 days.   Medium — Unused permissions granted for 90+ days.   Low — Minor policy hygiene issues.

SAMPLE FINDINGS — CLICK A ROW TO EXPAND
SEVERITY IDENTITY PROVIDER FINDING LAST USED
● CRITICAL
ci-deploy-prod
Service Account
 ⬡ AWS IAM wildcard admin (iam:*) on all resources — privilege escalation path to full org control Never
● HIGH
analytics-reader@corp.com
Human User
 ⬡ Azure Storage Blob Data Owner on all storage accounts — can write/delete production data 47 days ago
● HIGH
dataflow-worker@proj.iam.gserviceaccount.com
Service Account
 ⬡ GCP Project Editor role assigned — write access to all services in project 3 days ago
● MEDIUM
john.smith@company.com
Human User
 ⬡ AWS EC2 full access granted 134 days ago — zero EC2 API calls in last 90 days 134 days ago
● LOW
reporting-bot
Service Account
 ⬡ Azure Using password-based authentication instead of managed identity — credential rotation overdue Today

🔍 Privilege Escalation Paths

A key differentiator of Delinea's analysis is the privilege escalation path detector. Even if an identity doesn't have admin permissions directly, combinations like iam:CreateRole + iam:AttachRolePolicy + sts:AssumeRole create a multi-step path to full admin — Delinea detects and surfaces these chains automatically.

🧠
Knowledge Check · Module 4
QUESTION 1 OF 1 — FINDINGS INTERPRETATION
A CI/CD pipeline service account has zero iam:* usage in the last 90 days. A new engineer argues this is a Medium finding, not Critical, because "it's never been used to cause harm." How would you respond?
A The engineer is correct — if a permission has never been used it poses no active risk and can be deprioritized.
B Severity is based on blast radius potential, not historical usage. An unused iam:* permission is still a Critical finding because if the service account is compromised, the attacker gains full IAM control — the dormancy just means it hasn't been exploited yet.
C Delinea should automatically remove the permission since it is unused, regardless of severity classification.
D The finding should be closed as a false positive since CI/CD accounts require broad permissions by design.
🔧
Remediating Over-Permissioned Identities
Targeted access reviews, right-sizing, and automated enforcement

🗺 Remediation Approaches

Delinea offers three remediation modes: Automated (immediate policy adjustment via API), Access Review (workflow to certify or revoke access with approver sign-off), and Guided Manual (generated right-sized policy JSON for your team to apply). Choose the mode based on risk tolerance and change-management requirements.

📋

Step 1 — Initiate an Access Review

From any finding, click Start Access Review. Delinea creates a review task, assigns it to the identity owner or designated approver, and sets a deadline (default: 7 days). The reviewer sees a plain-language summary of what access the identity has vs. what it actually uses.

→
🤝

Step 2 — Manager / Owner Decision

The reviewer can choose: Certify (keep access — must provide business justification, triggers re-review in 90 days), Revoke (remove the specific permission), or Right-Size (accept Delinea's recommended least-privilege replacement policy).

→
⚡

Step 3 — Automated Enforcement

For Revoke and Right-Size decisions, Delinea calls the cloud provider API to apply the change immediately — no manual IAM console work required. A complete audit trail records who approved, when, and what change was made.

→
🔄

Step 4 — Post-Remediation Verification

Delinea re-scans the remediated identity within 24 hours and marks the finding as Resolved. If a Certified access generates a new risk finding within the certification window, the approver is automatically re-notified.

→
📝
Right-Sizing Example — ci-deploy-prod
Before and after the Delinea-generated least-privilege policy
❌ BEFORE — OVER-PERMISSIONED
{ "Statement": [{ "Effect": "Allow", "Action": "*", "Resource": "*" }] }
✅ AFTER — RIGHT-SIZED BY DELINEA
{ "Statement": [ { "Effect": "Allow", "Action": [ "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "s3:GetObject" ], "Resource": [ "arn:aws:ecr:us-east-1:123:repository/app", "arn:aws:s3:::deploy-artifacts-prod/*" ] } ] }
✅
Lab Exercise — Remediation Checklist
Complete the tasks below to practice the remediation workflow
✓
Navigate to Findings Dashboard — Filter by Severity: Critical. Confirm ci-deploy-prod appears at the top of the list.
✓
Open the finding — Review the effective permissions panel and confirm iam:* is listed as Critical with zero usage.
✓
Click "Right-Size" — Review the Delinea-generated least-privilege policy. Confirm it contains only ECR and S3 GetObject actions scoped to specific ARNs.
✓
Apply the right-sized policy — Click "Apply Change". Delinea will call iam:PutRolePolicy and iam:DetachRolePolicy to enforce the new policy.
✓
Initiate Access Review for john.smith — From the Medium finding for unused EC2 access, click "Start Access Review" and assign to john.smith's manager with a 7-day deadline.
✓
Review the audit log — Navigate to Governance → Audit Trail. Confirm both remediation actions are logged with timestamp, actor, and change detail.
✓
Schedule a re-scan — Set a 24-hour follow-up scan to verify the ci-deploy-prod finding resolves. Confirm the finding status changes to "Resolved".
🧠
Knowledge Check · Module 5
QUESTION 1 OF 1 — REMEDIATION
A manager certifies that their data analyst needs Storage Blob Data Owner access for a specific project. What should happen next in Delinea's workflow?
A The finding is permanently closed and will never resurface.
B Delinea escalates to a security administrator for a second approval before accepting the certification.
C The finding is marked Certified with the manager's justification recorded in the audit trail. A new access review is automatically scheduled for 90 days out, and if the permission generates risk findings again before then, the manager is re-notified.
D Delinea removes the permission anyway since the least-privilege principle overrides manager approval.