Rivitasoinen suojaus — AiHummer Asiakirjat

AiHummer on monivuokraajaympäristö, ja sen vahvin eristysraja sijaitsee itse tietokannassa: PostgreSQL-rivitason tietoturva (RLS). Kun RLS on otettu käyttöön, tietokanta — ei pelkästään sovelluskoodi — varmistaa, että kysely näkee vain sen hetkiseen vuokraajaan kuuluvat rivit.

Taso: Rivitason suojaus on maksetun palvelun takana Yritys taso — se ei ole osa ilmaista/Yhteisö-alustaa.

Miksi RLS

Sovelluskohtainen suodatus (WHERE tenant_id = ...) on välttämätön mutta hauras: yksittäinen unohtunut ehto voi vuotaa tietoja eri vuokralaisten välillä. RLS siirtää takuun PostgreSQL:ään, niin että jopa suodattamaton kysely palauttaa vain nykyisen vuokralaisen rivit. Se on syvyyspuolustuksen kerros sovelluksen oman kohdistuksen alla. Laajemman monivuokralaismallin osalta — ja miten se yhdistyy idempotentteihin sivuvaikutuksiin — katso Monivuokraisuus ja idempotenssi.

Rajoitettu rooli (valinnainen)

RLS on osallistua vapaaehtoisesti ja aktivoidaan antamalla portille toinen tietokantayhteys, joka käyttää rajoitettua roolia omistajan sijaan:

# /home/.aihummer/etc/gateway.env
# Owner pool — runs migrations, used for system/bypass operations
AIHUMMER_DATABASE_URL=postgres://owner:...@localhost/aihummer

# Restricted application pool — RLS policies apply (aihummer_app role)
AIHUMMER_DB_APP_URL=postgres://aihummer_app:...@localhost/aihummer

Se aihummer_app rooli on ei taulun omistaja, joten PostgreSQL soveltaa siihen RLS-politiikkoja. Sovellus kyselyt kulkevat tämän rajoitetun allaan kautta. RLS:n ottaminen käyttöön on kiinni asetuksesta AIHUMMER_DB_APP_URL — ja paikalliset/standardit (isäntäkohtaiset) asennukset asettavat sen muuttujan automaattisesti, joten RLS on aktiivinen heti alusta alkaen. Se on “valinnainen” vain siinä mielessä, että mukautetun tai manuaalisen käyttöönoton on asetettava AIHUMMER_DB_APP_URL itse.

[!NOTE] Ilman AIHUMMER_DB_APP_URL, portti käyttää kaikkeen omistajapoolia ja RLS ei käytännössä ole voimassa. Aseta rajoitettu allas (joka vakiovalmistaja tekee puolestasi) kytkeäksesi tietokantatason eristyksen päälle.

[!IMPORTANT] RLS ei riipu tilaustasosta. Se toimii samoin kaikilla tasoilla, myös Community-tasolla. Jos lisenssinäkymä näyttää ”Rivitason suojauksen” saavuttamattomana, kyse on kyseisen näkymän epätarkkuudesta eikä tietokantasi tilasta.

Missä RLS on jo päällä ja missä se pitää kytkeä itse

Miten asensit	RLS asennuksen jälkeen
Vakioasennus, asennusohjelma pystyttää PostgreSQL:n	Aktiivinen. Rajoitettu rooli ja `AIHUMMER_DB_APP_URL` luodaan puolestasi
Oma tai hallittu PostgreSQL (tietokannan osoite annettiin etukäteen)	Ei aktiivinen. Roolin ja `AIHUMMER_DB_APP_URL`-arvon luot itse
Asennus ilman pääkäyttäjäoikeuksia (rootless)	Ei aktiivinen. Sama asia

[!WARNING] Kaksi virhettä, joiden jälkeen RLS on ”päällä” muttei suojaa mitään. Ensimmäinen: AIHUMMER_DB_APP_URL osoittaa taulujen omistajaan tai pääkäyttäjään — PostgreSQL vapauttaa tällaiset roolit käytännöistä, ja yhdyskäytävä ilmoittaa RLS:n silti aktiiviseksi. Käytä erillistä rajoitettua roolia. Toinen: omassa PostgreSQL:ssä rajoitettu rooli voi syntyä automaattisesti ennakoitavalla salasanalla — anna sille oma salasanasi ennen kuin tietokanta on saavutettavissa verkosta.

Vuokralaiskohtainen laajuuden määrittely

Pyynnön sisällä sovellus määrittää nykyisen vuokralaisen yhteydelle ennen vuokraajaan kohdennettujen kyselyiden suorittamista — käsitteellisesti db.WithTenant. Kun se on määritelty, RLS-politiikat rajoitetulla roolilla rajoittavat jokaisen lukemisen ja kirjoittamisen kyseisen vuokralaisen riveihin. Määritelmä on sidottu työyksikköön, joten se ei vuoda samanaikaisten pyyntöjen välillä.

request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant

Järjestelmä / ohitustila työntekijöille

Jotkut työt ovat laillisesti ristivuokraajan tai vuokraajasta riippumattomia — taustatyöntekijät, ajastimet, toimitusten palautus ja vastaava ylläpito. Näissä portti käyttää järjestelmä (ohitus)tila joka toimii omistajapoolissa, per-tenant RLS-käytäntöjen ulkopuolella, joten infrastruktuuritehtävät voivat toimia koko tietojoukon yli.

[!WARNING] Ohitustila on tarkoitettu vain luotetuille sisäisille työntekijöille. Pyyntöjen käsittelykoodipolut joka toimii käyttäjän puolesta, on aina suoritettava rajoitetun kautta, vuokralaiskohtainen allas — ei koskaan ohitusreitti.

Migraatiot toimivat omistajapoolilla

Skeeman muutokset vaativat oikeuksia, joita rajoitetulla roolilla ei ole, joten siirrot suoritetaan aina omistajapoolilla (AIHUMMER_DATABASE_URL), neuvontalukituksen alaisena, käynnistyksen yhteydessä. Rajoitettu aihummer_app roolia käytetään vain tavalliseen sovelluksen liikenteeseen. Tämä pitää oikeuksien erottelun selkeänä: skeemaa muuttavat toiminnot käyttävät omistajaa; vuokralaisdatan käyttö käyttää rajoitettua roolia, johon RLS on sovellettu.

Minne seuraavaksi

Monivuokraisuus ja idempotenssi — täydellinen vuokralaismalli ja miten sivuvaikutukset pysyvät turvallisina palautuksen aikana.
Salaisuuksien holvi — vuokralaiskohtaiset DEK:t vahvistavat saman eristyminen salaisuuksien kerroksessa.
RBAC ja rajatut API-avaimet — valtuutus yli datalayer