--- title: "Ar Supabase saugus? Ką jis apima, o ką turite jūs" description: "Supabase sertifikuotas pagal SOC 2 Type 2 ir ISO 27001, duomenys šifruojami. Ar jūsų duomenys saugūs, priklauso nuo nustatymų, kuriuos valdote tik jūs." url: "https://madsalt.tech/lt/blog/is-supabase-secure/" author: "Denys Zaichenko" language: "lt" published: 2026-10-26 --- # Ar Supabase saugus? Ką jis apima, o ką turite jūs Trumpai Taip, platforma saugi: Supabase sertifikuotas pagal SOC 2 Type 2 ir ISO 27001, šifruoja duomenis AES-256 saugojimo metu ir TLS perduodant bei pasirašo HIPAA sutartis Team plane ir aukštesniuose. Jūsų projektas yra kitas klausimas. Pagal Supabase bendros atsakomybės modelį (shared responsibility model) prieiga prie lentelių, API raktai ir auth nustatymai yra jūsų, o platforma daro tiksliai tai, ką šie nustatymai nurodo. Mano vietinėje bandomojoje lentelėje vienas nustatymas lėmė, ar viešasis raktas gavo 0 eilučių, ar visas 3. Esu Denys, full-stack ir AI inžinierius, ir dauguma programų, kurias kuriu ar taisau, veikia ant Supabase. Klientai klausia „ar Supabase saugus?", turėdami omenyje „ar mano duomenys saugūs?". Atsakymai skirtingi, todėl šiame straipsnyje juos nagrinėju po vieną. ## Ar Supabase platforma saugi? Platformos pusę audituoja trečiosios šalys. Iš Supabase [saugos puslapio](https://supabase.com/security) ir [saugos dokumentacijos](https://supabase.com/docs/guides/security), perskaityta 2026 m. spalio 23 d.: | Kontrolė | Ką teigia Supabase | | ------------------ | ----------------------------------------------------------------------------------------------------------------- | | SOC 2 Type 2 | Audituojama kasmet; ataskaita prieinama Team ir Enterprise klientams | | ISO 27001 | Sertifikuota; sertifikatas prieinamas Team ir Enterprise klientams | | HIPAA | Palaikoma su pasirašyta Business Associate Agreement ir HIPAA priedu, Team planas ir aukštesni | | Šifravimas | AES-256 saugomiems duomenims, TLS perduodamiems; prieigos tokenai ir raktai papildomai šifruojami programos lygiu | | Atsarginės kopijos | Kasdienės mokamiems projektams; Point in Time Recovery kaip priedas nuo Pro plano | | Duomenų vieta | Duomenų bazė, Auth ir Storage lieka jūsų pasirinktame AWS regione | Nė viena iš šių priemonių neapsaugo lentelės, kurią palikote atvirą. [SOC 2 vadovas](https://supabase.com/docs/guides/security/soc-2-compliance) tai sako tiesiai: Supabase atitiktis neperkeliama niekam, kas yra už jos kontrolės ribų. ## Kokia jūsų dalis? Supabase [shared responsibility model](https://supabase.com/docs/guides/deployment/shared-responsibility-model) išvardija tai, kas visada jūsų: jūsų paskyra, prieigos valdymas prie duomenų bazės ir jos lentelių, jūsų duomenys ir saugos kontrolių taikymas, įskaitant įspėjimus, kuriuos iškelia Security Advisor. Praktiškai tai reiškia keturis nustatymų sluoksnius: ![Kas saugo kiekvieną užklausos žingsnį. Supabase valdo perdavimą ir raktus; teisės ir politikos yra jūsų. Iš naršyklės: Naršyklė → TLS, raktas · Supabase → Teisė · jūs → RLS · jūs; Iš jūsų serverio: Serveris → TLS · Supabase → Secret key · jūs → RLS praleistas.](https://madsalt.tech/charts/lt/is-supabase-secure.svg) *1 pav. Pagal Supabase shared responsibility model ir API keys vadovą, 2026 m. spalis.* 1. **Kas gali liesti lentelę.** Teisės (grants) nusprendžia, ar `anon` ir `authenticated` apskritai pasiekia lentelę. RLS politikos nusprendžia, kurias eilutes. 2. **Kuris raktas kur eina.** Publishable key pagal paskirtį yra viešas, secret key apeina RLS. Palyginau juos straipsnyje [Supabase anon key vs service role key](https://madsalt.tech/lt/blog/supabase-anon-key-vs-service-role-key/). 3. **Auth nustatymai.** El. pašto patvirtinimas, leaked password protection (Pro planas ir aukštesni), mažiausias slaptažodžio ilgis, MFA, redirect URL, CAPTCHA. 4. **Viskas aplink duomenų bazę.** Storage bucket ir jų politikos, `SECURITY DEFINER` funkcijos, Edge Function, naudojančios secret key, ir kurias schemas Data API atveria. ## Kiek pakeičia vienas nustatymas? Paleidau tą pačią užklausą vienai lentelei su trimis išgalvotais užsakymais vietinėje Supabase aplinkoje (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), su publishable key, kaip tai darytų naršyklė: | Lentelės nustatymas | Ką gavo viešasis raktas | | ------------------------------------- | -------------------------------------------------- | | RLS išjungtas | Visos 3 eilutės, o įterpimas grąžino `201 Created` | | RLS įjungtas, politikos nėra | `[]` | | RLS įjungtas, politika `using (true)` | Visos 3 eilutės | | Rolė `anon` neturi teisės | `42501 permission denied` | Ta pati platforma, tas pats šifravimas, tie patys sertifikatai. Skirtumas yra viena SQL eilutė. Todėl „saugi platforma" ir duomenis nutekinanti programa nėra prieštara: [CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/) rado 170 iš 1645 Lovable demonstracinių programų, atidavusių duomenis viešajam raktui, visas toje pačioje audituotoje platformoje. ## Ar Supabase pagal numatytuosius nustatymus tampa saugesnis? Taip, žingsnis po žingsnio. Supabase [2026 m. balandžio 28 d. changelog](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) išvardija RLS-on-by-default jungiklį, Data API atvirumo ženklą, lentelių lygio teises ir schemų išvardijimo apribojimą. Didžiausias pakeitimas įsigalioja 2026 m. spalio 30 d.: naujoms esamų projektų lentelėms Data API teisės automatiškai nebesuteikiamos, todėl užmiršta lentelė vietoj eilučių grąžins `42501`. Esamos lentelės teises išsaugo, todėl tai nieko neištaiso to, kas jau atvira. Seni `anon` ir `service_role` raktai taip pat laikomi pasenusiais iki 2026 m. pabaigos publishable ir secret key naudai; naujas secret key atmeta užklausas iš naršyklės. Ką dar sugadina perjungimas ir kaip patikrinti projektą iš anksto: [Supabase spalio 30 d. pokytis: kas sulūš ir kaip patikrinti](https://madsalt.tech/lt/blog/supabase-october-30-grant-change/). ## Kaip patikrinti savo projektą? Pradėkite nuo paties Supabase Security Advisor ir ištaisykite kiekvieną įspėjimą. Tada patikrinkite tai, ko jis neapima: - Paleiskite nemokamą [Supabase saugos tikrintuvą](https://madsalt.tech/lt/tools/supabase-security-check/). Jis jungiasi tik skaitymo režimu ir vertina projektą pagal 46 taisykles, susietas su OWASP Top 10:2025: RLS, politikos, view, funkcijos, teisės, storage ir auth nustatymai, kiekvienam radiniui pateikiant taisomąjį SQL. - Testuokite su dviem vartotojais dviejose įmonėse. Joks skeneris nežino, kurios eilutės kam priklauso; testas aprašytas mano [Lovable programos saugos sąraše](https://madsalt.tech/lt/blog/lovable-app-security-checklist/). - Jei jūsų programoje yra rolės ir leidimų ekranas, įrodykite, kad kiekvienas leidimo langelis daro tai, ką sako, kaip straipsnyje [kaip testuoju Supabase RLS](https://madsalt.tech/lt/blog/how-to-test-supabase-rls/). Taigi: Supabase yra saugi vieta duomenims laikyti ir suteikia įrankius jiems išlaikyti privačius. Ar jie liks privatūs, sprendžiama jūsų schemoje ir nustatymuose. Svarstote Supabase savo projektui? Mielai palyginsiu patirtį, ką nustatyti pirmiausia. Be pardavimų kalbų. [Susisiekti](https://madsalt.tech/lt/#contact)