Security
Security is foundational, not an afterthought
Orisan Connect was built for healthcare from day one. Every architectural decision — from database encryption to container orchestration — is designed to protect patient data and meet the rigorous requirements of HIPAA.
Encryption at Rest
All PHI columns use AES-256-GCM column-level encryption via cloak_ecto. RDS storage encryption and S3 KMS encryption provide additional layers of protection.
Encryption in Transit
TLS 1.3 enforced on all connections via AWS ALB security policy. HTTP requests are automatically redirected to HTTPS. All vendor API calls use HTTPS with certificate validation.
Immutable Audit Trail
Every data access, modification, and sync operation is recorded in an append-only audit log. Entries contain timestamps, actors, and resource identifiers — never PHI field values.
Serverless Infrastructure
AWS ECS Fargate runs containers without persistent hosts. No SSH access, no OS-level attack surface. Infrastructure is defined as code via Terraform and deployed through AWS CodePipeline.
Credential Vault
Vendor API credentials are stored with AES-256-GCM envelope encryption and managed through a dedicated credential lifecycle. Atomic rotation ensures zero-downtime credential updates.
Network Isolation
Databases and Redis instances reside in private subnets with no public internet access. Security groups restrict traffic to only the necessary service-to-service paths.
Infrastructure
Built on BAA-covered AWS services
Our infrastructure runs exclusively on AWS services covered under a Business Associate Agreement, ensuring every layer of the stack meets HIPAA requirements for safeguarding electronic Protected Health Information.
AWS ECS Fargate
Serverless container orchestration with no persistent hosts, no SSH access, and no OS-level attack surface. Containers are ephemeral and rebuilt on every deployment.
Amazon RDS (PostgreSQL)
Managed database with storage encryption enabled, automated backups with configurable retention, deletion protection, and private subnet isolation. Not publicly accessible.
AWS Secrets Manager
Database credentials, encryption keys, and API secrets are stored in Secrets Manager and injected into containers at runtime. No secrets are hardcoded or stored in environment files.
S3 with KMS encryption
Configuration buckets use AWS KMS server-side encryption, versioning, and a complete public access block. No S3 bucket is publicly accessible.
TLS 1.3 enforcement
The Application Load Balancer enforces ELBSecurityPolicy-TLS13-1-2-2021-06, supporting only TLS 1.3 and 1.2. HTTP requests receive a 301 redirect to HTTPS.
VPC isolation
PostgreSQL and Redis run in dedicated private subnets. Security groups restrict ingress to only the ECS service security group on the required ports (5432, 6379).
Argon2 password hashing
User passwords are hashed with Argon2, the OWASP-recommended algorithm for healthcare applications. A 12-character minimum length is enforced per HIPAA security requirements.
Session-based authentication
Authentication is enforced via on_mount LiveView hooks. Every authenticated route passes through :ensure_authenticated before rendering.
CSRF protection
Cross-Site Request Forgery protection is enabled on all browser routes via Phoenix's built-in :protect_from_forgery plug. CSRF tokens are embedded in every page.
Input validation via Ecto changesets
All user input and vendor API data is validated through Ecto changesets at every trust boundary. Strict type checking, format validation, and enum whitelisting are enforced before data enters the system.
No PHI in browser state
Protected Health Information is never stored in localStorage, sessionStorage, cookies, or phx-value-* HTML attributes. LiveView's server-rendered architecture keeps PHI on the server.
Secure browser headers
Phoenix's :put_secure_browser_headers plug sets X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, and other security headers on every response.
Application
Defense-in-depth at the application layer
Security controls are layered throughout the application. Authentication, authorization, input validation, and output encoding work together to ensure that a single bypass does not compromise patient data.
Data Protection
PHI protection at every layer
Protected Health Information receives multiple layers of protection, from column-level encryption in the database to automatic redaction in application logs.
Column-level encryption
PHI database columns are individually encrypted with AES-256-GCM via cloak_ecto. Encryption and decryption happen transparently in the Ecto schema layer. PHI columns use the _encrypted suffix convention in all migrations.
PHI redaction in logs
PHI is never logged in plaintext. The Compliance.Redactor module sanitizes data structures before they reach Logger output, telemetry events, or error messages. Only opaque UUIDs appear in logs.
UUIDs for all identifiers
Every primary key uses UUIDs, eliminating sequential or guessable identifiers. This prevents enumeration attacks and ensures resource references are opaque to external actors.
Secrets management
All secrets — database credentials, encryption keys, API tokens — are stored in AWS Secrets Manager and injected into containers at runtime. No credentials are hardcoded or committed to version control.
Envelope encryption
Vendor API credentials are stored using envelope encryption. The Cloak vault supports key rotation — new keys can be added without re-encrypting existing data immediately, and a migration path re-encrypts data with the current key.
UTC timestamps, ISO 8601
All timestamps are stored in UTC and formatted as ISO 8601. This ensures consistency across time zones and eliminates ambiguity in audit records and sync timestamps.
Audit & Monitoring
Complete visibility into every data movement
The audit subsystem records every meaningful event in the system, creating an immutable record that satisfies HIPAA audit requirements and enables rapid incident investigation.
Immutable, append-only audit log
Every data access, creation, update, and deletion produces an audit entry. Entries are append-only and cannot be modified or deleted through the application.
Structured audit entries
Every entry records: timestamp, actor (who), action (what), resource_type, and resource_id. PHI field values are never included in audit entries — only identifiers and field names.
Per-record granularity
Bulk sync operations produce individual audit entries for each record processed. This provides full traceability even for high-volume batch operations.
CloudWatch logging
Application logs are shipped to CloudWatch Log Groups with configurable retention periods (30 days in production). Log streams are organized by environment and deployment.
Real-time sync monitoring
The monitoring dashboard provides real-time visibility into sync pipeline status, connection health, and data flow metrics. Sync completions, failures, and conflicts trigger instant notifications.
OAuth 2.0 and API key authentication
Each vendor integration supports the authentication method required by the vendor API — OAuth 2.0 token flows, static API keys, or session-based authentication. Credential types are validated at creation.
Vendor-specific rate limiting
Each vendor has a dedicated rate limiter with tiered impact classification. The rate limiting engine supports peak/off-peak detection, per-endpoint budgets, and automatic backoff on 429 responses.
Proactive token refresh
The credential lifecycle monitors token expiration and triggers refresh before tokens expire. The expiring_soon query identifies credentials approaching expiration so refresh can happen proactively.
Atomic credential rotation
Credential rotation is performed as a database transaction: the credential is marked as rotating, secrets are replaced, and the credential is reactivated — all atomically. A failure at any step rolls back to the original state.
Vendor Connections
Secure integration with every connected system
Every vendor connection is secured with encrypted credential storage, vendor-aware rate limiting, and proactive token management. Credentials are never exposed in logs, error messages, or telemetry.
Reporting Security Vulnerabilities
If you discover a security vulnerability in Orisan Connect, we encourage responsible disclosure. Please report it to our security team and we will respond promptly.
security@orisanconnect.comWant to learn more about our security practices?
Our team is ready to walk you through our security architecture, compliance posture, and how we protect your patient data.