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

​

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

​

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

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

​

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

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health

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

​

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

{
  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 },
  },
}

​

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

• Віддавайте перевагу 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 лише для проксі на тому самому хості, де локальні процеси є довіреними, а проксі контролює заголовки ідентичності.

​

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

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

​

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

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

​

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

{
  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-адреси проксі та засоби контролю заголовків.
• Для особистих повідомлень типово використовується сполучення або списки дозволених значень, а не відкритий доступ.
• Групи вимагають згадок або явних списків дозволених значень.
• Спільні канали не мають доступу до особистих облікових даних.
• Неосновні сеанси виконуються в режимі ізоляції.
• Виконання команд на хості та інструменти з підвищеними привілеями заборонені або потребують схвалення.
• Секрети в журналах приховано.
• Критичні зауваження аудиту усунено.
• Кроки відкочування перевірено та задокументовано.