Eiropā radīts, un tur atrodas jūsu dati

Kur tiek veidots Nessie, kur atrodas jūsu dati un ko jūs kontrolējat, ja to uzstādāt paši.

Kas to veido un saskaņā ar kādiem tiesību aktiem

Nessie veido UnlikeOtherAI s.r.o. — uzņēmums, kas reģistrēts Čehijā un darbojas saskaņā ar Čehijas tiesību aktiem.

Šī lapa apraksta, kā programmatūra ir uzbūvēta un kur tā darbojas. Tas nav atbilstības apliecinājums: Nessie nav nevienas drošības sertifikācijas, un nekas šeit rakstītais nav jāuztver kā tāda. Kādi personas dati tiek apstrādāti un uz kāda pamata, ir aprakstīts privātuma politikā, kas ir atsevišķa lapa.

Kur darbojas mitinātais produkts

Nessie Cloud darbojas pie Eiropas mitināšanas pakalpojumu sniedzējiem — Scaleway, Hetzner un citiem. Mēs izvēlamies labāko pakalpojumu, ko piedāvā katrs sniedzējs, tāpēc dažādas produkta daļas var darboties pie dažādiem sniedzējiem, visi — Eiropā.

Nekas precīzāks par to — konkrēta vieta, pilsēta vai datu centrs — šeit apzināti netiek minēts, jo šī informācija novecotu, un neviens to nepamanītu.

Pašmitināšana izvēli atstāj jūsu rokās

Tas, kur darbojas pašmitināta instance, ir izvietošanas iestatījums, nevis produkta iestatījums. Vienas ierīces variants ir Docker Compose komplekts, ko novietojat jūsu izvēlētā ierīcē. Terraform konfigurācijā pārvaldītam mākonim reģions ir ievades parametrs bez jebkādas noklusējuma vērtības: neko tur nevar uzminēt, tāpēc tur nekam nav noklusējuma, un datubāze, objektu krātuves tvertne un pakalpojumi visi seko jūsu norādītajam reģionam.

Šim pašam jautājumam svarīgas vēl divas strukturālas detaļas. Rinda un reāllaika transports abi ir PostgreSQL — ceļā nav ne Redis, ne ziņojumu brokera, tātad nav trešās sistēmas, kas jānovieto. Un objektu krātuve ir saderīga ar S3, nevis piesaistīta vienam piegādātājam; atsauces izvietojumā MinIO darbojas konteinerā privātā tīklā bez savas ienākošās piekļuves. Daļas, kurām kaut kur jāatrodas, ir datubāze, objektu krātuve un divi Node pakalpojumi, un visas tās atrodas tur, kur jūs tās novietojat. Kā to uzstādīt, ir aprakstīts uzstādīšanas lapā.

Ko Nessie glabā — un ko apzināti neglabā

Identitāte netiek kopēta

Izmantojot UnlikeOtherAI pieteikšanos, identitātes pakalpojumu sniedzējs pārvalda un glabā cilvēku identitāti — autentifikācijas faktorus, profilus, organizācijas un komandu dalību un uzaicinājumus. Nessie ir uzticamā puse (relying party), nevis otra identitātes sistēma. Tas ir tikpat daudz datu jautājums, cik arhitektūras lēmums: identitāti, ko Nessie nekad neglabā, tas nevar nopludināt, pazaudēt vai neizdzēst.

Tabulā users faktiski tiek glabāts pakalpojumu sniedzēja stabilais lietotāja identifikators — atslēga, caur kuru tiek atrisināts viss pārējais —, e-pasta adrese, neautoritatīvs rādāmā vārda un avatāra spogulis un produkta lokālie lauki (preferences, vēlamie vietniekvārdi, tokena versija sesiju atsaukšanai). Spogulis pastāv tikai tāpēc, lai vārdu un attēlu varētu parādīt, nepieprasot katrai rindai atsevišķu pieprasījumu, un tas tiek atkārtoti sinhronizēts no pakalpojumu sniedzēja verificētajiem apgalvojumiem pieteikšanās brīdī, komandas maiņas brīdī un sesijas atsvaidzināšanas brīdī. Nekas neizdomā vērtību: cilvēkam, kuru pakalpojumu sniedzējs nav nosaucis vārdā, tiek rādīta e-pasta adrese, kamēr tas nav noticis. Paroles jaucējkods pastāv tikai sākotnējam īpašniekam instalācijā, kurā identitātes pakalpojumu sniedzēja nav vispār.

Tas pats attiecas uz struktūru. Viena pakalpojumu sniedzēja organizācija ir viena Nessie organizācija, kas saistīta ar pakalpojumu sniedzēja organizācijas identifikatoru; komanda bez augšupējās saites atbild ar 404 TEAM_NOT_LINKED, nevis atkāpjas uz vietēju minējumu, un dzīvs saraksta nolasījums tiek veikts pie identitātes pakalpojumu sniedzēja un neko nesaglabā.

Divi spoguļi vēl nav likvidēti, un būtu negodīgi to noklusēt. Organizāciju un komandu nosaukumi joprojām tiek glabāti lokāli līdzās saistīšanas identifikatoriem, un vietējās dalības rindas starp sinhronizācijām joprojām pilnvaro parastos pieprasījumus. Abu noņemšana ir repozitorijā izsekots, vēl neizpildīts darbs, nevis kaut kas jau paveikts.

Nekā komerciāla

Maksājumus pārvalda centrālais norēķinu pakalpojums. Nessie neglabā ne maksājumu pakalpojumu sniedzēja klientu, abonementu, rēķinu, cenu, kredīta atlikumu, papildināšanas politiku, maksājuma piekrišanu, izrakstu, ne atcelšanas stāvokli, un tas neaprēķina tarifus. Tas nolasa attēlošanai gatavas vērtības un parāda tās.

Noslēpumi

Lai noslēpumu vispār varētu glabāt, ir nepieciešams konfigurēts seifs. Apzināti nav ne datubāzes rezerves varianta, ne atklāta teksta ceļa: bez seifa noslēpuma saglabāšana, rotēšana un atsaukšana atgriež kļūdu, nevis pāriet uz kaut ko mazāk drošu. Nessie paša ieraksti par noslēpumu nesatur ne vērtību, ne šifrtekstu, ne atslēgu, ne seifa tokenu — tikai necaurskatāmu atsauci un tās metadatus —, un seifa ceļi tiek veidoti tikai no strukturāliem identifikatoriem, nekad no organizācijas, komandas, projekta vai personas nosaukuma.

Akreditācijas dati, kas Nessie pašam jāglabā, lai darbotos kā OAuth klients — savienotāju un pastkastu akreditācijas dati, webhook noslēpumi, sesiju atsvaidzināšanas materiāls, izpildītāju datu paketes —, ir noslēgti mērķim piesaistītās AES-256-GCM aploksnēs ar versionētu atslēgu kopu, kas ir atsevišķa sakne no sesiju parakstīšanas noslēpuma, ar dokumentētu rotācijas procedūru.

Ir arī noteikums par modeļiem: noslēpumu var zināt kā esošu un var pilnvarot to izmantot, bet noslēpuma materiāls nedrīkst nonākt modeļa kontekstā, uzvednēs, rīku argumentos, rīku rezultātos, atmiņā, iegultnēs, meklēšanā, žurnālos vai ziņojumos. Aģentam var piešķirt iespēju noslēpumu izmantot. Tam nekad nevar piešķirt iespēju to atklāt.

Tas, vai pamatā esošie diski ir šifrēti, ir īpašība ierīcei, kurā izvietojums darbojas. Repozitorijs nenosaka datubāzes un objektu krātuves sējumu šifrēšanu sējuma līmenī, tāpēc šī lapa to nepiesaka.

Nomnieku izolācija

Nessie pēc dizaina ir daudznomnieku sistēma: viena datubāze, kurā katra rinda pieder tieši vienai organizācijai un katrai pakārtotajai tabulai ir organization_id. Izolācija tiek nodrošināta divās vietās — ar darbības jomas klauzulu, ko nes katrs vaicājums, un ar īstām ārējām atslēgām uz šo kolonnu, kas pievienotas četrdesmit divos ierobežojumos pēc tam, kad iekšējā revīzija atklāja, ka desmitiem tabulu šī kolonna ir, bet nav ierobežota.

Atbilstības testu komplekts šo invariantu notur HTTP robežā. Tas izveido maksimāli privileģētu uzbrucēju — savas organizācijas pilntiesīgu īpašnieku — un pārbauda, ka katrs kanoniskais citas organizācijas resursu lasījums atbild ar 403, 404 vai tukšu rezultātu, un katra kanoniskā izmaiņa tiek noraidīta, atstājot citas organizācijas rindu neskartu. Tas aptver kanālus, apstiprinājumus, audita žurnālu, trigerus, aģentus un to piesaistes, izpildes, projektus, uzdevumus, pavedienus, savienojumus, darbplūsmu instalācijas, MCP instances, zināšanu bāzi un brīdinājumus.

Precīzi par mehānismu: tā ir lietojumprogrammas līmeņa ieviešana plus ārējās atslēgas, nevis PostgreSQL rindu līmeņa drošība (RLS). Nav nevienas RLS politikas un nav datubāzes puses rezerves aizsardzības, un atbilstības testu komplekts darbojas pret uzticamu atmiņas krātuvi, nevis dzīvu datubāzi, tāpēc tas pierāda klauzulas, ko raksta kods, nevis SQL, ko izpilda serveris. Repozitorijs to norāda paša komplekta dokumentācijā, un to norāda arī šī lapa.

Audita pēdas

Tiek reģistrēta katra nozīmīga darbība: kas rīkojās un kādā statusā — cilvēks, aģents, pakalpojums —, ko tas darīja, ar kuru resursu, kurā organizācijā, projektā, komandā vai kanālā, vai tas izdevās vai tika atteikts, kāpēc, un ar kādu pieprasījuma ID, adresi un lietotāja aģentu tas tika saņemts.

Žurnāls pēc dizaina ir tikai papildināms, un tajā nevar rakstīt no ārpuses: POST /api/audit-log nepastāv, un tas ir apzināti. Ieraksti ir saistīti ķēdē — katrs satur sava kanoniskā lauku kopuma SHA-256 jaucējkodu plus tās pašas organizācijas iepriekšējā ieraksta jaucējkodu —, tāpēc mainīta vai noņemta rinda pārtrauc ķēdi un tiek atklāta. Organizācijas īpašnieks vai administrators pēc pieprasījuma var šo ķēdi izstaigāt un uzzināt, kur tā pirmoreiz pārtrūkusi, ja tā ir pārtrūkusi.

Divas godīgas atrunas. Ķēde padara žurnālu manipulāciju atklājošu, nevis pret manipulācijām imūnu: aiz tā nav ne datubāzes līmeņa rakstīšanas tiesību atsaukšanas, ne vienreiz rakstāmas krātuves, tāpēc garantija ir atklāšana, nevis novēršana. Un ieraksti pēc noklusējuma tiek glabāti neierobežoti ilgi — konfigurējama glabāšana ar eksportu pirms dzēšanas ir izprojektēta, bet nav uzbūvēta. Ierakstiem arī aizliegts saturēt noslēpumus vai pilnus pieprasījumu pamattekstus, un fiksēts jutīgu metadatu lauku nosaukumu kopums tiek aizklāts, tiem ienākot.

Izmaksu virsgrāmata

Katrs modeļa izsaukums tiek reģistrēts pret organizāciju un pret lietotāju, komandu, projektu, kanālu, aģentu un izpildi, no kuras tas cēlies, ar patērētajiem tokeniem, blakus glabājot gan pakalpojumu sniedzēja ziņoto izmaksu, gan Nessie paša aplēsi. Rādītājs, ko pakalpojumu sniedzējs nezino, tiek glabāts kā null, nevis uzminēts. Pārskatus var nolasīt organizācijas īpašnieks vai administrators.

Šī virsgrāmata ir operatīvā telemetrija — ko organizācija iztērējusi un kā vārdā. Tas nav rēķins un nav norēķinu autoritāte.

Trešās puses, ja izmantojat mitināto produktu

Mitinātais izvietojums sazinās ar nelielu, fiksētu pakalpojumu kopu. Modeļu datplūsma un tīmekļa meklēšana nenonāk tieši pie pakalpojumu sniedzējiem: abas iziet cauri vienai vārtejai, ko darbina UnlikeOtherAI, un tur atrodas augšupējie modeļu un meklēšanas pakalpojumu sniedzēji. Pieteikšanās un norēķini notiek caur UnlikeOtherAI autentifikatoru. Noslēpumu seifs tiek pašmitināts līdzās lietojumprogrammai. Servera izveidotās videozvanu saites pēc noklusējuma izmanto publisko Jitsi pakalpojumu.

Gandrīz viss pārējais ir izslēgts, līdz operators to konfigurē, un par to paziņo, nevis klusi neizdodas: pievienotie Google, Microsoft un Slack konti; aģentu e-pasts, izmantojot Amazon SES, ko izvietojums darbina savā kontā bez starpnieka; mobilie un pārlūka push paziņojumi; pētniecības un dēļu avotu savienotāji; mākoņpārlūki. Divas detaļas ir vērts minēt, jo tās maina, kur dati nonāk:

• Pievienotās pastkastes paliek pie jūsu pakalpojumu sniedzēja. Pasts tiek lasīts tiešsaistē no jūsu sniedzēja, izmantojot IMAP un SMTP vai paša sniedzēja pieteikšanos; Nessie glabā noslēgtos akreditācijas datus un neko citu par kontu. Pastkaste, ko pievienojat sadaļas Klienti iesūtnei, ir izņēmums: jūs lūdzat, lai tās sarunas tiktu glabātas pie katra klienta, tāpēc tās tiek nokopētas.
• Balss zvani lietotnē neiet cauri Nessie. API izsniedz akreditācijas datus, un klients pats atver audio savienojumu. Diktēšana un tālruņa zvani ir citādi: to audio iet caur Nessie uz runas un modeļu sniedzējiem, kas to apstrādā.

Viena secināšanas detaļa seko tam pašam principam: parakstītas zvanītāja identitātes galvenes tiek sūtītas tikai konfigurētajam tērzēšanas resursdatoram, tāpēc iegultņu novirzīšana uz citu galapunktu šim galapunktam nekad nenodod deleģēšanas apgalvojumu par personu, kuras teksts tiek iegults.

Mitinātais produkts izmanto vairākus secināšanas sniedzējus un izvēlas starp tiem pēc izmaksām un kvalitātes. Organizācija administratorā varēs izvēlēties, kurus sniedzējus tās aģenti drīkst izmantot: tikai Rietumu, tikai Eiropas, tikai Ķīnas vai bez preferences — katram darbam efektīvākais sniedzējs. Pašmitināta instance izvēlas pati.

Ja to darbināt paši, viss šis mainās

Katra iepriekš minētā trešā puse pašmitinātā instancē ir konfigurācijas izvēle. Secināšanu var novirzīt uz jebkuru ar OpenAI saderīgu galapunktu, arī uz tādu, kas darbojas jūsu pašu aparatūrā. Savienotāji ir izslēgti, kamēr tos neieslēdzat. UnlikeOtherAI pieteikšanās ir atbalstītais ceļš, un izvietojums bez identitātes pakalpojumu sniedzēja vispār darbojas kā viena nesaistīta organizācija ar sākotnējo īpašnieku.

Tā ir visas šīs kārtības jēga: programmatūra ir tā pati, bet lēmumi par to, kur tā darbojas un ko tā drīkst sasniegt, pieder tam, kas to darbina. Kā to izdarīt, ir aprakstīts uzstādīšanas lapā.