У Hurma безпека ваших даних - це фундамент, а не опція. Коли ви налаштовуєте інтеграції через API або підключаєте AI-агентів (Claude, ChatGPT та інші) за допомогою MCP (Model Context Protocol), кожна взаємодія проходить через кілька незалежних рівнів перевірки. У цій статті ми технічно, але без зайвого жаргону розберемо, які механізми стоять між зовнішнім світом і вашими HR-даними.
Наша MCP-інтеграція збудована як окремий сервіс-посередник (broker): він є OAuth-сервером для AI-агента і водночас OAuth-клієнтом для вашого інстансу Hurma. Агент ніколи не спілкується з базою даних напряму - лише через строго контрольований периметр.
Підключення штучного інтелекту та зовнішніх платформ реалізовано за сучасним стандартом OAuth 2.1.
Пароль залишається у вас. Зовнішній агент отримує доступ за протоколом authorization-code flow із розширенням PKCE (метод S256). Логін відбувається на власній сторінці Hurma; агенту й брокеру ваші облікові дані не передаються взагалі. MCP-клієнту доступні лише гранти authorization_code та refresh_token - обміняти пароль на токен (ROPC) він технічно не може.
Самостійне під’єднання агентів. Агенти реєструються автоматично (Dynamic Client Registration), тож підключити новий інструмент - це кілька кліків, а не листування з підтримкою.
Ефемерні коди й ротація токенів. Для авторизації використовуються одноразові коди, які згорають одразу після обміну. Refresh-токени ротуються - при кожному оновленні видається новий, а попередній стає недійсним, що унеможливлює їх повторне використання зловмисником. Час життя токенів налаштовується індивідуально для кожного інстансу Hurma - під ваші вимоги до балансу зручності й безпеки.
Відкликання одним рухом. Усі активні MCP-інтеграції та співробітники, що зараз тримають дійсні токени, видно в налаштуваннях Hurma. Доступ можна відкликати будь- якої миті - це запускає каскадне відкликання всіх пов’язаних токенів (і access-, і refresh-), і підключення миттєво перестає працювати.
Ми розробили багаторівневу систему перевірки прав, щоб сторонні особи не могли отримати доступ до вашого робочого простору.
Жорстка валідація кожного запиту. Перш ніж запит дійде до даних, він проходить повний ланцюжок перевірок - чи існує токен, чи не був він відкликаний, чи активний співробітник-власник, чи входить він у список дозволених для цього підключення і чи має клієнт відповідний scope на цю дію. Будь-який зрив на цьому шляху - і запит відхиляється (401/403) ще до бізнес-логіки.
Криптографічно стійкі ключі. Усі API-токени та ключі генеруються криптографічним генератором випадкових чисел (CSPRNG) із запасом ентропії в сотні біт. Підібрати такий ключ перебором технічно неможливо.
Захист акаунтів. Паролі користувачів у базі хешуються алгоритмом bcrypt. Додатково діють обмеження на кількість спроб входу (throttling) і двофакторна автентифікація (2FA) - навіть коректний пароль сам по собі не дає доступу.
Ваші дані ізольовані від інших користувачів на архітектурному рівні.
Дублювання прав аж до рівня полів. Нижній шар архітектури повторно застосовує модель прав apiv3. Через MCP підключення користувач побачить рівно те, що бачив би використовуючи api через конкретний клієнт для apiv3. Доступ до сутностей обмежується рівнем scopes, і також можно обмежити окремі поля співробітників і кандидатів.
Серверний контроль робочого простору. До якого акаунта й компанії належить запит, сервер визначає виключно з валідованого токена, а не з параметрів запиту. Підмінити ідентифікатор у тілі чи query, щоб «перенаправити» токен на чужі дані, неможливо. Кожен інстанс Hurma - окремий ізольований тенант із власним ключем підпису токенів.
Увесь обмін даними між вашими сервісами, брокером і Hurma відбувається у зашифрованому вигляді.
Токени - лише в заголовках. Токени доступу приймаються й передаються лише у спеціальному заголовку Authorization. Ми ніколи не кладемо токен у query-параметри чи URL - такі посилання могли б осісти в історії браузера, кеші проксі або системних логах. Це правило діє наскрізно: і в адмінському API, і у виклику Hurma API v3 з боку брокера.
Тільки HTTPS. На рівні інфраструктури (балансувальник навантаження / reverse-proxy) приймається виключно захищене з’єднання HTTPS; незашифрований трафік до сервісу не доходить.
Ми мінімізували поверхню атаки й ризики витоку через службові канали.
Закритий периметр. Назовні відкрито лише чітко визначений білий список безпечних маршрутів - службові ендпоінти, OAuth-потік і власне MCP. Довільні шляхи до Hurma API прокинути через брокер неможливо: адреси ендпоінтів зашиті в самих інструментах, а параметри (ідентифікатори) суворо валідуються за форматом. Усі внутрішні сервіси та бази даних живуть у приватній мережі й недоступні ззовні.
Шифрування чутливих даних у спокої. Секрети OAuth-клієнтів і збережені токени Hurma лежать у нашому сховищі не у відкритому вигляді, а зашифрованими (Fernet). Навіть у малоймовірному сценарії доступу до бази ці дані залишаються нечитабельними.
Тільки операційні логи. Ми не пишемо в логи тіла запитів/відповідей і самі токени доступу. У журнали потрапляють лише технічні метадані (ідентифікатор тенанта, шлях, код статусу), потрібні для моніторингу стабільності.
Кожен рівень - транспорт, автентифікація, авторизація, ізоляція, журналювання працює незалежно й додає власну лінію оборони. Саме тому підключення AI-агента до Hurma через MCP залишається таким самим безпечним, як і робота у звичному веб-інтерфейсі.
