Part 040 — Security and Sensitive Data

1. Core mental model

A workflow engine is a data amplifier.

It does not only execute process logic. It also copies, stores, indexes, logs, displays, retries, exports, and exposes operational views of process data.

That means every process variable, task form field, error message, incident note, connector configuration, worker log, and audit trail can become a security or privacy risk.

For CPQ/order-management systems, sensitive data may include:

• customer identifiers;
• account identifiers;
• quote values;
• discounts;
• contract terms;
• commercial approval notes;
• order payloads;
• telecom service details;
• fallout reason;
• manual intervention comments;
• external system responses;
• personally identifiable information;
• API credentials by mistake;
• internal topology details;
• stack traces;
• tenant/customer boundary.

Senior rule:

Treat workflow runtime data as production business data, not as temporary orchestration metadata.

2. Sensitive data surfaces

Sensitive data can appear in many places:

Security review must follow the data, not just the application boundary.

3. Variable security principle

Process variables should contain the minimum data needed to advance the process.

Avoid using variables as:

• a full order document store;
• an API response archive;
• a quote pricing cache;
• a user profile cache;
• a credential store;
• an error dump;
• a replacement for PostgreSQL business tables;
• a cross-service payload bus.

Safer variable pattern:

{
  "quoteId": "Q-12345",
  "tenantId": "TENANT-A",
  "approvalType": "DISCOUNT_EXCEPTION",
  "correlationId": "corr-abc",
  "approvalDecision": "PENDING"
}

Risky variable pattern:

{
  "quoteId": "Q-12345",
  "customerFullProfile": {...},
  "fullPricingBreakdown": {...},
  "oauthToken": "...",
  "externalApiRawResponse": {...},
  "stackTrace": "..."
}

A variable should be easy to answer:

• why does the process need this value?
• who can see it?
• how long is it retained?
• is it needed after completion?
• can it be reconstructed from authoritative business tables?
• will it appear in incidents, history, exports, or logs?

4. Data classification for workflow variables

Classify variables before modelling process payload.

5. Sensitive process variable failure modes

6. Task forms and human-entered data

Human task forms create sensitive data because people type explanations, exceptions, and comments.

Common risks:

• operator types customer PII in free-text comment;
• approver writes commercial rationale in visible task field;
• fallout note includes credential, phone number, or address;
• save-draft stores incomplete sensitive data;
• task history retains form data longer than allowed;
• task search indexes form fields;
• screenshot/export of tasklist leaks data.

Design guidance:

• use structured fields where possible;
• constrain free text;
• add UI guidance for what not to enter;
• separate internal note from customer-visible note;
• classify form fields;
• redact or suppress sensitive fields in list/search views;
• apply field-level authorization if needed;
• audit who entered/edited form data;
• define retention policy for draft and completed data.

7. Incident and error data hygiene

Incidents are operational evidence, but they can leak data.

Do not put raw sensitive payload into:

• exception message;
• worker failure reason;
• incident message;
• BPMN error message;
• variable named errorDetails;
• log message;
• tracing span attributes.

Prefer structured error classification:

{
  "errorCode": "ORDER_VALIDATION_TIMEOUT",
  "errorCategory": "DOWNSTREAM_TIMEOUT",
  "retryable": true,
  "externalSystem": "ORDER_VALIDATION",
  "correlationId": "corr-abc"
}

Avoid:

{
  "error": "HTTP 500 while calling https://... with token ... payload {...customer...} stacktrace ..."
}

Incident detail must support debugging without becoming a data dump.

8. Secret management for connectors

Connector configuration is a common secret leak path.

Rules:

• never hardcode API keys, bearer tokens, passwords, or OAuth endpoints in BPMN XML;
• use connector secret references where supported;
• restrict who can edit connector templates/configuration;
• restrict who can view deployed BPMN XML if it contains sensitive endpoints;
• avoid exposing all environment variables as connector secrets;
• rotate connector secrets;
• audit connector config changes;
• validate connector logs do not print secret values.

Connector review questions:

• which secret provider is used?
• are secret names environment-specific?
• can modelers see secret values or only references?
• can a connector call arbitrary external URL?
• is egress restricted?
• are OAuth token endpoints protected?
• are connector failures redacted?
• is connector runtime isolated from other workloads?

9. Worker credential security

Workers are privileged because they can create side effects.

A worker may:

• read process variables;
• call external APIs;
• write PostgreSQL business tables;
• publish Kafka/RabbitMQ events;
• write Redis keys;
• complete jobs;
• fail jobs;
• throw BPMN errors;
• update variables;
• correlate messages.

Credential requirements:

• unique service identity per worker family;
• least privilege API scopes;
• least privilege DB permissions;
• scoped Kafka/RabbitMQ permissions;
• environment isolation;
• secret rotation;
• no credentials in logs;
• no credentials in process variables;
• no shared admin token;
• auditable worker deployment identity.

Bad worker model:

all workers use one global token with broad Camunda + DB + messaging access

Better worker model:

order-validation-worker-prod
  -> can activate only order-validation jobs
  -> can call only required downstream endpoint
  -> can update only required DB tables
  -> can publish only required event type/topic
  -> has rotated secret from approved secret manager

10. TLS, mTLS, OAuth, and OIDC

Workflow systems usually cross multiple boundaries:

browser/user -> Tasklist/custom UI -> backend API -> Camunda API
worker -> Camunda gateway/API
worker -> downstream service
connector runtime -> external API
Camunda component -> database/search

Security controls to verify:

• TLS for all external and internal traffic where required;
• mTLS where service identity must be strongly bound;
• OAuth/OIDC for user and service authentication;
• JWT validation in custom APIs;
• token audience/scope validation;
• token expiry and rotation;
• no bearer token in query parameter;
• no token in logs;
• private endpoints for internal services;
• ingress authentication for operational UIs;
• certificate rotation plan;
• on-prem/internal CA compatibility;
• cloud managed identity/IAM where used.

Do not assume network-private equals secure. Internal operators, support systems, and compromised workloads can still access internal endpoints.

11. Camunda 7 security considerations

Camunda 7 security review should cover:

• whether REST API is exposed;
• whether authentication protects REST API;
• whether authorization checks are enabled/configured;
• whether Cockpit/Tasklist/Admin are exposed;
• whether embedded engine APIs bypass user-level authorization;
• whether Java delegates log variables;
• whether external task workers use safe credentials;
• whether history level stores sensitive data;
• whether history cleanup aligns with retention policy;
• whether database access is restricted;
• whether process application deployment can include malicious delegate code;
• whether classpath/delegate loading is controlled.

Critical embedded-engine question:

Can any internal Java code call RuntimeService/TaskService without passing through domain authorization?

If yes, security depends heavily on code review and service boundary discipline.

12. Camunda 8 security considerations

Camunda 8 security review should cover:

• Identity/access control configuration;
• Orchestration Cluster authorization;
• Tasklist authorization;
• Operate/Admin access;
• Zeebe gateway/API authentication;
• worker client credentials;
• connector secrets;
• Elasticsearch/OpenSearch exposure;
• exporter data visibility;
• backup and snapshot protection;
• multi-tenant authorization;
• Kubernetes secret management;
• ingress and network policy;
• OAuth/OIDC integration;
• component version compatibility.

Important operational point:

Securing Zeebe job activation is not enough.
Operate, Tasklist, Admin, exporters, search, backups, and custom APIs are also data access paths.

13. PostgreSQL and history retention

For Camunda 7, runtime/history tables can contain sensitive process data. For Camunda 8, exported/search data and component stores can also contain workflow data.

Review points:

• history level;
• variable serialization;
• byte array payloads;
• incident/error detail tables;
• task/comment history;
• history cleanup policy;
• partitioning/archiving strategy;
• DB backups;
• read-only analyst access;
• DBA/support access;
• retention vs audit requirements;
• deletion/anonymization requirement;
• schema migration impact.

Do not rely on application-layer redaction if the DB/search index retains raw values.

14. Kafka/RabbitMQ data security

Workflow integration with messaging introduces data propagation risk.

Kafka/RabbitMQ review:

• do events include PII or full order payload?
• are topics/queues tenant-separated or authorization-controlled?
• are messages encrypted in transit?
• are brokers authenticated/authorized?
• can consumers replay sensitive historical data?
• are DLQs protected?
• are retry topics/queues retaining payloads longer than expected?
• is schema registry access controlled?
• are event logs used as audit or payload archive?
• are redaction and deletion requirements compatible with immutable logs?

Recommended pattern:

event contains IDs + minimal state + correlation metadata
consumer loads authorized details from business service if needed

15. Redis data security

Redis is often treated as temporary, but temporary data still leaks.

Review:

• keys contain tenant/customer/order IDs?
• values contain task payload or PII?
• TTL exists and is appropriate?
• eviction policy can remove security-critical idempotency keys?
• Redis AUTH/TLS/network isolation enabled?
• backups/snapshots protected?
• cache keys tenant-scoped?
• authorization decision cache invalidated?
• logs/monitoring expose keys/values?

Avoid storing process variable snapshots in Redis unless retention, authorization, and invalidation are clear.

16. Kubernetes/cloud/on-prem secret handling

Workflow systems often run in Kubernetes and cloud/on-prem hybrid environments.

Verify:

• Kubernetes Secret usage;
• external secret manager integration;
• secret mounted only into required pods;
• no secret in ConfigMap;
• no secret in Helm values committed to Git;
• no secret in BPMN/DMN/form files;
• no secret in CI/CD logs;
• no secret in container image;
• sealed secret / external secrets flow if used;
• service account binding;
• pod security context;
• network policy;
• ingress TLS;
• private endpoint;
• cloud IAM / managed identity;
• on-prem vault/internal CA;
• break-glass secret access audit.

GitOps warning:

GitOps gives excellent deployment traceability, but it also makes accidental secret commits very durable.

17. Logging, metrics, and tracing hygiene

Observability can become a data leak.

Logging rules:

• never log all variables blindly;
• never log full task form payload;
• never log bearer token/API key/password;
• never log raw external API response if it may contain PII;
• prefer IDs, error codes, and correlation IDs;
• redact known sensitive fields;
• structure logs for filtering;
• enforce log retention policy;
• restrict log access.

Metrics rules:

• do not use customer ID as high-cardinality label;
• do not use quote/order ID as metric label;
• do not use user email as metric label;
• prefer aggregate labels: process key, job type, environment, error category;
• protect dashboards with appropriate role.

Tracing rules:

• do not put payload in span attributes;
• include correlation ID, process instance key, job type;
• redact request/response bodies;
• consider sampling sensitive flows differently.

18. Audit trail design

Engine history is useful, but it may not be sufficient business audit.

Business audit should answer:

• who initiated the process?
• who approved/rejected?
• what decision was made?
• what business object was affected?
• what version of process/decision model was used?
• what tenant/customer scope applied?
• what data was visible at decision time?
• was this manual repair, automatic retry, or normal completion?
• which external event triggered the transition?
• which worker/service account performed side effects?

Do not confuse:

technical history = engine events
business audit    = domain evidence

For regulated business processes, you usually need both.

19. Data retention and deletion

Workflow data has multiple retention clocks:

• active runtime data;
• completed process history;
• task history;
• incident history;
• logs;
• metrics;
• traces;
• search index;
• backups;
• Kafka/RabbitMQ retention;
• Redis TTL;
• business audit tables;
• exported reports/dashboards.

Review questions:

• How long should process history be kept?
• Is retention driven by audit, support, legal, or privacy?
• Can sensitive variables be deleted/anonymized while retaining audit evidence?
• Do backups retain data longer than primary DB?
• Does search index cleanup match DB cleanup?
• Can old logs expose deleted data?
• Can DLQ/retry topics retain payload after primary cleanup?
• What is the customer/tenant deletion story?

20. Failure modes

21. Debugging sensitive data incident

Use this sequence:

1. Identify data category: secret, PII, commercial, tenant, internal topology.
2. Identify original source: variable, form, worker, connector, event, DB.
3. Identify propagation path: history, search, logs, traces, dashboards, backups.
4. Identify who could access it.
5. Identify whether data was exported, replayed, or cached.
6. Stop further propagation.
7. Rotate credential if secret was exposed.
8. Redact/delete where possible.
9. Patch modelling/worker/API/logging behavior.
10. Add regression test or static check.
11. Record audit/compliance evidence.

Do not fix only the UI symptom. The same data may already exist in history tables, search indexes, logs, backups, and DLQs.

22. Secure design checklist

Variables

• Store only minimal workflow state.
• Keep large/sensitive payload in authorized business storage.
• Never store secrets as process variables.
• Classify variables by sensitivity.
• Avoid logging variables wholesale.
• Define retention and cleanup.

Forms and tasks

• Classify form fields.
• Restrict sensitive fields.
• Limit free-text fields.
• Audit decision fields.
• Redact task list/search fields.
• Define draft retention.

Incidents and errors

• Use error codes/categories.
• Redact exception messages.
• Avoid raw API response in incident detail.
• Restrict incident visibility.
• Audit retry/repair action.

Secrets and credentials

• Use secret manager / connector secrets.
• Do not commit secrets in BPMN/XML/Helm values.
• Scope worker credentials.
• Rotate credentials.
• Restrict secret mount to required pods.
• Audit secret access.

Observability

• Redact logs.
• Avoid sensitive metrics labels.
• Avoid payload in traces.
• Restrict dashboard access.
• Align log retention with data policy.

Integration

• Keep Kafka/RabbitMQ payload minimal.
• Protect DLQ/retry topics.
• Secure Redis keys/values/backups.
• Validate tenant/correlation metadata.
• Avoid event payload as data archive.

23. Internal verification checklist

Verify in CSG/team context before assuming anything:

• Which process variables exist in actual BPMN models.
• Whether variables include PII, commercial data, raw order payload, or credentials.
• Whether task forms store sensitive free-text data.
• Whether Tasklist/Operate/Cockpit exposes sensitive fields.
• Whether incident details include raw payload/stack traces.
• Whether worker logs print variables or external API payloads.
• Whether connector secrets are used correctly.
• Whether secrets are stored in vault/secret manager/Kubernetes Secret/CI variables.
• Whether any BPMN/DMN/form/Helm/GitOps artifact contains secret-like values.
• Whether worker credentials are scoped and rotated.
• Whether TLS/mTLS/OAuth/OIDC is used for Camunda APIs and workers.
• Whether Camunda 7 history cleanup or Camunda 8 export/search retention is configured.
• Whether PostgreSQL/search backups retain workflow data.
• Whether Kafka/RabbitMQ topics/queues carry sensitive payload.
• Whether Redis stores task/process/customer-sensitive data.
• Whether logs, metrics, traces, and dashboards have redaction/access control.
• Whether tenant/customer data is isolated in observability tools.
• Whether data deletion/anonymization has a workflow-specific runbook.
• Whether security review is part of BPMN/DMN/worker PR review.
• Whether compliance evidence exists for workflow approvals and repairs.

24. Senior engineer heuristics

Use these rules in architecture and PR review:

1. A process variable is not harmless. It may be stored, indexed, logged, exported, and retained.
2. IDs beat payloads. Store references; fetch sensitive details from authorized services.
3. Secrets never belong in BPMN XML. Use secret references and secret managers.
4. Incident messages must be debug-friendly but data-poor. Prefer codes and correlation IDs.
5. Human task comments are dangerous. Free text tends to collect PII and sensitive context.
6. Logs are production data stores. Treat them as sensitive retention systems.
7. Search indexes need privacy review. They often outlive and out-expose primary runtime data.
8. Worker credentials are blast-radius controls. Scope them like privileged service accounts.
9. Backups are part of retention. Deletion is incomplete if backups keep raw data indefinitely.
10. Camunda security is not enough by itself. Custom APIs, DB, queues, Redis, Kubernetes, cloud, and observability must align.

25. Official documentation anchors

Use these as starting points, then verify exact deployed version:

• Camunda 8 connector secrets and connector configuration.
• Camunda 8 REST connector secret guidance.
• Camunda 8 Administration API authentication.
• Camunda 8 Identity/access control and authorization documentation.
• Camunda 7 securing guide.
• Camunda 8 self-managed secret management and TLS/OAuth deployment guidance.

Security behavior is deployment-specific. Always verify actual version, configuration, topology, and internal policy.