costos cloud HIPAA

Optimización cloud HIPAA, sin tocar nunca ePHI.

Los equipos de ingeniería healthtech pagan dos veces: una a AWS / GCP / Azure por la carga real, y otra en overhead de compliance reconciliando reportes de costos contra la HIPAA Security Rule. Lumicost trae un evaluador HIPAA real puntuado contra la misma evidencia que usás para optimización de costos — y una postura Limited Use que significa que nunca procesamos ePHI, jamás. Credenciales read-only, audit log tamper-evident y un BAA con scope honesto que le podés pasar a tu privacy officer.

§164.308–.312
Controles HIPAA Security Rule evaluados
0 ePHI
Limited Use — solo metadata + billing
SHA-256
Audit log tamper-evident por registro

La HIPAA Security Rule (45 CFR §164.308 / §164.310 / §164.312) no se preocupa de que vos 'solo estés optimizando costos' — si tu tooling toca sistemas que almacenan, transmiten o procesan ePHI, está in-scope. La mayoría de las herramientas FinOps esquivan el tema y le tiran al cliente la responsabilidad de redactar un BAA one-off y rezar para que el privacy officer firme. La postura de Lumicost es distinta: somos explícitamente Limited Use. Consumimos metadata de configuración cloud (instance shapes, IAM bindings, retention policies) y line items de billing — nunca tráfico de aplicación, nunca contenido de bases de datos, nunca logs que carguen ePHI. Después la plataforma corre un evaluador HIPAA real contra la evidencia recolectada — Information System Activity Review (§164.308(a)(1)(ii)(D)), Workforce Security (§164.308(a)(3)), Information Access Management (§164.308(a)(4)), Security Incident Procedures (§164.308(a)(6)), Evaluation (§164.308(a)(8)), Physical Safeguards (§164.310, delegadas a tus CSPs), Access Control (§164.312(a)), Audit Controls (§164.312(b)), Integrity (§164.312(c)), Person/Entity Authentication (§164.312(d)), Transmission Security (§164.312(e)).

Cómo Lumicost entrega costos cloud HIPAA

Evaluador HIPAA Security Rule real, no un PDF con checkboxes

ComplianceEvaluator.evaluateHipaa() en el backend puntúa 11 controles a través de §164.308 (Administrative Safeguards), §164.310 (Physical Safeguards) y §164.312 (Technical Safeguards) contra la misma recolección de evidencia que potencia SOC 2 e ISO 27001. PASS/FAIL/NEEDS_REVIEW por control con la fila de evidencia exacta que disparó el veredicto — no un PDF con tildes verdes.

Limited Use data handling — nunca procesamos ePHI

Por construcción, Lumicost lee solo metadata de configuración cloud (shapes de EC2, policies de buckets S3, IAM bindings, requests de pods EKS, billing CUR / GCP Billing Export) y nunca toca data planes de aplicación. Sin agente en el cluster, sin shipping de logs, sin queries a bases de datos, sin acceso a contenido de objetos. Nuestras IAM policies excluyen explícitamente `s3:GetObject` y cualquier read del data plane. Tu ePHI nunca sale de tu boundary — ni siquiera en forma de metadata.

Audit log tamper-evident por registro (§164.312(b) Audit Controls)

Cada acción — recomendación aceptada, commitment registrado, SSO toggleado, destino SIEM cambiado — se registra como un AuditEvent append-only con un integrity hash SHA-256 sobre sus campos centrales. Los registros nunca se actualizan ni se borran por código de aplicación. Para inmutabilidad a nivel de cadena, streameá el audit log a Splunk / Datadog / Sumo Logic donde tu policy de retención HIPAA existente lo sella.

Conexiones multi-cloud read-only que pasan una review de InfoSec

WIF en GCP, IAM Role + external-id por tenant en AWS, App Registration en Azure — sin service-account keys, sin credenciales estáticas, sin paths de escritura. Las IAM policies se publican textualmente y son revisables por tu privacy officer antes de firmar. La revocación es one-click desde tu propia consola cloud; perdemos acceso en el siguiente token refresh.

Optimización de costos para los workloads bajo scope §164.308

Rightsizing por pod en EKS / GKE / AKS para los clusters que corren tus workloads de ePHI, amortización de RI / Savings Plan / CUD que no desaparece cuando te ves forzado a hacer lift-and-shift cross-region por motivos de residencia, detección de anomalías sobre los line items que importan de verdad (RDS, KMS, CloudHSM, dedicated tenancy). Los ahorros viven sobre el mismo dataset que la evidencia — una review de InfoSec, una conversación de BAA.

Preguntas frecuentes

¿Firman BAA, y cuál es el scope?+

Sí — firmamos un Business Associate Agreement con scope acotado a metadata de infraestructura solamente. Como Lumicost es Limited Use por diseño (nunca recibimos, almacenamos ni transmitimos ePHI), el BAA codifica esa postura: somos un business associate de tu covered entity para el propósito de análisis de configuración cloud y billing, y reconocemos las obligaciones §164.308 / §164.310 / §164.312 que aplican a la metadata que sí guardamos (retención de audit log, access control, transmission security). Pedinos el BAA estándar — es un documento corto porque el scope es intencionalmente angosto.

¿Qué controles HIPAA chequea efectivamente el evaluador?+

Once controles de la Security Rule: §164.308(a)(1)(ii)(D) Information System Activity Review, §164.308(a)(3) Workforce Security, §164.308(a)(4) Information Access Management, §164.308(a)(6) Security Incident Procedures, §164.308(a)(8) Evaluation, §164.310 Physical Safeguards (delegadas a tu CSP bajo su lista de servicios HIPAA-eligible), §164.312(a) Access Control, §164.312(b) Audit Controls, §164.312(c) Integrity, §164.312(d) Person or Entity Authentication, §164.312(e) Transmission Security (TLS 1.2+ en el edge). Cada control devuelve PASS / FAIL / NEEDS_REVIEW con la fila de evidencia subyacente.

Si no ven ePHI, ¿cómo pueden optimizar costos sobre workloads que sí la manejan?+

La optimización corre sobre metadata de shape y utilización, no sobre el dato adentro. Vemos que una instancia RDS está provisionada en db.r6i.4xlarge con 60% de headroom de CPU sobre 14 días — no vemos qué hay almacenado adentro. Vemos que una task de Fargate pide 4 vCPU pero usa 0.6 vCPU p95 — no leemos el filesystem del container. Las recomendaciones son PR-ready (diff de Terraform, cambio de instance family) y tu equipo las aplica en su propio pipeline. La señal de optimización es completamente separable del payload protegido.

Estamos también bajo HITRUST CSF — ¿la evidencia traduce?+

Sí. Las mismas filas de evidencia que satisfacen los controles HIPAA §164.308 / §164.310 / §164.312 también mapean limpio a las categorías HITRUST CSF v11 (Information Protection Program, Endpoint Protection, Configuration Management, Access Control, Audit Logging & Monitoring). La atestación HITRUST no es una certificación que emita Lumicost — es algo que tu organización persigue — pero nuestra recolección de evidencia más el audit log tamper-evident le dan a tu assessor todo lo que necesita para los controles de infraestructura cloud in-scope.

¿Listo para empezar a ahorrar?

Conecta credenciales solo lectura y obtén tus primeros insights en 24 horas.