# Безпека

## Огляд

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

## Безпека мережі

### Зворотна петля за замовчуванням

Gateway прослуховує лише `127.0.0.1` (localhost), якщо ви явно не зміните режим прив'язки. За замовчуванням, нульова зовнішня мережева експозиція.

### Аутентифікація

Всі WebSocket-з'єднання вимагають аутентифікації:

- **Аутентифікація через токен**, Токен-носій (UUID або власний рядок)
- **Аутентифікація паролем**, Пароль, хешований за допомогою Bcrypt
- **Довірений проксі**, Попередньо аутентифіковані заголовки від зворотних проксі
- **Локальна довіра**, З'єднання через зворотну петлю неявно довіряються

### Безпека віддаленого доступу

Для віддаленого доступу рекомендований підхід, **Tailscale VPN** або **SSH-тунелювання**, ніколи не відкривайте Gateway безпосередньо в Інтернет.

## Спарювання пристроїв

### Як працює спарювання

Кожен клієнт, що підключається до Gateway, повинен бути спарений:

1. Пристрій представляє свою ідентичність (відбиток + відкритий ключ)
2. Gateway видає виклик спарювання (nonce)
3. Пристрій підписує nonce своїм приватним ключем
4. Ви затверджуєте пристрій через інтерфейс
5. 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 (патчі безпеки)
- Виявлення секретів у відкритому тексті
- Валідацію дозволеного списку плагінів
- Аудит відкритих мережевих інтерфейсів
- Повноту конфігурації аутентифікації

При наданні дозволу аудит може автоматично усунути багато проблем.

## Найкращі практики

1. **Тримайте Gateway на зворотній петлі**, Використовуйте Tailscale або SSH для віддаленого доступу
2. **Увімкніть ізоляцію**, Виконуйте команди агентів у Docker-контейнерах
3. **Використовуйте дозволені списки виконання**, Обмежуйте, які команди агенти можуть виконувати на вузлах
4. **Встановіть токени аутентифікації**, Завжди налаштовуйте аутентифікацію через токен, навіть для зворотної петлі
5. **Перевіряйте дозволи агентів**, Використовуйте мінімальні профілі інструментів, де це можливо
6. **Тримайте Neotask оновленим**, Оновлення включають патчі безпеки
7. **Проводьте аудит регулярно**, Запускайте аудити безпеки для виявлення неправильних конфігурацій
8. **Обмежте завантаження плагінів**, Встановлюйте лише довірені плагіни