Sensitive Data
The Audit Service includes mechanisms for handling sensitive data within audit events. This covers data masking in event payloads, flagging events that involve sensitive resources, and providing specialized alerting rules for sensitive data access patterns.
Sensitive Data in Audit Events
Audit events may contain sensitive information in several fields:
| Field | Risk | Mitigation |
|---|---|---|
previousState | May contain PII or secrets | Masking applied before storage |
newState | May contain PII or secrets | Masking applied before storage |
metadata | May contain custom sensitive data | Application-level responsibility |
actorEmail | Contains PII | Retained for compliance, subject to GDPR deletion |
ipAddress | May identify individuals | Retained for security, subject to retention policies |
Data Masking
Before storing audit events, the service applies masking to known sensitive fields:
- Passwords: Always masked, never stored in
previousStateornewState - API keys: Masked to show only the last 4 characters
- Email addresses in state: Partially masked (e.g.,
j***@acme.com) - Credit card numbers: Masked to show only the last 4 digits
- Social security numbers: Fully masked
Masking Configuration
Fields to mask are configured through patterns that match JSON paths within state objects. Services publishing audit events should exclude sensitive fields from the state diff or mark them for masking.
Sensitive Resource Tracking
Resources can be tagged as sensitive to trigger additional logging and alerting. The SENSITIVE_DATA_ACCESS alert rule type monitors access to these tagged resources.
Sensitive Resource Types
| Resource Type | Examples | Alert Level |
|---|---|---|
| PII Data | User profiles, contact information | HIGH |
| Financial Data | Invoices, payment records | HIGH |
| Security Config | API keys, credentials, permissions | CRITICAL |
| Compliance Data | Audit logs, GDPR requests | MEDIUM |
| System Config | Infrastructure configs, secrets | CRITICAL |
Alert Rules for Sensitive Data
The AuditAlertRule entity supports SENSITIVE_DATA_ACCESS as a rule type. When configured, the alerting system monitors for:
- Bulk access: A single user accessing many sensitive resources in a short window
- First-time access: Users accessing sensitive resources they have not accessed before
- After-hours access: Sensitive data access outside business hours
- Export activity: Sensitive data being exported or downloaded
Example Alert Rule
{
"name": "Sensitive Data Bulk Access",
"ruleType": "SENSITIVE_DATA_ACCESS",
"severity": "HIGH",
"conditions": {
"resourceTypes": ["pii_data", "financial_data"],
"eventTypes": ["DATA_ACCESS", "DATA_EXPORT"]
},
"thresholdCount": 50,
"thresholdWindowMinutes": 10,
"notificationChannels": "email,slack",
"cooldownMinutes": 60
}GDPR Integration
Sensitive data handling is closely integrated with the GDPR module:
- Data Access Requests: Collect all audit events referencing a data subject
- Data Deletion Requests: Anonymize or delete audit events containing PII for a subject
- Data Portability: Export audit events with sensitive data included in the portable format
- Consent Tracking: Audit events record consent changes for compliance
Retention for Sensitive Data
Sensitive audit events may have different retention requirements than standard events. The retention policy system supports per-event-type retention periods, allowing compliance-critical events (e.g., security alerts, data access logs) to be retained longer than standard operational events.
Even with data masking, audit events may contain identifying information in combinations of fields (e.g., tenant ID plus timestamp plus resource ID). Apply the principle of least privilege when granting access to audit data, and ensure GDPR deletion requests cover all correlated data.