Uniós fejlesztés és az adataid helye

Hol készül a Nessie, hol tárolódnak az adataid, és mit irányíthatsz, ha saját magad üzemelteted.

Ki építi, és milyen jog alatt

A Nessie-t az UnlikeOtherAI s.r.o. építi, amely Csehországban bejegyzett társaság, és a cseh jog szerint működik.

Ez az oldal azt írja le, hogyan épül a szoftver, és hol fut. Nem megfelelőségi nyilatkozat: a Nessie nem rendelkezik semmilyen biztonsági tanúsítvánnyal, és semmi az oldalon nem értelmezhető ilyenként. Azt, hogy milyen személyes adatokat kezelünk, és milyen jogalapon, az adatvédelmi tájékoztató tárgyalja, amely külön oldal.

Hol fut a szolgáltatásként kapott termék

A Nessie Cloud európai tárhelyszolgáltatókon fut — a Scalewayen, a Hetzneren és másokon. Minden szolgáltatótól a legjobb szolgáltatását választjuk, ezért a termék különböző részei különböző szolgáltatóknál futhatnak, mindegyik Európában.

Ennél pontosabbat — konkrét telephelyet, várost vagy adatközpontot — szándékosan nem közlünk itt, mert az idővel úgy avulna el, hogy senki sem venné észre.

Saját üzemeltetésnél te döntesz

Az, hogy egy saját üzemeltetésű példány hol fut, telepítési beállítás, nem termékbeállítás. Az egygépes út egy Docker Compose stack, amelyet az általad választott gépre teszel. A felügyelt felhőhöz készült Terraform-fában a régió olyan bemenet, amelynek egyáltalán nincs alapértéke: semmi nem találgatható, ezért semminek sincs alapértéke, és az adatbázis, az objektumtároló-bucket és a szolgáltatások mind az általad megnevezett régiót követik.

Ugyanennek a kérdésnek két szerkezeti részlete is számít. A sor és a valós idejű átvitel egyaránt PostgreSQL — nincs benne Redis és nincs üzenetközvetítő, így nincs egy harmadik rendszer, amelynek a helyét meg kellene határozni. Az objektumtárolás pedig S3-kompatibilis, nem köti egyetlen gyártó; a referenciatelepítés egy MinIO-t futtat konténerben, privát hálózaton, saját bejövő forgalom nélkül. Az a néhány elem, amelynek valahol élnie kell — az adatbázis, az objektumtároló és a két Node-szolgáltatás —, ott él, ahová te teszed. Hogyan állítsd fel mindezt, azt a telepítési oldalon találod.

Mit tárol a Nessie — és mit szándékosan nem

Az identitást nem másoljuk

Az UnlikeOtherAI-bejelentkezéssel az identitásszolgáltató kezeli és tárolja az emberi identitást — a hitelesítési tényezőket, a profilokat, a szervezeti és csapattagságot, valamint a meghívókat. A Nessie függő fél, nem egy második identitásrendszer. Ez ugyanannyira adatkezelési, mint építészeti döntés: az az identitás, amelyet a Nessie sosem tárol, nem szivároghat ki, nem veszhet el, és nem maradhat törlés nélkül.

A users tábla valójában a szolgáltató stabil felhasználóazonosítóját őrzi — ez a kulcs, amelyen át minden más feloldódik —, az e-mail-címet, egy nem hiteles megjelenítendőnév- és profilkép-tükröt, valamint termékoldali mezőket (beállítások, megszólítás, a munkamenetek visszavonására szolgáló tokenverzió). A tükör csak azért van, hogy egy név és egy kép soronkénti kérés nélkül megjeleníthető legyen, és a szolgáltató ellenőrzött állításaiból frissül bejelentkezéskor, csapatváltáskor és munkamenet-frissítéskor. Semmilyen értéket nem gyártunk: akit a szolgáltató még nem nevezett meg, annál az e-mail-címe szerepel, amíg meg nem történik. Jelszó-hash csak az olyan telepítés induló tulajdonosánál létezik, amelynek egyáltalán nincs identitásszolgáltatója.

Ugyanez érvényes a szerkezetre is. A szolgáltató egy szervezete a Nessie egy szervezete, a szolgáltató szervezetazonosítójához kötve; a fölérendelt kapcsolat nélküli csapat 404 TEAM_NOT_LINKED választ ad ahelyett, hogy helyi találgatásra váltana, az élő névsorolvasás pedig az identitásszolgáltatóhoz megy, és semmit nem tárol el.

Két tükör még megvan, és tisztességtelen lenne mást sugallni. A szervezet és a csapat neve még helyben is tárolódik a kötési azonosítók mellett, és a helyi tagsági sorok a szinkronizálások között még mindig ezek döntik el a hétköznapi kérések jogosultságát. Mindkettő eltávolítása követett, nyitott munka a tárolóban, nem valami, ami már kész.

Semmi kereskedelmi adat

A fizetéseket a központi számlázási szolgáltatás kezeli. A Nessie nem tárol fizetésszolgáltatói ügyfelet, előfizetést, számlát, árat, kreditegyenleget, feltöltési szabályt, fizetési hozzájárulást, kimutatást vagy lemondási állapotot, és tarifát sem számol. Megjelenítésre kész értékeket olvas be, és megmutatja őket.

Titkok

Titok tárolásához konfigurált széf kell. Szándékosan nincs adatbázisos tartalék és nincs nyílt szöveges út: széf nélkül a titok mentése, forgatása és visszavonása hibát ad, ahelyett, hogy kevésbé biztonságos megoldásra váltana. A Nessie saját nyilvántartása egy titokról nem tartalmaz értéket, titkosított szöveget, kulcsot vagy széf-tokent — csak egy átlátszatlan hivatkozást és a metaadatait —, a széf útvonalait pedig kizárólag szerkezeti azonosítókból építjük, soha nem egy szervezet, csapat, projekt vagy személy nevéből.

Azokat a hitelesítő adatokat, amelyeket a Nessie-nek magának kell őriznie ahhoz, hogy OAuth-kliensként működjön — összekötők és postafiókok hitelesítő adatai, webhook-titkok, munkamenet-frissítési anyag, executor-adatcsomagok —, célhoz kötött AES-256-GCM borítékokban zárjuk le, verziózott kulcskarika alatt, amely a munkamenet-aláíró titoktól külön gyökér, dokumentált forgatási eljárással.

A modellekre is van egy szabály: egy titokról tudható, hogy létezik, és használatra engedélyezhető, de a titkos anyag nem kerülhet a modell kontextusába, a promptokba, az eszközargumentumokba, az eszközeredményekbe, a memóriába, az embeddingekbe, a keresésbe, a naplókba vagy az üzenetekbe. Egy ügynök kaphat jogot egy titok használatára. Felfedésére soha nem kaphat jogot.

Az, hogy a mögöttes lemezek titkosítottak-e, annak a gépnek a tulajdonsága, amelyen a telepítés fut. A tároló nem állapítja meg az adatbázis- és objektumtároló-kötetek kötetszintű titkosítását, ezért ez az oldal nem állítja.

Bérlők elkülönítése

A Nessie tervezésénél fogva többbérlős: egyetlen adatbázis, amelyben minden sor pontosan egy szervezethez tartozik, és minden gyermektábla tartalmaz egy organization_id oszlopot. Az elkülönítést két helyen kényszerítjük ki — a minden lekérdezésben szereplő hatókörszűrő feltétellel, és az oszlopra tett valódi idegen kulcsokkal, amelyeket negyvenkét kényszerrel adtunk hozzá, miután egy belső audit azt találta, hogy az oszlop több tucat táblán megvan, de nincs rajta megszorítás.

Egy megfelelőségi tesztcsomag tartja helyén ezt az invariánst a HTTP-határon. Maximális jogosultságú támadót vet be — a saját szervezetének teljes jogú tulajdonosát —, és ellenőrzi, hogy egy másik szervezet erőforrásainak minden kanonikus olvasása 403-mal, 404-gyel vagy üres válasszal végződik, és minden kanonikus módosítás elutasításra kerül úgy, hogy a másik szervezet sora érintetlen marad. Lefedi a csatornákat, a jóváhagyásokat, az auditnaplót, az eseményindítókat, az ügynököket és azok kötéseit, a futásokat, a projekteket, a feladatokat, a szálakat, a kapcsolatokat, a munkafolyamat-telepítéseket, az MCP-példányokat, a tudásbázist és a riasztásokat.

A mechanizmusról pontosan: ez alkalmazásszintű kikényszerítés és idegen kulcsok, nem PostgreSQL sorszintű biztonság (row-level security). Nincs RLS-szabályzat és nincs adatbázis-oldali biztosíték, a megfelelőségi tesztcsomag pedig egy hű memóriabeli tárolón fut, nem élő adatbázison, így azt bizonyítja, hogy a kód milyen hatókörszűrő feltételeket ír, nem azt, hogy egy szerver milyen SQL-t hajt végre. A tároló ezt a tesztcsomag saját dokumentációjában kimondja, és ez az oldal is kimondja.

Az auditnapló

Minden jelentős műveletet rögzítünk: ki cselekedett és milyen minőségben — személy, ügynök vagy szolgáltatás —, mit tett, melyik erőforráson, melyik szervezetben, projektben, csapatban vagy csatornában, sikerült-e vagy megtagadták, miért, valamint a kérés azonosítóját, címét és a felhasználói ügynök (user agent) adatát, amellyel érkezett.

A napló tervezésénél fogva csak hozzáfűzhető, és kívülről nincs mód írni bele: a POST /api/audit-log nem létezik, és ez szándékos. A bejegyzések láncba vannak fűzve — mindegyik tartalmazza a saját kanonikus mezőinek SHA-256 kivonatát és az adott szervezet előző bejegyzésének kivonatát —, így a módosított vagy eltávolított sor megszakítja a láncot, és kimutatható. A szervezet tulajdonosa vagy adminisztrátora kérésre végigjárhatja ezt a láncot, és ha megszakadt, megtudja, hol szakadt meg először.

Két őszinte megszorítás. A lánc a naplót manipuláció-jelzővé teszi, nem teszi immunissá a manipulációval szemben: nincs mögötte adatbázisszintű írásvisszavonás vagy egyszer írható tárolás, így a garancia az észlelés, nem a megelőzés. A bejegyzéseket alapértelmezés szerint határidő nélkül őrizzük — a beállítható megőrzés törlés előtti exporttal tervezett, nem megépített. A bejegyzések nem hordozhatnak titkokat vagy teljes kéréstörzseket, és az érzékeny metaadat-mezőnevek rögzített készletét beíráskor kitakarjuk.

A költségnapló

Minden modellhívást rögzítünk a szervezethez, valamint ahhoz a felhasználóhoz, csapathoz, projekthez, csatornához, ügynökhöz és futáshoz rendelve, amelyből származik, a felhasznált tokenekkel, és a szolgáltató által jelentett költséggel és a Nessie saját becslésével egymás mellett. Ha egy mutatót a szolgáltató nem jelent, null értékként tároljuk, nem találgatjuk. A jelentéseket a szervezet tulajdonosa vagy adminisztrátora olvashatja.

Ez a napló működési telemetria — mennyit költött egy szervezet, és kinek a megbízásából. Nem számla, és nem számlázási hatóság.

Harmadik felek, ha a szolgáltatásként kapott terméket használod

A szolgáltatásként kapott telepítés egy kicsi, rögzített szolgáltatáskészlettel beszél. A modellforgalom és a webes keresés nem megy közvetlenül a szolgáltatókhoz: mindkettő egyetlen, az UnlikeOtherAI által üzemeltetett átjárón át távozik, amelynek mögött vannak a modell- és keresőszolgáltatók. A bejelentkezés és a számlázás az UnlikeOtherAI hitelesítőjéhez megy. A titkosszéf az alkalmazás mellett, saját üzemeltetésben fut. A szerver által generált videóhívás-linkek alapértelmezés szerint a nyilvános Jitsi szolgáltatást használják.

Szinte minden más ki van kapcsolva, amíg egy üzemeltető be nem állítja, és ezt ki is mondja, ahelyett hogy csendben hibázna: összekötött Google-, Microsoft- és Slack-fiókok; ügynöki e-mail az Amazon SES-en át, amelyet a telepítés a saját fiókjában futtat, közvetítő nélkül; mobil- és böngészős push; kutatási és táblaforrás-összekötők; felhőböngészők. Két részlet kimondásra érdemes, mert megváltoztatják, hová kerülnek az adatok:

• Az összekötött postafiókok a szolgáltatódnál maradnak. A leveleket élőben olvassuk a szolgáltatódtól, IMAP-on és SMTP-n vagy a szolgáltató saját bejelentkezésén át; a Nessie a lezárt hitelesítő adatot tárolja, a fiókról pedig mást semmit. Az Ügyfelek postaládájához csatlakoztatott postafiók kivétel: ezzel azt kéred, hogy a beszélgetései az egyes ügyfeleknél maradjanak meg, ezért átmásoljuk őket.
• Az alkalmazáson belüli hanghívások nem mennek át a Nessie-n. Az API hitelesítő adatot közvetít, a kliens maga nyitja meg a hangkapcsolatot. A diktálás és a telefonhívások mások: a hangjuk a Nessie-n át jut el a beszédet és a modelleket feldolgozó szolgáltatókhoz.

Egy következtetési részlet ugyanezt az elvet követi: az aláírt hívóazonosító-fejlécek csak a beállított csevegőhosztnak mennek el, ezért ha az embeddingeket másik végpontra irányítod, az a végpont soha nem kap delegálási állítást arról a személyről, akinek a szövegét beágyazzák.

A szolgáltatásként kapott termék több következtetési szolgáltatót használ, és költség és minőség szerint választ közülük. A szervezet az Adminban majd megadhatja, mely szolgáltatókat használhatják az ügynökei: csak nyugatit, csak európait, csak kínait, vagy nincs preferencia — minden feladathoz a leghatékonyabb szolgáltatót. A saját üzemeltetésű példány maga választ.

Ha magad üzemeltetsz, mindez megváltozik

Minden fenti harmadik fél konfigurációs választás egy saját üzemeltetésű példányon. A következtetés irányítható bármely OpenAI-kompatibilis végpontra, akár a saját gépeden futóra is. Az összekötők ki vannak kapcsolva, amíg be nem kapcsolod őket. Az UnlikeOtherAI-bejelentkezés a támogatott út, az identitásszolgáltató nélküli telepítés pedig egyetlen kötetlen szervezetként fut, induló tulajdonossal.

Ez az egész elrendezés lényege: a szoftver ugyanaz, a döntés pedig arról, hogy hol fut, és mihez férhet hozzá, azé, aki üzemelteti. Hogyan, azt a telepítési oldal mutatja.