01
Оберіть потрібні межі
Запускайте Kordon у власній інфраструктурі, коли потрібен суворіший контроль над розташуванням даних, шляхами доступу, мережевою видимістю або внутрішньою політикою хостингу.
Локальне розгортання GRC
GRC-платформа на власних серверах
Kordon може працювати у вашій власній інфраструктурі, коли внутрішня політика, межі даних або вимоги до розгортання унеможливлюють використання SaaS від постачальника. Якщо ви оцінюєте GRC-платформу для локального розгортання, ви все одно отримуєте ту саму зв'язану систему для ризиків, заходів безпеки, завдань, доказів, активів, постачальників і бізнес-процесів.
Як це працює
Від вимоги до розгортання до живої програми безпеки
Мета GRC на власних серверах — не лише місце розташування програмного забезпечення. Йдеться про те, чи продовжує система робити роботу з безпеки та відповідності операційною після розгортання у вашому середовищі.
02
Відображення реального операційного контексту
Документуйте активи, постачальників, бізнес-процеси, ризики та вимоги систем відповідності, що реально важливі для вашої організації, замість того щоб примусово вписувати все у загальний шаблон.
03
Пов'язуйте заходи безпеки з виконанням
Пов'язуйте кожен захід безпеки з ризиками, які він пом'якшує, та вимогами, яким він відповідає, а потім перетворюйте його на дієвий процес через повторювані завдання під відповідальністю людей, що виконують роботу.
04
Підтримуйте безперервний потік доказів
У міру виконання завдань накопичуються докази, аудитори отримують чітку простежуваність, а платформа відображає, чи програма працює так, як задумано, або відхиляється від заданого курсу.
Побудовано для обмежених середовищ
GRC-платформа на власних серверах без типових компромісів
Локальне розгортання повинно змінювати місце роботи платформи, а не те, що вона може робити. Kordon зберігає ту саму операційну модель, чи ви розгортаєте її у власному середовищі, чи використовуєте хмарне розгортання від нас.
Запускайте у власній інфраструктурі
Розгортайте Kordon у середовищі, яким ви управляєте, коли внутрішня політика хостингу, сегментація мережі або вимоги клієнтів роблять SaaS від постачальника неприйнятним варіантом.
Єдина зв'язана система
Ризики, заходи безпеки, вимоги, завдання, докази, активи, постачальники та бізнес-процеси залишаються зв'язаними в одному місці замість того, щоб бути розкиданими по таблицях та папках.
Заходи безпеки стають операційною роботою
Kordon перетворює регламенти та заходи безпеки на повторювані завдання, призначення власників, нагадування та докази, щоб програма продовжувала працювати у вашому середовищі замість перетворення на статичну документацію.
Підлаштуйте платформу під вашу модель
Використовуйте настроювані поля, мітки, дозволи та структуру, що відображають реальну роботу вашої організації, замість того щоб підлаштовувати програму під схему за замовчуванням від постачальника.
Залучайте більше людей до програми
Надавайте власникам заходів безпеки, власникам ризиків, аудиторам та операційним стейкхолдерам чітку видимість та відповідальність без перетворення команди безпеки на вузьке місце документування.
Зберігайте інтеграції
Доступ до API та автоматизація залишаються важливими і при локальному розгортанні. Підключайте Kordon до решти вашого технологічного стеку та підтримуйте збір доказів, робочі процеси та звітність в рамках вашого середовища.
Розгортання
Що змінюється, коли ви розгортаєте самі, а що ні
Розташування даних — це зазвичай те, що приводить на цю сторінку, і обидва способи розгортання Kordon дають на це відповідь: хмарна платформа працює у Фінляндії або Німеччині, або ви запускаєте все самостійно. У багатьох постачальників версія для самостійного розгортання є урізаною: вона на один випуск позаду хмарної або має інтеграції, які тихо повертаються через хмару постачальника. Kordon змінює лише місце розгортання.
| Хмара Kordon | Ваша власна інфраструктура | |
|---|---|---|
| Де фізично зберігаються дані | Хмара KordonУ ЄС, у країні на ваш вибір. Ви обираєте Фінляндію або Німеччину під час створення облікового запису, і дані залишаються в цьому регіоні. | Ваша власна інфраструктураТам, куди ви їх покладете. Питання розташування даних більше не потребує довіри до слова постачальника. |
| Модель об'єктів, інтерфейс, права доступу | Хмара KordonУся платформа | Ваша власна інфраструктураТа сама платформа, тієї самої версії |
| REST API та вузол n8n | Хмара KordonПовний API, офіційний вузол n8n | Ваша власна інфраструктураТой самий API, той самий вузол. Жодна можливість не зарезервована лише для хмарної версії. |
| На чому це працює | Хмара KordonНі на чому. Ми це обслуговуємо. | Ваша власна інфраструктураDocker-контейнер на звичайній Linux-інфраструктурі, налаштований через змінні середовища |
| HTTPS | Хмара KordonОбслуговуємо ми | Ваша власна інфраструктураВбудований у контейнер, тож окремий зворотний проксі піднімати не потрібно |
| Єдиний вхід | Хмара KordonGoogle Workspace, Microsoft Entra, Okta, Keycloak | Ваша власна інфраструктураТі самі чотири, вбудовані в контейнер, без потреби в окремому сервісі автентифікації поруч |
| Автоматичне створення користувачів | Хмара KordonSCIM 2.0 з Entra, Okta, OneLogin та Google Workspace | Ваша власна інфраструктураТак само |
| Де зберігаються файли доказів | Хмара KordonОбслуговуємо ми | Ваша власна інфраструктураЛокальна файлова система, Google Cloud Storage або AWS S3, у вашому власному бакеті |
| Вміст систем відповідності | Хмара KordonISO 27001, SOC 2, NIS2, DORA, E-ITS, ISO 9001, ISO 14001 та сотні інших стандартів попередньо завантажені, а також ваші внутрішні системи як власні вимоги | Ваша власна інфраструктураТа сама бібліотека, попередньо завантажена. Один захід безпеки може закривати вимоги кількох систем одночасно. Як працює управління системами відповідності → |
| Штучний інтелект та агенти | Хмара KordonПриведіть власного агента. У платформу не вбудовано жодної моделі. Агенти під'єднуються через REST API, офіційний вузол n8n та навички, створені для Kordon, у тому фреймворку, з яким ви вже працюєте. Як працює агентна GRC → | Ваша власна інфраструктураТак само, і саме це зберігає межу цілою: оскільки модель ніколи не перебуває всередині платформи, ваш агент і його обчислення можуть бути там, де вам потрібно, зокрема на обладнанні у вашій власній мережі |
| Оновлення, резервні копії, доступність, обсяг | Хмара KordonНаша відповідальність | Ваша власна інфраструктураВаша, за вашим власним графіком змін |
Поширені запитання
Розташування даних і самостійне розгортання
Чи потрібне локальне розгортання, щоб тримати дані в ЄС?
Часто ні, і це варто перевірити, перш ніж брати на себе експлуатаційне навантаження. Хмара Kordon працює в ЄС, і ви обираєте Фінляндію або Німеччину під час створення облікового запису. Якщо ваша вимога говорить про названий регіон ЄС у розумінні GDPR, на цьому питання закрите. Самостійне розгортання є відповіддю тоді, коли вимога виходить за межі географії. Так буває з національною політикою розміщення, яка називає вашу власну інфраструктуру, з галузевим правилом про те, хто може зберігати дані, з договором клієнта, що виключає спільні середовища, або з правлінням, яке не погодиться тримати СУІБ у хмарі іншої компанії. Обидва шляхи запускають ту саму платформу, тож це питання про ваші зобов'язання, а не про те, який продукт ви отримаєте. Одну річ варто запитати в будь-якого постачальника: чи регіон із маркетингових матеріалів є тим самим, що й в адресі сайту, і чи залишаються в ньому функції штучного інтелекту.
Чи є локальна версія урізаною версією платформи?
Ні. Це той самий застосунок, що й хмарний: та сама модель об'єктів, той самий повний REST API, той самий офіційний вузол n8n, та сама модель прав доступу і та сама попередньо завантажена бібліотека систем відповідності, яка охоплює ISO 27001, SOC 2, NIS2, DORA, E-ITS, ISO 9001, ISO 14001 та сотні інших стандартів, а також будь-яку внутрішню систему, яку ви додасте як власні вимоги. Самостійне розгортання — це вибір способу розгортання, а не рівень продукту. Це варто перепитати в будь-якого постачальника: часто версія для самостійного розгортання відстає на один випуск, або її інтеграції тихо проходять через хмару постачальника, що знищує сам сенс розгортання у власних межах.
Яка інфраструктура нам потрібна?
Середовище Linux, здатне запустити Docker-контейнер, і місце для зберігання файлів доказів. Уся конфігурація виконується через змінні середовища, TLS вбудований у контейнер, тож окремий зворотний проксі не потрібен, а сховище доказів може вказувати на локальну файлову систему, Google Cloud Storage або AWS S3. Kordon використовує серверну пагінацію та фільтрацію, тому залишається швидким і за десятків тисяч активів і завдань.
Де відбувається обробка штучним інтелектом при самостійному розгортанні?
Там, де ви вирішите. Kordon побудований так, щоб ви приводили власного агента: у платформу не вбудовано жодної моделі. Агенти під'єднуються через повний REST API, офіційний вузол n8n та навички, створені для Kordon, і підходить будь-який фреймворк, чи то Claude, LangChain, n8n, чи щось написане вашою власною командою. Оскільки в нас немає власної моделі, куди це надсилати, ваші докази за замовчуванням нікуди не виходять: ви скеровуєте агента на модель, що працює на вашому обладнанні, і обчислення залишаються в тих самих межах, що й дані, під тими самими правами, які діють для ваших людей. Саме це питання варто ставити будь-якому постачальнику GRC під час перевірки розташування даних, бо саме тут обіцянки зазвичай ламаються. Платформа може бути у вашому регіоні і все одно надсилати кожен документ, який опрацьовує, до моделі десь інде. Питайте, де відбувається обчислення, а не лише де стоїть база даних.
Хто встановлює оновлення і за яким графіком?
Ви самі, за власним графіком змін, що зазвичай і є сенсом самостійного розгортання. У будь-якого постачальника варто запитати, як довго підтримується конкретний випуск для самостійного розгортання, бо платформа, яку ніхто не оновлює, за пару років сама стає аудиторським спостереженням.
Чи можемо ми почати в хмарі Kordon і згодом перейти на власну інфраструктуру?
Так. Оскільки обидва варіанти розгортання запускають той самий застосунок на тій самій моделі об'єктів, програма, яку ви побудуєте в одному, — це та сама програма, яку ви запустите в іншому. Можна почати в хмарі, поки ви ще формуєте набір заходів безпеки й обсяг систем відповідності, а перейти пізніше, коли вимога клієнта, регулятор або внутрішня політика розміщення зробить межу обов'язковою.
Чи працюють SSO та автоматичне створення користувачів при локальному розгортанні?
Так, і без додаткових складників. Єдиний вхід для Google Workspace, Microsoft Entra, Okta та Keycloak вбудований у контейнер Kordon, а не потребує окремого екземпляра Keycloak чи сервісу автентифікації поруч, а створення користувачів через SCIM 2.0 працює з Entra, Okta, OneLogin та Google Workspace. Користувачі створюються й деактивуються в Kordon автоматично, коли змінюються у вашому провайдері ідентичності.
Кому насправді потрібна GRC на власних серверах?
Командам, чию межу розгортання визначає хтось інший: регулятор, національна політика розміщення, анкета клієнта з безпеки або правління, яке не погодиться тримати СУІБ у хмарі іншої компанії. Це не те саме, що віддавати перевагу самостійному розгортанню. Якщо ви вже керуєте власною інфраструктурою і маєте команду, яка її обслуговує, розміщення там GRC-платформи не є додатковим тягарем, який ви на себе берете, — це середовище, у якому ви вже працюєте. Якщо ні, хмара Kordon — це та сама платформа без експлуатаційного навантаження.