8.3 Attribute-Based Access Control (ABAC), Encryption & Audit Trails
Key Takeaways
- Attribute-Based Access Control (ABAC) augments RBAC by evaluating contextual user attributes, case attributes, and environmental conditions at runtime, enforcing row-level case filtering and column-level property masking.
- An ABAC implementation requires pairing an Access Control Policy (Rule-Access-Policy) with an Access Control Policy Condition (Rule-Access-PolicyCondition) across Read, Update, Discover, Delete, or PropertyRead actions.
- Property-level encryption encrypts sensitive PII fields (such as SSN or banking credentials) within the storage stream (BLOB) using cryptographic keystores and symmetric ciphers like AES-256.
- Field-level auditing automatically tracks and timestamps modifications to critical case properties, appending immutable audit entries to pyWorkHistory in the pc_history_work database table.
- In Pega's layered defense, RBAC evaluates first to determine baseline class and feature entitlements, followed by ABAC to dynamically restrict or mask matching data rows and columns.
8.3 Attribute-Based Access Control (ABAC), Encryption & Audit Trails
While Role-Based Access Control (RBAC) provides robust, class-level entitlements based on user personas, modern enterprise compliance requires dynamic, context-sensitive security that adapts to real-time data attributes and regulatory mandates (such as GDPR, HIPAA, and PCI-DSS).
Pega Platform meets these demands through three advanced security capabilities:
- Attribute-Based Access Control (ABAC): Dynamic row-level case filtering and column-level property masking.
- Cryptographic Data Protection & Encryption: Securing sensitive personally identifiable information (PII) at rest, in memory, and within the database BLOB.
- Field-Level Auditing: Immutable, forensic tracking of modifications to mission-critical case properties.
1. Evolution from RBAC to Attribute-Based Access Control (ABAC)
In traditional RBAC, access decisions depend strictly on static user roles. However, enterprise business rules often demand contextual restrictions:
- "Underwriters may only view loan applications originated in their assigned geographic territory."
- "Customer service representatives may see a customer's case history, but the Social Security Number must display only the last four digits unless the supervisor authorizes an unmasking."
- "Physicians may only open medical claim cases where they are listed as the primary attending care provider."
Attempting to solve these requirements using RBAC results in role explosion—creating hundreds of artificial roles like Underwriter-Northeast, Underwriter-Southwest, and Manager-Tier2-California.
Attribute-Based Access Control (ABAC) solves this by evaluating four dynamic vectors at runtime:
- Subject Attributes: Attributes of the authenticated operator (e.g.,
Operator.pyDepartment,Operator.Region,Operator.SecurityClearance). - Resource Attributes: Attributes of the target case or data instance (e.g.,
Case.Region,Case.ClaimAmount,Case.SensitivityLevel). - Action: The specific operation requested (
Read,Update,Discover,Delete,PropertyRead). - Environmental Context: Contextual factors such as current time, client IP subnet, or device posture.
2. ABAC Policies in Pega Platform
Pega implements ABAC through two complementary rule types located in Dev Studio under the Security rule category:
+-------------------------------------------------------------------------+
| PEGA ABAC POLICY RULES |
+-------------------------------------------------------------------------+
| [1] ACCESS CONTROL POLICY (Rule-Access-Policy) |
| Defines the Target Class (Applies-To), the Policy Action, and |
| references one or more Policy Conditions. |
| |
| [2] ACCESS CONTROL POLICY CONDITION (Rule-Access-PolicyCondition) |
| Defines the reusable boolean filter logic comparing Subject |
| attributes against Resource properties. |
+-------------------------------------------------------------------------+
The Five ABAC Policy Actions
An Access Control Policy (Rule-Access-Policy) specifies the protected class and selects exactly one of five policy actions:
| Policy Action | Enforcement Mechanism | Business Use Case & Impact |
|---|---|---|
Read | Injected dynamically into database queries and evaluated when opening a case. | Restricts full case viewing. If condition fails, user receives an access-denied error when attempting to open the case. |
Update | Evaluated whenever an operator attempts to save or submit changes to a case. | Restricts modification. If condition fails, the case opens in read-only mode, disabling form inputs and submission buttons. |
Discover | Injected into search queries, Report Definitions, and work lists. | Enables limited visibility. If condition fails, the case is hidden entirely from search results and reports, preventing discovery. |
Delete | Evaluated prior to executing case purge or deletion routines. | Restricts case deletion to instances matching specific age, status, or administrative attributes. |
PropertyRead | Controls property-level (column-level) field visibility and masking on forms and reports. | Masks sensitive PII (e.g., SSN, Tax ID, credit card numbers, medical diagnoses) based on user clearance. |
PropertyRead Masking Modes
When configuring a PropertyRead policy, architects select how the protected property appears to users who do not meet the condition criteria:
- Masked (Full): Completely replaces the data value with asterisks (e.g.,
*********). - Masked (Partial / N Characters Visible): Reveals only designated characters, such as the last four digits of a Social Security Number or payment card (e.g.,
***-**-8421). - Clear: The unmasked, plaintext value is displayed when the user satisfies the policy condition.
Access Control Policy Conditions (Rule-Access-PolicyCondition)
A Policy Condition rule defines reusable conditional expressions using standard logical operators:
Policy Condition Logic Expression:
(Operator.pyDepartment = Case.AssignedDepartment) AND (Case.RiskScore <= Operator.MaxAuthorizedRisk)
Because ABAC policy conditions are injected directly into the SQL generation engine for Report Definitions, case filtering occurs directly at the database tier, ensuring high query performance and preventing unauthorized records from ever entering application memory.
3. Comparison Matrix: RBAC vs. ABAC
| Architectural Dimension | Role-Based Access Control (RBAC) | Attribute-Based Access Control (ABAC) |
|---|---|---|
| Primary Rule Types | Rule-Access-Role-Name, Rule-Access-Role-Obj, Rule-Access-Privilege-Name | Rule-Access-Policy, Rule-Access-PolicyCondition |
| Decision Basis | Static user roles defined in the user's Access Group. | Dynamic comparison of Subject, Resource, Action, and Environment attributes. |
| Level of Granularity | Coarse-grained: Entire classes, rule types, and specific Flow Actions. | Fine-grained: Specific case rows and individual property columns/fields. |
| Inheritance Model | Inherited hierarchically via pattern and directed class inheritance. | Policies defined on ancestor classes automatically apply to all child classes. |
| Data Masking Support | No native field masking (all-or-nothing form access). | Native column-level masking (Full, Partial, Clear). |
| Evaluation Timing | Checked upfront during portal load, case open, and action rendering. | Dynamically injected into SQL generation and evaluated on property fetch. |
| Operational Relationship | Outer Gatekeeper: Evaluated first. If RBAC denies access, ABAC is never reached. | Inner Filter: Evaluated second. Refines and filters data that passes RBAC. |
Critical Exam Rule: ABAC does not replace RBAC. They work in tandem as a layered defense. A user must first possess valid RBAC permissions (ARO and Privileges) to access a case class before ABAC policies evaluate to filter rows or mask sensitive fields.
4. Cryptographic Data Protection & Encryption
Enterprise applications handling confidential data must comply with data-at-rest encryption standards. Pega Platform differentiates between infrastructure-level database encryption and application-level cryptographic protection.
+-------------------------------------------------------------------------+
| PEGA LAYERED ENCRYPTION ARCHITECTURE |
+-------------------------------------------------------------------------+
| [1] INFRASTRUCTURE LAYER: Transparent Data Encryption (TDE) |
| Storage-tier encryption protecting physical disk drives and SANs |
| |
| [2] PEGA PLATFORM LAYER: Class / Table-Level Encryption |
| Encrypts entire storage streams (BLOBs) for specific work classes |
| |
| [3] PROPERTY-LEVEL ENCRYPTION: Granular PII Protection |
| Encrypts individual sensitive fields (SSN, Card Number) before |
| persisting into the BLOB or relational database columns |
+-------------------------------------------------------------------------+
Infrastructure TDE vs. Application-Level Encryption
- Transparent Data Encryption (TDE): Operates at the relational database management system (RDBMS) or storage hardware layer. Protects against physical disk theft or raw backup tampering, but provides zero protection if an unauthorized user gains access through an authenticated database session.
- Pega Application-Level Encryption: Operates inside the Pega engine before data is persisted. Encrypts data in application memory and writes cipher-text directly into the database Storage Stream (
pzPVStreamBLOB) or relational columns. Even database administrators inspecting tables directly see only encrypted binary strings.
Property-Level Encryption Configuration
To protect sensitive individual fields (such as .TaxIdentifier, .CreditCardNumber, or .HealthRecordID):
- In Dev Studio, open the property rule (
Rule-Obj-Property). - On the Advanced tab, select the Encrypt control checkbox.
- Once marked, the Pega engine automatically encrypts the property using the configured enterprise Keystore before writing to the database, and decrypts the property transparently when loaded into authorized clipboard sessions.
Keystores and Key Management Systems (KMS)
Pega manages cryptographic keys using Keystore data instances (Data-Admin-Security-Keystore):
- Supports standard formats including Java Keystore (JKS) and PKCS12.
- Integrates natively with cloud Key Management Services, including AWS KMS, Microsoft Azure Key Vault, Google Cloud KMS, and HashiCorp Vault.
- Employs AES-256 symmetric cipher suites with master key rotation policies to ensure cryptographic longevity and regulatory compliance.
5. Field-Level Auditing and Immutable Case History
Regulatory compliance mandates that modifications to critical financial, personal, or legal case data maintain an immutable, non-repudiable audit trail.
The Case History Architecture
Every case instance maintains a corresponding history log stored in the dedicated history database table pc_history_work (mapped to classes derived from History-Work-).
- Whenever a user progresses a case, executes an assignment, or updates status, the engine appends a record to the Page List property
.pyWorkHistory. - Standard audit history captures:
- Timestamp (
pxTimeCreated): Exact date and time of the event. - Actor (
pyPerformer): The Operator ID who performed the change. - Action Description (
pyMessageKey): Description of the lifecycle event or stage transition.
- Timestamp (
Configuring Field-Level Auditing
Standard case history records high-level workflow events, but does not track individual property modifications by default. Architects configure Field-Level Auditing to track changes to critical properties (such as .LoanAmount, .InterestRate, or .BeneficiaryName):
- App Studio Configuration: Navigate to Case Type Settings > Auditing. Enable auditing and select the specific fields to monitor.
- Dev Studio Configuration: Utilize the Field-Level Auditing wizard or configure a Declare Trigger (
Rule-Declare-Trigger) running on the class that monitors.pyWorkPagechanges and calls standard history logging activities. - Audit Detail Captured: When an audited property changes, the system records:
- The property name.
- The previous value (Old Value).
- The new updated value (New Value).
- The modifying operator and timestamp.
Immutability and Compliance Integrity
Audit records stored in pc_history_work are strictly immutable:
- Standard Pega application rules and user portals provide no mechanism to edit or delete history rows.
- Modifications trigger automatic checksum updates.
- This non-repudiation architecture guarantees compliance with external audit standards, including Sarbanes-Oxley (SOX), HIPAA Security Rule, and PCI-DSS Requirement 10.
6. Enterprise Compliance Best Practices & Exam Pitfalls
| Common Architecture Mistake | Regulatory / Operational Risk | Certified Architect Solution |
|---|---|---|
| Exposing encrypted properties without ABAC masking | If an unmasked property is exposed in a Report Definition, unauthorized users can view raw confidential PII. | Combine property encryption with a PropertyRead ABAC policy to enforce partial or full masking in UI views. |
| Attempting to replace RBAC entirely with ABAC | Eliminating ARO rules removes class-level guardrails, allowing unintended access if an ABAC policy condition is misconfigured. | Always maintain a strict baseline RBAC structure (AROs and Privileges); apply ABAC as an additive filtering layer. |
| Over-auditing high-frequency transactional fields | Enabling field-level auditing on dozens of frequently updated calculation properties causes massive database table bloat in pc_history_work. | Audit only legally binding, financial, or compliance-critical properties that require forensic traceability. |
| Hardcoding cryptographic keys in application rules | Hardcoded keys in properties or data transforms violate security standards and prevent automated key rotation. | Store cryptographic materials in enterprise Keystores (Data-Admin-Security-Keystore) linked to cloud KMS vaults. |
A commercial lending institution requires that loan officers only be permitted to view and open commercial loan cases that belong to their specific geographical region (e.g., Eastern, Central, Western), based on the officer's assigned department. How should the architect enforce this dynamic row-level security policy without causing role explosion?
In a healthcare insurance application, patient records contain a sensitive Tax Identifier property (.TaxID). Compliance rules state that customer support representatives may view the case, but the Tax ID must be masked so that only the final four digits are visible (e.g., *--1234), whereas compliance managers must see the full unmasked value. Which Pega security capability achieves this?
A regulatory audit discovers that loan underwriters have been altering approved mortgage interest rates after managerial sign-off, without any record of the previous rate or the modifying user. What configuration must the System Architect implement to establish forensic traceability for this critical property?