Коли ми починали презентувати наш ШI-бот корпоративним клiєнтам, перше питання завжди було одне й те саме: що станеться, якщо вiн змiнить нашi данi? Це обґрунтоване занепокоєння. У вас є робочий iнстанс Odoo, на якому тримається весь бiзнес - продажi, склад, бухгалтерiя, HR. Надавати ШI-iнструменту доступ до цiєї системи звучить ризиковано. Тому ми спроектували архiтектуру так, щоб бот фiзично не мiг записувати, оновлювати чи видаляти будь-що.
Основа проста: бот пiдключається до Odoo через XML-RPC, використовуючи окремий сервiсний обліковий запис iз суворо обмеженими правами лише на читання. Це не програмний перемикач, який ми можемо випадково увiмкнути. Користувач Odoo, призначений для бота, має власнi права доступу на рiвнi моделей - доступ до читання моделей, якi схвалює клiєнт, i жодних дозволiв на запис/створення/видалення. Навiть якщо в нашому кодi була б помилка, що намагається виконати операцiю запису, рiвень контролю доступу Odoo вiдхилить її з помилкою AccessError.
Ми пiшли далi, нiж просто дозволи Odoo. У iнтеграцiйному шарi бота взагалi не реалiзовано методи запису. XML-RPC клiєнт, який ми створили, надає лише операцiї search_read, fields_get та read. Нiде в кодовiй базi немає виклику execute_kw для create, write або unlink. Це захист у глибину - навiть якщо хтось скомпрометує прикладний рiвень, iнструментарiю для змiни даних просто не iснує у розгорнутому кодi.
Зберiгання облiкових даних було ще одним критичним рiшенням. Деталi пiдключення до Odoo кожного клiєнта - URL, назва бази даних, API-ключ - зашифрованi в станi спокою за допомогою AES-256-GCM. Ключi шифрування зберiгаються окремо вiд зашифрованих даних, за принципом envelope encryption. Ми використовуємо унiкальний вектор iнiцiалiзацiї для кожної операцiї шифрування, що означає: навiть iдентичнi облiковi данi двох клiєнтiв дають абсолютно рiзнi шифротексти.
Самi API-ключi заслуговують на окрему увагу. Ми використовуємо вбудовану систему API-ключiв Odoo, а не зберiгаємо паролi. API-ключi можуть бути миттєво вiдкликанi клiєнтом з його адмiн-панелi Odoo, взагалi без нашої участi. Якщо клiєнт хоче вiдключити доступ бота, вiн видаляє API-ключ i той одразу перестає працювати. Нi заявок, нi очiкування, нi залежностi вiд нас.
Данi в процесi передачi захищенi TLS 1.3 для всiх з'єднань мiж нашим сервером бота та iнстансами Odoo клiєнтiв. Ми забезпечуємо валiдацiю сертифiкатiв - жодних пропускiв SSL-перевiрок навiть для розробки. Сам сервер бота працює на iзольованому Hetzner VPS з мiнiмальною поверхнею атаки: жодних зайвих вiдкритих портiв, автентифiкацiя лише за SSH-ключем, автоматичнi оновлення безпеки.
Одне питання, яке ми часто чуємо вiд IT-команд, - чи використовуються клiєнтськi данi для навчання ШI-моделей. Вiдповiдь - нi, i архiтектура це забезпечує. Коли користувач ставить запитання боту, ми запитуємо Odoo клiєнта щодо вiдповiдних даних, форматуємо їх у промпт, надсилаємо в API Claude i повертаємо вiдповiдь. Ми не зберiгаємо результати запитiв за межами сесiї розмови. Ми не збираємо данi для навчання. Умови API Claude прямо вказують, що вхiднi та вихiднi данi API не використовуються для навчання моделi.
Сама iсторiя розмов зберiгається у нашiй базi даних з тим самим шифруванням AES-256-GCM, що й для облiкових даних. Розмови прив'язанi до окремих користувачiв Telegram i автоматично очищаються через 30 днiв. Клiєнт може запросити негайне видалення всiх своїх даних розмов, i ми виконуємо це протягом кiлькох хвилин.
Правила записiв (record rules) в Odoo додають ще один рiвень захисту, який бiльшiсть людей не враховує. Навiть за наявностi доступу на читання, правила записiв можуть обмежувати, якi записи може бачити користувач-бот. Клiєнт може налаштувати свою Odoo так, щоб бот бачив лише записи вiд конкретних компанiй у багатофiрмовiй конфiгурацiї, або лише схваленi/опублiкованi товари, або лише певнi категорiї спiвробiтникiв. Бот автоматично успадковує всi цi обмеження, оскiльки працює як звичайний користувач Odoo.
Ми також реалiзували обмеження частоти запитiв на кiлькох рiвнях. Бот обмежує кiлькiсть запитiв на одного користувача за хвилину, щоб запобiгти зловживанням. Вiн обмежує загальну кiлькiсть запитiв на клiєнтську органiзацiю за годину, щоб запобiгти некерованим витратам. I має глобальне обмеження частоти для захисту нашої iнфраструктури. Якщо будь-який лiмiт перевищено, бот вiдповiдає ввiчливим повiдомленням, i користувач може спробувати знову згодом.
Для клiєнтiв у регульованих галузях ми надаємо детальну вiдповiдь на анкету з безпеки та можемо органiзувати аудит нашої кодової бази командою їхньої безпеки. Ми вже робили це тричi, i кожен аудит пiдтвердив, що архiтектура лише для читання є реальною, а не просто маркетингом. Один аудитор особливо зазначив, що вiдсутнiсть методiв запису в кодовiй базi є незвичною - бiльшiсть систем реалiзує методи запису, а потiм намагається блокувати їх на рiвнi дозволiв, що за своєю суттю менш безпечно.
Практичний результат усього цього полягає в тому, що наш бот обробив понад 10 000 запитiв до iнстансiв Odoo клiєнтiв без жодного iнциденту з даними. Жодних випадкових записiв, жодних витокiв даних, жодного несанкцiонованого доступу. Архiтектура лише для читання - це не просто функцiя безпеки, а основний принцип дизайну продукту, який робить можливим його впровадження на корпоративному рiвнi.