Secure application design with high data privacy requirements
summary
Design decisions emphasize concrete controls not slogans for example separate identity from health data and store tokens or join records only when authorized use key managers and use key derivation not millions of stored keys to generate per‑record keys on the fly protect keys with KMS HSM or HashiCorp Vault encrypt at column or table level log access with tokens not raw PI apply de‑identification by either removing the 18 HIPAA identifiers or via expert attestation enforce retention and purge plans, threat model and run vulnerability management and MFA.
AI-written summary · about
chapters (20)
- 0:00Intro
- 0:30Background
- 1:17What we're covering
- 2:46How did we get here?
- 5:50We don't have to...
- 7:59What should we do?
- 9:20Identity Data Management
- 11:32Identity records
- 12:51Live data access
- 16:19Cryptography - data storage
- 17:36Cryptography – practices
- 20:04Cryptography - key considerations
- 23:17Logging and accountability
- 25:55Data de-identification
- 27:27Data retention
- 29:18Basic practices
- 32:53Supply chain management
- 34:51Risk management
- 35:50Future-proofing
- 37:15Resources
related talks
39mBuilding a secure data platform: why good design and security go hand in hand
51mKeynote: Data is a new security boundary
43mSecurity By Design
01h 02mLock That Sh*t Down! Auth Security Patterns for Apps, APIs, and Infra
18mSecuring PHI in the cloud: Best practices in AWS environments
37mAdd security to architecture one step at a time
50mSecure and Privacy by Design Converge with Threat Modeling
24mSafeguarding Sensitive Data Access At Scale with Privacy-Enhancing Technologies