---
title: "Vai Supabase ir HIPAA saderīgs? Ko BAA atstāj jums"
description: "Supabase paraksta BAA Team plānā ar HIPAA add-on. Desmit pienākumi paliek jums, no PITR līdz savienojumu žurnālam. Kurus var redzēt bezmaksas pārbaude."
url: "https://madsalt.tech/lv/blog/is-supabase-hipaa-compliant/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/lv/about/"
language: "lv"
published: 2026-11-03
---

# Vai Supabase ir HIPAA saderīgs? Ko BAA atstāj jums

Īsumā

Jā, hostētais Supabase var glabāt veselības datus: tas paraksta Business Associate Agreement (BAA) Team plānā un augstākos, kad ir ieslēgts HIPAA add-on. Pašhostētais Supabase nav iekļauts. BAA nekonfigurē jūsu projektu. Supabase kopīgās atbildības modelis (shared responsibility model) uzskaita desmit pienākumus, kas paliek jums, tostarp point-in-time recovery, SSL izpildi, tīkla ierobežojumus un Postgres savienojumu žurnālēšanu. No šiem desmit mans bezmaksas Supabase pārbaudītājs tieši atzīmē 3, tikai daļēji 2, bet pārējos 5 neredz.

Esmu Denys, full-stack un AI inženieris, un lielākā daļa lietotņu, ko veidoju vai labāju, darbojas uz Supabase. Kad veselības vai labsajūtas lietotne jautā, vai drīkst izmantot Supabase, godīgā atbilde ir divās daļās: ko Supabase paraksta un ko jums joprojām jāieslēdz pašam. Šis raksts iet tādā secībā, pēc paša Supabase dokumentiem, lasītiem 2026. gada 29. oktobrī.

## Vai Supabase ir HIPAA saderīgs?

Hostētā platforma ir. Supabase [HIPAA compliance guide](https://supabase.com/docs/guides/security/hipaa-compliance) norāda, ka tas darbojas kā business associate klientiem, kas apstrādā Protected Health Information (PHI), ir parakstījis BAA ar saviem piegādātājiem, kuri var piekļūt šiem datiem, piemēram, AWS, un ka tā HIPAA kontroles tiek auditētas katru gadu tajā pašā audita periodā kā SOC 2. HIPAA projekti saņem arī visas SOC 2 kontroles, kas ir pārējai platformai.

Tajā pašā ceļvedī ir divi ierobežojumi. Pašhostētais Supabase šīs kontroles nesaņem uzreiz, un HIPAA atbilstība tur ir jūsu un jūsu auditora ziņā. Un BAA sedz tikai Supabase daļu: ceļvedis jūsu pienākumos min HIPAA Privacy, Security un Breach Notification Rules ievērošanu, BAA parakstīšanu un jūsu HIPAA projektu konfigurēšanu tā, kā to norāda Security Advisor.

## Kas nepieciešams, pirms glabājat PHI?

No [HIPAA projects lapas](https://supabase.com/docs/guides/platform/hipaa-projects) un [shared responsibility model](https://supabase.com/docs/guides/deployment/shared-responsibility-model):

1. **Team plāns vai augstāks.** Zemākos plānos BAA nav pieejams.
2. **HIPAA add-on un parakstīts BAA.** Abus pieprasāt no Supabase; add-on tiek ieslēgts organizācijai.
3. **High Compliance katrā projektā.** Kad add-on ir ieslēgts, projektu General Project Settings var atzīmēt kā High Compliance. Kopš tā brīža Supabase šim projektam nepārtraukti veic papildu pārbaudes, un neatbilstošs iestatījums parādās kā brīdinājums Security Advisor.

Security Advisor brīdina, bet nelabo. Supabase ceļvedis to saka tieši: ieteikto kontroļu piemērošanas atbildība gulstas uz klientu.

## Kādi iestatījumi vajadzīgi HIPAA projektam?

Šis ir pilns saraksts no shared responsibility model, ar vietu, kur katrs atrodas, un norādi, vai bezmaksas [Supabase drošības pārbaude](https://madsalt.tech/lv/tools/supabase-security-check/) to var redzēt. Pārbaudītājs nolasa projektu caur Supabase Management API pēc pieteikšanās ar Supabase, tāpēc tas redz iestatījumus, nevis līgumus.

| Jūsu pienākums saskaņā ar BAA                  | Kur tas atrodas                                              | Bezmaksas pārbaudītājs                                      |
| ---------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------- |
| Parakstīt BAA, Team plāns vai augstāks         | Līgums ar Supabase                                           | Neredz                                                      |
| Atzīmēt projektus kā HIPAA, labot brīdinājumus | General Project Settings, Security Advisor                   | Daļēji: rāda katru Security Advisor lint, ko saņem          |
| MFA katram Supabase kontam, obligāts           | Organization settings                                        | Neredz                                                      |
| Point-in-time recovery (PITR)                  | Database → Backups, vajag nelielu compute add-on             | Daļēji: izturēs arī ar ikdienas rezerves kopijām vien       |
| SSL izpilde                                    | Database Settings → SSL Configuration                        | Atzīmē: "SSL not enforced on database connections"          |
| Tīkla ierobežojumi                             | Database Settings → Network Restrictions                     | Atzīmē: "Database open to every IP address"                 |
| Postgres savienojumu žurnālēšana ieslēgta      | `log_connections`, jaunos projektos pēc noklusējuma izslēgts | Neredz                                                      |
| Šifrēšana saskaņā ar HIPAA Security Rule       | Supabase šifrē miera stāvoklī un pārsūtīšanā                 | Neredz; šifrēšana lietotnes līmenī ir jūsu izvēle           |
| Nekādu PHI publiskos Storage buckets           | Storage → bucket settings                                    | Atzīmē katru publisko bucket; vai tajā ir PHI, spriežat jūs |
| Nekādas pārsūtīšanas uz organizāciju bez HIPAA | Project transfer                                             | Neredz                                                      |

![Supabase 10 HIPAA pienākumi: ko redz bezmaksas pārbaude. Pienākumi no Supabase shared responsibility model. Atzīmē pārbaudītāja noteikums: 3; Redzams tikai daļēji: 2; Pārbaudītājam neredzams: 5.](https://madsalt.tech/charts/lv/is-supabase-hipaa-compliant.svg)

*1. attēls. Supabase shared responsibility model, lasīts 2026. gada 29. oktobrī, pret mana bezmaksas Supabase pārbaudītāja noteikumiem.*

## Ko bezmaksas pārbaude nepamana?

Trīs robus vērts izskaidrot, jo zaļš rezultāts var izskatīties pēc vairāk, nekā tas ir.

**Ikdienas rezerves kopijas nav PITR.** Pārbaudītāja rezerves kopiju noteikums iziet, ja projektam ir point-in-time recovery vai vismaz viena rezerves kopija. Maksas projekts ar ikdienas kopijām un bez PITR to iztur. HIPAA projektiem vajag tieši PITR, tāpēc paši apskatiet Database → Backups; PITR vajag vismaz nelielo compute add-on. Ko glabā katrs plāns un kā izskatās atjaunošanas tests, ir piezīmē Supabase backups.

**Divi dažādi MFA iestatījumi.** Pārbaudītāja "No multi-factor method enabled" attiecas uz jūsu lietotnes lietotājiem: vai Supabase Auth viņiem piedāvā otru faktoru. HIPAA pienākums attiecas uz cilvēkiem, kas var atvērt jūsu Supabase dashboard: MFA katram organizācijas kontam, ieviests kā prasība. Vajag abus, un tie tiek ieslēgti dažādās vietās.

**Savienojumu žurnālēšana.** Supabase jaunos projektos iestata `log_connections` uz izslēgtu, un HIPAA projektiem tam jābūt ieslēgtam audita pēdai. Pārbaudītājam nav noteikuma, kas to nolasa. SQL editorā `show log_connections;` atbild vienā rindā, un Security Advisor High Compliance projektā par to brīdina.

Pārbaudītājs rāda katru lint, ko atgriež Security Advisor, gan kļūdas, gan brīdinājumus. Es to neesmu palaidis High Compliance projektā, tāpēc nevaru apstiprināt, ka HIPAA brīdinājumi nonāk tajā pašā sarakstā. Lasiet tos dashboard jebkurā gadījumā.

## Ko HIPAA iestatījumi nesedz

Neviens no desmit pienākumiem nepiemin Row Level Security. HIPAA projekts ar visiem iepriekš minētajiem iestatījumiem joprojām var atdot pacientu tabulu ikvienam, kam ir publiskā atslēga, ja tabulai RLS ir izslēgts vai politika ļauj visas rindas. Tieši šo daļu pārbaudītājs nolasa pilnībā: grants, politikas, funkcijas, kas apiet RLS, un jutīgi izskatošās kolonnas, kas nolasāmas anonīmiem apmeklētājiem. Atšķirība starp abām atslēgām ir rakstā [Supabase anon key vs service role key](https://madsalt.tech/lv/blog/supabase-anon-key-vs-service-role-key/), bet kā es pierādu katru atļauju pret API, ir rakstā [kā es testēju Supabase RLS](https://madsalt.tech/lv/blog/how-to-test-supabase-rls/).

Tas pats attiecas uz visu ārpus Supabase. Shared responsibility model trešo pušu pakalpojumus uzliek jums: SMTP un SMS pakalpojumu sniedzējus, OAuth pieteikšanos un jebkuru ārēju API, ko izsauc Edge Function vai datubāzes trigeris. Ja kāds no tiem saņem PHI, tas ir jūsu HIPAA aprites, nevis Supabase daļa, tāpēc pārbaudiet, vai katrs pakalpojumu sniedzējs paraksta BAA, pirms dati tam nonāk.

## Kā pārbaudīt savu projektu?

1. Dashboard apstipriniet, ka organizācijai ir HIPAA add-on un projekts ir atzīmēts kā High Compliance, tad atveriet Security Advisor un izejiet cauri katram brīdinājumam.
2. Atveriet Database → Backups un pārliecinieties, ka PITR ir ieslēgts, nevis tikai ikdienas rezerves kopijas.
3. SQL editorā palaidiet `show log_connections;`. Tam jāatgriež `on`.
4. Organization settings pārliecinieties, ka katram dalībniekam ir MFA un ka MFA ir obligāts.
5. Palaidiet [bezmaksas Supabase drošības pārbaudi](https://madsalt.tech/lv/tools/supabase-security-check/) SSL, tīkla ierobežojumiem, publiskajiem buckets un iepriekšminētajiem piekļuves noteikumiem. Mana piezīme par publiskajiem buckets aptver failu pārcelšanu uz parakstītām saitēm.

Par plašāko jautājumu, ko platforma garantē un ko ne, skatiet [vai Supabase ir drošs?](https://madsalt.tech/lv/blog/is-supabase-secure/). Šis raksts nav juridisks padoms; jūsu atbilstības speciālists vai auditors izlemj, ko prasa jūsu BAA un HIPAA programma.

Veidojat veselības lietotni uz Supabase?

Labprāt apskatīšu jūsu projekta iestatījumus un salīdzināšu pieredzi. Bez pārdošanas.

[Sazināties](https://madsalt.tech/lv/#contact)
