Travel PII ve Passenger Data Boundaries

Travel booking sistemleri search aşamasında anonim çalışabilirken booking ve servicing sırasında passenger identity, contact ve document verisi işlemek zorunda kalabilir. Temel prensip PII'yi domain boyunca taşımak yerine ihtiyaç olan boundary'de açmak olmalıdır.

Data boundary

Passenger data boundary

Mermaid source (.mmd)

Data classes

Ayrı sınıflandırın:

• traveler/passenger name,
• email/phone,
• date of birth,
• nationality,
• passport/identity document,
• loyalty number,
• special service requests,
• payment identifiers,
• booking references.

Hepsi aynı retention ve access policy'ye sahip olmak zorunda değildir.

Token/reference pattern

Search, analytics ve observability katmanına raw passenger record taşımak yerine internal reference kullanın:

passengerProfileRef -> secure vault lookup -> scoped provider payload

Least privilege

Provider adapter yalnız ilgili booking operation için gerekli alanlara erişebilmelidir. Search/ranking service passport veya phone görmemelidir.

Logging

Yasaklanması gereken örnekler:

• full provider request body,
• passport number,
• full email/phone,
• raw payment details,
• auth headers/tokens.

Loglarda booking ID/provider reference gibi operational ID'ler tercih edilmelidir.

Encryption and secrets

PII at-rest ve in-transit protection, secret management ve key rotation altyapının temel parçasıdır. Provider credential ile passenger data aynı config/log surface'inde tutulmamalıdır.

Retention

Retention operation bazlı olmalıdır:

• booking lifecycle ihtiyacı,
• servicing/refund period,
• legal/accounting obligation,
• fraud/dispute handling,
• explicit deletion/anonymization policy.

"Belki lazım olur" retention gerekçesi olmamalıdır.

Analytics boundary

Analytics event'lerinde raw PII yerine:

• market,
• route/destination class,
• booking state,
• provider,
• amount bucket,
• latency gibi business fields kullanılmalıdır.

Support / ops access

Ops ekranları maskelenmiş data göstermeli; sensitive field reveal explicit permission ve audit trail gerektirmelidir.

Failure modes

• PII'nin trace/log'a düşmesi,
• test fixture içinde gerçek passenger data,
• analytics pipeline'a email gönderilmesi,
• cache key'de passport/email,
• provider error body'nin kontrolsüz persist edilmesi,
• backup retention'ın primary DB policy'den uzun olması.

Observability

Privacy/security metrics:

• redaction failure count,
• unauthorized reveal attempt,
• sensitive-field access audit,
• retention deletion failures,
• raw payload persistence detection.

Production checklist

• data classification,
• PII-free search domain,
• secure passenger reference,
• scoped adapter access,
• redaction,
• retention policy,
• masked ops UI,
• audited reveal,
• sanitized fixtures,
• backup/deletion parity.