IAM role-based access control policies not enforcing GL module segregation of duties for financial compliance

Cloud Platforms Oracle Cloud
, , , , , , , ,
1

We’re failing audit requirements because our IAM policies aren’t properly enforcing segregation of duties in the GL module. Users who should only have journal entry creation rights are able to approve their own entries, which violates SOD principles.

Our current policy structure:

{
  "statements": [
    {"allow group GL_Users to manage journals in compartment Finance"}
  ]
}

We’ve set up separate groups (GL_Creators and GL_Approvers) with role-based access control, but the policy conditions aren’t working as expected. Users in GL_Creators group can still perform approval actions. We need dynamic group membership based on user attributes, but I’m not sure how to implement policy conditions that check the request type (create vs approve) and prevent the same user from doing both. This SOD violation was flagged in our audit and needs immediate resolution.

2

Your policy is way too broad - ‘manage’ grants all permissions. You need to break it down into specific verbs: ‘use’, ‘read’, ‘inspect’ for different operations. For SOD enforcement, create separate policies for each group with explicit verbs. GL_Creators should only have ‘use’ permission for journal creation, while GL_Approvers get ‘manage’ for approval workflows. The ‘manage’ verb is essentially admin access and bypasses any SOD controls you’re trying to implement.

3

I tried breaking down the permissions, but I’m struggling with the policy conditions syntax. How do I specify that GL_Creators can only perform ‘create’ operations and not ‘approve’ operations on the same resource? Also, for dynamic group membership, we want to automatically assign users to groups based on their department attribute in our identity provider. Is this possible with OCI IAM federation?

4

The segregation of duties enforcement requires a combination of IAM policies and application-level controls. At the IAM level, you can use resource-level permissions and policy conditions, but OCI IAM doesn’t have native support for workflow-based approvals. You need to implement this in your application logic - the GL module should track who created each journal entry and prevent that same user from approving it, regardless of their IAM permissions. IAM policies control access to resources, but business logic like SOD needs to be enforced in the application layer.

5

Let me provide a comprehensive solution addressing all four aspects of your SOD challenge:

1. Role-Based Access Control Implementation: Replace your overly permissive policy with granular, verb-specific policies:

GL_Creators Policy:

{
  "statements": [
    {
      "allow group GL_Creators to use journals in compartment Finance where request.operation='CreateJournalEntry'"
    },
    {
      "allow group GL_Creators to read journals in compartment Finance"
    },
    {
      "deny group GL_Creators to manage journals in compartment Finance where request.operation='ApproveJournalEntry'"
    }
  ]
}

GL_Approvers Policy:

{
  "statements": [
    {
      "allow group GL_Approvers to manage journals in compartment Finance where request.operation='ApproveJournalEntry'"
    },
    {
      "allow group GL_Approvers to read journals in compartment Finance"
    },
    {
      "deny group GL_Approvers to use journals in compartment Finance where request.operation='CreateJournalEntry'"
    }
  ]
}

2. Segregation of Duties Enforcement: The key is using explicit DENY statements. OCI IAM evaluates policies in this order: Deny → Allow. Even if a user is accidentally added to both groups, the deny policy prevents them from performing the conflicting action. Additionally, implement these safeguards:

  • Never assign users to both GL_Creators and GL_Approvers groups
  • Use OCI audit logs to monitor for policy violations
  • Implement periodic access reviews to verify group memberships
  • Create an alert rule that triggers when a user is added to multiple conflicting groups

3. Policy Conditions: Policy conditions use the ‘where’ clause to evaluate request context. Available conditions include:

  • request.operation: The specific API operation being performed
  • request.user.id: The OCID of the user making the request
  • target.resource.id: The OCID of the resource being accessed
  • request.networkSource.name: Network source of the request

For SOD enforcement, the critical condition is request.operation, which allows you to permit/deny specific actions. However, note that operation names must match the actual OCI API operations - you may need to work with your application team to identify the exact operation names used by your GL module.

4. Dynamic Group Membership: OCI dynamic groups are for compute instances, not users. For user group assignment based on attributes, configure federation group mapping:

SAML Federation Setup:

  1. In your IdP, create groups matching your OCI groups (GL_Creators, GL_Approvers)
  2. Configure SAML assertion to include group membership attribute
  3. In OCI Identity Federation, map IdP groups to OCI IAM groups
  4. Users automatically inherit OCI group membership based on their IdP groups

Mapping Configuration:

{
  "groupMappings": [
    {"idpGroup": "Department-GL-Create", "ociGroup": "GL_Creators"},
    {"idpGroup": "Department-GL-Approve", "ociGroup": "GL_Approvers"}
  ]
}

Critical Additional Controls: IAM policies alone cannot fully enforce SOD for complex business workflows. You MUST implement application-level controls:

  1. Database-level enforcement: Store creator user ID with each journal entry
  2. Application logic: Check if approver.id == creator.id and reject if true
  3. Audit trail: Log all creation and approval actions with user IDs and timestamps
  4. Workflow engine: Implement multi-stage approval requiring different users at each stage

For audit compliance, document that your SOD control has two layers:

  • IAM Policy Layer: Prevents users from having both create and approve permissions simultaneously
  • Application Layer: Prevents the same user from approving entries they created, even if they later gain approval permissions

This defense-in-depth approach satisfies auditors and provides true SOD enforcement. Make sure your audit team understands that OCI IAM controls resource access, while business logic controls workflow-based SOD requirements.