nessie

ELis loodud ja teie andmete asukoht

Kus Nessie on loodud, kus teie andmed asuvad ja mida kontrollite, kui majutate Nessie ise.

Kes seda ehitab ja mis õiguse alusel

Nessie’t ehitab UnlikeOtherAI s.r.o., Tšehhi Vabariigis registreeritud ettevõte, mis tegutseb Tšehhi õiguse alusel.

See leht kirjeldab, kuidas tarkvara on ehitatud ja kus see töötab. See ei ole vastavusdeklaratsioon: Nessie’l puudub turvasertifikaat ja siinset teksti ei tohi sellena käsitada. Milliseid isikuandmeid töödeldakse ja mis alusel, on kirjas privaatsuspoliitikas, mis on eraldi leht.

Kus majutatud toode töötab

Nessie Cloud töötab Euroopa majutusteenuse pakkujate juures – Scaleway, Hetzner ja teised. Valime igalt pakkujalt parima teenuse, seega võivad toote eri osad töötada eri pakkujate juures, kõik Euroopas.

Midagi sellest täpsemat – kindlat asukohta, linna või andmekeskust – me teadlikult siin ei nimeta, sest see vananeks märkamatult.

Oma serveris majutades otsustate ise

Kus isemajutatud paigaldus töötab, on juurutuse seadistus, mitte toote seadistus. Ühe masina lahendus on Docker Compose’i komplekt, mille paigaldate endale sobivale masinale. Hallatud pilve Terraformi puus on piirkond sisend ilma vaikeväärtuseta: seal ei saa midagi ära arvata, seega pole seal midagi vaikimisi, ning andmebaas, objektisalvestuse ämber ja teenused järgivad kõik teie nimetatud piirkonda.

Sama küsimuse puhul on olulised veel kaks ehituslikku üksikasja. Järjekord ja reaalajaedastus põhinevad mõlemad PostgreSQL-il – teel ei ole Redist ega sõnumivahendajat, seega pole kolmandat süsteemi, mida kuhugi paigutada. Ja objektisalvestus on S3-ühilduv, mitte seotud ühe tarnijaga; viitepaigaldus käitab MinIO-t konteineris privaatvõrgus, millel puudub oma sissepääs. Osad, millel peab kuskil asukoht olema, on andmebaas, objektisalvestus ja kaks Node’i teenust ning need kõik asuvad seal, kuhu te need panete. Kuidas seda püsti panna, on kirjas paigalduslehel.

Mida Nessie hoiab – ja mida ta teadlikult ei hoia

Identiteeti ei kopeerita

UnlikeOtherAI sisselogimise korral haldab ja salvestab inimese identiteeti identiteedipakkuja – autentimisfaktorid, profiilid, organisatsiooni- ja meeskonnaliikmelisus ning kutsed. Nessie on usaldav pool, mitte teine identiteedisüsteem. See on niisama andmeotsus kui arhitektuuriline otsus: identiteeti, mida Nessie kunagi ei salvesta, ei saa ta lekitada, kaotada ega jätta kustutamata.

Tabel users hoiab tegelikult pakkuja püsivat kasutajatunnust – võtit, mille kaudu kõik muu lahendatakse –, e-posti aadressi, mitteautoriteetset kuvanime ja avatari peeglit ning tootesiseseid välju (eelistused, asesõnad, seansside tühistamiseks kasutatav tokeni versioon). Peegel on olemas ainult selleks, et nime ja pilti saaks kuvada ilma päringuta iga rea kohta, ning see sünkroonitakse pakkuja kontrollitud väidetest uuesti sisselogimisel, meeskonna vahetamisel ja seansi värskendamisel. Väärtusi ei fabritseerita: isik, keda pakkuja pole nimetanud, kannab seni oma e-posti aadressi. Parooliräsi on olemas ainult nende paigalduste algomanikul, kus identiteedipakkujat üldse pole.

Sama kehtib struktuuri kohta. Üks pakkuja organisatsioon on üks Nessie organisatsioon, mis on seotud pakkuja organisatsioonitunnusega; meeskond, millel pole ülesvoolu seost, vastab 404 TEAM_NOT_LINKED, selle asemel et langeda tagasi kohalikule oletusele, ning otsene nimekirjapäring läheb identiteedipakkujale ega salvesta midagi.

Kaks peeglit pole veel kadunud ja vastupidist vihjata oleks ebaaus. Organisatsioonide ja meeskondade nimed on endiselt salvestatud kohapeal sidumistunnuste kõrval ning kohalikud liikmelisuse read annavad sünkroonimiste vahel endiselt tavapäraste päringute õigused. Mõlema eemaldamine on hoidlas jälgitav lahtine töö, mitte midagi, mis oleks juba valmis.

Ärilist ei hoita

Makseid haldab keskne arveldusteenus. Nessie ei salvesta makseteenuse pakkuja kliendi-, tellimus-, arve-, hinna-, krediidisaldo-, täiendamisreegli-, maksenõusoleku-, väljavõtte- ega tühistamisolekut ning ta ei arvuta tariife. Ta loeb valmis kuvamisvalmis väärtused ja näitab neid.

Saladused

Saladuse salvestamiseks on vaja seadistatud hoidlat. Andmebaasi varuvarianti ega lahtise tekstiga teed teadlikult ei ole: ilma hoidlata annavad saladuse salvestamine, roteerimine ja tühistamine veateate, selle asemel et langeda vähem turvalisele lahendusele. Nessie enda kirjed saladuse kohta ei sisalda väärtust, šifreeritud teksti, võtit ega hoidla tokenit – ainult läbipaistmatu viite ja selle metaandmed – ning hoidla teed koostatakse ainult struktuursetest tunnustest, mitte kunagi organisatsiooni, meeskonna, projekti ega isiku nimest.

Mandaadid, mida Nessie peab OAuthi kliendina tegutsemiseks ise hoidma – ühenduste ja postkastide mandaadid, veebihaagi saladused, seansi värskendusmaterjal, executori andmekoormused –, on pitseeritud otstarbega seotud AES-256-GCM ümbrikutes versioonitud võtmerõngaga, mis on seansi allkirjastamise saladusest eraldi juur ja mille roteerimiskord on dokumenteeritud.

Mudelite kohta kehtib lisaks reegel: saladuse olemasolu võib olla teada ja selle kasutamine võib olla lubatud, kuid saladuse sisu ei tohi sattuda mudeli konteksti, viipadesse, tööriistade argumentidesse ega tulemustesse, mällu, vektoresitustesse, otsingusse, logidesse ega sõnumitesse. Agendile saab anda õiguse saladust kasutada. Õigust seda avaldada ei saa talle anda kunagi.

Kas aluseks olevad kettad on krüpteeritud, sõltub masinast, millel paigaldus töötab. Hoidlas ei ole tõendatud andmebaasi ja objektisalvestuse köidete krüpteerimine köite tasandil, mistõttu see leht seda ei väida.

Rentnike eraldatus

Nessie on loomu poolest mitme rentnikuga: üks andmebaas, milles iga rida kuulub täpselt ühele organisatsioonile ja iga alamtabel kannab veergu organization_id. Eraldatust jõustatakse kahes kohas – iga päringu kaasas olev ulatuse klausel ja selle veeru päris võõrvõtmed, mis lisati neljakümne kahe piiranguna pärast seda, kui sisemine audit leidis, et veerg on kümnetes tabelites olemas, kuid piiranguteta.

Vastavustestide komplekt hoiab seda invarianti paigas HTTP piiril. See loob maksimaalsete õigustega ründaja – oma organisatsiooni täieõigusliku omaniku – ja kontrollib, et iga teise organisatsiooni ressursside kanooniline lugemine vastab 403, 404 või tühjaga ning iga kanooniline muutmine lükatakse tagasi, jättes teise organisatsiooni rea puutumata. See katab kanalid, kinnitused, auditilogi, päästikud, agendid ja nende sidemed, käitused, projektid, ülesanded, lõimed, ühendused, töövoo paigaldused, MCP eksemplarid, teadmusbaasi ja teavitused.

Mehhanismi kohta täpselt: see on rakendustaseme jõustamine pluss võõrvõtmed, mitte PostgreSQL-i reataseme turve. RLS-poliitikat ei ole ja andmebaasipoolset tagavara ei ole ning vastavuskomplekt töötab täpse mälusisese hoidla vastu, mitte päris andmebaasi vastu, seega tõestab see koodi kirjutatud ulatuse klausleid, mitte serveri täidetavat SQL-i. Hoidla ütleb seda komplekti enda dokumentatsioonis ja nii ütleb ka see leht.

Auditijälg

Iga tagajärgedega toiming salvestatakse: kes tegutses ja mis rollis – isik, agent, teenus –, mida ta tegi, millise ressursiga, millises organisatsioonis, projektis, meeskonnas või kanalis, kas see õnnestus või keelati, miks, ning päringu tunnus, aadress ja kasutajaagent, millega see saabus.

Logi on loomu poolest ainult lisatav ja sinna ei saa väljastpoolt kirjutada: POST /api/audit-log ei eksisteeri ning see on teadlik valik. Kirjed on aheldatud – igaüks kannab oma kanooniliste väljade SHA-256 räsi pluss selle organisatsiooni eelmise kirje räsi –, nii et muudetud või eemaldatud rida katkestab ahela ja on avastatav. Organisatsiooni omanik või admin saab ahela soovi korral läbi käia ja talle öeldakse, kus see esimest korda katkes, kui see katkes.

Kaks ausat piirangut. Ahel muudab logi rikkumist paljastavaks, mitte rikkumise vastu immuunseks: selle taga pole andmebaasitaseme kirjutusõiguse äravõtmist ega ühekordse kirjutusega salvestust, seega on tagatis avastamine, mitte ärahoidmine. Ja kirjeid säilitatakse vaikimisi tähtajatult – seadistatav säilitus koos eksportimisega enne kustutamist on kavandatud, mitte ehitatud. Kirjetes ei tohi olla saladusi ega täielikke päringu sisusid ning kindel hulk tundlikke metaandmete väljanimesid varjatakse sisenemisel.

Kuluraamat

Iga mudelikutse salvestatakse organisatsiooni ning kasutaja, meeskonna, projekti, kanali, agendi ja käituse kohta, kust see pärines, koos kulutatud tokenitega ning teenusepakkuja teatatud kulu ja Nessie enda hinnanguga kõrvuti. Näitaja, mida pakkuja ei teata, salvestatakse nullina, mitte ei arvata. Aruandeid saab lugeda organisatsiooni omanik või admin.

See raamat on operatiivne telemeetria – mida organisatsioon kulutas ja kelle nimel. See ei ole arve ega arveldusallikas.

Kolmandad osapooled, kui kasutate majutatud toodet

Majutatud paigaldus suhtleb väikese kindla hulga teenustega. Mudeliliiklus ja veebiotsing ei lähe otse pakkujatele: mõlemad väljuvad ühe UnlikeOtherAI hallatava lüüsi kaudu, mille taga asuvad ülesvoolu mudeli- ja otsingupakkujad. Sisselogimine ja arveldus lähevad UnlikeOtherAI autentijale. Saladuste hoidla on majutatud rakenduse kõrval ise. Serveri loodud videokõne lingid kasutavad vaikimisi avalikku Jitsi teenust.

Peaaegu kõik muu on välja lülitatud, kuni operaator selle seadistab, ning ütleb seda otse, selle asemel et vaikselt ebaõnnestuda: ühendatud Google’i, Microsofti ja Slacki kontod; agendi e-post Amazon SES-i kaudu, mida paigaldus käitab oma kontol ilma vahendajata; mobiili- ja brauseriteavitused; uurimis- ja tahvliallikate ühendused; pilvebrauserid. Kaks üksikasja tasub välja tuua, sest need muudavad andmete liikumisteed:

  • Ühendatud postkastid jäävad teie teenusepakkuja juurde. Kirju loetakse otse teie teenusepakkujalt, IMAP-i ja SMTP-protokolli kaudu või pakkuja enda sisselogimisega; Nessie salvestab pitseeritud mandaadi ja kontost muud midagi. Erand on postkast, mille ühendate kliendisuhtluse postkasti: te palute selle vestlused hoida iga kliendi juures, seega kopeeritakse need sisse.
  • Rakenduse häälkõned ei läbi Nessie’t. API vahendab mandaadi ja klient avab helisideme ise. Dikteerimine ja telefonikõned on teised: nende heli läheb Nessie kaudu kõne- ja mudelipakkujatele, kes seda töötlevad.

Üks järeldamise üksikasi järgib sama põhimõtet: allkirjastatud kutsuja identiteedi päised saadetakse ainult seadistatud vestlusserverile, nii et vektoresituste suunamine teisele lõpp-punktile ei anna sellele lõpp-punktile kunagi delegeerimise väidet isiku kohta, kelle teksti vektoresitatakse.

Majutatud toode kasutab mitut järeldamise pakkujat ja valib nende vahel hinna ja kvaliteedi järgi. Organisatsioon saab varsti adminis valida, milliseid pakkujaid selle agendid tohivad kasutada: ainult lääne, ainult Euroopa, ainult Hiina või eelistuseta – iga töö jaoks kõige tõhusam pakkuja. Isemajutatud paigaldus valib oma pakkujad ise.

Ise majutades muutub see kõik

Iga ülalnimetatud kolmas osapool on isemajutatud paigalduses seadistusvalik. Järeldamise saab suunata mis tahes OpenAI-ühilduvale lõpp-punktile, sealhulgas teie enda riistvaral olevale. Ühendused on välja lülitatud, kuni te need sisse lülitate. UnlikeOtherAI sisselogimine on toetatud tee ning paigaldus ilma identiteedipakkujata töötab ühe sidumata organisatsioonina koos algomanikuga.

Selles ongi kokkuleppe mõte: tarkvara on sama ning otsused selle üle, kus see töötab ja mida see tohib kasutada, kuuluvad sellele, kes seda käitab. Kuidas, selgub paigalduslehelt.