Sukurta ES ir kur saugomi jūsų duomenys

Kur kuriama Nessie, kur saugomi jūsų duomenys ir ką kontroliuojate, kai sistemą talpinate patys.

Kas ją kuria ir pagal kurios šalies teisę

Nessie kuria UnlikeOtherAI s.r.o. – bendrovė, įregistruota Čekijoje ir veikianti pagal Čekijos teisę.

Šiame puslapyje aprašoma, kaip programinė įranga sukurta ir kur ji veikia. Tai nėra atitikties pareiškimas: Nessie neturi jokio saugumo sertifikato, ir nieko, kas čia parašyta, nereikėtų suprasti kaip tokio sertifikato. Kokie asmens duomenys tvarkomi ir kokiu pagrindu – aprašyta atskirame puslapyje, privatumo politikoje.

Kur veikia talpinamas produktas

Nessie Cloud veikia Europos talpinimo teikėjų sistemose – Scaleway, Hetzner ir kitų. Iš kiekvieno teikėjo renkamės geriausią jo siūlomą paslaugą, todėl skirtingos produkto dalys gali veikti pas skirtingus teikėjus, o visi jie yra Europoje.

Tikslesnė informacija – konkreti vieta, miestas ar duomenų centras – čia sąmoningai nenurodoma, nes laikui bėgant ji pasentų, o to niekas nepastebėtų.

Savarankiškai talpindami sprendžiate jūs

Kur veikia savarankiškai talpinamas egzempliorius, nusprendžiama diegimo nustatymais, o ne produkto nustatymais. Vieno kompiuterio kelias – tai Docker Compose rinkinys, kurį pasirinktame kompiuteryje paleidžiate jūs. Terraform medyje, skirtame valdomam debesiui, regionas yra įvesties parametras, visai neturintis numatytosios reikšmės: nieko čia negalima atspėti, todėl nieko čia nėra numatyta iš anksto, o duomenų bazė, objektų saugyklos talpykla ir paslaugos pasirenka tą regioną, kurį nurodote jūs.

Tam pačiam klausimui svarbios dvi struktūrinės detalės. Eilė ir realaus laiko transportas abu veikia PostgreSQL pagrindu – kelyje nėra nei Redis, nei pranešimų tarpininko, todėl nėra ir trečios sistemos, kurią reikėtų kažkur patalpinti. O objektų saugykla yra suderinama su S3 ir nėra susieta su vienu tiekėju; pavyzdiniame diegime MinIO veikia konteineryje privačiame tinkle, be savo įėjimo iš išorės. Vietos reikia duomenų bazei, objektų saugyklai ir dviem Node paslaugoms – visos jos veikia ten, kur jas pastatysite. Kaip tai paruošti, aprašyta diegimo puslapyje.

Ką Nessie saugo ir ko sąmoningai nesaugo

Tapatybė nekopijuojama

Prisijungiant per UnlikeOtherAI, žmogaus tapatybę tvarko ir saugo tapatybės teikėjas – autentifikavimo veiksnius, profilius, organizacijos ir komandos narystę bei kvietimus. Nessie yra priklausoma šalis, o ne antra tapatybės sistema. Tai tiek pat duomenų, kiek ir architektūros sprendimas: tapatybės, kurios Nessie niekada nesaugo, ji negali nutekinti, prarasti ar nepavykti ištrinti.

Lentelėje users iš tikrųjų laikoma teikėjo stabilus naudotojo identifikatorius – raktas, pagal kurį atpažįstama visa kita, – el. pašto adresas, neautoritetingas rodomo vardo ir avataro atvaizdas bei produkto lygio laukai (nuostatos, įvardžiai, žetonų versija, naudojama seansams atšaukti). Atvaizdas egzistuoja tik tam, kad vardą ir nuotrauką būtų galima parodyti be atskiros užklausos kiekvienai eilutei, ir jis iš naujo sinchronizuojamas iš teikėjo patikrintų teiginių prisijungiant, keičiant komandą ir atnaujinant seansą. Reikšmių niekas negamina: žmogus, kurio teikėjas dar nepavadino, turi savo el. pašto adresą, kol vardas atsiras. Slaptažodžio maiša egzistuoja tik pradinio savininko paskyrai tokiame diegime, kuriame tapatybės teikėjo nėra visai.

Tas pats galioja ir struktūrai. Viena teikėjo organizacija yra viena Nessie organizacija, susieta pagal teikėjo organizacijos identifikatorių; komanda be nuorodos į teikėją atsako 404 TEAM_NOT_LINKED, užuot grįžusi prie vietinio spėjimo, o gyvas narių sąrašo skaitymas eina pas tapatybės teikėją ir nieko nesaugo.

Dviejų atvaizdų dar neatsisakyta, ir būtų nesąžininga teigti kitaip. Organizacijų ir komandų pavadinimai vis dar saugomi vietoje kartu su susiejimo identifikatoriais, o vietinės narystės eilutės tarp sinchronizacijų vis dar suteikia teisę vykdyti įprastas užklausas. Abiejų atsisakymas yra sekamas, dar neužbaigtas darbas saugykloje, o ne jau atliktas dalykas.

Nieko komercinio

Mokėjimus tvarko centrinė atsiskaitymo paslauga. Nessie nesaugo mokėjimo teikėjo kliento, prenumeratos, sąskaitos faktūros, kainos, kreditų likučio, papildymo politikos, mokėjimo sutikimo, ataskaitos ar atšaukimo būsenos ir neskaičiuoja tarifų. Ji nuskaito paruoštas rodyti reikšmes ir jas parodo.

Slapti duomenys

Kad apskritai būtų galima išsaugoti slaptą reikšmę, būtina sukonfigūruota saugykla. Atsarginio saugojimo duomenų bazėje ir kelio atviru tekstu sąmoningai nėra: be saugyklos slaptos reikšmės išsaugojimas, rotacija ir atšaukimas grąžina klaidą, o ne pereina į mažiau saugų režimą. Nessie savo įrašuose apie slaptą reikšmę nelaiko nei reikšmės, nei šifrogramos, nei rakto, nei saugyklos žetono – tik nieko nesakančią nuorodą ir metaduomenis, o saugyklos keliai kuriami tik iš struktūrinių identifikatorių, niekada iš organizacijos, komandos, projekto ar žmogaus pavadinimo.

Prisijungimo duomenys, kuriuos Nessie turi laikyti pati, kad galėtų veikti kaip OAuth klientas – jungčių ir pašto dėžučių duomenys, webhook paslaptys, seanso atnaujinimo medžiaga, vykdytojo duomenys – užplombuojami paskirčiai skirtuose AES-256-GCM vokuose, naudojant versijuojamą raktų žiedą, kuris yra atskira šaknis nuo seanso pasirašymo paslapties, o rotacijos tvarka yra dokumentuota.

Yra ir taisyklė dėl modelių: apie slaptos reikšmės egzistavimą žinoti galima ir naudoti ją galima leisti, bet pati slapta medžiaga negali patekti į modelio kontekstą, užklausas, įrankių argumentus, įrankių rezultatus, atmintį, įterpinius, paiešką, žurnalus ar žinutes. Agentui galima suteikti teisę slaptą reikšmę naudoti. Teisės jos atskleisti jam negalima suteikti niekada.

Ar pagrindiniai diskai užšifruoti, priklauso nuo kompiuterio, kuriame veikia diegimas. Saugykla neįrodo, kad duomenų bazės ir objektų saugyklos tomai šifruojami tomo lygiu, todėl šis puslapis to netvirtina.

Nuomininkų izoliacija

Nessie pagal paskirtį yra daugianuomė: viena duomenų bazė, kurioje kiekviena eilutė priklauso lygiai vienai organizacijai, o kiekviena pavaldi lentelė turi stulpelį organization_id. Izoliacija užtikrinama dviejose vietose – apimties sąlyga, kurią turi kiekviena užklausa, ir tikrais išoriniais raktais šiame stulpelyje; jie buvo pridėti keturiasdešimt dviem apribojimais po vidinio audito, kuris nustatė, kad stulpelis yra, bet dešimtyse lentelių nėra apribojimų.

Atitikties testų rinkinys šią taisyklę išlaiko HTTP riba. Jis sukuria maksimaliai privilegijuotą užpuoliką – visateisį savo organizacijos savininką – ir tikrina, kad kiekvienas kanoninis kitos organizacijos išteklių skaitymas baigiasi 403, 404 arba tuščiu atsakymu, o kiekvienas kanoninis pakeitimas atmetamas nepalietus kitos organizacijos eilutės. Jis apima kanalus, patvirtinimus, audito žurnalą, paleidiklius, agentus ir jų susiejimus, paleidimus, projektus, užduotis, gijas, jungtis, darbo eigų diegimus, MCP egzempliorius, žinių bazę ir įspėjimus.

Tiksliai apie mechanizmą: tai yra taikomojo lygmens užtikrinimas ir išoriniai raktai, o ne PostgreSQL eilučių lygio saugumas. RLS politikos nėra ir duomenų bazės pusėje atsarginės apsaugos nėra, o atitikties rinkinys vykdomas ne su gyva duomenų baze, o su ištikimu atminties saugykla, todėl jis įrodo apimties sąlygas, kurias rašo kodas, o ne SQL, kurį vykdo serveris. Tai pasakyta paties rinkinio dokumentacijoje saugykloje, ir tą patį sakoma čia.

Audito pėdsakas

Užfiksuojamas kiekvienas reikšmingas veiksmas: kas veikė ir kaip – žmogus, agentas ar paslauga, – ką padarė, su kuriuo ištekliumi, kurioje organizacijoje, projekte, komandoje ar kanale, ar veiksmas pavyko, ar buvo atmestas, kodėl, taip pat užklausos identifikatorius, adresas ir naudotojo agentas, su kuriais jis atėjo.

Žurnalas pagal paskirtį yra tik papildomas, ir iš išorės į jį įrašyti neįmanoma: POST /api/audit-log neegzistuoja, ir tai daroma sąmoningai. Įrašai sujungti grandine – kiekvienas turi savo kanoninių laukų SHA-256 santrauką ir ankstesnio tos organizacijos įrašo santrauką, todėl pakeista ar pašalinta eilutė nutraukia grandinę ir tai galima aptikti. Organizacijos savininkas ar administratorius gali bet kada pereiti šią grandinę ir sužinoti, kur ji pirmą kartą nutrūko, jei nutrūko.

Dvi sąžiningos išlygos. Grandinė daro žurnalą akivaizdžiai pažeidžiamą, bet ne apsaugotą nuo klastojimo: už jos nėra duomenų bazės lygio rašymo atšaukimo ar vieną kartą įrašomos saugyklos, todėl garantija yra aptikimas, o ne prevencija. O įrašai pagal numatytuosius nustatymus saugomi neribotai – konfigūruojamas saugojimo terminas su eksportu prieš ištrynimą yra suprojektuotas, bet nesukurtas. Be to, įrašams uždrausta turėti slaptų duomenų ar pilnus užklausų kūnus, o nustatytas jautrių metaduomenų laukų pavadinimų rinkinys įrašant paslepiamas.

Išlaidų žurnalas

Kiekvienas modelio iškvietimas įrašomas prie organizacijos ir prie naudotojo, komandos, projekto, kanalo, agento ir paleidimo, iš kurių jis atėjo, su sunaudotais žetonais, o teikėjo nurodyta kaina ir paties Nessie įvertis laikomi šalia. Rodiklis, kurio teikėjas nenurodo, saugomas kaip null, o ne atspėjamas. Ataskaitas gali skaityti organizacijos savininkas ar administratorius.

Šis žurnalas yra eksploatacinė telemetrija – kiek organizacija išleido ir kieno vardu. Tai nėra sąskaita faktūra ir nėra atsiskaitymo autoritetas.

Trečiosios šalys, kai naudojate talpinamą produktą

Talpinamas diegimas bendrauja su nedideliu, pastoviu paslaugų rinkiniu. Modelių srautas ir žiniatinklio paieška tiesiogiai pas teikėjus neina: abu išeina per vieną UnlikeOtherAI valdomą šliuzą, už kurio yra aukštutiniai modelių ir paieškos teikėjai. Prisijungimas ir atsiskaitymas eina į UnlikeOtherAI autentifikatorių. Slaptų duomenų saugykla savarankiškai talpinama kartu su programa. Serverio sugeneruotos vaizdo skambučių nuorodos pagal numatytuosius nustatymus naudoja viešąją Jitsi paslaugą.

Beveik viskas kita išjungta, kol operatorius to nesukonfigūruoja, ir apie tai pasakoma, užuot tyliai nepavykus: prijungtos Google, Microsoft ir Slack paskyros; agentų el. paštas per Amazon SES, kurį diegimas vykdo savo paskyroje be tarpininko; mobilieji ir naršyklės tiesioginiai pranešimai; tyrimų ir lentos šaltinių jungtys; debesų naršyklės. Dvi detalės verta paminėti, nes jos keičia, kur keliauja duomenys:

• Prijungtos pašto dėžutės lieka pas jūsų teikėją. Paštas skaitomas tiesiogiai iš jūsų teikėjo, per IMAP ir SMTP arba per paties teikėjo prisijungimą; Nessie saugo užplombuotus prisijungimo duomenis ir daugiau nieko apie paskyrą. Išimtis – pašto dėžutė, kurią prijungiate prie klientų skyriaus gautųjų: prašote, kad jos pokalbiai būtų saugomi prie kiekvieno kliento, todėl jie nukopijuojami.
• Balso skambučiai per Nessie neeina. API tarpininkauja suteikdama prisijungimo duomenis, o garso ryšį klientas atidaro pats. Diktavimas ir telefono skambučiai yra kitokie: jų garsas eina per Nessie pas kalbos ir modelių teikėjus, kurie jį apdoroja.

Su tuo pačiu principu susijusi viena išvados detalė: pasirašytos skambinančiojo tapatybės antraštės siunčiamos tik sukonfigūruotam pokalbių serveriui, todėl nukreipus įterpinius į kitą galinį tašką, tam taškui niekada neperduodamas įgaliojimo teiginys apie žmogų, kurio tekstas įterpiamas.

Talpinamas produktas naudoja kelis išvadų teikėjus ir renkasi tarp jų pagal kainą bei kokybę. Organizacija galės administravimo skiltyje pasirinkti, kuriuos teikėjus gali naudoti jos agentai: tik vakarietiškus, tik europietiškus, tik kiniškus arba be pirmenybės – efektyviausią teikėją kiekvienam darbui. Savarankiškai talpinamas egzempliorius pasirenka savo.

Pats talpindami, pakeičiate visa tai

Kiekviena aukščiau minėta trečioji šalis savarankiškai talpinamame egzemplioriuje yra konfigūravimo pasirinkimas. Išvadas galima nukreipti į bet kurį su OpenAI suderinamą galinį tašką, įskaitant tą, kuris veikia jūsų pačių įrangoje. Jungtys išjungtos, kol jų neįjungsite. Prisijungimas per UnlikeOtherAI yra palaikomas kelias, o diegimas be jokio tapatybės teikėjo veikia kaip viena nesusieta organizacija su pradiniu savininku.

Tame ir yra visos tvarkos esmė: programinė įranga ta pati, o sprendimai, kur ji veikia ir ką gali pasiekti, priklauso tam, kas ją paleidžia. Kaip tai padaryti, aprašyta diegimo puslapyje.