--- read_when: - Надання доступу до Gateway через LAN, tailnet, Tailscale Serve, Funnel або зворотний проксі-сервер - Перевірка розгортання перед наданням доступу реальним користувачам обміну повідомленнями - Відкочування ризикованої конфігурації віддаленого доступу або особистих повідомлень sidebarTitle: Exposure runbook summary: Контрольний список попередніх перевірок і відкату перед відкриттям доступу до OpenClaw Gateway за межами local loopback title: Інструкція з надання доступу до Gateway x-i18n: generated_at: "2026-07-12T13:19:52Z" model: gpt-5.6 postprocess_version: locale-links-v1 provider: openai source_hash: fb8e66af57e804325afc91281122b822183337177c734efe065c5fc18b175e72 source_path: gateway/security/exposure-runbook.md workflow: 16 --- Відкривайте доступ до Gateway лише після того, як зможете пояснити, хто може до нього підключатися, як відбувається автентифікація, яких агентів ці користувачі можуть запускати та які інструменти можуть використовувати ці агенти. У разі сумнівів поверніться до доступу лише через local loopback і повторно запустіть аудит. Цей операційний посібник перетворює загальніші рекомендації з розділу [Безпека](/uk/gateway/security) на контрольний список оператора для віддаленого доступу та відкриття доступу через канали обміну повідомленнями. ## Виберіть схему відкриття доступу Віддавайте перевагу найвужчій схемі, яка задовольняє потреби робочого процесу. | Схема | Рекомендовано, коли | Обов’язкові засоби контролю | | -------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Local loopback + тунель SSH | Особисте використання, адміністративний доступ, налагодження | Залиште `gateway.bind: "loopback"` і створіть тунель до `127.0.0.1:18789` | | Local loopback + Tailscale Serve | Особистий доступ із tailnet до інтерфейсу керування/WebSocket | Залиште Gateway доступним лише через local loopback; заголовки ідентифікації Tailscale автентифікують лише WebSocket-поверхню інтерфейсу керування, а не інші шляхи автентифікації | | Прив’язка до tailnet/LAN | Виділена приватна мережа з відомими пристроями | Автентифікація Gateway, список дозволених правил брандмауера, відсутність публічного перенаправлення порту | | Довірений зворотний проксі | SSO/OIDC організації перед Gateway | Автентифікація `trusted-proxy`, суворі `trustedProxies`, правила перезапису/видалення заголовків, явний список дозволених користувачів | | Публічний інтернет | Рідкісні розгортання із високим ризиком | Проксі з урахуванням ідентичності, TLS, обмеження частоти запитів, суворі списки дозволених значень, ізольовані сеанси поза основним сеансом | Уникайте прямого публічного перенаправлення портів до Gateway. Якщо публічний доступ необхідний, розмістіть перед ним проксі з урахуванням ідентичності та зробіть цей проксі єдиним мережевим шляхом до Gateway. ## Попередня інвентаризація Запишіть наведені нижче дані перед зміною прив’язки, проксі, Tailscale або політики каналу: - Хост Gateway, користувач ОС і каталог стану (типово `~/.openclaw`). - URL-адреса Gateway і режим прив’язки (`gateway.bind`; типовий порт `18789`). - Режим автентифікації, джерело токена/пароля або джерело ідентичності довіреного проксі. - Кожен увімкнений канал і те, чи приймає він особисті повідомлення, групові повідомлення або Webhook. - Агенти, доступні нелокальним відправникам. - Профіль інструментів, режим ізоляції та політика інструментів із підвищеними привілеями для кожного доступного агента. - Зовнішні облікові дані, доступні цим агентам. - Розташування резервної копії `~/.openclaw/openclaw.json` та облікових даних. Якщо боту може надсилати повідомлення більше ніж одна особа, вважайте це спільним делегованим доступом до інструментів, а не ізоляцією хоста для кожного користувача. ## Базові перевірки Виконайте перед відкриттям доступу: ```bash openclaw doctor openclaw security audit openclaw security audit --deep openclaw health ``` Спочатку усуньте критичні зауваження. Приймайте попередження лише тоді, коли вони є навмисними та задокументованими для цього розгортання. Значення кожного `checkId` і відповідний ключ виправлення наведено в розділі [Перевірки аудиту безпеки](/uk/gateway/security/audit-checks). Для віддаленої перевірки через CLI передавайте облікові дані явно: ```bash openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN" ``` Не припускайте, що облікові дані з локальної конфігурації застосовуються до явно вказаної віддаленої URL-адреси. ## Мінімальна безпечна базова конфігурація Використовуйте цю структуру як вихідну для розгортань із відкритим доступом: ```json5 { 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 може бути надмірно відкритим: ```json5 { 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-адреси проксі та засоби контролю заголовків. - Для особистих повідомлень типово використовується сполучення або списки дозволених значень, а не відкритий доступ. - Групи вимагають згадок або явних списків дозволених значень. - Спільні канали не мають доступу до особистих облікових даних. - Неосновні сеанси виконуються в режимі ізоляції. - Виконання команд на хості та інструменти з підвищеними привілеями заборонені або потребують схвалення. - Секрети в журналах приховано. - Критичні зауваження аудиту усунено. - Кроки відкочування перевірено та задокументовано.