Security & GRCarchitect

Cloud IAG Architecture: Hybrid Targets, IAG Bridge, Workflows and Audit Evidence

Key takeaway

Design SAP Cloud IAG across BTP, cloud and on-premise targets with governed connectors, role collections, workflow, cross-system risk analysis and audit-ready lifecycle evidence.

Explanation

📌 KEY POINTS
✅ A technically connected target with no correct rule mapping produces incomplete/empty analysis — and false confidence.
⚠️ Platform administrator access should not automatically imply governance-application administration.
💡 Monitor deprovisioning failures especially closely — orphaned access after employment/role changes is the real risk.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE ARCHITECTURE

BTP service + identity/trust setup + connectivity to target applications
Integrates with cloud and on-premise systems; can coexist with SAP Access Control via IAG Bridge

━━━━━━━━━━━━━━━━━━━━
⚠️ 2. THE MAPPING TRAP

Connected systems must be assigned to correct business-function groups and risk-rule contexts
A technically connected target with wrong/no rule mapping → incomplete analysis that LOOKS complete

━━━━━━━━━━━━━━━━━━━━
▶ 3. WORKFLOW SEPARATION

Requester, manager, role owner, risk approver — separated where policy requires
Privileged access needs stronger logging and post-use review

━━━━━━━━━━━━━━━━━━━━
▶ 4. GOVERNING THE GOVERNANCE APP

IAG's own BTP role collections need least-privilege administration
Platform admin ≠ governance-app admin — don't conflate them

━━━━━━━━━━━━━━━━━━━━
▶ 5. AUDIT EVIDENCE CHAIN

Request → approval → risk analysis → provisioning result → certification → removal
Watch deprovisioning failures closest — orphaned access is the real danger

✅ CHECKPOINT: explain how a "connected" target system can still produce a false sense of security.

Real project scenario

A target system was connected successfully but returned no SoD findings. The cause was missing business-function-group assignment for that application type, so the risk rules were never applied.

Common mistakes

Equating connection success with risk-analysis completeness.
Excessive IAG admin role collections.
No separation between requester and risk approver.
Weak privileged-access review.
Monitoring provisioning but not removal.

Best practices

Validate target-to-risk-rule mapping.
Separate governance duties.
Apply least privilege to IAG administration.
Preserve end-to-end request evidence.
Monitor deprovisioning failures.

Interview angle

Design a hybrid Cloud IAG architecture and explain system/rule mapping, workflow, IAG Bridge and lifecycle evidence.

Practice this lesson

Quick check

1. During hypercare for SAP Cloud Identity Access Governance, which principle from Cloud IAG Architecture: Hybrid Targets, IAG Bridge, Workflows and Audit Evidence is most likely to prevent repeat incidents?

2. Scenario — A target system was connected successfully but returned no SoD findings. Which response best addresses the design or operating risk in Cloud IAG Architecture: Hybrid Targets, IAG Bridge, Workflows and Audit Evidence?

3. Design SAP Cloud IAG across BTP, cloud and on-premise targets with governed connectors, role collections, workflow, cross-system risk analysis and audit-ready lifecycle evidence. A production team now has to make a design decision in Cloud IAG Architecture: Hybrid Targets, IAG Bridge, Workflows and Audit Evidence. Which option best preserves reliability and supportability?

Interview questions

1. What are the most important concepts in SAP Cloud Identity Access Governance, and how do they connect to Cloud IAG Architecture: Hybrid Targets, IAG Bridge, Workflows and Audit Evidence in a real SAP landscape?

Answer it in your own words first, then compare.

2. You inherit an existing SAP Cloud Identity Access Governance implementation covering Cloud IAG Architecture: Hybrid Targets, IAG Bridge, Workflows and Audit Evidence. What would you review before changing it, and what would make you confident the change is production-ready?