---
title: "Onko Supabase turvallinen? Mitä se kattaa ja mitä sinä"
description: "Supabase on SOC 2 Type 2- ja ISO 27001 -sertifioitu ja salaa datan. Onko datasi turvassa, riippuu asetuksista, joita vain sinä hallitset."
url: "https://madsalt.tech/fi/blog/is-supabase-secure/"
author: "Denys Zaichenko"
language: "fi"
published: 2026-10-26
---

# Onko Supabase turvallinen? Mitä se kattaa ja mitä sinä

TL;DR

Kyllä, alusta on turvallinen: Supabase on SOC 2 Type 2- ja ISO 27001 -sertifioitu, salaa datan levossa AES-256:lla ja siirrossa TLS:llä sekä allekirjoittaa HIPAA-sopimuksia Team-paketista ylöspäin. Projektisi on eri kysymys. Supabasen jaetun vastuun mallissa pääsy tauluihin, API-avaimet ja auth-asetukset ovat sinun, ja alusta tekee täsmälleen sen, mitä ne asetukset sanovat. Testitaulussani yksi asetus ratkaisi, sai julkinen avain 0 riviä vai kaikki 3.

Olen Denys, full-stack- ja tekoäly-insinööri, ja useimmat rakentamani tai korjaamani sovellukset pyörivät Supabasella. Asiakkaat kysyvät "onko Supabase turvallinen?", kun he tarkoittavat "onko datani turvassa?". Niillä on eri vastaukset, joten tässä artikkelissa ne käydään läpi yksi kerrallaan.

## Onko Supabase-alusta turvallinen?

Alustan puolen auditoivat kolmannet osapuolet. Supabasen [tietoturvasivulta](https://supabase.com/security) ja [tietoturvadokumentaatiosta](https://supabase.com/docs/guides/security), luettu 23. lokakuuta 2026:

| Kontrolli      | Mitä Supabase ilmoittaa                                                                                |
| -------------- | ------------------------------------------------------------------------------------------------------ |
| SOC 2 Type 2   | Auditoidaan vuosittain; raportti on saatavilla Team- ja Enterprise-asiakkaille                         |
| ISO 27001      | Sertifioitu; sertifikaatti on saatavilla Team- ja Enterprise-asiakkaille                               |
| HIPAA          | Tuettu allekirjoitetulla Business Associate Agreementilla ja HIPAA-lisäosalla, Team-paketista ylöspäin |
| Salaus         | AES-256 levossa, TLS siirrossa; pääsytokenit ja avaimet salataan lisäksi sovellustasolla               |
| Varmuuskopiot  | Päivittäiset maksullisille projekteille; Point in Time Recovery lisäosana Pro-paketista alkaen         |
| Datan sijainti | Tietokanta, Auth ja Storage pysyvät valitsemassasi AWS-alueella                                        |

Mikään tästä ei suojaa taulua, jonka jätit auki. [SOC 2 -opas](https://supabase.com/docs/guides/security/soc-2-compliance) sanoo sen suoraan: Supabasen vaatimustenmukaisuus ei siirry mihinkään, mikä on sen hallinnan ulkopuolella.

## Mikä on sinun osuutesi?

Supabasen [jaetun vastuun malli](https://supabase.com/docs/guides/deployment/shared-responsibility-model) listaa, mikä on aina sinun: tilisi, tietokannan ja sen taulujen käyttöoikeuksien hallinta, datasi sekä tietoturvakontrollien soveltaminen, Security Advisorin nostamat varoitukset mukaan lukien. Käytännössä se tarkoittaa neljää asetuskerrosta:

![Kuka vartioi pyynnön jokaista vaihetta. Supabase hoitaa siirron ja avaimet; oikeudet ja politiikat ovat sinun. Selaimesta: Selain → TLS, key · Supabase → Oikeus · sinä → RLS · sinä; Palvelimeltasi: Palvelin → TLS · Supabase → Secret key · sinä → RLS ohitetaan.](https://madsalt.tech/charts/fi/is-supabase-secure.svg)

*Kuva 1. Perustuu Supabasen jaetun vastuun malliin ja API-avainoppaaseen, lokakuu 2026.*

1. **Kuka voi koskea tauluun.** Oikeudet (grants) ratkaisevat, yltävätkö `anon` ja `authenticated` tauluun lainkaan. RLS-politiikat ratkaisevat, mihin riveihin.
2. **Mikä avain kuuluu minnekin.** Publishable key on suunnittelultaan julkinen, secret key ohittaa RLS:n. Vertailin niitä artikkelissa [Supabase anon key vs service role key](https://madsalt.tech/fi/blog/supabase-anon-key-vs-service-role-key/).
3. **Auth-asetukset.** Sähköpostivahvistus, leaked password protection (Pro-paketista ylöspäin), salasanan vähimmäispituus, MFA, redirect-URL:t, CAPTCHA.
4. **Kaikki tietokannan ympärillä.** Storage-bucketit ja niiden politiikat, `SECURITY DEFINER` -funktiot, Edge Functionit, jotka käyttävät secret keytä, ja se, mitkä skeemat Data API julkaisee.

## Kuinka paljon yksi asetus muuttaa?

Ajoin saman pyynnön yhdelle kolmen tekaistun tilauksen taululle paikallisella Supabase-stackilla (CLI 2.109.1, Postgres 17.6, PostgREST 14.14) publishable keyllä, niin kuin selain tekisi:

| Taulun asetus                         | Mitä julkinen avain sai                          |
| ------------------------------------- | ------------------------------------------------ |
| RLS pois                              | Kaikki 3 riviä, ja insert palautti `201 Created` |
| RLS päällä, ei politiikkaa            | `[]`                                             |
| RLS päällä, politiikka `using (true)` | Kaikki 3 riviä                                   |
| Ei oikeutta roolille `anon`           | `42501 permission denied`                        |

Sama alusta, sama salaus, samat sertifioinnit. Ero on yksi rivi SQL:ää. Siksi "turvallinen alusta" ja vuotava sovellus eivät ole ristiriidassa: [CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/) löysi 170 Lovablen 1 645 esittelysovelluksesta tarjoamassa dataa julkiselle avaimelle, kaikki samalla auditoidulla alustalla.

## Onko Supabase tulossa oletuksena turvallisemmaksi?

Kyllä, vaiheittain. Supabasen [changelog 28. huhtikuuta 2026](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) listaa kytkimen RLS:n päällä pitämiseksi oletuksena, Data API -altistuksen merkin, taulukohtaiset hienojakoiset oikeudet ja rajoituksen skeemojen luetteloinnille. Suurin tulee voimaan 30. lokakuuta 2026: uudet taulut olemassa olevissa projekteissa eivät enää saa Data API -oikeuksia automaattisesti, joten unohtunut taulu palauttaa riviensä sijaan `42501`. Olemassa olevat taulut säilyttävät oikeutensa, joten tämä ei korjaa mitään, mikä on jo auki. Vanhat `anon`- ja `service_role`-avaimet poistuvat myös käytöstä vuoden 2026 loppuun mennessä publishable- ja secret-avainten tieltä; uusi secret key torjuu selaimen pyynnöt.

Mitä muuta vaihto rikkoo ja miten projektin voi tarkistaa etukäteen: [Supabasen grant-muutos 30. lokakuuta: mikä hajoaa](https://madsalt.tech/fi/blog/supabase-october-30-grant-change/).

## Miten tarkistat oman projektisi?

Aloita Supabasen omasta Security Advisorista ja korjaa jokainen varoitus. Tarkista sitten se, mitä se ei kata:

- Aja ilmainen [Supabase-tietoturvatarkistus](https://madsalt.tech/fi/tools/supabase-security-check/). Se yhdistää vain luku -tilassa ja arvioi projektin 46 säännön mukaan, jotka on kytketty OWASP Top 10:2025 -listaan: RLS, politiikat, viewt, funktiot, oikeudet, storage ja auth-asetukset, ja jokaiselle löydökselle korjaus-SQL.
- Testaa kahdella käyttäjällä kahdessa yrityksessä. Mikään skanneri ei tiedä, mitkä rivit kuuluvat kenellekin; testi on [Lovable-sovelluksen tietoturvatarkistuslistassani](https://madsalt.tech/fi/blog/lovable-app-security-checklist/).
- Jos sovelluksessasi on rooleja ja oikeuksien hallintanäkymä, todista, että jokainen oikeusvalinta tekee sen, mitä se sanoo, kuten artikkelissa [Supabase RLS:n testaus](https://madsalt.tech/fi/blog/how-to-test-supabase-rls/).

Eli: Supabase on turvallinen paikka säilyttää dataa, ja se antaa sinulle työkalut pitää data yksityisenä. Pysyykö se yksityisenä, ratkeaa skeemassasi ja asetuksissasi.

Harkitsetko Supabasea projektiin?

Vertaan mielelläni kokemuksia siitä, mitä kannattaa ottaa käyttöön ensin. Ei myyntipuhetta.

[Ota yhteyttä](https://madsalt.tech/fi/#contact)
