---
title: "Kas Supabase on turvaline? Mida see katab ja mida teie"
description: "Supabase on SOC 2 Type 2 ja ISO 27001 sertifitseeritud ning krüpteerib andmed. Kas teie andmed on turvalised, sõltub seadetest, mida kontrollite ainult teie."
url: "https://madsalt.tech/et/blog/is-supabase-secure/"
author: "Denys Zaichenko"
language: "et"
published: 2026-10-26
---

# Kas Supabase on turvaline? Mida see katab ja mida teie

Lühidalt

Jah, platvorm on turvaline: Supabase on SOC 2 Type 2 ja ISO 27001 sertifitseeritud, krüpteerib andmed AES-256-ga puhkeolekus ja TLS-iga edastamisel ning sõlmib HIPAA lepingud Team plaanis ja kõrgemates. Teie projekt on teine küsimus. Supabase'i jagatud vastutuse mudeli (shared responsibility model) järgi on ligipääs tabelitele, API võtmed ja auth-seaded teie ning platvorm teeb täpselt seda, mida need seaded ütlevad. Minu kohalikul testtabelil otsustas üks seadistus, kas avalik võti sai 0 rida või kõik 3.

Olen Denys, full-stack- ja AI-insener, ja enamik rakendusi, mida ehitan või parandan, töötab Supabase'i peal. Kliendid küsivad "kas Supabase on turvaline?", kui mõtlevad "kas minu andmed on turvalised?". Neil on erinevad vastused, seega käsitlen neid ükshaaval.

## Kas Supabase'i platvorm on turvaline?

Platvormi poolt auditeerivad kolmandad osapooled. Supabase'i [turvalehelt](https://supabase.com/security) ja [turvadokumentatsioonist](https://supabase.com/docs/guides/security), loetud 23. oktoobril 2026:

| Kontroll        | Mida Supabase väidab                                                                                   |
| --------------- | ------------------------------------------------------------------------------------------------------ |
| SOC 2 Type 2    | Auditeeritakse igal aastal; aruanne on saadaval Team- ja Enterprise-klientidele                        |
| ISO 27001       | Sertifitseeritud; sertifikaat on saadaval Team- ja Enterprise-klientidele                              |
| HIPAA           | Toetatud allkirjastatud Business Associate Agreementi ja HIPAA lisandmooduliga, Team plaan ja kõrgemad |
| Krüpteerimine   | AES-256 puhkeolekus, TLS edastamisel; juurdepääsutokenid ja võtmed on krüpteeritud ka rakendustasandil |
| Varukoopiad     | Igapäevased tasuliste projektide jaoks; Point in Time Recovery lisandmoodulina Pro plaanist alates     |
| Andmete asukoht | Andmebaas, Auth ja Storage jäävad AWS-i regiooni, mille valite                                         |

Mitte ükski neist ei kaitse tabelit, mille jätsite lahti. [SOC 2 juhend](https://supabase.com/docs/guides/security/soc-2-compliance) ütleb selle otse: Supabase'i vastavus ei kandu üle millelegi, mis jääb väljapoole selle kontrolli.

## Mis on teie osa?

Supabase'i [shared responsibility model](https://supabase.com/docs/guides/deployment/shared-responsibility-model) loetleb, mis on alati teie: teie konto, juurdepääsuhaldus andmebaasile ja selle tabelitele, teie andmed ja turvakontrollide rakendamine, sealhulgas hoiatused, mida Security Advisor tõstab. Praktikas tähendab see nelja kihti seadeid:

![Kes kaitseb päringu iga sammu. Supabase haldab edastust ja võtmeid; õigused ja poliitikad on teie. Brauserist: Brauser → TLS, võti · Supabase → Õigus · teie → RLS · teie; Teie serverist: Server → TLS · Supabase → Secret key · teie → RLS vahele jäetud.](https://madsalt.tech/charts/et/is-supabase-secure.svg)

*Joonis 1. Supabase'i shared responsibility model'i ja API keys juhendi põhjal, oktoober 2026.*

1. **Kes tabelit puudutada saab.** Õigused (grants) otsustavad, kas `anon` ja `authenticated` tabelini üldse jõuavad. RLS-poliitikad otsustavad, milliste ridadeni.
2. **Milline võti kuhu läheb.** Publishable key on loomult avalik, secret key jätab RLS-i vahele. Võrdlesin neid artiklis [Supabase anon key vs service role key](https://madsalt.tech/et/blog/supabase-anon-key-vs-service-role-key/).
3. **Auth-seaded.** E-posti kinnitus, leaked password protection (Pro plaan ja kõrgemad), minimaalne paroolipikkus, MFA, redirect URL-id, CAPTCHA.
4. **Kõik andmebaasi ümber.** Storage bucket'id ja nende poliitikad, `SECURITY DEFINER` funktsioonid, Edge Function'id, mis kasutavad secret key't, ja millised skeemid Data API avaldab.

## Kui palju üks seadistus muudab?

Tegin sama päringu ühele kolme võltstellimusega tabelile kohalikul Supabase'i pinul (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), publishable key'ga, nagu brauser teeks:

| Seadistus tabelil                  | Mida avalik võti sai                           |
| ---------------------------------- | ---------------------------------------------- |
| RLS väljas                         | Kõik 3 rida ja lisamine tagastas `201 Created` |
| RLS sees, poliitikat pole          | `[]`                                           |
| RLS sees, poliitika `using (true)` | Kõik 3 rida                                    |
| Rollil `anon` õigust pole          | `42501 permission denied`                      |

Sama platvorm, sama krüpteerimine, samad sertifikaadid. Vahe on üks SQL-i rida. Seepärast ei ole "turvaline platvorm" ja lekkiv rakendus vastuolu: [CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/) leidis 170 Lovable'i näiterakendust 1645-st, mis andsid andmeid avalikule võtmele, kõik samal auditeeritud platvormil.

## Kas Supabase muutub vaikimisi turvalisemaks?

Jah, sammhaaval. Supabase'i [28. aprilli 2026 changelog](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) loetleb RLS-on-by-default lüliti, Data API avalikustamise märgi, tabelipõhised õigused ja skeemide loendamise piirangu. Suurim jõustub 30. oktoobril 2026: olemasolevate projektide uued tabelid ei saa enam Data API õigusi automaatselt, seega unustatud tabel tagastab ridade asemel `42501`. Olemasolevad tabelid säilitavad oma õigused, seega see ei paranda midagi, mis on juba lahti. Vanad `anon` ja `service_role` võtmed on samuti aegumas 2026. aasta lõpuks publishable ja secret key'de kasuks; uus secret key keeldub brauseri päringutest.

Mida ümberlülitus veel katki teeb ja kuidas projekti enne kontrollida: [Supabase 30. oktoobri grantide muudatus: mis läheb katki](https://madsalt.tech/et/blog/supabase-october-30-grant-change/).

## Kuidas oma projekti kontrollida?

Alustage Supabase'i enda Security Advisorist ja parandage iga hoiatus. Seejärel kontrollige, mida see ei kata:

- Käivitage tasuta [Supabase'i turvakontroll](https://madsalt.tech/et/tools/supabase-security-check/). See ühendub kirjutuskaitstult ja hindab projekti 46 reegli vastu, mis on seotud OWASP Top 10:2025-ga: RLS, poliitikad, view'd, funktsioonid, õigused, storage ja auth-seaded, igale leiule parandus-SQL.
- Testige kahe kasutajaga kahes ettevõttes. Ükski skanner ei tea, millised read kellele kuuluvad; test on minu [Lovable'i rakenduse turvanimekirjas](https://madsalt.tech/et/blog/lovable-app-security-checklist/).
- Kui teie rakendusel on rollid ja õiguste ekraan, tõestage, et iga õiguse ruut teeb seda, mida ütleb, nagu artiklis [kuidas Supabase'i RLS-i testida](https://madsalt.tech/et/blog/how-to-test-supabase-rls/).

Seega: Supabase on turvaline koht andmete hoidmiseks ja annab teile tööriistad nende privaatsena hoidmiseks. See, kas need privaatseks jäävad, otsustatakse teie skeemis ja seadetes.

Kaalute Supabase'i oma projekti jaoks?

Võrdlen hea meelega märkmeid selle kohta, mida kõigepealt seadistada. Müügijututa.

[Võtke ühendust](https://madsalt.tech/et/#contact)
