Governance Constraints
Constraints are governance rules that enforce access control policies across your organization.
They allow you to define conditions that must be met for your identity and access management to remain compliant with your security policies and regulations.
Overview
Section titled “Overview”Big ACL supports five types of constraints, each designed to address specific governance requirements:
| Type | Purpose |
|---|---|
| Cardinality | Limit the number of users with specific roles |
| Separation of Duties | Prevent users from holding incompatible roles |
| Toxic Combination | Forbid dangerous combinations of multiple roles |
| Temporal | Enforce time-based rules on assignments |
| Attribute Constraint | Require specific attributes on users or assignments |
Constraint Types
Section titled “Constraint Types”Cardinality Constraint
Section titled “Cardinality Constraint”Cardinality constraints limit the number of users that can hold a specific role or set of roles. This helps prevent over-privileged access and ensures proper distribution of responsibilities.
When to Use
Section titled “When to Use”- Limit the number of administrators for critical applications
- Ensure a minimum number of users have emergency access
- Control the size of privileged groups
Example Use Cases
Section titled “Example Use Cases”- “Maximum 3 Jira administrators per project”
- “At least 2 users must have break-glass access to production systems”
- “No more than 5 users per application can have the Super Admin role”
Separation of Duties (SoD) Constraint
Section titled “Separation of Duties (SoD) Constraint”Separation of Duties constraints prevent a single user from holding two roles that are considered incompatible. This is a fundamental control for preventing fraud, errors, and ensuring proper oversight through the “four-eyes principle.”
When to Use
Section titled “When to Use”- Prevent the same person from initiating and approving transactions
- Ensure developers cannot deploy their own code to production
- Separate access request creation from approval
Example Use Cases
Section titled “Example Use Cases”- “A user cannot be both Payment Validator and Payment Executor”
- “The same person cannot create and approve purchase orders”
- “Code reviewers cannot be the authors of the code they review”
Toxic Combination Constraint
Section titled “Toxic Combination Constraint”Toxic Combination constraints extend Separation of Duties to three or more roles. They identify dangerous concentrations of privileges that could enable a single user to bypass controls or commit fraud.
When to Use
Section titled “When to Use”- Prevent accumulation of multiple sensitive roles
- Identify users with excessive privileges across systems
- Enforce the principle of least privilege
Example Use Cases
Section titled “Example Use Cases”- “No user should have Admin, Approver, and Auditor roles simultaneously”
- “The combination of Create, Approve, and Execute permissions is forbidden”
- “Users cannot hold all three finance roles: Budget Owner, Invoice Approver, and Payment Releaser”
Temporal Constraint
Section titled “Temporal Constraint”Temporal constraints enforce time-based rules on role assignments. They ensure that access is regularly reviewed and that temporary access does not become permanent.
Subtypes
Section titled “Subtypes”Maximum Duration Ensures that role assignments do not exceed a specified time period. Ideal for temporary access, contractors, or project-based permissions.
Recertification Requires periodic review and re-approval of role assignments. Essential for compliance with regulations that mandate regular access reviews.
Example Use Cases
Section titled “Example Use Cases”- “Contractor access must not exceed 90 days”
- “All privileged access must be reviewed every quarter”
- “Temporary admin rights expire after 7 days”
- “External consultant access requires monthly recertification”
Attribute Constraint
Section titled “Attribute Constraint”Attribute constraints require that users or assignments have specific attributes before certain roles can be assigned. This enables complex validation logic based on organizational properties.
When to Use
Section titled “When to Use”- Restrict roles based on department, location, or job function
- Require specific certifications or training completion
- Enforce regional or legal entity boundaries
Example Use Cases
Section titled “Example Use Cases”- “Only IT department employees can have system administrator roles”
- “Finance roles require users to have completed SOX training”
- “Access to EU customer data requires users to be based in the EU”
- “Manager approval role requires the ‘people_manager’ attribute”
Constraint Lifecycle
Section titled “Constraint Lifecycle”Status
Section titled “Status”Constraints follow a lifecycle with three statuses:
| Status | Description |
|---|---|
| Draft | The constraint is being configured. Violations are detected but not enforced. |
| Active | The constraint is fully enforced. New violations are blocked and existing ones must be remediated. |
| Archived | The constraint is no longer enforced and is kept for historical reference. |
Best Practices
Section titled “Best Practices”Writing Clear Descriptions
Section titled “Writing Clear Descriptions”Use descriptive names that explain the business rule in plain language:
-
Good: “Maximum 3 Jira administrators per project”
-
Poor: “Jira admin cardinality”
-
Good: “No user can approve and execute payments”
-
Poor: “SoD finance”
Plan for Exceptions
Section titled “Plan for Exceptions”Some constraints may need controlled exceptions. Consider:
- Using tolerance settings for toxic combinations when legacy situations exist
- Documenting exception processes for time-limited overrides
- Regularly reviewing exceptions to ensure they remain justified
Regular Review
Section titled “Regular Review”Periodically review your constraints to ensure they:
- Remain aligned with current policies and regulations
- Are still relevant to your application landscape
- Have acceptable violation rates
- Include appropriate remediation workflows