Final StretchOrdered learning track
Security, Privacy, and Compliance Review
Review akses process/task/variable, sensitive variable, form privacy, worker credential, connector secret, TLS, audit trail, retention, deletion, incident privacy, log redaction, tenant isolation, dan compliance evidence.
7 min read1357 words
Lesson 5660 lesson track51–60 Final Stretch
#camunda#security#privacy#compliance+3 more
Part 056 — Security, Privacy, and Compliance Review
Fokus part ini: membangun checklist security, privacy, dan compliance untuk workflow system. Targetnya bukan hanya “Camunda pakai login”, tetapi memastikan process, task, variable, incident, connector, worker, log, database, message, dan operational tooling tidak membocorkan data atau memberi akses yang terlalu luas.
Workflow system sering menjadi pusat data sensitif karena ia menghubungkan banyak domain:
Quote data
Order data
Customer data
Approval data
Contract data
Pricing data
Manual task decision
Incident notes
External API payload
Worker logs
Process variables
History/search index
Dalam CPQ/order management, workflow bisa melewati data komersial, customer, tenant, agreement, entitlement, pricing, provisioning, dan audit trail. Karena itu, security review workflow tidak boleh hanya melihat endpoint REST. Review harus melihat seluruh lifecycle.
1. Security Mental Model for Workflow Systems
1.1 Workflow expands the attack surface
Camunda/workflow system menambahkan beberapa permukaan baru:
BPMN deployment
DMN deployment
Form/task configuration
Process start API
Task query/complete API
Message correlation API
Worker activation/completion API
Connector secret/configuration
Operate/Cockpit/Tasklist/Admin access
Process variables/history/search index
Incident details
Manual repair tools
Migration/cancel/retry operations
Setiap permukaan punya risiko:
- unauthorized process start;
- unauthorized task visibility;
- unauthorized task completion;
- sensitive variable exposure;
- connector secret leakage;
- worker credential misuse;
- cross-tenant data access;
- log/incident privacy leakage;
- operational privilege abuse.
1.2 Security review must follow lifecycle
Gunakan lifecycle berikut:
Design
Model
Deploy
Start process
Run automation
Handle human task
Store variables/history
Integrate external systems
Observe and debug
Operate/retry/repair/migrate
Retain/delete/archive
Audit and produce evidence
Security bug bisa muncul di salah satu fase.
2. Access Control Review
2.1 Process-level access
Review pertanyaan:
Who can deploy BPMN/DMN?
Who can start process instances?
Who can view process definitions?
Who can view process instances?
Who can cancel/suspend/migrate instances?
Who can retry/resolve incidents?
Who can modify variables?
Who can access historical data?
Akses process-level terlalu luas bisa memungkinkan user/operator melakukan tindakan yang secara bisnis tidak valid.
2.2 Task-level access
Task-level access harus menjawab:
Who can see the task?
Who can claim it?
Who can complete it?
Who can delegate/reassign it?
Who can view form data?
Who can view task history?
Who can override SLA/escalation?
Assignment bukan authorization. Candidate group membantu routing task, tetapi backend tetap harus memastikan user memang berhak melakukan action.
2.3 Variable-level access
Variable sering lebih sensitif dari task name. Contoh:
customer identity
contract number
discount value
pricing approval reason
credit/risk data
internal note
external API payload
provisioning parameter
access token accidentally stored
Review apakah semua user yang bisa melihat process/task juga boleh melihat semua variable. Jawabannya sering: tidak.
2.4 Internal verification checklist
[ ] Apakah access matrix process/task/variable ada?
[ ] Apakah operator bisa melihat semua tenant/customer?
[ ] Apakah task visibility dikontrol oleh backend atau hanya UI filter?
[ ] Apakah variable update/retry/migration/cancel action dibatasi?
[ ] Apakah admin privilege dipisahkan dari business operator privilege?
[ ] Apakah service account worker punya privilege minimal?
3. Identity, Role, Group, and Tenant Review
3.1 Identity source
Verifikasi sumber identity:
OIDC/SSO
LDAP
Internal identity provider
Camunda Identity/Admin
Application-level identity
Service account/client credentials
Jangan berasumsi group di enterprise IdP otomatis sama dengan candidate group di BPMN. Mapping harus diverifikasi.
3.2 Role design
Minimal role yang biasanya perlu dipisahkan:
Model author
Workflow deployer
Business operator
Approver
Support operator
SRE/platform operator
Security auditor
Read-only auditor
Workflow admin
Worker service account
Connector runtime identity
Role gabungan “admin untuk semua orang support” adalah risiko operasional dan audit.
3.3 Tenant isolation
Tenant isolation harus diterapkan di semua layer:
API request
Process start
Process instance query
Task query
Variable visibility
Message correlation
Worker access
Database query
Kafka/RabbitMQ topic/queue metadata
Redis key namespace
Logs and dashboards
Operate/Cockpit/Tasklist visibility
Satu tenant check yang hilang bisa membocorkan process data lintas customer.
3.4 Internal verification checklist
[ ] Tenant ID disimpan di mana?
[ ] Tenant ID masuk process variable, business table, atau engine tenant field?
[ ] Apakah worker memproses job lintas tenant?
[ ] Apakah dashboard bisa difilter tenant dengan aman?
[ ] Apakah support user dibatasi tenant/customer tertentu?
[ ] Apakah audit log menyimpan tenant context?
4. Sensitive Variable Review
4.1 Classify variables
Buat klasifikasi variable:
| Class | Example | Handling |
|---|---|---|
| Public process metadata | process name, activity name | visible broadly |
| Business identifier | quoteId, orderId, customerId | visible with role/tenant restriction |
| Commercial sensitive | discount, margin, contract term | restricted |
| Personal data | name, email, address, ID | privacy controlled |
| Secret credential | token, password, API key | must not be process variable |
| Technical debug payload | request/response body | minimize/redact |
4.2 Do not store secrets as variables
Never store these as process variables:
access token
refresh token
client secret
password
private key
basic auth credential
connector secret value
database credential
cloud credential
Store only secret reference/key if absolutely needed.
4.3 Large payload risk
Large variable is security and performance risk:
- appears in history/search;
- copied into logs/errors;
- increases DB/search load;
- makes incident review expose too much;
- makes retention/deletion harder;
- increases accidental PII leakage.
Prefer storing canonical business data in domain DB and passing references.
4.4 Internal verification checklist
[ ] List top 50 process variables by size.
[ ] List variables containing customer/PII/contract/pricing data.
[ ] Check if any variable contains token/password/secret.
[ ] Check if worker logs variable payload.
[ ] Check if incident messages include sensitive values.
[ ] Check retention policy for variable/history/search index.
5. Task Form Privacy Review
5.1 Form data is not automatically safe
User task form can expose:
customer data
commercial terms
approval reason
internal comments
attachments metadata
fallout reason
manual override details
Review both read and write paths.
5.2 Form design rules
- Show minimum necessary fields.
- Do not expose raw variable payload.
- Separate display field from hidden process variable.
- Validate server-side.
- Record who changed what.
- Avoid storing draft data in insecure browser/local storage.
- Ensure stale task completion does not overwrite newer data.
5.3 Manual comment risk
Free-text fields often leak sensitive data. Examples:
Customer said ...
Internal pricing exception because ...
Credential shared by ...
Personal identifier copied from email ...
Manual notes need policy, redaction, and retention review.
5.4 Internal verification checklist
[ ] Are forms versioned with BPMN?
[ ] Are form fields classified by sensitivity?
[ ] Are hidden fields protected server-side?
[ ] Are free-text comments searchable/logged/exported?
[ ] Are attachments handled outside process variables?
[ ] Is task completion audited with before/after values?
6. Worker Credential and Service Account Review
6.1 Worker identity
Each worker should have an identity appropriate to its job:
quote-validation-worker
order-fulfillment-worker
pricing-approval-worker
fallout-repair-worker
message-correlation-consumer
connector-runtime
Avoid one global super-service-account for all workflow operations.
6.2 Least privilege
Worker credentials should only allow required operations:
- activate/fetch relevant jobs;
- complete/fail jobs;
- throw BPMN error if needed;
- read/write required variables only if platform supports granularity;
- call required internal services;
- publish/consume required topics/queues;
- access required database tables/secrets.
6.3 Credential rotation
Review:
Where are worker credentials stored?
How are they rotated?
Do pods reload secrets?
What happens during rotation?
Are old credentials revoked?
Are failed auth attempts monitored?
6.4 Internal verification checklist
[ ] One service account per worker class or domain?
[ ] Secrets stored in Kubernetes Secret, cloud secret manager, Vault, or config file?
[ ] Secret rotation tested?
[ ] Worker credentials scoped by environment?
[ ] Non-prod credentials cannot reach prod?
[ ] Worker action logs include service account identity?
7. Connector Secret Review
7.1 Connector risks
Connectors can hide integration complexity but they also centralize secrets and external calls:
HTTP bearer token
OAuth client secret
Kafka credential
RabbitMQ credential
Webhook secret
API key
TLS certificate reference
Connector configuration must not leak secrets into BPMN XML, Git, logs, incidents, or screenshots.
7.2 Connector vs worker security
Use connector when:
- integration is simple;
- secret management is mature;
- observability is sufficient;
- retry behavior is understood;
- payload does not require complex redaction/custom audit.
Use custom worker when:
- domain logic is complex;
- idempotency requires DB coordination;
- payload contains sensitive data requiring careful redaction;
- custom authorization/tenant logic is needed;
- integration needs richer audit and compensating logic.
7.3 Internal verification checklist
[ ] Are connector secrets referenced, not embedded?
[ ] Are connector configs stored as code?
[ ] Are secrets excluded from BPMN XML and Git?
[ ] Are connector failures redacted?
[ ] Are connector outbound payloads logged anywhere?
[ ] Is connector runtime identity separated per environment?
8. JAX-RS API Security Review
8.1 Workflow API endpoints
Review endpoints such as:
POST /quotes/{id}/submit
POST /orders/{id}/workflow/start
POST /tasks/{taskId}/claim
POST /tasks/{taskId}/complete
POST /workflow/messages/{messageName}/correlate
GET /orders/{id}/workflow/status
POST /admin/workflow/{instanceId}/retry
POST /admin/workflow/{instanceId}/cancel
Each endpoint needs authentication, authorization, tenant check, idempotency, audit, and rate limiting appropriate to its risk.
8.2 Dangerous endpoint patterns
- Complete task by task ID without checking business ownership.
- Correlate arbitrary message name/key from external clients.
- Return full process variables from status endpoint.
- Allow admin retry/cancel/migration from normal app role.
- Trust tenant/customer ID from request body instead of authenticated context.
- Accept hidden form fields as authority.
8.3 Internal verification checklist
[ ] Does every workflow endpoint enforce authN/authZ server-side?
[ ] Is tenant derived from trusted context?
[ ] Are idempotency keys required for mutating endpoints?
[ ] Are admin operations separated from user operations?
[ ] Are response payloads redacted?
[ ] Are all mutating operations audited?
9. PostgreSQL/MyBatis/JDBC Security Review
9.1 Database state around workflow
Workflow system often stores related state in:
business tables
state transition tables
outbox/inbox tables
processed job tables
manual repair tables
audit tables
Camunda runtime/history tables
Review access and leakage for each.
9.2 MyBatis/JDBC risks
- Missing tenant filter in mapper query.
- Dynamic SQL exposing unintended rows.
- Raw variable payload copied to audit table.
- Manual repair SQL run without audit.
- Worker service account has broad DB privileges.
- Outbox event payload includes sensitive data.
- History cleanup not aligned with compliance retention.
9.3 Internal verification checklist
[ ] Are tenant predicates mandatory in workflow-related queries?
[ ] Are DB users scoped per service/worker?
[ ] Are outbox/inbox payloads classified and redacted?
[ ] Are manual repair SQL scripts reviewed and archived?
[ ] Are audit tables immutable enough for compliance?
[ ] Are Camunda runtime/history tables included in backup/retention policy?
10. Kafka/RabbitMQ/Redis Security Review
10.1 Kafka
Review:
topic ACL
producer/consumer identity
event payload sensitivity
schema registry access
replay authorization
DLQ access
PII in event metadata
correlation key leakage
10.2 RabbitMQ
Review:
vhost separation
exchange/queue permissions
routing key conventions
DLQ visibility
message TTL
retry queue payload
consumer credential rotation
management UI access
10.3 Redis
Review:
key namespace
tenant isolation in keys
TTL policy
PII in cache
lock key leakage
auth/TLS
operator access
backup/snapshot exposure
10.4 Internal verification checklist
[ ] Are event/message payloads minimized?
[ ] Are DLQs access-controlled?
[ ] Are replay tools restricted?
[ ] Are Redis keys tenant-safe?
[ ] Are queue/topic credentials scoped per worker?
[ ] Are message headers free from secrets/PII?
11. Logging, Tracing, and Incident Privacy Review
11.1 Logging risk
Workflow logs often include:
variables
request/response payload
external API error body
customer/order IDs
approval notes
stack traces with serialized data
connector failure detail
message headers
Logs are widely searchable. Treat logs as a data store.
11.2 Redaction rules
Redact:
- token;
- password;
- secret;
- authorization header;
- cookie;
- personal identifier;
- free-text approval notes if sensitive;
- pricing/margin if access restricted;
- raw external API payload unless explicitly allowed.
11.3 Tracing rule
Trace IDs and correlation IDs are good. Full payload in trace attributes is not.
11.4 Internal verification checklist
[ ] Are logs classified by environment?
[ ] Does worker log full variables?
[ ] Does connector log full request/response?
[ ] Are incident messages redacted?
[ ] Are traces sampled and redacted?
[ ] Who can access production logs?
[ ] What is log retention?
12. Audit Trail Review
12.1 What must be auditable
For workflow systems, audit should cover:
process started
process version used
task assigned/claimed/completed/delegated
approval/rejection decision
variable changes affecting decision
worker side effect command
message correlation
retry action
incident resolution
manual variable modification
process cancellation
process migration
compensation/manual repair
security role/permission change
12.2 Audit quality
Good audit event includes:
who
what
when
where/environment
tenant
business ID
process instance ID
activity/task/job ID
old value/new value if appropriate
reason/comment
approval reference if manual repair
12.3 Internal verification checklist
[ ] Are manual operations audited?
[ ] Are retry/resolve/migrate/cancel actions audited?
[ ] Is audit immutable or tamper-evident enough?
[ ] Are audit records correlated to quote/order/customer?
[ ] Can audit evidence be produced without exposing unrelated data?
13. Retention, Cleanup, and Deletion Review
13.1 Retention dimensions
Workflow data may live in:
Camunda runtime tables/state
Camunda history tables
Operate/Cockpit/Tasklist/Optimize storage
Elasticsearch/OpenSearch secondary storage
Business DB
Outbox/inbox tables
Logs/traces/metrics
Kafka topics/DLQ
RabbitMQ queues/DLQ
Redis cache/snapshots
Backup archives
Exported reports
Deletion request is not complete if only business DB row is deleted.
13.2 Retention conflict
There is often tension between:
audit requirement
regulatory evidence
operational debugging
privacy minimization
data deletion request
business reporting
customer support need
Policy must define which data is retained, for how long, and why.
13.3 Internal verification checklist
[ ] Is Camunda history cleanup configured?
[ ] Are search/index retention policies defined?
[ ] Are logs/traces retention aligned with privacy policy?
[ ] Are DLQ/event retention policies known?
[ ] Are backups included in deletion/retention policy?
[ ] Is there a data deletion playbook for workflow data?
14. Kubernetes, Cloud, and On-Prem Security Review
14.1 Kubernetes
Review:
namespace isolation
service account/RBAC
NetworkPolicy
PodSecurity settings
Secrets mounting
env var exposure
resource isolation
image provenance
container registry access
ingress/TLS
admin UI exposure
14.2 AWS/Azure
Review:
private networking
security group/NSG
IAM/managed identity scope
Secrets Manager/Key Vault
RDS/PostgreSQL access
OpenSearch/search access
S3/Blob backup access
CloudWatch/Azure Monitor access
KMS/key management
load balancer exposure
14.3 On-prem/hybrid
Review:
firewall rules
internal CA
TLS/mTLS
proxy inspection
air-gapped registry
patch management
backup media
operator access
hybrid worker connectivity
responsibility boundary
14.4 Internal verification checklist
[ ] Are Camunda UIs private/internal only?
[ ] Are worker pods restricted by NetworkPolicy?
[ ] Are secrets mounted only where needed?
[ ] Are cloud identities least-privilege?
[ ] Are backups encrypted?
[ ] Is on-prem operator access audited?
15. Compliance Evidence Checklist
For an audit/security review, prepare evidence:
[ ] Access matrix for Camunda tools and workflow APIs.
[ ] Role/group/tenant mapping document.
[ ] BPMN/DMN deployment approval trail.
[ ] Process versioning and migration records.
[ ] Task approval audit examples.
[ ] Incident resolution audit examples.
[ ] Manual repair approval examples.
[ ] Variable/data classification list.
[ ] Retention and cleanup configuration.
[ ] Secret management design.
[ ] Worker service account inventory.
[ ] Network diagram for engine/broker/workers/UIs.
[ ] Backup/restore evidence.
[ ] Log redaction policy.
[ ] Security testing result.
Compliance evidence should be reproducible from systems, not assembled manually during audit panic.
16. PR Review Checklist
When reviewing BPMN/worker/API/security-related PR:
[ ] Does the change introduce new process variables?
[ ] Are variables classified for sensitivity?
[ ] Does any variable contain PII/secret/large payload?
[ ] Does the change expose new task/form fields?
[ ] Are task authorization and assignment both correct?
[ ] Does the API enforce tenant and role checks server-side?
[ ] Does the worker use least-privilege credentials?
[ ] Are connector secrets referenced securely?
[ ] Are logs and incidents redacted?
[ ] Are retry/manual repair actions audited?
[ ] Are Kafka/RabbitMQ/Redis payloads safe?
[ ] Is retention affected?
[ ] Is migration/cancel/retry permission affected?
[ ] Are dashboards exposing sensitive variables?
[ ] Is compliance evidence updated?
17. Security Anti-Patterns
Avoid these:
Storing access tokens as process variables.
Returning all variables from status endpoint.
Using task assignment as authorization.
Giving support users global Camunda admin.
Allowing arbitrary message correlation from external clients.
Logging full variable payload.
Putting connector secrets in BPMN XML.
Using one worker credential for all operations.
Missing tenant filter in task/process query.
Leaving DLQ readable by broad engineering group.
Treating history/search index as non-sensitive.
Running manual repair without audit.
Keeping old process data forever because cleanup is scary.
18. Internal Verification Checklist
Use this as the CSG/team-specific security review template:
[ ] Which Camunda version/deployment mode is used?
[ ] Which identity provider is integrated?
[ ] How are roles/groups mapped to task/process permissions?
[ ] Is tenant isolation required? If yes, where enforced?
[ ] Who can deploy BPMN/DMN/forms/connectors?
[ ] Who can start/cancel/migrate/retry process instances?
[ ] Who can view/modify variables?
[ ] Which variables contain PII/commercially sensitive data?
[ ] Are secrets ever stored in BPMN XML, variables, logs, or incidents?
[ ] How are worker credentials stored and rotated?
[ ] How are connector secrets managed?
[ ] Are workflow APIs protected by server-side authZ?
[ ] Are task forms privacy-reviewed?
[ ] Are logs/traces/incidents redacted?
[ ] What is retention for history/search/log/event/DLQ/backups?
[ ] Can compliance evidence be produced quickly?
[ ] Are manual repair actions approved and audited?
19. Key Takeaways
- Workflow systems are security-sensitive because they collect process, task, variable, integration, and operational data in one place.
- Assignment is not authorization.
- Process variables, incidents, logs, and search indexes must be treated as data stores.
- Connector and worker credentials need least privilege and rotation.
- Tenant isolation must be enforced across API, task, process, worker, DB, queue, cache, logs, and dashboards.
- Compliance readiness depends on auditability, retention, evidence, and disciplined manual repair.
Lesson Recap
You just completed lesson 56 in final stretch. Use the series map if you want to review the broader track, or continue directly into the next lesson while the context is still warm.
Continue The Track
Keep the momentum while the lesson is still fresh. Move backward for review or continue forward into the next concept.