Произведено во ЕУ и каде се чуваат вашите податоци

Каде е изграден Nessie, каде се чуваат вашите податоци и што контролирате кога го хостирате сами.

Кој го гради и според кој закон

Nessie го гради UnlikeOtherAI s.r.o., компанија регистрирана во Чешка која работи според чешкото право.

Оваа страница опишува како е изграден софтверот и каде работи. Не е изјава за усогласеност: Nessie нема никаков безбедносен сертификат и ништо овде не треба да се чита како таков. Кои лични податоци се обработуваат и врз која основа е предмет на политиката за приватност, која е посебна страница.

Каде работи хостираниот производ

Nessie Cloud работи на европски хостинг провајдери — Scaleway, Hetzner и други. Од секој провајдер ја избираме најдобрата услуга, па различни делови од производот може да работат кај различни провајдери, сите во Европа.

Нешто попрецизно од тоа — одредена локација, град или податочен центар — намерно не се наведува овде, бидејќи би застарело, а никој не би забележал.

Со сопствен хостинг изборот е ваш

Каде работи инстанцата на сопствен хостинг е поставка на распоредувањето, не поставка на производот. Патеката со една машина е Docker Compose стек што го поставувате на машина по ваш избор. Во Terraform-дрвото за управуван облак, регионот е влезен параметар без никаква стандардна вредност: ништо таму не може да се погоди, па затоа ништо таму нема стандардна вредност, а базата на податоци, складиштето за објекти и сервисите го следат регионот што ќе го наведете.

За истото прашање важат уште две структурни детали. Редицата и преносот во реално време се и двете PostgreSQL — нема Redis ниту брокер на пораки на патеката, па нема трет систем што треба да се смести. А складиштето на објекти е компатибилно со S3, а не врзан за еден производител; референтното распоредување користи MinIO во контејнер на приватна мрежа без свој влез. Деловите што мора да живеат некаде се базата на податоци, складиштето на објекти и двата Node сервиса, и сите живеат таму каде што ќе ги ставите. Како да го поставите тоа е објаснето на страницата за инсталација.

Што чува Nessie — и што намерно не чува

Идентитетот не се копира

Со најава преку UnlikeOtherAI, провајдерот на идентитет го управува и го чува човечкиот идентитет — факторите за автентикација, профилите, членството во организација и тим, и поканите. Nessie е доверлива страна (relying party), а не втор систем за идентитет. Ова е одлука за податоците колку и за архитектурата: идентитет што Nessie никогаш не го чува е идентитет што не може да го открие, да го изгуби или да не го избрише.

Табелата users всушност ги чува: стабилниот кориснички идентификатор од провајдерот — клучот преку кој се решава сè друго —, адресата на е-пошта, неавторитативно огледало на прикажаното име и аватарот, и полиња локални за производот (преференции, заменки, верзија на токен со која се поништуваат сесии). Огледалото постои само за да може да се прикаже име и слика без барање по ред, а се синхронизира од проверените тврдења на провајдерот при најава, при промена на тим и при обновување на сесијата. Ништо не измислува вредност: лице што провајдерот не го именувал ја носи својата адреса на е-пошта додека не го стори тоа. Хеш на лозинка постои само за почетниот сопственик на инсталација без провајдер на идентитет.

Истото важи и за структурата. Една организација кај провајдерот е една организација во Nessie, поврзана преку идентификаторот на организацијата кај провајдерот; тим без врска нагоре одговара со 404 TEAM_NOT_LINKED наместо да се враќа на локално погодување, а читањето на тековниот список на членови оди до провајдерот на идентитет и не зачувува ништо.

Две огледала сѐ уште не се отстранети и би било нечесно да се сугерира спротивното. Имињата на организацијата и тимот сè уште се чуваат локално покрај идентификаторите на врската, а локалните редови за членство сè уште овластуваат обични барања меѓу синхронизациите. Отстранувањето на двете е следена, отворена работа во репозиториумот, а не нешто веќе завршено.

Ништо комерцијално

Централната услуга за наплата ги управува плаќањата. Nessie не чува клиент кај давател на плаќања, претплата, фактура, цена, салдо на кредити, политика за дополнување, согласност за плаќање, извод ниту состојба на откажување, и не пресметува тарифи. Чита вредности подготвени за приказ и ги прикажува.

Тајни

За да се чува тајна воопшто, потребен е конфигуриран трезор. Намерно нема резервна опција во базата ниту патека со чист текст: без трезор, зачувувањето, ротирањето и отповикувањето на тајна враќаат грешка наместо да се претворат во нешто помалку безбедно. Сопствените записи на Nessie за тајната не содржат вредност, шифриран текст, клуч ниту токен за трезорот — само непроѕирна референца и нејзините метаподатоци — а патеките во трезорот се градат само од структурни идентификатори, никогаш од името на организација, тим, проект или лице.

Акредитивите што Nessie мора сам да ги чува за да дејствува како OAuth клиент — акредитиви за конектори и поштенски сандачиња, тајни за webhook, материјал за обновување на сесии, содржини на извршители — се запечатени во AES-256-GCM обвивки врзани за намена, под верзиран прстен на клучеви кој е посебен корен од тајната за потпишување на сесии, со документирана постапка за ротација.

Постои и правило за моделите: може да се знае дека тајната постои и може да се овласти нејзино користење, но материјалот на тајната не смее да влезе во контекстот на моделот, во инструкциите, во аргументите или резултатите на алатките, во меморијата, во вградувањата, во пребарувањето, во дневниците или во пораките. На агент може да му се даде способност да ја користи тајната. Никогаш не може да му се даде способност да ја открие.

Дали основните дискови се шифрирани е својство на машината на која работи распоредувањето. Репозиториумот не утврдува шифрирање на ниво на волумен за волумените на базата на податоци и на складиштето на објекти, па оваа страница не тврди такво нешто.

Изолација на тенантите

Nessie е мултитенантски по дизајн: една база на податоци во која секој ред припаѓа на точно една организација и секоја подредена табела носи organization_id. Изолацијата се спроведува на две места — во клаузулата за опсег што ја носи секое барање и во вистински надворешни клучеви на таа колона, кои беа додадени преку четириесет и две ограничувања откако внатрешна ревизија откри дека колоната постои, но на десетици табели не е ограничена.

Збир од тестови за усогласеност го држи тој инвариант на границата на HTTP. Тој создава максимално привилегиран напаѓач — полноправен сопственик на сопствена организација — и тврди дека секое канонско читање на ресурсите на друга организација враќа 403, 404 или празно, а секоја канонска мутација се одбива, при што редот на другата организација останува недопрен. Опфаќа канали, одобрувања, дневник на ревизија, активатори, агенти и нивните врски, извршувања, проекти, задачи, нишки, конекции, инсталации на работни текови, MCP инстанци, базата на знаење и известувања.

Прецизно за механизмот: ова е спроведување на ниво на апликација плус надворешни клучеви, а не PostgreSQL безбедност на ниво на ред (row-level security). Нема RLS политика ниту резервна заштита од страна на базата, а збирот од тестови работи врз верна меморија, а не врз жива база на податоци, па докажува кои клаузули за опсег ги пишува кодот, а не кој SQL го извршува серверот. Репозиториумот го вели тоа во документацијата на самите тестови, а го вели и оваа страница.

Трага за ревизија

Секоја значајна акција се бележи: кој дејствувал и како што — лице, агент, сервис — што направил, врз кој ресурс, во која организација, проект, тим или канал, дали успеало или било одбиено, зошто, како и идентификаторот на барањето, адресата и корисничкиот агент со кои пристигнало.

Дневникот е само за додавање по дизајн и не постои начин да се пишува во него однадвор: POST /api/audit-log не постои, и тоа е намерно. Записите се поврзани во синџир — секој носи SHA-256 дигест на сопствените канонски полиња плус дигестот на претходниот запис за таа организација — па изменет или отстранет ред го прекинува синџирот и може да се открие. Сопственик или администратор на организацијата може да го помине синџирот на барање и му се кажува каде прво се прекинал, ако се прекинал.

Две искрени ограничувања. Синџирот го прави дневникот со откривање на неовластена измена, а не имун на неовластена измена: зад него нема отповикување на запишувањето на ниво на база ниту складирање еднаш-за-пишување, па гаранцијата е откривање, а не спречување. И записите стандардно се чуваат неограничено — конфигурабилното чување со извоз пред бришење е дизајнирано, но не и изградено. На записите им е забрането да носат тајни или цели тела на барања, а фиксен збир на чувствителни имиња на метаподатоци се маскира при внесувањето.

Книга на трошоци

Секое повикување на модел се бележи кај организацијата, а кај корисникот, тимот, проектот, каналот, агентот и извршувањето од кои потекнува, со потрошените токени, при што трошокот пријавен од провајдерот и сопствената проценка на Nessie се чуваат една до друга. Метрика што провајдерот не ја пријавува се чува како null, а не се погодува. Извештаите може да ги чита сопственик или администратор на организацијата.

Оваа книга е оперативна телеметрија — што потрошила организацијата и во чие име. Не е фактура и не е авторитет за наплата.

Трети страни, кога го користите хостираниот производ

Хостираното распоредување комуницира со мал, фиксен збир на сервиси. Сообраќајот на моделите и веб-пребарувањето не одат директно до провајдерите: и двете излегуваат преку еден гејтвеј што го води UnlikeOtherAI, а таму се наоѓаат надворешните провајдери на модели и пребарување. Најавата и наплатата одат до автентикаторот на UnlikeOtherAI. Трезорот за тајни е на сопствен хостинг заедно со апликацијата. Врските за видеоповици создадени од серверот стандардно користат јавниот сервис Jitsi.

Речиси сè друго е исклучено додека оператор не го конфигурира, и тоа го вели наместо тивко да откаже: поврзани сметки на Google, Microsoft и Slack; е-пошта на агент преку Amazon SES, што распоредувањето го води во своја сметка без посредник; мобилни и прелистувачки известувања (push); конектори за истражување и извори на табли; облачни прелистувачи. Два детали вреди да се наведат бидејќи менуваат каде одат податоците:

• Поврзаните поштенски сандачиња остануваат кај вашиот провајдер. Поштата се чита во живо од вашиот провајдер, преку IMAP и SMTP или преку најавата на самиот провајдер; Nessie ја чува запечатената акредитација и ништо друго за сметката. Сандаче што го поврзувате со влезното сандаче на Клиенти е исклучок: барате разговорите од него да се чуваат кај секој клиент, па затоа се копираат.
• Гласовните повици во апликацијата не поминуваат низ Nessie. API-то посредува акредитив, а клиентот самиот ја отвора аудио врската. Диктирањето и телефонските повици се различни: нивното аудио поминува низ Nessie до провајдерите на говор и модели што го обработуваат.

Еден детаљ за инференцијата го следи истиот принцип: потпишаните заглавија со идентитет на повикувачот се испраќаат само до конфигурираниот хост за разговор, па насочувањето на вградувањата кон друг ендпоинт никогаш не му дава на тој ендпоинт тврдење за делегација за лицето чиј текст се вградува.

Хостираниот производ користи неколку провајдери на инференција и избира меѓу нив според цената и квалитетот. Организацијата ќе може во Admin да избере кои провајдери смеат да ги користат нејзините агенти: само западни, само европски, само кинески или без преференција — најефикасниот провајдер за секоја работа. Инстанцата на сопствен хостинг си избира сама.

Ако го водите сами, сето ова се менува

Секоја трета страна погоре е избор на конфигурација на инстанца на сопствен хостинг. Инференцијата може да се насочи кон кој било ендпоинт компатибилен со OpenAI, вклучително и таков на ваш хардвер. Конекторите се исклучени освен ако ги вклучите. Најавата преку UnlikeOtherAI е поддржаната патека, а распоредување без провајдер на идентитет работи како една неврзана организација со почетен сопственик.

Токму тоа е смислата на аранжманот: софтверот е ист, а одлуките каде работи и до што смее да допре му припаѓаат на оној што го води. Како, е објаснето на страницата за инсталација.