Операційний посібник з відкриття доступу до Gateway

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

Виберіть схему експозиції

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

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

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

Зафіксуйте це перед зміною політики прив'язки, проксі, Tailscale або каналу:

• Хост Gateway, користувач ОС і каталог стану.
• URL Gateway і режим прив'язки.
• Режим автентифікації, джерело токена/пароля або джерело ідентичності довіреного проксі.
• Усі ввімкнені канали та чи приймають вони особисті повідомлення, групи або webhooks.
• Агенти, доступні від нелокальних відправників.
• Профіль інструментів, режим пісочниці та політика підвищених інструментів для кожного доступного агента.
• Зовнішні облікові дані, доступні цим агентам.
• Розташування резервної копії для ~/.openclaw/openclaw.json та облікових даних.

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

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

Запустіть це перед відкриттям доступу:

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

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

Для віддаленої перевірки 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 },  },}

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

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

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

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

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

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

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

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

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

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

Перегляд інструментів і пісочниці

Перед відкриттям агента для віддалених відправників:

• Підтвердьте, які сеанси працюють на хості, а які в пісочниці.
• Забороніть або вимагайте схвалення для host exec.
• Тримайте підвищені інструменти вимкненими, якщо вони не потрібні конкретному довіреному відправнику.
• Уникайте інструментів браузера, canvas, node, cron, gateway і породження сеансів для відкритих або напіввідкритих поверхонь повідомлень.
• Тримайте bind mounts вузькими й уникайте шляхів до облікових даних, home, Docker socket і системних шляхів.
• Використовуйте окремі gateways, користувачів ОС або хости для суттєво різних меж довіри.

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

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

Після кожної зміни експозиції:

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 залишається доступним лише через loopback, якщо немає задокументованої причини.
• Доступ не через loopback має автентифікацію, firewall і не має прямого публічного маршруту.
• Розгортання з довіреним проксі мають строгі IP-адреси проксі та засоби контролю заголовків.
• Особисті повідомлення використовують pairing або списки дозволених, а не відкритий доступ за замовчуванням.
• Групи вимагають згадок або явних списків дозволених.
• Спільні канали не досягають особистих облікових даних.
• Сеанси не з main працюють у режимі пісочниці.
• Host exec і підвищені інструменти заборонені або захищені схваленням.
• Журнали редагують секрети.
• Критичні знахідки аудиту усунені.
• Кроки відкату протестовані та задокументовані.