--- read_when: - Додавання функцій, що розширюють доступ або автоматизацію summary: Міркування безпеки та модель загроз для запуску AI Gateway із доступом до оболонки title: Безпека x-i18n: generated_at: "2026-07-04T11:00:46Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: 42a398a347f04414c443277c8ab3632953bce73e957c8439883846813f882dd5 source_path: gateway/security/index.md workflow: 16 --- **Модель довіри персонального помічника.** Ці настанови припускають одну довірену межу оператора на Gateway (модель одного користувача, персонального помічника). OpenClaw **не** є ворожою багатокористувацькою межею безпеки для кількох зловмисних користувачів, які спільно використовують одного агента або Gateway. Якщо вам потрібна робота зі змішаною довірою або зловмисними користувачами, розділіть межі довіри (окремий Gateway + облікові дані, в ідеалі окремі користувачі ОС або хости). ## Спершу область застосування: модель безпеки персонального помічника Настанови з безпеки OpenClaw припускають розгортання **персонального помічника**: одна довірена межа оператора, потенційно багато агентів. - Підтримувана позиція безпеки: один користувач/межа довіри на Gateway (бажано один користувач ОС/хост/VPS на межу). - Не підтримувана межа безпеки: один спільний Gateway/агент, який використовують взаємно недовірені або зловмисні користувачі. - Якщо потрібна ізоляція зловмисних користувачів, розділіть за межами довіри (окремий Gateway + облікові дані, а в ідеалі окремі користувачі ОС/хости). - Якщо кілька недовірених користувачів можуть надсилати повідомлення одному агенту з увімкненими інструментами, вважайте, що вони спільно використовують ті самі делеговані повноваження інструментів для цього агента. Ця сторінка пояснює посилення захисту **в межах цієї моделі**. Вона не заявляє про ворожу багатокористувацьку ізоляцію на одному спільному Gateway. Перед зміною віддаленого доступу, політики DM, зворотного проксі або публічного відкриття використайте [інструкцію з відкриття Gateway](/uk/gateway/security/exposure-runbook) як контрольний список попередньої перевірки та відкату. ## Швидка перевірка: `openclaw security audit` Див. також: [Формальна верифікація (моделі безпеки)](/uk/security/formal-verification) Запускайте це регулярно (особливо після зміни конфігурації або відкриття мережевих поверхонь): ```bash openclaw security audit openclaw security audit --deep openclaw security audit --fix openclaw security audit --json ``` `security audit --fix` навмисно має вузьку дію: він перемикає поширені відкриті групові політики на списки дозволених, відновлює `logging.redactSensitive: "tools"`, посилює дозволи для state/config/include-файлів і використовує скидання ACL Windows замість POSIX `chmod` під час запуску в Windows. Він позначає поширені небезпечні помилки (відкриття автентифікації Gateway, відкриття керування браузером, розширені списки дозволених, дозволи файлової системи, надто поблажливі схвалення exec і відкриття інструментів у відкритих каналах). OpenClaw є і продуктом, і експериментом: ви підключаєте поведінку frontier-моделей до реальних поверхонь обміну повідомленнями та реальних інструментів. **Не існує "ідеально безпечного" налаштування.** Мета — свідомо визначити: - хто може спілкуватися з вашим ботом - де боту дозволено діяти - до чого бот може мати доступ Почніть із найменшого доступу, який усе ще працює, а потім розширюйте його в міру зростання впевненості. ### Блокування залежностей опублікованого пакета Вихідні checkout-и OpenClaw використовують `pnpm-lock.yaml`. Опублікований npm-пакет `openclaw` і npm-пакети Plugin, що належать OpenClaw, містять `npm-shrinkwrap.json`, публіковний lockfile залежностей npm, щоб установлення пакетів використовувало перевірений транзитивний граф залежностей із релізу, а не розв'язувало свіжий граф під час установлення. Shrinkwrap — це межа посилення ланцюга постачання та відтворюваності релізів, а не пісочниця. Просте пояснення моделі, команди для супровідників і перевірки інспекції пакетів див. у [npm shrinkwrap](/uk/gateway/security/shrinkwrap). ### Розгортання та довіра до хоста OpenClaw припускає, що межа хоста й конфігурації є довіреною: - Якщо хтось може змінювати стан/конфігурацію хоста Gateway (`~/.openclaw`, включно з `openclaw.json`), вважайте цю особу довіреним оператором. - Запуск одного Gateway для кількох взаємно недовірених/зловмисних операторів **не є рекомендованим налаштуванням**. - Для команд зі змішаною довірою розділяйте межі довіри окремими Gateway (або щонайменше окремими користувачами ОС/хостами). - Рекомендоване типове налаштування: один користувач на машину/хост (або VPS), один Gateway для цього користувача та один або кілька агентів у цьому Gateway. - Усередині одного екземпляра Gateway автентифікований доступ оператора є довіреною роллю площини керування, а не роллю орендаря на рівні користувача. - Ідентифікатори сеансів (`sessionKey`, ID сеансів, мітки) є селекторами маршрутизації, а не токенами авторизації. - Якщо кілька людей можуть надсилати повідомлення одному агенту з увімкненими інструментами, кожен із них може керувати тим самим набором дозволів. Ізоляція сеансів/пам'яті на рівні користувача допомагає приватності, але не перетворює спільного агента на авторизацію хоста на рівні користувача. ### Безпечні файлові операції OpenClaw використовує `@openclaw/fs-safe` для доступу до файлів у межах кореня, атомарних записів, видобування архівів, тимчасових робочих просторів і допоміжних засобів для секретних файлів. OpenClaw типово вимикає необов'язковий POSIX Python-помічник fs-safe; установлюйте `OPENCLAW_FS_SAFE_PYTHON_MODE=auto` або `require` лише тоді, коли вам потрібне додаткове посилення мутацій відносно fd і ви можете підтримувати середовище виконання Python. Докладніше: [Безпечні файлові операції](/uk/gateway/security/secure-file-operations). ### Спільний робочий простір Slack: реальний ризик Якщо "усі в Slack можуть надсилати повідомлення боту", основний ризик — делеговані повноваження інструментів: - будь-який дозволений відправник може спричинити виклики інструментів (`exec`, браузер, мережеві/файлові інструменти) у межах політики агента; - ін'єкція prompt/вмісту від одного відправника може спричинити дії, що впливають на спільний стан, пристрої або виходи; - якщо один спільний агент має чутливі облікові дані/файли, будь-який дозволений відправник потенційно може спрямувати ексфільтрацію через використання інструментів. Для командних робочих процесів використовуйте окремих агентів/Gateway з мінімальними інструментами; агентів із персональними даними тримайте приватними. ### Спільний агент компанії: прийнятний шаблон Це прийнятно, коли всі, хто використовує цього агента, перебувають в одній межі довіри (наприклад, одна команда компанії), а агент суворо обмежений бізнес-сферою. - запускайте його на виділеній машині/VM/контейнері; - використовуйте виділеного користувача ОС + виділений браузер/профіль/облікові записи для цього середовища виконання; - не входьте в цьому середовищі виконання до персональних облікових записів Apple/Google або персональних профілів менеджера паролів/браузера. Якщо ви змішуєте персональні й корпоративні ідентичності в одному середовищі виконання, ви руйнуєте розділення та збільшуєте ризик відкриття персональних даних. ## Концепція довіри Gateway і node Розглядайте Gateway і node як один домен довіри оператора з різними ролями: - **Gateway** — це площина керування та поверхня політик (`gateway.auth`, політика інструментів, маршрутизація). - **Node** — це поверхня віддаленого виконання, спарена з цим Gateway (команди, дії пристрою, локальні можливості хоста). - Викликача, автентифікованого в Gateway, вважають довіреним у межах Gateway. Після спарення дії node вважаються діями довіреного оператора на цьому node. - Рівні області оператора та перевірки під час схвалення підсумовано в [областях оператора](/uk/gateway/operator-scopes). - Прямі loopback backend-клієнти, автентифіковані спільним токеном/паролем gateway, можуть виконувати внутрішні RPC площини керування без подання ідентичності користувацького пристрою. Це не обхід віддаленого чи браузерного спарення: мережеві клієнти, клієнти node, клієнти з device-token і явні ідентичності пристроїв усе ще проходять спарення та примусове підвищення області. - `sessionKey` — це вибір маршрутизації/контексту, а не автентифікація на рівні користувача. - Схвалення exec (список дозволених + запит) — це запобіжники для наміру оператора, а не ворожа багатокористувацька ізоляція. - Типове налаштування продукту OpenClaw для довірених конфігурацій з одним оператором полягає в тому, що host exec на `gateway`/`node` дозволений без запитів на схвалення (`security="full"`, `ask="off"`, якщо ви це не посилите). Це типове налаштування є навмисним UX, а не вразливістю саме по собі. - Схвалення exec прив'язуються до точного контексту запиту та best-effort прямих локальних файлових операндів; вони не моделюють семантично кожен шлях завантажувача runtime/інтерпретатора. Для сильних меж використовуйте пісочниці та ізоляцію хоста. Якщо вам потрібна ізоляція ворожих користувачів, розділіть межі довіри за користувачем ОС/хостом і запускайте окремі Gateway. ## Матриця меж довіри Використовуйте це як швидку модель під час triage ризиків: | Межа або контроль | Що це означає | Поширене хибне тлумачення | | --------------------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------- | | `gateway.auth` (token/password/trusted-proxy/device auth) | Автентифікує викликачів до API gateway | "Для безпеки потрібні підписи кожного повідомлення на кожному кадрі" | | `sessionKey` | Ключ маршрутизації для вибору контексту/сеансу | "Ключ сеансу є межею автентифікації користувача" | | Запобіжники prompt/вмісту | Зменшують ризик зловживання моделлю | "Самої ін'єкції prompt достатньо, щоб довести обхід автентифікації" | | `canvas.eval` / browser evaluate | Навмисна можливість оператора, коли ввімкнена | "Будь-який примітив JS eval автоматично є вразливістю в цій моделі довіри" | | Локальна оболонка TUI `!` | Явне локальне виконання, ініційоване оператором | "Зручна команда локальної оболонки є віддаленою ін'єкцією" | | Спарення Node і команди node | Віддалене виконання рівня оператора на спарених пристроях | "Віддалене керування пристроєм слід типово вважати доступом недовіреного користувача" | | `gateway.nodes.pairing.autoApproveCidrs` | Політика реєстрації node з довіреної мережі за явним увімкненням | "Вимкнений за замовчуванням список дозволених є автоматичною вразливістю спарення" | ## Не є вразливостями за задумом Про ці шаблони часто повідомляють, і зазвичай їх закривають без дій, якщо не продемонстровано реальний обхід межі: - Ланцюги лише з ін'єкцією prompt без обходу політики, автентифікації або пісочниці. - Твердження, що припускають ворожу багатокористувацьку роботу на одному спільному хості або конфігурації. - Твердження, що класифікують звичайний доступ оператора шляхом читання (наприклад `sessions.list` / `sessions.preview` / `chat.history`) як IDOR у налаштуванні спільного Gateway. - Знахідки для розгортання лише на localhost (наприклад HSTS на Gateway лише для loopback). - Знахідки щодо підписів вхідних Webhook Discord для вхідних шляхів, яких немає в цьому репозиторії. - Звіти, що трактують метадані спарення node як прихований другий шар схвалення на команду для `system.run`, тоді як реальною межею виконання все ще є глобальна політика команд node у gateway плюс власні схвалення exec цього node. - Звіти, що трактують налаштований `gateway.nodes.pairing.autoApproveCidrs` як вразливість саму по собі. Цей параметр вимкнений за замовчуванням, потребує явних записів CIDR/IP, застосовується лише до першого спарення `role: node` без запитаних областей і не схвалює автоматично operator/browser/Control UI, WebChat, підвищення ролей, підвищення областей, зміни метаданих, зміни публічного ключа або same-host loopback trusted-proxy header paths, якщо loopback trusted-proxy auth не було явно ввімкнено. - Знахідки про "відсутню авторизацію на рівні користувача", які трактують `sessionKey` як токен автентифікації. ## Посилений базовий рівень за 60 секунд Спершу використайте цей базовий рівень, а потім вибірково знову вмикайте інструменти для кожного довіреного агента: ```json5 { gateway: { mode: "local", bind: "loopback", auth: { mode: "token", token: "replace-with-long-random-token" }, }, session: { dmScope: "per-channel-peer", }, tools: { profile: "messaging", deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"], fs: { workspaceOnly: true }, exec: { security: "deny", ask: "always" }, elevated: { enabled: false }, }, channels: { whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } }, }, } ``` Це залишає Gateway доступним лише локально, ізолює DM і типово вимикає інструменти площини керування/runtime. ## Швидке правило для спільної вхідної скриньки Якщо більше ніж одна людина може надсилати DM вашому боту: - Установіть `session.dmScope: "per-channel-peer"` (або `"per-account-channel-peer"` для каналів із кількома обліковими записами). - Залиште `dmPolicy: "pairing"` або суворі списки дозволених. - Ніколи не поєднуйте спільні приватні повідомлення з широким доступом до інструментів. - Це посилює захист спільних або кооперативних скриньок вхідних, але не призначено для ізоляції від ворожих співкористувачів, коли користувачі мають спільний доступ на запис до хоста/конфігурації. ## Модель видимості контексту OpenClaw розділяє два поняття: - **Авторизація запуску**: хто може запускати агента (`dmPolicy`, `groupPolicy`, списки дозволених, шлюзи згадувань). - **Видимість контексту**: який додатковий контекст додається до вхідних даних моделі (текст відповіді, процитований текст, історія гілки, переслані метадані). Списки дозволених обмежують запуски та авторизацію команд. Параметр `contextVisibility` керує фільтрацією додаткового контексту (цитованих відповідей, коренів гілок, отриманої історії): - `contextVisibility: "all"` (типово) залишає додатковий контекст у тому вигляді, у якому його отримано. - `contextVisibility: "allowlist"` фільтрує додатковий контекст до відправників, дозволених активними перевірками списку дозволених. - `contextVisibility: "allowlist_quote"` працює як `allowlist`, але все одно зберігає одну явну процитовану відповідь. Установіть `contextVisibility` для кожного каналу або для кожної кімнати/розмови. Докладні налаштування див. у [Групові чати](/uk/channels/groups#context-visibility-and-allowlists). Рекомендації з консультативного тріажу: - Твердження, які лише показують, що "модель може бачити процитований або історичний текст від відправників не зі списку дозволених", є знахідками для посилення захисту, які можна виправити за допомогою `contextVisibility`, а не самостійними обходами меж авторизації чи пісочниці. - Щоб мати вплив на безпеку, звіти все одно мають демонструвати обхід межі довіри (авторизації, політики, пісочниці, схвалення або іншої задокументованої межі). ## Що перевіряє аудит (загальний рівень) - **Вхідний доступ** (політики приватних повідомлень, групові політики, списки дозволених): чи можуть сторонні запускати бота? - **Радіус ураження інструментів** (підвищені інструменти + відкриті кімнати): чи може інʼєкція промпта перетворитися на дії shell/файлової системи/мережі? - **Зсув файлової системи exec**: чи заборонено інструменти, що змінюють файлову систему, тоді як `exec`/`process` залишаються доступними без файлових обмежень пісочниці? - **Зсув схвалень exec** (`security=full`, `autoAllowSkills`, списки дозволених інтерпретаторів без `strictInlineEval`): чи захисні обмеження host-exec досі роблять те, що ви очікуєте? - `security="full"` — це широке попередження про позицію безпеки, а не доказ помилки. Це вибране типове значення для довірених налаштувань персонального асистента; посилюйте його лише тоді, коли ваша модель загроз потребує схвалення або обмежень списками дозволених. - **Мережевий вплив** (привʼязка/автентифікація Gateway, Tailscale Serve/Funnel, слабкі/короткі токени автентифікації). - **Вплив керування браузером** (віддалені вузли, порти ретрансляції, віддалені кінцеві точки CDP). - **Гігієна локального диска** (дозволи, символічні посилання, включення конфігурації, шляхи "синхронізованих папок"). - **Plugins** (plugins завантажуються без явного списку дозволених). - **Зсув політик/помилкова конфігурація** (налаштування sandbox docker сконфігуровано, але режим пісочниці вимкнено; неефективні шаблони `gateway.nodes.denyCommands`, бо зіставлення виконується лише за точною назвою команди (наприклад `system.run`) і не перевіряє текст shell; небезпечні записи `gateway.nodes.allowCommands`; глобальний `tools.profile="minimal"` перевизначено профілями окремих агентів; інструменти, якими володіють plugins, доступні за поблажливої політики інструментів). - **Зсув очікувань runtime** (наприклад, припущення, що неявний exec досі означає `sandbox`, коли `tools.exec.host` тепер типово дорівнює `auto`, або явне встановлення `tools.exec.host="sandbox"`, коли режим пісочниці вимкнено). - **Гігієна моделі** (попереджати, коли сконфігуровані моделі виглядають застарілими; це не жорстке блокування). Якщо запустити `--deep`, OpenClaw також спробує виконати best-effort живу перевірку Gateway. ## Карта зберігання облікових даних Використовуйте це під час аудиту доступу або рішення, що резервно копіювати: - **WhatsApp**: `~/.openclaw/credentials/whatsapp//creds.json` - **Токен бота Telegram**: config/env або `channels.telegram.tokenFile` (лише звичайний файл; символічні посилання відхиляються) - **Токен бота Discord**: config/env або SecretRef (провайдери env/file/exec) - **Токени Slack**: config/env (`channels.slack.*`) - **Списки дозволених для pairing**: - `~/.openclaw/credentials/-allowFrom.json` (типовий обліковий запис) - `~/.openclaw/credentials/--allowFrom.json` (нетипові облікові записи) - **Профілі автентифікації моделі**: `~/.openclaw/agents//agent/auth-profiles.json` - **Стан runtime Codex (типово)**: `~/.openclaw/agents//agent/codex-home/` - **Спільний стан runtime Codex (за явного ввімкнення)**: `$CODEX_HOME` або `~/.codex`, коли `plugins.entries.codex.config.appServer.homeScope` дорівнює `"user"`. Цей режим використовує нативний обліковий запис, конфігурацію, plugins і сховище гілок Codex; вмикайте його лише для локального Gateway під контролем власника. Див. [обвʼязку Codex](/uk/plugins/codex-harness#share-threads-with-codex-desktop-and-cli). - **Корисне навантаження секретів на основі файлу (необовʼязково)**: `~/.openclaw/secrets.json` - **Імпорт застарілого OAuth**: `~/.openclaw/credentials/oauth.json` ## Контрольний список аудиту безпеки Коли аудит друкує знахідки, розглядайте це як порядок пріоритетів: 1. **Будь-що "відкрите" + увімкнені інструменти**: спочатку заблокуйте приватні повідомлення/групи (pairing/списки дозволених), потім посильте політику інструментів/пісочницю. 2. **Публічний мережевий вплив** (привʼязка до LAN, Funnel, відсутня автентифікація): виправте негайно. 3. **Віддалений вплив керування браузером**: розглядайте це як операторський доступ (лише tailnet, свідомо спаровуйте вузли, уникайте публічного доступу). 4. **Дозволи**: переконайтеся, що стан/конфігурація/облікові дані/автентифікація не доступні для читання групі або всім. 5. **Plugins**: завантажуйте лише те, чому явно довіряєте. 6. **Вибір моделі**: надавайте перевагу сучасним моделям, посиленим для інструкцій, для будь-якого бота з інструментами. ## Глосарій аудиту безпеки Кожна знахідка аудиту має структурований ключ `checkId` (наприклад `gateway.bind_no_auth` або `tools.exec.security_full_configured`). Поширені класи критичної серйозності: - `fs.*` - дозволи файлової системи для стану, конфігурації, облікових даних, профілів автентифікації. - `gateway.*` - режим привʼязки, автентифікація, Tailscale, Control UI, налаштування довіреного проксі. - `hooks.*`, `browser.*`, `sandbox.*`, `tools.exec.*` - посилення захисту за окремими поверхнями. - `plugins.*`, `skills.*` - ланцюг постачання plugin/skill і знахідки сканування. - `security.exposure.*` - наскрізні перевірки, де політика доступу перетинається з радіусом ураження інструментів. Повний каталог із рівнями серйозності, ключами виправлень і підтримкою автоматичного виправлення див. у [перевірках аудиту безпеки](/uk/gateway/security/audit-checks). ## Control UI через HTTP Control UI потребує **безпечного контексту** (HTTPS або localhost), щоб створити ідентичність пристрою. `gateway.controlUi.allowInsecureAuth` — це локальний перемикач сумісності: - На localhost він дозволяє автентифікацію Control UI без ідентичності пристрою, коли сторінку завантажено через незахищений HTTP. - Він не обходить перевірки pairing. - Він не послаблює вимоги до ідентичності віддалених (не-localhost) пристроїв. Надавайте перевагу HTTPS (Tailscale Serve) або відкривайте UI на `127.0.0.1`. Лише для аварійних сценаріїв `gateway.controlUi.dangerouslyDisableDeviceAuth` повністю вимикає перевірки ідентичності пристрою. Це серйозне зниження рівня безпеки; тримайте його вимкненим, якщо ви не виконуєте активне налагодження й не можете швидко повернути налаштування. Окремо від цих небезпечних прапорців, успішний `gateway.auth.mode: "trusted-proxy"` може допускати **операторські** сеанси Control UI без ідентичності пристрою. Це навмисна поведінка режиму автентифікації, а не скорочення `allowInsecureAuth`, і вона все одно не поширюється на сеанси Control UI з роллю вузла. `openclaw security audit` попереджає, коли цей параметр увімкнено. ## Підсумок незахищених або небезпечних прапорців `openclaw security audit` піднімає `config.insecure_or_dangerous_flags`, коли відомі незахищені/небезпечні перемикачі налагодження ввімкнено. Не встановлюйте їх у production. Кожен увімкнений прапорець звітується як окрема знахідка. Якщо налаштовано придушення аудиту, `security.audit.suppressions.active` залишається в активному виводі аудиту, навіть коли відповідні знахідки переходять до `suppressedFindings`. - `gateway.controlUi.allowInsecureAuth=true` - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` - `gateway.controlUi.dangerouslyDisableDeviceAuth=true` - `security.audit.suppressions configured ()` - `hooks.gmail.allowUnsafeExternalContent=true` - `hooks.mappings[].allowUnsafeExternalContent=true` - `tools.exec.applyPatch.workspaceOnly=false` - `plugins.entries.acpx.config.permissionMode=approve-all` Control UI і браузер: - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback` - `gateway.controlUi.dangerouslyDisableDeviceAuth` - `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` Зіставлення назв каналів (вбудовані канали та канали plugins; також доступно для кожного `accounts.`, де застосовно): - `channels.discord.dangerouslyAllowNameMatching` - `channels.slack.dangerouslyAllowNameMatching` - `channels.googlechat.dangerouslyAllowNameMatching` - `channels.msteams.dangerouslyAllowNameMatching` - `channels.synology-chat.dangerouslyAllowNameMatching` (канал plugin) - `channels.synology-chat.dangerouslyAllowInheritedWebhookPath` (канал plugin) - `channels.zalouser.dangerouslyAllowNameMatching` (канал plugin) - `channels.irc.dangerouslyAllowNameMatching` (канал plugin) - `channels.mattermost.dangerouslyAllowNameMatching` (канал plugin) Мережевий вплив: - `channels.telegram.network.dangerouslyAllowPrivateNetwork` (також для кожного облікового запису) Sandbox Docker (типові значення + для кожного агента): - `agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets` - `agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources` - `agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin` ## Конфігурація зворотного проксі Якщо ви запускаєте Gateway за зворотним проксі (nginx, Caddy, Traefik тощо), налаштуйте `gateway.trustedProxies` для правильного оброблення IP клієнта, переданого через заголовки. Коли Gateway виявляє proxy headers з адреси, якої **немає** в `trustedProxies`, він **не** вважатиме зʼєднання локальними клієнтами. Якщо автентифікацію gateway вимкнено, такі зʼєднання відхиляються. Це запобігає обходу автентифікації, коли проксійовані зʼєднання інакше виглядали б як такі, що надходять із localhost, і отримували б автоматичну довіру. `gateway.trustedProxies` також живить `gateway.auth.mode: "trusted-proxy"`, але цей режим автентифікації суворіший: - автентифікація trusted-proxy **типово fail closed для проксі з loopback-джерелом** - зворотні проксі loopback на тому самому хості можуть використовувати `gateway.trustedProxies` для виявлення локального клієнта та оброблення forwarded IP - зворотні проксі loopback на тому самому хості можуть задовольнити `gateway.auth.mode: "trusted-proxy"` лише коли `gateway.auth.trustedProxy.allowLoopback = true`; інакше використовуйте автентифікацію токеном/паролем ```yaml gateway: trustedProxies: - "10.0.0.1" # reverse proxy IP # Optional. Default false. # Only enable if your proxy cannot provide X-Forwarded-For. allowRealIpFallback: false auth: mode: password password: ${OPENCLAW_GATEWAY_PASSWORD} ``` Коли `trustedProxies` налаштовано, Gateway використовує `X-Forwarded-For`, щоб визначити IP клієнта. `X-Real-IP` типово ігнорується, якщо `gateway.allowRealIpFallback: true` явно не встановлено. Заголовки довіреного проксі не роблять pairing пристроїв вузлів автоматично довіреним. `gateway.nodes.pairing.autoApproveCidrs` — це окрема операторська політика, вимкнена за замовчуванням. Навіть коли її ввімкнено, шляхи заголовків trusted-proxy з loopback-джерелом виключено з автоматичного схвалення вузлів, бо локальні виклики можуть підробляти ці заголовки, зокрема коли автентифікацію trusted-proxy loopback явно ввімкнено. Правильна поведінка зворотного проксі (перезаписувати вхідні заголовки переспрямування): ```nginx proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; ``` Неправильна поведінка зворотного проксі (додавати/зберігати недовірені заголовки переспрямування): ```nginx proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ``` ## Нотатки щодо HSTS і origin - OpenClaw gateway спершу є локальним/loopback. Якщо ви завершуєте TLS на зворотному проксі, налаштуйте HSTS там, на HTTPS-домені, зверненому до проксі. - Якщо gateway сам завершує HTTPS, ви можете встановити `gateway.http.securityHeaders.strictTransportSecurity`, щоб OpenClaw відповіді надсилали заголовок HSTS. - Докладні вказівки щодо розгортання наведено в [автентифікації довіреного проксі](/uk/gateway/trusted-proxy-auth#tls-termination-and-hsts). - Для розгортань Control UI не через loopback `gateway.controlUi.allowedOrigins` за замовчуванням є обов’язковим. - `gateway.controlUi.allowedOrigins: ["*"]` — це явна політика дозволу всіх браузерних origin, а не захищене типове значення. Уникайте її поза суворо контрольованим локальним тестуванням. - Збої браузерної origin-автентифікації на loopback все одно обмежуються за частотою, навіть коли загальний виняток loopback увімкнено, але ключ блокування обмежується кожним нормалізованим значенням `Origin`, а не одним спільним localhost-бакетом. - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` вмикає режим резервного визначення origin за заголовком Host; розглядайте це як небезпечну політику, явно вибрану оператором. - Розглядайте DNS rebinding і поведінку заголовків proxy-host як питання посилення захисту розгортання; тримайте `trustedProxies` суворо обмеженим і уникайте прямого відкриття gateway у публічний інтернет. ## Локальні журнали сеансів зберігаються на диску OpenClaw зберігає транскрипти сеансів на диску в `~/.openclaw/agents//sessions/*.jsonl`. Це потрібно для безперервності сеансу та (необов’язково) індексування пам’яті сеансу, але це також означає, що **будь-який процес/користувач із доступом до файлової системи може читати ці журнали**. Вважайте доступ до диска межею довіри та обмежте дозволи для `~/.openclaw` (див. розділ аудиту нижче). Якщо вам потрібна сильніша ізоляція між агентами, запускайте їх під окремими користувачами ОС або на окремих хостах. ## Виконання Node (system.run) Якщо macOS-вузол спарено, Gateway може викликати `system.run` на цьому вузлі. Це **віддалене виконання коду** на Mac: - Потребує спарення вузла (схвалення + токен). - Спарення вузла Gateway не є поверхнею схвалення для кожної команди. Воно встановлює ідентичність/довіру вузла та видачу токена. - Gateway застосовує грубу глобальну політику команд вузла через `gateway.nodes.allowCommands` / `denyCommands`. - Керується на Mac через **Settings → Exec approvals** (security + ask + allowlist). - Політика `system.run` для окремого вузла — це власний файл схвалень виконання вузла (`exec.approvals.node.*`), який може бути суворішим або слабшим за глобальну політику command-ID gateway. - Вузол, що працює з `security="full"` і `ask="off"`, дотримується типової моделі довіреного оператора. Вважайте це очікуваною поведінкою, якщо ваше розгортання явно не потребує суворішої позиції щодо схвалення або allowlist. - Режим схвалення прив’язує точний контекст запиту і, коли можливо, один конкретний локальний операнд скрипта/файлу. Якщо OpenClaw не може точно визначити один прямий локальний файл для команди інтерпретатора/середовища виконання, виконання на основі схвалення відхиляється замість обіцянки повного семантичного покриття. - Для `host=node` виконання на основі схвалення також зберігає канонічний підготовлений `systemRunPlan`; подальші схвалені пересилання повторно використовують цей збережений план, а перевірка gateway відхиляє зміни викликачем команди/cwd/контексту сеансу після створення запиту на схвалення. - Якщо ви не хочете віддаленого виконання, установіть security на **deny** і видаліть спарення вузла для цього Mac. Ця відмінність важлива для тріажу: - Повторно підключений спарений вузол, що оголошує інший список команд, сам по собі не є вразливістю, якщо глобальна політика Gateway і локальні схвалення виконання вузла все ще забезпечують фактичну межу виконання. - Звіти, які розглядають метадані спарення вузла як другий прихований рівень схвалення для кожної команди, зазвичай є плутаниною політики/UX, а не обходом межі безпеки. ## Динамічні Skills (спостерігач / віддалені вузли) OpenClaw може оновлювати список Skills посеред сеансу: - **Спостерігач Skills**: зміни в `SKILL.md` можуть оновити знімок Skills на наступному ході агента. - **Віддалені вузли**: підключення macOS-вузла може зробити доступними Skills лише для macOS (на основі перевірки bin). Розглядайте папки Skills як **довірений код** і обмежуйте, хто може їх змінювати. ## Модель загроз Ваш AI-асистент може: - Виконувати довільні команди shell - Читати/записувати файли - Доступатися до мережевих сервісів - Надсилати повідомлення будь-кому (якщо ви надасте йому доступ до WhatsApp) Люди, які пишуть вам повідомлення, можуть: - Намагатися обманом змусити ваш AI робити шкідливі речі - Соціально інженерити доступ до ваших даних - Зондувати деталі інфраструктури ## Основна концепція: контроль доступу перед інтелектом Більшість збоїв тут — не витончені експлойти, а ситуації на кшталт «хтось написав боту, і бот зробив те, що його попросили». Позиція OpenClaw: - **Спершу ідентичність:** вирішіть, хто може спілкуватися з ботом (спарення DM / allowlist / явне "open"). - **Далі область дії:** вирішіть, де боту дозволено діяти (allowlist груп + gating за згадкою, інструменти, sandboxing, дозволи пристрою). - **Модель насамкінець:** припускайте, що моделлю можна маніпулювати; проєктуйте так, щоб маніпуляції мали обмежений радіус ураження. ## Модель авторизації команд Slash-команди та директиви виконуються лише для **авторизованих відправників**. Авторизація виводиться з allowlist/спарення каналу плюс `commands.useAccessGroups` (див. [Конфігурацію](/uk/gateway/configuration) і [Slash-команди](/uk/tools/slash-commands)). Якщо allowlist каналу порожній або містить `"*"`, команди фактично відкриті для цього каналу. `/exec` — це зручність лише для сеансу для авторизованих операторів. Вона **не** записує конфігурацію і не змінює інші сеанси. ## Ризик інструментів площини керування Два вбудовані інструменти можуть вносити постійні зміни до площини керування: - `gateway` може перевіряти конфігурацію за допомогою `config.schema.lookup` / `config.get` і може вносити постійні зміни через `config.apply`, `config.patch` і `update.run`. - `cron` може створювати заплановані завдання, які продовжують працювати після завершення початкового чату/завдання. Агентський runtime-інструмент `gateway` усе ще відмовляється переписувати `tools.exec.ask` або `tools.exec.security`; застарілі псевдоніми `tools.bash.*` нормалізуються до тих самих захищених шляхів exec перед записом. Редагування `gateway config.apply` і `gateway config.patch`, керовані агентом, за замовчуванням працюють за принципом fail-closed: агент може налаштовувати лише вузький набір низькоризикових шляхів runtime-тюнінгу, gating за згадкою та видимих відповідей. Глобальні типові значення моделі та prompt-накладки залишаються під контролем оператора. Тому нові чутливі дерева конфігурації захищені, якщо їх навмисно не додано до allowlist. Для будь-якого агента/поверхні, що обробляє недовірений вміст, за замовчуванням забороняйте їх: ```json5 { tools: { deny: ["gateway", "cron", "sessions_spawn", "sessions_send"], }, } ``` `commands.restart=false` блокує лише дії перезапуску. Це не вимикає дії конфігурації/оновлення `gateway`. ## Плагіни Плагіни працюють **у процесі** разом із Gateway. Розглядайте їх як довірений код: - Установлюйте плагіни лише з джерел, яким довіряєте. - Надавайте перевагу явним allowlist `plugins.allow`. - Переглядайте конфігурацію плагіна перед увімкненням. - Перезапускайте Gateway після змін плагінів. - Якщо ви встановлюєте або оновлюєте плагіни (`openclaw plugins install `, `openclaw plugins update `), ставтеся до цього як до запуску недовіреного коду: - Шлях встановлення — це каталог окремого плагіна під активним коренем встановлення плагінів. - OpenClaw не запускає вбудоване локальне блокування небезпечного коду під час встановлення/оновлення. Використовуйте `security.installPolicy` для локальних рішень allow/block, що належать оператору, і `openclaw security audit --deep` для діагностичного сканування. - Встановлення npm і git-плагінів запускають узгодження залежностей пакетного менеджера лише під час явного потоку встановлення/оновлення. Локальні шляхи й архіви розглядаються як самодостатні пакети плагінів; OpenClaw копіює/посилається на них без запуску `npm install`. - Надавайте перевагу зафіксованим точним версіям (`@scope/pkg@1.2.3`) і перевіряйте розпакований код на диску перед увімкненням. - `--dangerously-force-unsafe-install` застарів і більше не змінює поведінку встановлення/оновлення плагінів. - Налаштовуйте `security.installPolicy`, коли операторам потрібна довірена локальна команда для прийняття host-специфічних рішень allow/block щодо встановлення Skills і плагінів. Ця політика виконується після підготовки вихідних матеріалів, але до продовження встановлення, застосовується також до Skills ClawHub і не обходиться застарілими unsafe-прапорцями. Докладніше: [Плагіни](/uk/tools/plugin) ## Модель доступу DM: спарення, allowlist, open, disabled Усі поточні канали з підтримкою DM підтримують політику DM (`dmPolicy` або `*.dm.policy`), яка відсікає вхідні DM **до** обробки повідомлення: - `pairing` (типово): невідомі відправники отримують короткий код спарення, а бот ігнорує їхнє повідомлення, доки його не схвалено. Коди спливають через 1 годину; повторні DM не надсилатимуть код знову, доки не буде створено новий запит. Очікувані запити за замовчуванням обмежені **3 на канал**. - `allowlist`: невідомі відправники блокуються (без handshake спарення). - `open`: дозволити DM від будь-кого (публічно). **Потребує**, щоб allowlist каналу містив `"*"` (явне увімкнення). - `disabled`: повністю ігнорувати вхідні DM. Схвалити через CLI: ```bash openclaw pairing list openclaw pairing approve ``` Докладніше + файли на диску: [Спарення](/uk/channels/pairing) ## Ізоляція DM-сеансів (багатокористувацький режим) За замовчуванням OpenClaw спрямовує **усі DM у головний сеанс**, щоб ваш асистент мав безперервність між пристроями та каналами. Якщо **кілька людей** можуть надсилати DM боту (відкриті DM або багатокористувацький allowlist), розгляньте ізоляцію DM-сеансів: ```json5 { session: { dmScope: "per-channel-peer" }, } ``` Це запобігає витоку контексту між користувачами, зберігаючи ізольованими групові чати. Це межа контексту повідомлень, а не межа адміністратора хоста. Якщо користувачі взаємно ворожі та спільно використовують той самий хост/конфігурацію Gateway, натомість запускайте окремі gateway для кожної межі довіри. ### Захищений режим DM (рекомендовано) Розглядайте фрагмент вище як **захищений режим DM**: - Типово: `session.dmScope: "main"` (усі DM спільно використовують один сеанс для безперервності). - Типово для локального CLI onboarding: записує `session.dmScope: "per-channel-peer"`, коли не задано (зберігає наявні явні значення). - Захищений режим DM: `session.dmScope: "per-channel-peer"` (кожна пара канал+відправник отримує ізольований DM-контекст). - Ізоляція peer між каналами: `session.dmScope: "per-peer"` (кожен відправник отримує один сеанс у всіх каналах одного типу). Якщо ви запускаєте кілька облікових записів на тому самому каналі, використовуйте натомість `per-account-channel-peer`. Якщо та сама людина зв’язується з вами через кілька каналів, використовуйте `session.identityLinks`, щоб звести ці DM-сеанси до однієї канонічної ідентичності. Див. [Керування сеансами](/uk/concepts/session) і [Конфігурацію](/uk/gateway/configuration). ## Allowlists для DM і груп OpenClaw має два окремі рівні «хто може мене запускати?» : - **Список дозволених для DM** (`allowFrom` / `channels.discord.allowFrom` / `channels.slack.allowFrom`; застаріле: `channels.discord.dm.allowFrom`, `channels.slack.dm.allowFrom`): хто може спілкуватися з ботом у прямих повідомленнях. - Коли `dmPolicy="pairing"`, схвалення записуються до сховища списку дозволених сполучень у межах облікового запису в `~/.openclaw/credentials/` (`-allowFrom.json` для типового облікового запису, `--allowFrom.json` для нетипових облікових записів), об’єднаного зі списками дозволених із конфігурації. - **Список дозволених для груп** (залежить від каналу): з яких груп/каналів/гільдій бот узагалі прийматиме повідомлення. - Поширені шаблони: - `channels.whatsapp.groups`, `channels.telegram.groups`, `channels.imessage.groups`: типові параметри для кожної групи, як-от `requireMention`; коли задано, це також діє як список дозволених груп (додайте `"*"`, щоб зберегти поведінку дозволу для всіх). - `groupPolicy="allowlist"` + `groupAllowFrom`: обмежує, хто може активувати бота _всередині_ групового сеансу (WhatsApp/Telegram/Signal/iMessage/Microsoft Teams). - `channels.discord.guilds` / `channels.slack.channels`: списки дозволених для кожної поверхні + типові параметри згадок. - Перевірки груп виконуються в такому порядку: спочатку `groupPolicy`/списки дозволених груп, потім активація згадкою/відповіддю. - Відповідь на повідомлення бота (неявна згадка) **не** обходить списки дозволених відправників, як-от `groupAllowFrom`. - **Примітка з безпеки:** розглядайте `dmPolicy="open"` і `groupPolicy="open"` як налаштування крайнього випадку. Їх слід використовувати вкрай рідко; віддавайте перевагу сполученню + спискам дозволених, якщо ви не повністю довіряєте кожному учаснику кімнати. Докладніше: [Конфігурація](/uk/gateway/configuration) і [Групи](/uk/channels/groups) ## Prompt injection (що це таке і чому це важливо) Prompt injection — це коли зловмисник створює повідомлення, яке маніпулює моделлю, змушуючи її зробити щось небезпечне ("ігноруй свої інструкції", "виведи свою файлову систему", "перейди за цим посиланням і виконай команди" тощо). Навіть із сильними системними промптами **prompt injection не є розв’язаною проблемою**. Запобіжники системного промпта — це лише м’які вказівки; жорстке забезпечення дають політика інструментів, схвалення виконання, ізоляція та списки дозволених каналів (а оператори можуть навмисно вимкнути їх). Що допомагає на практиці: - Тримайте вхідні DM заблокованими (сполучення/списки дозволених). - Віддавайте перевагу обмеженню за згадкою в групах; уникайте ботів, які "завжди ввімкнені", у публічних кімнатах. - За замовчуванням розглядайте посилання, вкладення та вставлені інструкції як ворожі. - Виконуйте чутливі інструменти в ізольованому середовищі; тримайте секрети поза файловою системою, доступною агенту. - Примітка: ізоляція є опційною. Якщо режим ізоляції вимкнено, неявне `host=auto` розв’язується до хоста gateway. Явне `host=sandbox` усе одно завершується закритою відмовою, бо середовище виконання ізоляції недоступне. Установіть `host=gateway`, якщо хочете зробити цю поведінку явною в конфігурації. - Обмежуйте високоризикові інструменти (`exec`, `browser`, `web_fetch`, `web_search`) довіреними агентами або явними списками дозволених. - Якщо ви додаєте інтерпретатори до списку дозволених (`python`, `node`, `ruby`, `perl`, `php`, `lua`, `osascript`), увімкніть `tools.exec.strictInlineEval`, щоб форми inline eval усе одно потребували явного схвалення. - Аналіз схвалення shell також відхиляє форми POSIX-розгортання параметрів (`$VAR`, `$?`, `$$`, `$1`, `$@`, `${…}`) всередині **неекранованих heredoc**, тому тіло heredoc зі списку дозволених не може непомітно протягнути shell-розгортання повз перевірку списку дозволених як звичайний текст. Візьміть завершувач heredoc у лапки (наприклад, `<<'EOF'`), щоб увімкнути семантику буквального тіла; неекрановані heredoc, які розгортали б змінні, відхиляються. - **Вибір моделі має значення:** старіші/менші/застарілі моделі значно менш стійкі до prompt injection і неправильного використання інструментів. Для агентів з інструментами використовуйте найсильнішу доступну модель найновішого покоління, загартовану інструкціями. Червоні прапорці, які слід вважати недовіреними: - "Прочитай цей файл/URL і зроби саме те, що там сказано." - "Ігноруй свій системний промпт або правила безпеки." - "Розкрий свої приховані інструкції або виводи інструментів." - "Встав повний вміст ~/.openclaw або своїх журналів." ## Санітизація спеціальних токенів у зовнішньому вмісті OpenClaw видаляє поширені літерали спеціальних токенів чат-шаблонів self-hosted LLM із загорнутого зовнішнього вмісту та метаданих до того, як вони досягнуть моделі. Охоплені сімейства маркерів включають Qwen/ChatML, Llama, Gemma, Mistral, Phi та токени ролей/ходів GPT-OSS. Чому: - OpenAI-сумісні бекенди, що проксують self-hosted моделі, іноді зберігають спеціальні токени, які з’являються в користувацькому тексті, замість того щоб маскувати їх. Зловмисник, який може записати в зовнішній вхідний вміст (отриману сторінку, тіло електронного листа, вивід інструмента з вмістом файлу), інакше міг би ін’єктувати синтетичну межу ролі `assistant` або `system` і обійти запобіжники загорнутого вмісту. - Санітизація відбувається на шарі загортання зовнішнього вмісту, тому застосовується однаково до інструментів fetch/read і вхідного вмісту каналів, а не окремо для кожного провайдера. - Вихідні відповіді моделі вже мають окремий санітайзер, який видаляє витоки ``, ``, ``, `` та подібної внутрішньої runtime-обв’язки з видимих користувачу відповідей на фінальній межі доставки каналу. Санітайзер зовнішнього вмісту є вхідним відповідником. Це не замінює інші заходи посилення на цій сторінці - `dmPolicy`, списки дозволених, схвалення exec, ізоляція та `contextVisibility` усе ще виконують основну роботу. Це закриває один конкретний обхід на шарі токенізатора проти self-hosted стеків, які передають користувацький текст зі спеціальними токенами без змін. ## Небезпечні прапорці обходу зовнішнього вмісту OpenClaw містить явні прапорці обходу, які вимикають безпечне загортання зовнішнього вмісту: - `hooks.mappings[].allowUnsafeExternalContent` - `hooks.gmail.allowUnsafeExternalContent` - Поле корисного навантаження Cron `allowUnsafeExternalContent` Рекомендації: - Тримайте їх незаданими/false у production. - Вмикайте лише тимчасово для вузько обмеженого налагодження. - Якщо ввімкнено, ізолюйте такого агента (ізоляція + мінімум інструментів + окремий простір імен сеансу). Примітка про ризики hooks: - Корисні навантаження hook є недовіреним вмістом, навіть коли доставка надходить із систем, які ви контролюєте (пошта/документи/веб-вміст можуть містити prompt injection). - Слабкі рівні моделей збільшують цей ризик. Для автоматизації, керованої hook, віддавайте перевагу сильним сучасним рівням моделей і тримайте політику інструментів суворою (`tools.profile: "messaging"` або суворішою), а також використовуйте ізоляцію, де можливо. ### Prompt injection не потребує публічних DM Навіть якщо **лише ви** можете писати боту, prompt injection усе одно може статися через будь-який **недовірений вміст**, який бот читає (результати web search/fetch, сторінки браузера, електронні листи, документи, вкладення, вставлені журнали/код). Іншими словами: відправник не є єдиною поверхнею загроз; **сам вміст** може нести ворожі інструкції. Коли інструменти ввімкнено, типовий ризик — витік контексту або запуск викликів інструментів. Зменшуйте радіус ураження так: - Використовуйте **агента-читача** лише для читання або без інструментів, щоб підсумовувати недовірений вміст, а потім передавайте підсумок основному агенту. - Тримайте `web_search` / `web_fetch` / `browser` вимкненими для агентів з інструментами, якщо вони не потрібні. - Для URL-входів OpenResponses (`input_file` / `input_image`) задавайте суворі `gateway.http.endpoints.responses.files.urlAllowlist` і `gateway.http.endpoints.responses.images.urlAllowlist`, а `maxUrlParts` тримайте низьким. Порожні списки дозволених вважаються незаданими; використовуйте `files.allowUrl: false` / `images.allowUrl: false`, якщо хочете повністю вимкнути отримання URL. - Для файлових входів OpenResponses декодований текст `input_file` усе ще ін’єктується як **недовірений зовнішній вміст**. Не покладайтеся на те, що текст файлу є довіреним лише тому, що Gateway декодував його локально. Ін’єктований блок усе одно містить явні маркери межі `<<>>` плюс метадані `Source: External`, навіть якщо цей шлях пропускає довший банер `SECURITY NOTICE:`. - Таке саме загортання на основі маркерів застосовується, коли розпізнавання медіа витягує текст із прикріплених документів перед додаванням цього тексту до медіа-промпта. - Увімкніть ізоляцію та суворі списки дозволених інструментів для будь-якого агента, який торкається недовіреного вводу. - Тримайте секрети поза промптами; натомість передавайте їх через env/config на хості gateway. ### Self-hosted LLM бекенди OpenAI-сумісні self-hosted бекенди, як-от vLLM, SGLang, TGI, LM Studio або кастомні стеки токенізаторів Hugging Face, можуть відрізнятися від хостингових провайдерів тим, як обробляються спеціальні токени чат-шаблонів. Якщо бекенд токенізує буквальні рядки на кшталт `<|im_start|>`, `<|start_header_id|>` або `` як структурні токени чат-шаблону всередині користувацького вмісту, недовірений текст може спробувати підробити межі ролей на шарі токенізатора. OpenClaw видаляє поширені літерали спеціальних токенів сімейств моделей із загорнутого зовнішнього вмісту перед надсиланням його до моделі. Тримайте загортання зовнішнього вмісту ввімкненим і віддавайте перевагу налаштуванням бекенда, які розділяють або екранують спеціальні токени в наданому користувачем вмісті, коли це доступно. Хостингові провайдери, як-от OpenAI і Anthropic, уже застосовують власну санітизацію на боці запиту. ### Сила моделі (примітка з безпеки) Стійкість до prompt injection **не** є однаковою на різних рівнях моделей. Менші/дешевші моделі загалом більш схильні до неправильного використання інструментів і перехоплення інструкцій, особливо під ворожими промптами. Для агентів з інструментами або агентів, які читають недовірений вміст, ризик prompt injection зі старішими/меншими моделями часто надто високий. Не запускайте такі навантаження на слабких рівнях моделей. Рекомендації: - **Використовуйте модель найновішого покоління найкращого рівня** для будь-якого бота, який може запускати інструменти або торкатися файлів/мереж. - **Не використовуйте старіші/слабші/менші рівні** для агентів з інструментами або недовірених вхідних скриньок; ризик prompt injection надто високий. - Якщо ви мусите використовувати меншу модель, **зменшіть радіус ураження** (інструменти лише для читання, сильна ізоляція, мінімальний доступ до файлової системи, суворі списки дозволених). - Під час запуску малих моделей **увімкніть ізоляцію для всіх сеансів** і **вимкніть web_search/web_fetch/browser**, якщо вхідні дані не перебувають під жорстким контролем. - Для персональних асистентів лише для чату з довіреним вводом і без інструментів менші моделі зазвичай прийнятні. ## Reasoning і докладний вивід у групах `/reasoning`, `/verbose` і `/trace` можуть розкривати внутрішні міркування, вивід інструментів або діагностику plugin, які не призначалися для публічного каналу. У групових налаштуваннях розглядайте їх як **лише для налагодження** і тримайте вимкненими, якщо вони вам явно не потрібні. Рекомендації: - Тримайте `/reasoning`, `/verbose` і `/trace` вимкненими в публічних кімнатах. - Якщо вмикаєте їх, робіть це лише в довірених DM або жорстко контрольованих кімнатах. - Пам’ятайте: докладний і trace-вивід може містити аргументи інструментів, URL, діагностику plugin і дані, які бачила модель. ## Приклади посилення конфігурації ### Права доступу до файлів Тримайте конфігурацію + стан приватними на хості gateway: - `~/.openclaw/openclaw.json`: `600` (лише читання/запис користувачем) - `~/.openclaw`: `700` (лише користувач) `openclaw doctor` може попередити та запропонувати посилити ці права доступу. ### Мережеве відкриття (bind, port, firewall) Gateway мультиплексує **WebSocket + HTTP** на одному порту: - Типово: `18789` - Конфігурація/прапорці/env: `gateway.port`, `--port`, `OPENCLAW_GATEWAY_PORT` Ця HTTP-поверхня включає Control UI і хост canvas: - Control UI (SPA-ресурси) (типовий базовий шлях `/`) - Хост canvas: `/__openclaw__/canvas/` і `/__openclaw__/a2ui/` (довільні HTML/JS; розглядайте як недовірений вміст) Якщо ви завантажуєте canvas-вміст у звичайному браузері, ставтеся до нього як до будь-якої іншої недовіреної вебсторінки: - Не відкривайте хост canvas для недовірених мереж/користувачів. - Не змушуйте canvas-вміст спільно використовувати той самий origin із привілейованими веб-поверхнями, якщо ви повністю не розумієте наслідків. Режим bind керує тим, де Gateway слухає: - `gateway.bind: "loopback"` (типово): підключатися можуть лише локальні клієнти. - Нелокальні bind (`"lan"`, `"tailnet"`, `"custom"`) розширюють поверхню атаки. Використовуйте їх лише з автентифікацією gateway (спільний токен/пароль або правильно налаштований довірений проксі) і справжнім firewall. Практичні правила: - Надавайте перевагу Tailscale Serve замість прив’язок до LAN (Serve тримає Gateway на loopback, а Tailscale обробляє доступ). - Якщо потрібно прив’язатися до LAN, обмежте порт у firewall жорстким дозволеним списком IP-адрес джерел; не робіть для нього широке port-forwarding. - Ніколи не відкривайте Gateway без автентифікації на `0.0.0.0`. ### Публікація портів Docker з UFW Якщо ви запускаєте OpenClaw з Docker на VPS, пам’ятайте, що опубліковані порти контейнерів (`-p HOST:CONTAINER` або Compose `ports:`) маршрутизуються через ланцюги переспрямування Docker, а не лише через правила `INPUT` хоста. Щоб трафік Docker відповідав вашій політиці firewall, застосовуйте правила в `DOCKER-USER` (цей ланцюг обробляється перед власними правилами accept Docker). У багатьох сучасних дистрибутивах `iptables`/`ip6tables` використовують frontend `iptables-nft` і все одно застосовують ці правила до backend nftables. Мінімальний приклад дозволеного списку (IPv4): ```bash # /etc/ufw/after.rules (append as its own *filter section) *filter :DOCKER-USER - [0:0] -A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j RETURN -A DOCKER-USER -s 127.0.0.0/8 -j RETURN -A DOCKER-USER -s 10.0.0.0/8 -j RETURN -A DOCKER-USER -s 172.16.0.0/12 -j RETURN -A DOCKER-USER -s 192.168.0.0/16 -j RETURN -A DOCKER-USER -s 100.64.0.0/10 -j RETURN -A DOCKER-USER -p tcp --dport 80 -j RETURN -A DOCKER-USER -p tcp --dport 443 -j RETURN -A DOCKER-USER -m conntrack --ctstate NEW -j DROP -A DOCKER-USER -j RETURN COMMIT ``` IPv6 має окремі таблиці. Додайте відповідну політику в `/etc/ufw/after6.rules`, якщо Docker IPv6 увімкнено. Уникайте жорстко заданих назв інтерфейсів, як-от `eth0`, у фрагментах документації. Назви інтерфейсів відрізняються між образами VPS (`ens3`, `enp*` тощо), а невідповідність може випадково пропустити ваше правило deny. Швидка перевірка після перезавантаження: ```bash ufw reload iptables -S DOCKER-USER ip6tables -S DOCKER-USER nmap -sT -p 1-65535 --open ``` Очікувані зовнішні порти мають бути лише тими, які ви навмисно відкриваєте (для більшості налаштувань: SSH + порти вашого reverse proxy). ### Виявлення mDNS/Bonjour Коли вбудований plugin `bonjour` увімкнено, Gateway транслює свою присутність через mDNS (`_openclaw-gw._tcp` на порту 5353) для виявлення локальних пристроїв. У повному режимі це включає TXT-записи, які можуть розкривати операційні деталі: - `cliPath`: повний шлях файлової системи до бінарного файлу CLI (розкриває ім’я користувача та місце встановлення) - `sshPort`: оголошує доступність SSH на хості - `displayName`, `lanHost`: інформація про hostname **Міркування операційної безпеки:** Трансляція деталей інфраструктури спрощує розвідку для будь-кого в локальній мережі. Навіть "нешкідлива" інформація, як-от шляхи файлової системи й доступність SSH, допомагає зловмисникам картографувати ваше середовище. **Рекомендації:** 1. **Тримайте Bonjour вимкненим, якщо виявлення LAN не потрібне.** Bonjour автоматично запускається на хостах macOS і є opt-in в інших середовищах; прямі URL Gateway, Tailnet, SSH або wide-area DNS-SD уникають локального multicast. 2. **Мінімальний режим** (типово, коли Bonjour увімкнено; рекомендовано для відкритих gateway): вилучає чутливі поля з трансляцій mDNS: ```json5 { discovery: { mdns: { mode: "minimal" }, }, } ``` 3. **Вимкніть режим mDNS**, якщо хочете залишити plugin увімкненим, але придушити виявлення локальних пристроїв: ```json5 { discovery: { mdns: { mode: "off" }, }, } ``` 4. **Повний режим** (opt-in): включає `cliPath` + `sshPort` у TXT-записи: ```json5 { discovery: { mdns: { mode: "full" }, }, } ``` 5. **Змінна середовища** (альтернатива): задайте `OPENCLAW_DISABLE_BONJOUR=1`, щоб вимкнути mDNS без змін конфігурації. Коли Bonjour увімкнено в мінімальному режимі, Gateway транслює достатньо для виявлення пристрою (`role`, `gatewayPort`, `transport`), але вилучає `cliPath` і `sshPort`. Застосунки, яким потрібна інформація про шлях CLI, можуть натомість отримати її через автентифіковане WebSocket-з’єднання. ### Захистіть Gateway WebSocket (локальна автентифікація) Автентифікація Gateway **обов’язкова за замовчуванням**. Якщо не налаштовано чинний шлях автентифікації gateway, Gateway відхиляє WebSocket-з’єднання (fail-closed). Onboarding типово генерує токен (навіть для loopback), тому локальні клієнти мають автентифікуватися. Задайте токен, щоб **усі** WS-клієнти мали автентифікуватися: ```json5 { gateway: { auth: { mode: "token", token: "your-token" }, }, } ``` Doctor може згенерувати його для вас: `openclaw doctor --generate-gateway-token`. `gateway.remote.token` і `gateway.remote.password` є джерелами облікових даних клієнта. Вони **не** захищають локальний WS-доступ самі по собі. Локальні шляхи викликів можуть використовувати `gateway.remote.*` як fallback лише коли `gateway.auth.*` не задано. Якщо `gateway.auth.token` або `gateway.auth.password` явно налаштовано через SecretRef і не розв’язано, розв’язання завершується fail-closed (без маскування через remote fallback). Необов’язково: закріпіть remote TLS через `gateway.remote.tlsFingerprint` під час використання `wss://`. Plaintext `ws://` приймається для loopback, приватних IP-літералів, `.local` і Tailnet `*.ts.net` URL gateway. Для інших довірених private-DNS імен задайте `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` у процесі клієнта як break-glass. Це навмисно лише змінна середовища процесу, а не ключ конфігурації `openclaw.json`. Мобільне pairing і ручні або скановані маршрути gateway на Android суворіші: cleartext приймається для loopback, але private-LAN, link-local, `.local` і hostnames без крапок мають використовувати TLS, якщо ви явно не ввімкнули довірений cleartext-шлях приватної мережі. Pairing локального пристрою: - Pairing пристрою автоматично схвалюється для прямих підключень через local loopback, щоб клієнти на тому самому хості працювали плавно. - OpenClaw також має вузький backend/container-local шлях самопідключення для довірених helper-потоків зі спільним секретом. - Підключення через Tailnet і LAN, включно з same-host tailnet binds, вважаються remote для pairing і все одно потребують схвалення. - Доказ forwarded-header у loopback-запиті дискваліфікує loopback locality. Автосхвалення metadata-upgrade має вузьку область дії. Див. [pairing Gateway](/uk/gateway/pairing) для обох правил. Режими автентифікації: - `gateway.auth.mode: "token"`: спільний bearer token (рекомендовано для більшості налаштувань). - `gateway.auth.mode: "password"`: автентифікація паролем (краще задавати через env: `OPENCLAW_GATEWAY_PASSWORD`). - `gateway.auth.mode: "trusted-proxy"`: довіряє identity-aware reverse proxy автентифікувати користувачів і передавати identity через headers (див. [автентифікацію через довірений проксі](/uk/gateway/trusted-proxy-auth)). Чеклист ротації (token/password): 1. Згенеруйте/задайте новий secret (`gateway.auth.token` або `OPENCLAW_GATEWAY_PASSWORD`). 2. Перезапустіть Gateway (або перезапустіть застосунок macOS, якщо він наглядає за Gateway). 3. Оновіть усі remote-клієнти (`gateway.remote.token` / `.password` на машинах, які викликають Gateway). 4. Перевірте, що ви більше не можете підключитися зі старими обліковими даними. ### Заголовки identity Tailscale Serve Коли `gateway.auth.allowTailscale` має значення `true` (типово для Serve), OpenClaw приймає заголовки identity Tailscale Serve (`tailscale-user-login`) для автентифікації Control UI/WebSocket. OpenClaw перевіряє identity, розв’язуючи адресу `x-forwarded-for` через локальний daemon Tailscale (`tailscale whois`) і зіставляючи її із заголовком. Це спрацьовує лише для запитів, які потрапляють на loopback і містять `x-forwarded-for`, `x-forwarded-proto` та `x-forwarded-host`, як інжектовано Tailscale. Для цього async-шляху перевірки identity невдалі спроби для того самого `{scope, ip}` серіалізуються до того, як limiter зафіксує failure. Тому одночасні невдалі повтори від одного клієнта Serve можуть одразу заблокувати другу спробу замість того, щоб пройти наввипередки як дві звичайні невідповідності. HTTP API endpoints (наприклад `/v1/*`, `/tools/invoke` і `/api/channels/*`) **не** використовують автентифікацію через заголовки identity Tailscale. Вони все одно дотримуються налаштованого режиму HTTP-автентифікації gateway. Важлива примітка щодо межі: - HTTP bearer auth Gateway фактично є all-or-nothing операторським доступом. - Вважайте облікові дані, які можуть викликати `/v1/chat/completions`, `/v1/responses`, маршрути plugin, як-от `/api/v1/admin/rpc`, або `/api/channels/*`, повнодоступними operator secrets для цього gateway. - На OpenAI-сумісній HTTP-поверхні bearer auth зі спільним secret відновлює повний типовий набір operator scopes (`operator.admin`, `operator.approvals`, `operator.pairing`, `operator.read`, `operator.talk.secrets`, `operator.write`) і owner semantics для agent turns; вужчі значення `x-openclaw-scopes` не зменшують цей шлях зі спільним secret. - Per-request scope semantics на HTTP застосовуються лише тоді, коли запит надходить із режиму з identity, як-от trusted proxy auth, або з явно no-auth private ingress. - У цих режимах з identity відсутність `x-openclaw-scopes` призводить до fallback на звичайний типовий набір operator scopes; надсилайте заголовок явно, коли потрібен вужчий набір scopes. Owner-level OpenAI-сумісні заголовки, як-от `x-openclaw-model`, потребують `operator.admin`, коли scopes звужено. - `/tools/invoke` і endpoints історії HTTP sessions дотримуються того самого правила спільного secret: bearer auth через token/password також вважається повним операторським доступом, тоді як режими з identity все одно враховують оголошені scopes. - Не діліться цими обліковими даними з недовіреними callers; надавайте перевагу окремим gateway для кожної межі довіри. **Припущення довіри:** tokenless Serve auth припускає, що gateway host є довіреним. Не вважайте це захистом від hostile same-host processes. Якщо на gateway host може виконуватися недовірений локальний код, вимкніть `gateway.auth.allowTailscale` і вимагайте явну автентифікацію зі спільним secret через `gateway.auth.mode: "token"` або `"password"`. **Правило безпеки:** не пересилайте ці заголовки з власного reverse proxy. Якщо ви завершуєте TLS або проксіюєте перед gateway, вимкніть `gateway.auth.allowTailscale` і використовуйте shared-secret auth (`gateway.auth.mode: "token"` або `"password"`) або [автентифікацію через довірений проксі](/uk/gateway/trusted-proxy-auth) натомість. Довірені проксі: - Якщо ви завершуєте TLS перед Gateway, задайте `gateway.trustedProxies` на IP-адреси вашого proxy. - OpenClaw довірятиме `x-forwarded-for` (або `x-real-ip`) з цих IP-адрес, щоб визначити IP клієнта для перевірок local pairing і HTTP auth/local checks. - Переконайтеся, що ваш proxy **перезаписує** `x-forwarded-for` і блокує прямий доступ до порту Gateway. Див. [Tailscale](/uk/gateway/tailscale) і [огляд Web](/uk/web). ### Керування браузером через node host (рекомендовано) Якщо ваш Gateway є remote, але браузер працює на іншій машині, запустіть **node host** на машині браузера й дозвольте Gateway проксіювати дії браузера (див. [інструмент браузера](/uk/tools/browser)). Ставтеся до node pairing як до admin access. Рекомендований шаблон: - Тримайте Gateway і node host в одному tailnet (Tailscale). - Свідомо виконайте pairing node; вимкніть маршрутизацію browser proxy, якщо вона вам не потрібна. Уникайте: - Відкриття relay/control портів через LAN або публічний Internet. - Tailscale Funnel для endpoints керування браузером (публічне відкриття). ### Secrets на диску Припускайте, що все під `~/.openclaw/` (або `$OPENCLAW_STATE_DIR/`) може містити secrets або приватні дані: - `openclaw.json`: конфіг може містити токени (gateway, віддалений gateway), налаштування провайдерів і списки дозволеного. - `credentials/**`: облікові дані каналів (приклад: облікові дані WhatsApp), списки дозволеного для сполучення, застарілі імпорти OAuth. - `agents//agent/auth-profiles.json`: API-ключі, профілі токенів, OAuth-токени та необов'язкові `keyRef`/`tokenRef`. - `agents//agent/codex-home/**`: обліковий запис app-server Codex для окремого агента, конфіг, Skills, plugins, нативний стан потоків і діагностика (типово). - `$CODEX_HOME/**` або `~/.codex/**`: коли Codex plugin явно використовує `appServer.homeScope: "user"`, Gateway може читати й оновлювати нативний обліковий запис Codex, конфіг, plugins і потоки. Вважайте це привілейованим доступом власника; цей режим працює лише через локальний stdio, а керування нативними потоками доступне лише власнику. - `secrets.json` (необов'язково): файлове секретне навантаження, яке використовують провайдери SecretRef `file` (`secrets.providers`). - `agents//agent/auth.json`: файл застарілої сумісності. Статичні записи `api_key` очищаються під час виявлення. - `agents//sessions/**`: транскрипти сесій (`*.jsonl`) + метадані маршрутизації (`sessions.json`), які можуть містити приватні повідомлення та вивід інструментів. - пакети bundled plugin: установлені plugins (плюс їхні `node_modules/`). - `sandboxes/**`: робочі простори пісочниць інструментів; можуть накопичувати копії файлів, які ви читаєте/записуєте всередині пісочниці. Поради з посилення захисту: - Тримайте дозволи суворими (`700` для каталогів, `600` для файлів). - Використовуйте повнодискове шифрування на хості gateway. - Віддавайте перевагу окремому обліковому запису користувача ОС для Gateway, якщо хост спільний. ### Файли `.env` робочого простору OpenClaw завантажує локальні для робочого простору файли `.env` для агентів та інструментів, але ніколи не дозволяє цим файлам непомітно перевизначати засоби керування виконанням gateway. - Змінні середовища з обліковими даними провайдерів блокуються з недовірених файлів `.env` робочого простору. Приклади: `GEMINI_API_KEY`, `GOOGLE_API_KEY`, `XAI_API_KEY`, `MISTRAL_API_KEY`, `GROQ_API_KEY`, `DEEPSEEK_API_KEY`, `PERPLEXITY_API_KEY`, `BRAVE_API_KEY`, `TAVILY_API_KEY`, `EXA_API_KEY`, `FIRECRAWL_API_KEY` і ключі автентифікації провайдерів, оголошені встановленими довіреними plugins. Розміщуйте облікові дані провайдерів у середовищі процесу Gateway, `~/.openclaw/.env` (`$OPENCLAW_STATE_DIR/.env`), блоці конфігу `env` або необов'язковому імпорті login-shell. - Будь-який ключ, що починається з `OPENCLAW_*`, блокується з недовірених файлів `.env` робочого простору. - Налаштування кінцевих точок каналів для Matrix, Mattermost, IRC і Synology Chat також блокуються від перевизначень із `.env` робочого простору, тож клоновані робочі простори не можуть перенаправляти трафік bundled connector через локальний конфіг кінцевих точок. Env-ключі кінцевих точок (як-от `MATRIX_HOMESERVER`, `MATTERMOST_URL`, `IRC_HOST`, `SYNOLOGY_CHAT_INCOMING_URL`) мають надходити із середовища процесу gateway або `env.shellEnv`, а не з `.env`, завантаженого з робочого простору. - Блокування закрите за замовчуванням: нова змінна керування виконанням, додана в майбутньому релізі, не може бути успадкована з доданого до репозиторію або наданого атакувальником `.env`; ключ ігнорується, а gateway зберігає власне значення. - Довірені змінні середовища процесу/ОС, глобальний runtime dotenv, конфіг `env` і ввімкнений імпорт login-shell усе ще застосовуються - це обмежує лише завантаження файлів `.env` робочого простору. Чому: файли `.env` робочого простору часто лежать поруч із кодом агента, випадково комітяться або записуються інструментами. Блокування облікових даних провайдерів запобігає підстановці контрольованих атакувальником облікових записів провайдерів у клонованому робочому просторі. Блокування всього префікса `OPENCLAW_*` означає, що додавання нового прапорця `OPENCLAW_*` пізніше ніколи не призведе до непомітного успадкування зі стану робочого простору. ### Журнали й транскрипти (редагування та зберігання) Журнали й транскрипти можуть розкривати чутливу інформацію навіть за коректних контролів доступу: - Журнали Gateway можуть містити підсумки інструментів, помилки та URL-адреси. - Транскрипти сесій можуть містити вставлені секрети, вміст файлів, вивід команд і посилання. Рекомендації: - Тримайте редагування журналів і транскриптів увімкненим (`logging.redactSensitive: "tools"`; типово). - Додайте власні шаблони для вашого середовища через `logging.redactPatterns` (токени, імена хостів, внутрішні URL-адреси). - Під час поширення діагностики віддавайте перевагу `openclaw status --all` (зручно вставляти, секрети відредаговані) замість сирих журналів. - Видаляйте старі транскрипти сесій і файли журналів, якщо вам не потрібне тривале зберігання. Докладніше: [Журналювання](/uk/gateway/logging) ### DM: сполучення за замовчуванням ```json5 { channels: { whatsapp: { dmPolicy: "pairing" } }, } ``` ### Групи: вимагати згадку всюди ```json { "channels": { "whatsapp": { "groups": { "*": { "requireMention": true } } } }, "agents": { "list": [ { "id": "main", "groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] } } ] } } ``` У групових чатах відповідайте лише за явної згадки. ### Окремі номери (WhatsApp, Signal, Telegram) Для каналів на основі телефонних номерів розгляньте запуск вашого ШІ на окремому від особистого телефонному номері: - Особистий номер: ваші розмови залишаються приватними - Номер бота: ШІ обробляє їх із відповідними межами ### Режим лише для читання (через пісочницю та інструменти) Можна створити профіль лише для читання, поєднавши: - `agents.defaults.sandbox.workspaceAccess: "ro"` (або `"none"` без доступу до робочого простору) - списки дозволу/заборони інструментів, які блокують `write`, `edit`, `apply_patch`, `exec`, `process` тощо. Додаткові варіанти посилення захисту: - `tools.exec.applyPatch.workspaceOnly: true` (типово): гарантує, що `apply_patch` не може записувати/видаляти поза каталогом робочого простору, навіть коли пісочницю вимкнено. Установлюйте `false` лише якщо ви навмисно хочете, щоб `apply_patch` торкався файлів поза робочим простором. - `tools.fs.workspaceOnly: true` (необов'язково): обмежує шляхи `read`/`write`/`edit`/`apply_patch` і шляхи автоматичного завантаження зображень нативного prompt каталогом робочого простору (корисно, якщо сьогодні ви дозволяєте абсолютні шляхи й хочете єдине запобіжне обмеження). - Тримайте корені файлової системи вузькими: уникайте широких коренів, як-от ваш домашній каталог, для робочих просторів агентів/робочих просторів пісочниці. Широкі корені можуть відкривати чутливі локальні файли (наприклад, стан/конфіг у `~/.openclaw`) для файлових інструментів. ### Захищена базова конфігурація (копіювати/вставити) Один конфіг "безпечного стандартного значення", який залишає Gateway приватним, вимагає сполучення DM і уникає постійно активних групових ботів: ```json5 { gateway: { mode: "local", bind: "loopback", port: 18789, auth: { mode: "token", token: "your-long-random-token" }, }, channels: { whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } }, }, }, } ``` Якщо ви також хочете "безпечніше за замовчуванням" виконання інструментів, додайте пісочницю + забороніть небезпечні інструменти для будь-якого агента, що не є власником (приклад нижче в розділі "Профілі доступу для окремих агентів"). Вбудована базова лінія для керованих чатом ходів агента: відправники, що не є власниками, не можуть використовувати інструменти `cron` або `gateway`. ## Пісочниця (рекомендовано) Окремий документ: [Пісочниця](/uk/gateway/sandboxing) Два взаємодоповнювальні підходи: - **Запустити весь Gateway у Docker** (межа контейнера): [Docker](/uk/install/docker) - **Пісочниця інструментів** (`agents.defaults.sandbox`, gateway на хості + ізольовані пісочницею інструменти; Docker є типовим бекендом): [Пісочниця](/uk/gateway/sandboxing) Щоб запобігти міжагентному доступу, тримайте `agents.defaults.sandbox.scope` на `"agent"` (типово) або `"session"` для суворішої ізоляції за сесіями. `scope: "shared"` використовує один контейнер або робочий простір. Також врахуйте доступ до робочого простору агента всередині пісочниці: - `agents.defaults.sandbox.workspaceAccess: "none"` (типово) робить робочий простір агента недоступним; інструменти працюють із робочим простором пісочниці під `~/.openclaw/sandboxes` - `agents.defaults.sandbox.workspaceAccess: "ro"` монтує робочий простір агента лише для читання в `/agent` (вимикає `write`/`edit`/`apply_patch`) - `agents.defaults.sandbox.workspaceAccess: "rw"` монтує робочий простір агента для читання/запису в `/workspace` - Додаткові `sandbox.docker.binds` перевіряються щодо нормалізованих і канонікалізованих вихідних шляхів. Трюки з батьківськими symlink і канонічні псевдоніми домашнього каталогу все одно fail closed, якщо вони розв'язуються в заблоковані корені, як-от `/etc`, `/var/run` або каталоги облікових даних під домашнім каталогом ОС. `tools.elevated` - це глобальний базовий аварійний вихід, який запускає exec поза пісочницею. Ефективний хост типово `gateway` або `node`, коли ціль exec налаштовано на `node`. Тримайте `tools.elevated.allowFrom` суворим і не вмикайте його для незнайомців. Можна додатково обмежити підвищений режим для окремого агента через `agents.list[].tools.elevated`. Див. [Підвищений режим](/uk/tools/elevated). ### Запобіжне обмеження делегування субагентам Якщо ви дозволяєте інструменти сесій, розглядайте делеговані запуски субагентів як ще одне рішення щодо межі: - Забороніть `sessions_spawn`, якщо агенту справді не потрібне делегування. - Тримайте `agents.defaults.subagents.allowAgents` і будь-які перевизначення для окремого агента `agents.list[].subagents.allowAgents` обмеженими відомо безпечними цільовими агентами. - Для будь-якого workflow, який має залишатися в пісочниці, викликайте `sessions_spawn` із `sandbox: "require"` (типово `inherit`). - `sandbox: "require"` швидко завершується з помилкою, коли цільове дочірнє середовище виконання не в пісочниці. ## Ризики керування браузером Увімкнення керування браузером дає моделі можливість керувати реальним браузером. Якщо цей профіль браузера вже містить виконані входи в сесії, модель може отримати доступ до цих облікових записів і даних. Вважайте профілі браузера **чутливим станом**: - Віддавайте перевагу окремому профілю для агента (типовий профіль `openclaw`). - Уникайте спрямування агента на ваш особистий щоденний профіль. - Тримайте керування браузером хоста вимкненим для агентів у пісочниці, якщо ви їм не довіряєте. - Самостійний API керування браузером через loopback визнає лише автентифікацію зі спільним секретом (bearer-автентифікація токеном gateway або пароль gateway). Він не споживає заголовки ідентичності trusted-proxy або Tailscale Serve. - Вважайте завантаження браузера недовіреним введенням; віддавайте перевагу ізольованому каталогу завантажень. - За можливості вимкніть синхронізацію браузера/менеджери паролів у профілі агента (зменшує радіус ураження). - Для віддалених gateways вважайте "керування браузером" еквівалентним "доступу оператора" до всього, чого може досягти цей профіль. - Тримайте хости Gateway і node лише в tailnet; уникайте відкриття портів керування браузером у LAN або публічний інтернет. - Вимикайте маршрутизацію проксі браузера, коли вона не потрібна (`gateway.nodes.browser.mode="off"`). - Режим наявної сесії Chrome MCP **не** є "безпечнішим"; він може діяти від вашого імені в усьому, чого може досягти профіль Chrome на тому хості. ### Політика Browser SSRF (сувора за замовчуванням) Політика навігації браузера OpenClaw сувора за замовчуванням: приватні/внутрішні призначення залишаються заблокованими, якщо ви явно не погодитеся. - Типово: `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` не встановлено, тому навігація браузера тримає приватні/внутрішні/спеціального використання призначення заблокованими. - Застарілий псевдонім: `browser.ssrfPolicy.allowPrivateNetwork` усе ще приймається для сумісності. - Режим згоди: установіть `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true`, щоб дозволити приватні/внутрішні/спеціального використання призначення. - У суворому режимі використовуйте `hostnameAllowlist` (шаблони на кшталт `*.example.com`) і `allowedHostnames` (точні винятки хостів, включно із заблокованими іменами на кшталт `localhost`) для явних винятків. - Навігація перевіряється перед запитом і best-effort повторно перевіряється на кінцевій URL-адресі `http(s)` після навігації, щоб зменшити pivot через перенаправлення. Приклад суворої політики: ```json5 { browser: { ssrfPolicy: { dangerouslyAllowPrivateNetwork: false, hostnameAllowlist: ["*.example.com", "example.com"], allowedHostnames: ["localhost"], }, }, } ``` ## Профілі доступу для окремих агентів (мультиагент) З мультиагентною маршрутизацією кожен агент може мати власну пісочницю + політику інструментів: використовуйте це, щоб надати **повний доступ**, **лише читання** або **без доступу** для окремого агента. Див. [Пісочниця й інструменти для Multi-Agent](/uk/tools/multi-agent-sandbox-tools), щоб отримати повні подробиці та правила пріоритету. Поширені сценарії: - Особистий агент: повний доступ, без пісочниці - Сімейний/робочий агент: у пісочниці + інструменти лише для читання - Публічний агент: у пісочниці + без інструментів файлової системи/оболонки ### Приклад: повний доступ (без пісочниці) ```json5 { agents: { list: [ { id: "personal", workspace: "~/.openclaw/workspace-personal", sandbox: { mode: "off" }, }, ], }, } ``` ### Приклад: інструменти лише для читання + робочий простір лише для читання ```json5 { agents: { list: [ { id: "family", workspace: "~/.openclaw/workspace-family", sandbox: { mode: "all", scope: "agent", workspaceAccess: "ro", }, tools: { allow: ["read"], deny: ["write", "edit", "apply_patch", "exec", "process", "browser"], }, }, ], }, } ``` ### Приклад: без доступу до файлової системи/оболонки (обмін повідомленнями з провайдером дозволено) ```json5 { agents: { list: [ { id: "public", workspace: "~/.openclaw/workspace-public", sandbox: { mode: "all", scope: "agent", workspaceAccess: "none", }, // Session tools can reveal sensitive data from transcripts. By default OpenClaw limits these tools // to the current session + spawned subagent sessions, but you can clamp further if needed. // See `tools.sessions.visibility` in the configuration reference. tools: { sessions: { visibility: "tree" }, // self | tree | agent | all allow: [ "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "session_status", "whatsapp", "telegram", "slack", "discord", ], deny: [ "read", "write", "edit", "apply_patch", "exec", "process", "browser", "canvas", "nodes", "cron", "gateway", "image", ], }, }, ], }, } ``` ## Реагування на інциденти Якщо ваш ШІ зробить щось погане: ### Локалізуйте 1. **Зупиніть його:** зупиніть застосунок macOS (якщо він керує Gateway) або завершіть ваш процес `openclaw gateway`. 2. **Закрийте доступ:** задайте `gateway.bind: "loopback"` (або вимкніть Tailscale Funnel/Serve), доки не зрозумієте, що сталося. 3. **Заморозьте доступ:** перемкніть ризиковані DM/групи на `dmPolicy: "disabled"` / вимагайте згадування та видаліть записи дозволу для всіх `"*"`, якщо вони у вас були. ### Ротуйте (припускайте компрометацію, якщо секрети витекли) 1. Ротуйте автентифікацію Gateway (`gateway.auth.token` / `OPENCLAW_GATEWAY_PASSWORD`) і перезапустіть. 2. Ротуйте секрети віддалених клієнтів (`gateway.remote.token` / `.password`) на будь-якій машині, що може викликати Gateway. 3. Ротуйте облікові дані провайдера/API (облікові дані WhatsApp, токени Slack/Discord, ключі моделі/API в `auth-profiles.json` і значення зашифрованих секретних payload, коли вони використовуються). ### Аудит 1. Перевірте журнали Gateway: `/tmp/openclaw/openclaw-YYYY-MM-DD.log` (або `logging.file`). 2. Перегляньте відповідні транскрипти: `~/.openclaw/agents//sessions/*.jsonl`. 3. Перегляньте останні зміни конфігурації (усе, що могло розширити доступ: `gateway.bind`, `gateway.auth`, політики DM/груп, `tools.elevated`, зміни Plugin). 4. Повторно запустіть `openclaw security audit --deep` і підтвердьте, що критичні знахідки усунуто. ### Зберіть для звіту - Часова позначка, ОС хоста Gateway + версія OpenClaw - Транскрипти сеансів + короткий хвіст журналу (після редагування) - Що надіслав атакувальник + що зробив агент - Чи був Gateway відкритий поза loopback (LAN/Tailscale Funnel/Serve) ## Сканування секретів CI запускає pre-commit-хук `detect-private-key` для репозиторію. Якщо він завершується невдало, видаліть або ротуйте зафіксований у репозиторії ключовий матеріал, а потім відтворіть локально: ```bash pre-commit run --all-files detect-private-key ``` ## Повідомлення про проблеми безпеки Знайшли вразливість в OpenClaw? Будь ласка, повідомте відповідально: 1. Email: [security@openclaw.ai](mailto:security@openclaw.ai) 2. Не публікуйте відкрито, доки не буде виправлено 3. Ми зазначимо ваш внесок (якщо ви не віддаєте перевагу анонімності)