Part 041 — Data Privacy and Compliance

Redis sering diperlakukan sebagai komponen teknis murni: cepat, ephemeral, dan dekat dengan aplikasi. Itu berbahaya.

Dalam sistem enterprise, Redis bisa memegang data yang sama sensitifnya dengan PostgreSQL:

• session identifier
• access token atau refresh token state
• token blacklist
• idempotency response body
• cached quote/order/customer data
• tenant configuration
• user profile fragment
• permission/entitlement cache
• rate limit state berbasis user/IP/tenant
• workflow state sementara
• job payload
• stream payload
• lock key yang mengandung entity identifier

Walaupun Redis digunakan sebagai cache, data di dalamnya tetap data produksi. Kalau key/value mengandung PII, rahasia, token, customer identifier, atau business-sensitive information, Redis harus masuk ke ruang lingkup privacy, security, audit, retention, dan compliance.

Prinsip utamanya:

Ephemeral does not mean non-sensitive.
Cache does not mean out of compliance scope.
Fast does not mean safe.
Temporary does not mean exempt from retention and deletion policy.

1. Core Mental Model

Redis privacy/compliance harus dilihat dari empat lapisan:

Data Classification
  -> Key and Value Design
  -> Access and Retention Control
  -> Operational Evidence

Atau lebih detail:

Java/JAX-RS Request
  -> User / Tenant / Customer Context
  -> Service Layer
  -> Redis Key Construction
  -> Redis Payload Serialization
  -> TTL / Retention Policy
  -> Redis Storage
  -> Logs / Metrics / Traces
  -> Snapshot / Backup / Dump
  -> Debugging / Incident Access
  -> Deletion / Expiry / Rotation

Compliance failure bisa terjadi di setiap titik, bukan hanya di Redis server.

Contoh:

• key name memakai email customer
• value berisi full customer profile tanpa TTL
• idempotency response menyimpan body yang mengandung PII terlalu lama
• debug log mencetak Redis key lengkap
• slowlog atau APM span mencatat command dengan sensitive identifier
• snapshot Redis disimpan di bucket yang aksesnya terlalu luas
• stream payload tidak pernah di-trim
• token blacklist key tidak terenkripsi dan bisa dibaca service lain
• tenant A bisa membaca key tenant B karena key pattern/ACL tidak dibatasi

Redis privacy bukan hanya soal enkripsi. Redis privacy adalah soal minimisasi data, isolasi akses, TTL, observability hygiene, backup hygiene, dan evidence.

2. Data Classification for Redis

Sebelum membuat Redis key, engineer harus bertanya:

Data apa yang masuk Redis?
Apakah data itu PII?
Apakah data itu credential/security state?
Apakah data itu business-sensitive?
Apakah data itu tenant-scoped?
Apakah data itu boleh hilang?
Apakah data itu harus dihapus?
Berapa lama data itu boleh tinggal?
Siapa yang boleh membaca/menulisnya?
Apakah data itu muncul di logs, metrics, backup, atau traces?

Klasifikasi praktis:

Rule senior engineer:

Jika tidak yakin data aman, perlakukan sebagai sensitive sampai diklasifikasi resmi.

3. PII in Redis Key Name

Kesalahan yang sangat umum adalah memasukkan PII langsung ke nama key.

Contoh buruk:

user:john.doe@example.com:session
customer:+6281234567890:quote-cache
tenant:acme:user:jane@corp.example:profile

Masalahnya:

• key name sering muncul di logs
• key name muncul di metrics cardinality/debugging
• key name terlihat saat scanning/debugging
• key name bisa masuk ke slowlog/trace/span attribute
• key name bisa terlihat oleh engineer yang tidak perlu membaca PII
• key name sulit di-redact kalau format bebas

Desain yang lebih aman:

session:{tenantId}:{opaqueUserId}:{sessionIdHash}
quote-cache:{tenantId}:{quoteId}
rate-limit:{tenantId}:{actorHash}:{endpointGroup}

Namun opaqueUserId dan quoteId pun tetap bisa sensitif tergantung kebijakan internal. Jangan otomatis menganggap identifier aman.

Checklist desain key:

• Hindari email, phone, name, address, token, raw IP jika tidak perlu.
• Gunakan opaque internal ID bila diizinkan.
• Hash identifier jika key hanya butuh deterministic lookup.
• Jangan hash dengan cara yang menciptakan false sense of security; unsalted hash dari email masih bisa ditebak.
• Pastikan key format bisa di-redact dengan regex stabil.
• Pisahkan tenant prefix secara eksplisit.
• Dokumentasikan key yang mengandung identifier sensitif.

4. PII in Redis Value

Redis value lebih mudah mengandung data besar:

• JSON cache object
• serialized Java object
• response cache untuk idempotency
• stream entry payload
• job payload
• hash fields
• session attributes

Contoh risk:

{
  "customerName": "Jane Doe",
  "email": "jane@example.com",
  "phone": "+6281234567890",
  "quoteId": "Q-123",
  "price": "199.99",
  "currency": "USD"
}

Pertanyaan desain:

Apakah semua field ini benar-benar dibutuhkan di Redis?
Apakah service bisa cache derived/minimized representation saja?
Apakah value harus encrypted at application layer?
Apakah TTL sesuai retention policy?
Apakah payload bisa muncul di debug logs?
Apakah payload ada di RDB/AOF/snapshot?

Strategi minimisasi:

• Cache hanya field yang dibutuhkan read path.
• Jangan cache full entity jika hanya butuh status dan version.
• Jangan menyimpan raw token; simpan hash/token identifier jika cukup.
• Jangan menyimpan full response idempotency jika response mengandung sensitive data dan replay bisa dilakukan dengan reference.
• Untuk job/stream, simpan reference ID dan ambil detail dari PostgreSQL jika durability/audit lebih tepat di database.

5. Token and Session Data

Redis sering dipakai untuk security state karena TTL native sangat cocok untuk expiring state. Tetapi ini membuat Redis menjadi komponen security-critical.

Use case umum:

• session store
• refresh token state
• access token blacklist
• one-time token
• password reset token
• CSRF token
• login attempt counter
• MFA attempt counter
• device/session registry

Risiko:

• credential exposure jika value menyimpan raw token
• account takeover jika attacker bisa modify session state
• logout/revocation gagal jika Redis unavailable
• TTL salah membuat session terlalu panjang atau terlalu pendek
• key tanpa TTL membuat token state tidak pernah hilang
• shared Redis credential memungkinkan service non-auth membaca security state

Prinsip:

Security state in Redis must be treated as high sensitivity data.

Desain lebih aman:

• Simpan token hash, bukan raw token, jika memungkinkan.
• Gunakan TTL eksplisit untuk semua security state.
• Pisahkan keyspace security dari cache umum.
• Batasi ACL per service/key pattern.
• Jangan log key/value token secara penuh.
• Buat alert untuk key tanpa TTL di security namespace.
• Definisikan behavior saat Redis unavailable: fail closed atau degraded?

Untuk sistem enterprise, keputusan fail-open/fail-closed harus eksplisit. Misalnya:

6. TTL as Retention Control

TTL bukan hanya performance mechanism. TTL adalah retention control.

Tanpa TTL, Redis bisa menyimpan sensitive data lebih lama dari yang dimaksudkan. Dengan TTL terlalu panjang, cache bisa melanggar prinsip minimisasi. Dengan TTL terlalu pendek, sistem bisa gagal secara fungsional.

TTL harus ditentukan dari:

Business Validity
  + Security Requirement
  + Privacy Retention Policy
  + Operational Recovery Need
  + Cost/Memory Constraint

Contoh TTL decision:

Anti-pattern:

redis.set(key, payload); // no TTL

Lebih baik wrapper internal memaksa TTL untuk namespace tertentu:

cache.put(key, payload, ttlPolicy.forQuoteSummary());

Checklist TTL privacy:

• Apakah key sensitive punya TTL?
• Apakah TTL sesuai policy, bukan angka asal?
• Apakah TTL configurable per environment?
• Apakah TTL terlalu panjang dibanding kebutuhan replay/retry?
• Apakah ada alert untuk key tanpa TTL di namespace sensitif?
• Apakah eviction dipahami sebagai deletion tidak terencana, bukan retention mechanism?

7. Deletion and Right-to-Erasure Style Requirements

Untuk data tertentu, expiry pasif tidak cukup. Jika ada kewajiban menghapus data user/customer, Redis harus masuk ke daftar tempat yang perlu dibersihkan.

Masalah umum:

• PostgreSQL record dihapus/anonymized, tetapi Redis cache masih menyimpan value lama.
• Idempotency response masih menyimpan data customer.
• Stream/job payload masih berisi PII.
• Snapshot/backup masih memuat data yang sudah dihapus dari source DB.
• Key tidak bisa ditemukan karena naming tidak terdokumentasi.

Desain yang lebih defensible:

Deletion Request
  -> Source of Truth Update/Delete/Anonymize
  -> Emit Deletion/Invalidation Event
  -> Delete Known Redis Keys
  -> Invalidate Derived Caches
  -> Ensure TTL Bounds for Unenumerable Keys
  -> Record Evidence

Untuk key yang tidak mudah ditemukan, TTL pendek menjadi safety net. Tetapi TTL bukan pengganti deletion mechanism jika requirement mengharuskan deletion eksplisit.

Key design membantu deletion:

customer-cache:{tenantId}:{customerId}
quote-cache:{tenantId}:{quoteId}
user-session:{tenantId}:{userId}:{sessionId}

Kalau key menggunakan hash opaque tanpa index balik, deletion bisa sulit. Perlu trade-off antara privacy key obfuscation dan operational discoverability.

8. Redis Dumps, Snapshots, RDB, AOF, and Backups

Redis data bisa hidup lebih lama dari TTL runtime jika persistence/backup/snapshot diaktifkan.

Data bisa berada di:

• RDB file
• AOF file
• cloud snapshot
• backup bucket/storage account
• imported/exported dump
• disk volume Kubernetes
• on-prem backup storage
• debugging copy
• disaster recovery environment

Pertanyaan compliance:

Apakah Redis persistence aktif?
Apakah snapshot terenkripsi?
Siapa yang bisa mengakses backup?
Berapa lama backup disimpan?
Apakah backup mengandung PII/token/session?
Apakah backup ikut retention policy?
Apakah restore ke lower environment diperbolehkan?
Apakah data dimasking sebelum restore?

Anti-pattern serius:

Production Redis snapshot restored to dev/staging for debugging without masking/access control.

Untuk enterprise system, backup privacy harus masuk ke evidence:

• encryption at rest
• storage access policy
• retention period
• restore authorization
• audit logs
• deletion/anonymization limitation statement
• environment separation

9. Logs, Metrics, Traces, and Redaction

Redis privacy sering bocor bukan dari Redis, tetapi dari observability.

Contoh kebocoran:

DEBUG Redis GET session:tenant-a:user:jane@example.com:abc
TRACE cache miss for customer:+6281234567890
ERROR failed Redis SET quote-cache:tenant-x:customer-name-john-doe

Observability yang aman:

• log key pattern, bukan full key
• hash/redact sensitive segment
• jangan log value
• jangan log token/session/idempotency payload
• jangan menjadikan user/customer ID sebagai high-cardinality metric label tanpa approval
• pastikan APM span tidak capture command argument sensitif

Contoh lebih aman:

cache_miss namespace=quote-cache tenant=tenant-a keyHash=9f2a... reason=not_found
redis_error operation=GET namespace=session tenant=tenant-a error=timeout

Untuk Java/JAX-RS:

• Correlation ID boleh dilog.
• Tenant ID mungkin sensitif tergantung policy.
• User ID/customer ID perlu klasifikasi.
• Redis key sebaiknya direpresentasikan sebagai structured object yang bisa meredact diri sendiri.

Contoh wrapper:

public record RedisKey(String namespace, String tenantId, String entityId, String raw) {
    public String safeForLog() {
        return namespace + ":" + tenantId + ":" + hash(entityId);
    }
}

10. Multi-Tenant Isolation

Dalam sistem CPQ/order management/telco BSS, multi-tenancy sangat mungkin muncul. Redis multi-tenant risk tidak hanya soal data value. Key namespace juga harus tenant-aware.

Risiko:

• key tidak memasukkan tenant ID
• tenant ID berada di value, bukan key
• service bisa membaca semua tenant namespace
• global cache accidentally dipakai untuk tenant-specific data
• cache invalidation tenant A menghapus data tenant B
• rate limiter global menggabungkan tenant berbeda
• lock key tidak tenant-scoped sehingga tenant saling memblokir

Contoh salah:

quote:{quoteId}
pricing-rule:{ruleId}
rate-limit:{userId}
lock:catalog-refresh

Contoh lebih aman:

quote:{tenantId}:{quoteId}
pricing-rule:{tenantId}:{catalogVersion}:{ruleId}
rate-limit:{tenantId}:{actorHash}:{endpointGroup}
lock:{tenantId}:catalog-refresh

Namun tidak semua key harus tenant-scoped. Ada key global yang valid, misalnya:

• global maintenance mode
• global kill switch
• system-wide throttling
• cluster-wide worker coordination

Kuncinya: scope harus eksplisit.

global:maintenance-mode
system:rate-limit:external-provider-x
tenant:{tenantId}:quote:{quoteId}

11. Access Audit

Redis OSS tidak selalu memberi audit trail selevel database enterprise. Managed services juga berbeda-beda kemampuannya. Karena itu evidence sering harus dikumpulkan dari kombinasi:

• infrastructure logs
• cloud audit logs
• Redis ACL/user config
• network security group/firewall rules
• Kubernetes NetworkPolicy
• secret manager access logs
• application logs
• deployment history
• incident/change records

Pertanyaan audit:

Siapa yang bisa connect ke Redis?
Service mana memakai credential apa?
Command apa yang boleh dijalankan?
Key pattern apa yang boleh diakses?
Siapa yang bisa rotate secret?
Siapa yang bisa snapshot/restore?
Siapa yang bisa menjalankan FLUSH/CONFIG/EVAL?
Apakah akses emergency tercatat?

Untuk compliance, jawaban “hanya internal network” biasanya belum cukup. Butuh bukti:

• network boundary
• credential isolation
• role/access mapping
• command restriction
• snapshot access policy
• rotation history
• monitoring/alerting

12. Java/JAX-RS Backend Concerns

Di Java/JAX-RS service, privacy Redis biasanya muncul di beberapa tempat:

Resource Method
  -> Request DTO
  -> Tenant/User Context
  -> Service Method
  -> Cache Key Builder
  -> Serializer
  -> Redis Client
  -> Logger/Metrics/Tracer

Review point:

• Apakah request body sensitif masuk ke idempotency response cache?
• Apakah exception handler mencetak Redis key/value?
• Apakah cache key builder menerima raw email/phone/token?
• Apakah serializer menyimpan field lebih banyak dari yang dibutuhkan?
• Apakah DTO internal berubah lalu cache lama gagal deserialize?
• Apakah TTL ditentukan di call site secara ad hoc?
• Apakah cache wrapper memisahkan namespace sensitive dan non-sensitive?

Pattern yang lebih aman:

Controller should not construct Redis key directly.
Service should not invent TTL casually.
Redis wrapper should enforce namespace policy.
Serializer should use explicit cache DTO.
Logger should use safe key representation.

13. PostgreSQL/MyBatis/JDBC Interaction

PostgreSQL biasanya menjadi source of truth. Redis sering menyimpan derived copy. Privacy issue muncul ketika lifecycle DB dan Redis tidak sinkron.

Contoh:

Customer data updated/anonymized in PostgreSQL
  -> Redis still contains old customer payload

Atau:

Order deleted/hidden in DB
  -> cached order summary remains readable for TTL duration

Atau:

Migration removes sensitive column from table
  -> old cache payload still contains that field

Checklist DB integration:

• Apakah update/delete DB menghapus cache terkait?
• Apakah migration yang mengubah sensitive field juga invalidasi cache?
• Apakah cache DTO lebih kecil dari DB entity?
• Apakah Redis payload menyimpan data yang DB sudah tidak expose?
• Apakah deletion/anonymization workflow mencakup Redis?
• Apakah cache warming setelah deployment tidak mengisi ulang data yang harus dihapus?

Untuk MyBatis/JDBC, hati-hati dengan mapping object langsung ke Redis. Entity persistence model bukan selalu cache model. Lebih aman gunakan DTO khusus cache.

14. Kafka/RabbitMQ Interaction

Event-driven invalidation sering dipakai untuk menjaga Redis tetap sinkron. Namun dari sisi privacy/compliance, event pipeline bisa memperpanjang umur data.

Contoh:

CustomerDeleted event
  -> Consumer deletes Redis customer cache
  -> Failure occurs before delete
  -> Cache remains until TTL

Atau:

QuoteUpdated event contains full quote payload
  -> Consumer writes full payload to Redis projection
  -> Stream/DLQ/log retains payload

Risiko:

• event payload membawa PII
• Redis cache update gagal tetapi event dianggap sukses
• DLQ menyimpan data sensitif lebih lama
• duplicate event menghidupkan kembali cache lama
• out-of-order event menulis versi lama ke Redis

Mitigasi:

• gunakan event version/timestamp
• gunakan idempotent consumer
• gunakan tombstone/deletion event yang menang atas update lama
• minimalkan payload event jika hanya untuk invalidation
• monitor invalidation lag/failure
• pastikan DLQ/failed message retention sesuai privacy policy

15. Kubernetes, AWS, Azure, and On-Prem Concerns

Kubernetes

Periksa:

• Secret Redis credential tidak bocor ke env dump/log.
• NetworkPolicy membatasi akses Redis.
• Pod debug/exec access dikontrol.
• PersistentVolume Redis terenkripsi jika menyimpan sensitive data.
• Backup operator tidak menyalin snapshot ke lokasi tidak aman.
• Lower environment tidak memakai production Redis data.

AWS

Periksa:

• subnet/security group isolation
• encryption in transit/at rest
• AUTH/ACL support sesuai service mode
• CloudWatch metric/log tanpa sensitive label
• snapshot retention/access
• KMS key ownership
• cross-account access

Azure

Periksa:

• private endpoint/VNet integration
• firewall rules
• TLS enforcement
• access key rotation
• Azure Monitor access
• backup/import/export policy
• geo-replication privacy boundary

On-Prem/Hybrid

Periksa:

• firewall dan network segmentation
• TLS certificate lifecycle
• backup storage access
• OS-level access
• patching ownership
• air-gapped export/import process
• hybrid latency dan data residency

16. Failure Modes

16.1 PII appears in Redis key name

Impact:

• logs/metrics/snapshots expose PII
• broad engineer access can reveal user/customer identifiers

Detection:

• sample key scan di non-prod atau production-safe controlled scan
• static analysis key builder
• log search pattern untuk email/phone/token-like string

Fix:

• migrate key format
• delete old key namespace
• redact logs
• add key builder validation

16.2 Sensitive value without TTL

Impact:

• data retained indefinitely
• deletion/anonymization incomplete

Detection:

• sample TTL check per namespace
• Redis keyspace analysis
• wrapper metrics for no-TTL writes

Fix:

• enforce TTL at wrapper level
• backfill expiry if safe
• delete invalid namespace
• update PR checklist

16.3 Snapshot exposes sensitive data

Impact:

• backup becomes privacy breach vector
• lower environment restore leaks production data

Detection:

• audit backup location and access
• review restore history
• inspect data classification for Redis namespace

Fix:

• restrict backup access
• encrypt storage
• rotate credentials if needed
• prohibit raw prod restore to lower env

16.4 Cross-tenant cache leakage

Impact:

• tenant A receives tenant B data
• severe compliance/customer trust incident

Detection:

• cache key missing tenant dimension
• inconsistent tenant context propagation
• suspicious cache hit across tenant boundary

Fix:

• add tenant prefix
• invalidate old global namespace
• add tenant-aware tests
• add ACL/key pattern isolation if possible

16.5 Redis observability leaks sensitive identifiers

Impact:

• logs/APM/metrics become sensitive data stores

Detection:

• log scan for email/phone/token/customer identifiers
• inspect APM Redis spans
• inspect metric labels

Fix:

• redact key/value
• lower span argument capture
• centralize safe key formatter
• rotate logs according to incident policy

17. Production-Safe Debugging

Do not debug privacy-sensitive Redis issues with broad commands like:

KEYS *
MONITOR
HGETALL huge-or-sensitive-key
LRANGE sensitive-list 0 -1
XRANGE sensitive-stream - +

Production-safe approach:

1. Identify namespace from code/config.
2. Confirm data classification.
3. Use sampled SCAN with strict pattern and limit if approved.
4. Inspect TTL/type/memory before value.
5. Avoid printing raw value.
6. Use safe tooling that redacts key segments.
7. Record who accessed what and why for sensitive investigations.

Prefer commands that answer operational questions without exposing value:

TYPE key
TTL key
MEMORY USAGE key
OBJECT ENCODING key
XLEN stream-key
HLEN hash-key
SCARD set-key
ZCARD zset-key

Value inspection should require stronger justification.

18. Trade-Offs

Senior-level decision making means documenting why the trade-off is acceptable.

19. Compliance Evidence Checklist

For Redis systems, useful evidence includes:

• Redis use case inventory
• key namespace documentation
• data classification per namespace
• TTL/retention policy per namespace
• ACL/user/service mapping
• network isolation diagram
• TLS/encryption configuration
• backup/snapshot retention policy
• restore access policy
• logging/redaction rules
• deletion/anonymization workflow
• incident access procedure
• dashboard/alert list
• secret rotation history
• PR/ADR review checklist

Compliance evidence should be maintainable. A stale spreadsheet nobody trusts is not evidence; it is risk disguised as documentation.

20. PR Review Checklist

When reviewing Redis changes, ask:

• What data enters Redis?
• Is it PII, token, tenant data, or business-sensitive?
• Is PII present in key name?
• Is PII present in value?
• Is the key tenant-scoped where needed?
• Does every sensitive key have TTL?
• Is TTL justified by business/security/privacy policy?
• Can the key be deleted during deletion/anonymization workflows?
• Does serialization include more fields than necessary?
• Are logs/traces/metrics redacted?
• Does Redis persistence/backup store this data?
• Are ACL/key pattern restrictions sufficient?
• What happens if Redis is restored from backup?
• What happens during rolling deployment with old cached payload?
• Does event-driven invalidation cover deletion/privacy events?
• Is there observability for stale sensitive cache?

21. Internal Verification Checklist

Verify internally with backend/platform/SRE/security/compliance teams:

• Redis use cases that store PII/security/business-sensitive data.
• Key naming convention and whether PII is forbidden in key names.
• Namespace ownership and data classification.
• TTL policy per namespace.
• Redis persistence, snapshot, backup, and restore policy.
• Whether Redis data is included in deletion/anonymization workflows.
• Whether production Redis snapshot can be restored to lower environments.
• ACL/user/key-pattern separation by service.
• TLS/encryption/network isolation posture.
• Secret rotation and credential ownership.
• Logging/APM/metrics redaction for Redis commands and keys.
• Dashboard and alerts for no-TTL sensitive keys, memory, eviction, and access anomalies.
• Incident procedure for suspected Redis data exposure.
• Compliance evidence location and owner.

22. Practical Rule of Thumb

Use this rule during design review:

If the data would be sensitive in PostgreSQL, it is sensitive in Redis.
If the identifier would be sensitive in an API URL, it is probably sensitive in a Redis key.
If the value would be sensitive in logs, it is sensitive in cache.
If deletion matters in the source of truth, Redis must be part of the deletion story.

Redis is not outside the system boundary. Redis is part of the data processing system.

23. Summary

Redis privacy/compliance is not a separate concern from engineering correctness. It affects:

• key design
• TTL policy
• cache payload design
• idempotency response storage
• session/token handling
• stream/job payload retention
• backup/snapshot policy
• logging and observability
• multi-tenant isolation
• deletion/anonymization workflows
• PR and architecture review

A production-ready Redis design answers not only “is it fast?” but also:

Is it allowed?
Is it minimized?
Is it isolated?
Is it retained only as long as needed?
Is it deletable?
Is it observable without leaking data?
Is the evidence defensible?

That is the privacy/compliance bar for Redis in enterprise backend systems.