Data Security

Three independent layers of encryption protect health data — at the disk, column, and transport levels — so PHI is never exposed in clear text.

🔐

Encryption Architecture

Defence-in-depth: three independent encryption layers

💾

Layer 1 — Encryption at Rest

Amazon Aurora storage is encrypted using AWS KMS with a Customer Managed Key (CMK). The key is rotated annually and access is governed by KMS key policies scoped to the CareSphere IAM role.

  • AES-256-GCM via AWS KMS CMK
  • Annual automatic key rotation
  • S3 backups encrypted with the same CMK
  • EBS volumes encrypted at block level
🔑

Layer 2 — Column-Level PHI Encryption

Sensitive PHI columns are stored as BYTEA and encrypted individually with pgp_sym_encrypt (pgcrypto). The application PHI key is held in AWS Secrets Manager — never in source code.

  • AES-256 symmetric encryption per column
  • Key loaded from Secrets Manager at startup
  • Decrypted only at query time — never written back
  • Minimum-necessary: only required columns decrypted per query
🌐

Layer 3 — Encryption in Transit

All network communication — API, database, IoT — is protected by TLS 1.2 or higher. Unencrypted connections are rejected at the database and load-balancer level.

  • TLS 1.2+ on all API endpoints (HTTPS)
  • rds.force_ssl = 1 — plaintext DB connections rejected
  • MQTT over TLS for ESP32 IoT sensors
  • HSTS enforced on all web properties
🗂️

Database Schema Isolation

PHI is physically separated from application data at the schema level

caresphere schema

Non-PHI operational data: facilities, users (login credentials only), roles, sessions, staff profiles, certifications, calendars, inventory, and alerts. Accessible by the application database role.

phi schema

Protected Health Information: resident records, clinical profiles, vitals, ADL scores, mood logs, care notes, incidents, and staff PII. Access is REVOKEd from application roles by default — only role_phi_rw and role_phi_ro can access.

med schema

Medication records including MAR (Medication Administration Records), inventory, and controlled substance waste logs. Separate schema enforces that medication data is never inadvertently exposed by general queries.

audit schema

Immutable event log. Application roles have INSERT only — UPDATE and DELETE are never granted. SIEM tools access via dedicated role_audit_read with SELECT only. No PHI is stored here — only metadata.

⚠️
Schema-level REVOKE REVOKE USAGE ON SCHEMA phi FROM PUBLIC is executed at database creation time. No PostgreSQL role can access PHI tables unless explicitly granted role_phi_rw or role_phi_ro. This is enforced at the database engine level, not just the application layer.
🏷️

18 HIPAA PHI Identifiers Protected

Every identifier defined by 45 CFR §164.514(b) is encrypted in CareSphere

# HIPAA Identifier CareSphere Field(s) Protection
1Namesphi.residents.first_name, last_name, phi.staff_pii.first_nameBYTEA [ENC]
2Geographic dataphi.staff_pii.address, city, zip_postalBYTEA [ENC]
3Dates (except year)phi.residents.date_of_birth, admission, discharge datesBYTEA [ENC]
4Phone numbersphi.resident_contact_info.phone, phi.staff_piiBYTEA [ENC]
5Fax numbersContact info tablesBYTEA [ENC]
6Email addressesphi.staff_pii.registry_emailBYTEA [ENC]
7Social security / SIN numbersphi.staff_pii.sin_ssn, last_four_ssnBYTEA [ENC]
8Medical record numbersphi.residents.mrnBYTEA [ENC]
9Health plan beneficiary numbersResident health profileBYTEA [ENC]
10Account numbersFinancial records (when applicable)BYTEA [ENC]
11Certificate / license numbersphi.staff_pii.license_number, ncsbn_idBYTEA [ENC]
12Vehicle / serial numbersNot applicable to CareSphereN/A
13Device identifiersIoT device IDs are non-PHI sensor IDsNon-PHI
14Web URLsNot stored with PHIN/A
15IP addressesaudit.login_events.ip_address — audit only, INET typeAUDIT ONLY
16Biometric identifiersNot collectedN/A
17Full-face photographsphi.residents.photo_s3_key — S3 path is itself encryptedBYTEA [ENC]
18Any other unique identifierAll unique identifiers are reviewed; PHI status applied on discoveryPOLICY
🗝️

Key Management

Encryption keys never reside in source code or environment files in production

AWS KMS Customer Managed Key (CMK)
Used for Aurora storage encryption and S3 backups. Rotated annually. Access restricted to the CareSphere IAM role via key policy.
KMS MANAGED
PHI Column Encryption Key
Stored in AWS Secrets Manager. Resolved by the API at startup via utils/secrets.py. Never logged or included in error responses.
SECRETS MANAGER
JWT Signing Keys
Local auth: HS256 secret from Secrets Manager. Cognito SSO: RS256 JWKS from Cognito's public endpoint, verified on every request.
ROTATABLE
IoT Device Certificates
ESP32 nodes use X.509 certificates issued by AWS IoT Core CA. Certificates are device-unique and revocable independently.
X.509 / AWS IoT CA