Інструкція з надання доступу до Gateway

Цей операційний посібник перетворює загальніші рекомендації з розділу Безпека на контрольний список оператора для віддаленого доступу та відкриття доступу через канали обміну повідомленнями.

Виберіть схему відкриття доступу

Віддавайте перевагу найвужчій схемі, яка задовольняє потреби робочого процесу.

Уникайте прямого публічного перенаправлення портів до Gateway. Якщо публічний доступ необхідний, розмістіть перед ним проксі з урахуванням ідентичності та зробіть цей проксі єдиним мережевим шляхом до Gateway.

Попередня інвентаризація

Запишіть наведені нижче дані перед зміною прив’язки, проксі, Tailscale або політики каналу:

• Хост Gateway, користувач ОС і каталог стану (типово ~/.openclaw).
• URL-адреса Gateway і режим прив’язки (gateway.bind; типовий порт 18789).
• Режим автентифікації, джерело токена/пароля або джерело ідентичності довіреного проксі.
• Кожен увімкнений канал і те, чи приймає він особисті повідомлення, групові повідомлення або Webhook.
• Агенти, доступні нелокальним відправникам.
• Профіль інструментів, режим ізоляції та політика інструментів із підвищеними привілеями для кожного доступного агента.
• Зовнішні облікові дані, доступні цим агентам.
• Розташування резервної копії ~/.openclaw/openclaw.json та облікових даних.

Якщо боту може надсилати повідомлення більше ніж одна особа, вважайте це спільним делегованим доступом до інструментів, а не ізоляцією хоста для кожного користувача.

Базові перевірки

Виконайте перед відкриттям доступу:

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

Спочатку усуньте критичні зауваження. Приймайте попередження лише тоді, коли вони є навмисними та задокументованими для цього розгортання. Значення кожного checkId і відповідний ключ виправлення наведено в розділі Перевірки аудиту безпеки.

Для віддаленої перевірки через CLI передавайте облікові дані явно:

openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

Не припускайте, що облікові дані з локальної конфігурації застосовуються до явно вказаної віддаленої URL-адреси.

Мінімальна безпечна базова конфігурація

Використовуйте цю структуру як вихідну для розгортань із відкритим доступом:

{  gateway: {    bind: "loopback",    auth: {      mode: "token",      token: "replace-with-a-long-random-token",    },  },  session: {    dmScope: "per-channel-peer",  },  agents: {    defaults: {      sandbox: { mode: "non-main" },    },  },  tools: {    profile: "messaging",    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

Розширюйте по одному засобу контролю за раз: додайте список дозволених значень для конкретного каналу перед увімкненням інструментів із можливістю запису або увімкніть зворотний проксі перед прийманням віддаленого трафіку інтерфейсу керування.

tools.exec.security: "deny" блокує всі виклики виконання команд, зокрема безпечну діагностику. Якщо потрібна діагностика або команди з низьким ризиком, послаблюйте це обмеження лише після вибору конкретних відправників, агентів, команд і режиму схвалення, які відповідають вашій моделі загроз.

Відкриття доступу до особистих і групових повідомлень

Канали обміну повідомленнями є поверхнями введення недовірених даних. Перш ніж дозволяти особисті або групові повідомлення:

• Віддавайте перевагу dmPolicy: "pairing" або суворому списку allowFrom замість dmPolicy: "open".
• Не поєднуйте списки дозволених значень із "*" із широким доступом до інструментів.
• Вимагайте згадок у групах, якщо доступ до кімнати не контролюється суворо.
• Установіть session.dmScope: "per-channel-peer" (або "per-account-channel-peer" для каналів із кількома обліковими записами), коли кілька людей можуть надсилати боту особисті повідомлення, щоб сеанси особистих повідомлень не використовували спільний контекст.
• Спрямовуйте спільні канали до агентів із мінімальним набором інструментів і без особистих облікових даних.

Сполучення дозволяє відправнику запускати бота. Воно не створює для цього відправника окрему межу безпеки хоста.

Перевірки зворотного проксі

Для проксі з урахуванням ідентичності:

• Проксі повинен автентифікувати користувачів перед переспрямуванням до Gateway.
• Брандмауер або мережева політика повинні блокувати прямий доступ до порту Gateway.
• gateway.trustedProxies має містити лише IP-адреси джерел проксі.
• Проксі повинен видаляти або перезаписувати надані клієнтом заголовки ідентичності та переспрямування.
• Установіть gateway.auth.trustedProxy.allowUsers, коли проксі обслуговує більше ніж одну аудиторію.
• Використовуйте gateway.auth.trustedProxy.allowLoopback лише для проксі на тому самому хості, де локальні процеси є довіреними, а проксі контролює заголовки ідентичності.

Після змін проксі запустіть openclaw security audit --deep. Зауваження щодо довіреного проксі є особливо важливими, оскільки проксі стає межею автентифікації.

Перевірка інструментів та ізоляції

Перш ніж відкривати агенту доступ для віддалених відправників:

• Перевірте, які сеанси виконуються на хості, а які — в ізольованому середовищі.
• Забороніть виконання команд на хості або вимагайте його схвалення.
• Залишайте інструменти з підвищеними привілеями вимкненими, якщо вони не потрібні конкретному довіреному відправнику.
• Уникайте інструментів браузера, полотна, Node, Cron, Gateway і створення сеансів для відкритих або напіввідкритих поверхонь обміну повідомленнями.
• Звужуйте точки монтування; уникайте шляхів до облікових даних, домашнього каталогу, сокета Docker і системних шляхів.
• Використовуйте окремі Gateway, користувачів ОС або хости для суттєво різних меж довіри.

Якщо віддалені користувачі не є повністю довіреними, ізоляція має забезпечуватися окремими розгортаннями, а не лише підказками чи мітками сеансів.

Перевірка після змін

Після кожної зміни відкриття доступу:

1. Повторно запустіть openclaw security audit --deep.
2. Переконайтеся, що успішне авторизоване підключення встановлюється.
3. Переконайтеся, що неавторизованому відправнику або сеансу браузера відмовлено в доступі.
4. Переконайтеся, що секрети в журналах приховано.
5. Переконайтеся, що маршрутизація особистих/групових повідомлень спрямовує їх лише до призначеного агента.
6. Переконайтеся, що інструменти з високим рівнем впливу запитують схвалення або заборонені.
7. Задокументуйте прийняті залишкові попередження.

Не переходьте до наступної зміни відкриття доступу, доки не зрозумієте поточну.

План відкочування

Якщо Gateway може бути надмірно відкритим:

{  gateway: {    bind: "loopback",  },  channels: {    whatsapp: { dmPolicy: "disabled" },    telegram: { dmPolicy: "disabled" },    discord: { dmPolicy: "disabled" },    slack: { dmPolicy: "disabled" },  },  tools: {    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

Потім:

1. Зупиніть публічне переспрямування, Tailscale Funnel або маршрути зворотного проксі.
2. Замініть токени/паролі Gateway і облікові дані пов’язаних інтеграцій.
3. Видаліть "*" і неочікуваних відправників зі списків дозволених значень.
4. Перегляньте останні журнали аудиту, історію запусків, виклики інструментів і зміни конфігурації.
5. Повторно запустіть openclaw security audit --deep.
6. Знову увімкніть доступ за найвужчою схемою, яка задовольняє потреби робочого процесу.

Контрольний список перевірки

• Gateway залишається доступним лише через local loopback, якщо немає задокументованої причини для іншого.
• Доступ не через local loopback має автентифікацію, захист брандмауером і не має прямого публічного маршруту.
• Розгортання з довіреним проксі мають суворо визначені IP-адреси проксі та засоби контролю заголовків.
• Для особистих повідомлень типово використовується сполучення або списки дозволених значень, а не відкритий доступ.
• Групи вимагають згадок або явних списків дозволених значень.
• Спільні канали не мають доступу до особистих облікових даних.
• Неосновні сеанси виконуються в режимі ізоляції.
• Виконання команд на хості та інструменти з підвищеними привілеями заборонені або потребують схвалення.
• Секрети в журналах приховано.
• Критичні зауваження аудиту усунено.
• Кроки відкочування перевірено та задокументовано.