Безпека
Огляд
Neotask розроблено з архітектурою, що ставить безпеку на перше місце. Gateway за замовчуванням прив'язується до localhost, всі чутливі дані шифруються у стані спокою, а виконання агентів може бути ізольоване в окремих контейнерах.
Безпека мережі
Зворотна петля за замовчуванням
Gateway прослуховує лише 127.0.0.1 (localhost), якщо ви явно не зміните режим прив'язки. За замовчуванням, нульова зовнішня мережева експозиція.
Аутентифікація
Всі WebSocket-з'єднання вимагають аутентифікації:
- Аутентифікація через токен, Токен-носій (UUID або власний рядок)
- Аутентифікація паролем, Пароль, хешований за допомогою Bcrypt
- Довірений проксі, Попередньо аутентифіковані заголовки від зворотних проксі
- Локальна довіра, З'єднання через зворотну петлю неявно довіряються
Безпека віддаленого доступу
Для віддаленого доступу рекомендований підхід, Tailscale VPN або SSH-тунелювання, ніколи не відкривайте Gateway безпосередньо в Інтернет.
Спарювання пристроїв
Як працює спарювання
Кожен клієнт, що підключається до Gateway, повинен бути спарений:
- Пристрій представляє свою ідентичність (відбиток + відкритий ключ)
- Gateway видає виклик спарювання (nonce)
- Пристрій підписує nonce своїм приватним ключем
- Ви затверджуєте пристрій через інтерфейс
- Gateway видає токен пристрою для майбутніх підключень
Модель довіри
- Локальні пристрої (зворотна петля) автоматично затверджуються для зручності
- Нелокальні пристрої вимагають явного затвердження
- Токени пристроїв зберігаються локально та повторно використовуються при перепідключенні
- Пристрої можуть бути відкликані в будь-який час
Шифрування
Дані у стані спокою
- AES-256-GCM, Всі токени, секрети та API-ключі шифруються у стані спокою
- Ключі, похідні від машини, Ключі шифрування, отримані за допомогою scrypt від ідентичності пристрою
- Без зберігання у відкритому тексті, Токени ніколи не зберігаються у відкритому тексті
Дані в транзиті
- TLS, HTTPS для API-комунікації
- WSS, WebSocket Secure для підключень Gateway (при використанні Tailscale Serve або зворотного проксі)
- Підпис HMAC, Цілісність запитів з nonce та міткою часу
Ізоляція (Sandbox)
Ізоляція на основі Docker
Виконання команд агентів може бути ізольоване в Docker-контейнерах:
- Профілі для кожного агента, Кожен агент може мати власну конфігурацію sandbox
- Обмеження ресурсів, Конфігуровані ліміти CPU, пам'яті та часу виконання
- Мережева ізоляція, Контейнери можуть бути ізольовані від мережі
- Обмеження файлової системи, Агенти мають доступ лише до свого простору роботи
- Власні образи, Використання попередньо побудованих образів з встановленими конкретними інструментами
Типи sandbox-ізоляції
| Тип | Опис |
|---|---|
| На сесію | Новий контейнер для кожної сесії |
| На агента | Постійний контейнер для кожного агента |
| Спільний | Спільний контейнер для кількох агентів |
Доступ до простору роботи
Агенти у sandbox мають доступ до своєї директорії простору роботи (змонтованої в контейнер), але не можуть отримати доступ до файлової системи хосту за межами свого простору роботи.
Дозволи на виконання
Контролюйте, які команди можуть виконувати агенти на вузлах та хості Gateway:
Режими
| Режим | Опис |
|---|---|
| Дозволений список | Виконуються лише попередньо схвалені команди |
| Запит | Невідомі команди запитують затвердження користувача |
| Повний | Без обмежень (використовуйте обережно) |
Конфігурація для кожного вузла
Кожен вузол (macOS, безголовий хост) має власну конфігурацію дозволів виконання, що зберігається локально. Ви можете дозволити конкретні бінарні файли (наприклад, /usr/bin/docker, /usr/local/bin/terraform), блокуючи все інше.
Підвищений режим
Деякі операції вимагають виконання безпосередньо на хості Gateway (не в sandbox). Підвищений режим:
- Контролюється явним дозволом у конфігурації агента
- Доступний лише на хості Gateway
- Вимкнений за замовчуванням
- Доступний для аудиту через ведення журналу
Аудит безпеки
Вбудований аудит безпеки перевіряє:
- Дозволи на файл конфігурації (мають бути 600)
- Дозволи на файли сесій
- Версію Node.js (патчі безпеки)
- Виявлення секретів у відкритому тексті
- Валідацію дозволеного списку плагінів
- Аудит відкритих мережевих інтерфейсів
- Повноту конфігурації аутентифікації
При наданні дозволу аудит може автоматично усунути багато проблем.
Найкращі практики
- Тримайте Gateway на зворотній петлі, Використовуйте Tailscale або SSH для віддаленого доступу
- Увімкніть ізоляцію, Виконуйте команди агентів у Docker-контейнерах
- Використовуйте дозволені списки виконання, Обмежуйте, які команди агенти можуть виконувати на вузлах
- Встановіть токени аутентифікації, Завжди налаштовуйте аутентифікацію через токен, навіть для зворотної петлі
- Перевіряйте дозволи агентів, Використовуйте мінімальні профілі інструментів, де це можливо
- Тримайте Neotask оновленим, Оновлення включають патчі безпеки
- Проводьте аудит регулярно, Запускайте аудити безпеки для виявлення неправильних конфігурацій
- Обмежте завантаження плагінів, Встановлюйте лише довірені плагіни