26. Облікові дані, шифрування та доступ¶

Work in progress

Захист StudioFS складається з кількох компонентів, кожен із яких відповідає за окремий аспект.

Які секрети потрібно берегти¶

Для роботи тому потрібні облікові дані S3 та рядок підключення до PostgreSQL. Якщо в рядку підключення є пароль, увесь цей рядок — секрет. Окремо StudioFS автоматично створює ключ шифрування вмісту тому.

Ці дані не залишаються лише в пам’яті під час першого запуску. Після init локальна база метаданих <назва-тому>.db містить конфігурацію тому, зокрема ключі доступу S3, рядок підключення до PostgreSQL і ключ шифрування. Конфігурація тому також передається до спільних метаданих PostgreSQL, де зберігається й матеріал ключа шифрування. Під час discover інший комп’ютер отримує конфігурацію та створює власну локальну базу.

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

Що шифрується автоматично¶

У поточному форматі тому StudioFS шифрує вміст перед завантаженням до S3-сумісного сховища. Для цього використовується XChaCha20-Poly1305 і випадковий 256-бітний ключ тому. Кожен віддалений фрагмент шифрується окремо, а не весь файл як один об’єкт.

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

Вмикати це вручну не потрібно. У StudioFS немає окремого прапорця шифрування, пароля шифрування чи налаштування KMS. Не потрібно додавати такі параметри до init, mount або settings. Старі томи з незашифрованими віддаленими об’єктами не мають гарантованої сумісності з поточним форматом.

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

Що залишається відкритим¶

Шифрування віддаленого вмісту не охоплює всі дані StudioFS:

Де або що	Межа захисту
Вміст віддалених фрагментів у S3	Шифрується StudioFS перед завантаженням
Локальний кеш і файли підготовки до завантаження	Можуть містити відкритий вміст; StudioFS їх не шифрує
Локальна база метаданих і PostgreSQL	Не шифруються цим механізмом
Назви файлів, розміри, атрибути, ACL, розширені атрибути та знімки метаданих	Не приховуються цим механізмом
Пам’ять процесу та буфери файлової системи	Містять відкриті дані під час роботи

Захищаємо з’єднання¶

Шифрування об’єктів у S3 та шифрування мережевого з’єднання виконують різні завдання. Для робочої кінцевої точки S3 використовуйте https://. StudioFS також допускає явно задану адресу http://, але використовуйте її лише для з’єднання в довіреній локальній мережі. Якщо клієнти підключаються через інтернет, налаштуйте TLS на reverse proxy та використовуйте https://.

Для PostgreSQL зверніть увагу на параметр sslmode у рядку підключення:

Якщо його не задано, типовий режим спочатку намагається використати TLS, але допускає незашифроване з’єднання, коли сервер не підтримує TLS.
sslmode=require вимагає TLS: якщо встановити захищене з’єднання не вдалося, підключення завершується помилкою.
sslmode=disable явно вимикає TLS. Це свідомий вибір адміністратора, а не рекомендований спосіб усунути помилку сертифіката.

Поточний клієнт PostgreSQL використовує Rustls і набір кореневих сертифікатів webpki-roots для перевірки сертифіката та імені сервера. Використовуйте ім’я сервера, яке відповідає сертифікату. Якщо замінити його на VPN-адресу, а сертифікат видано лише на DNS-ім’я, перевірка може завершитися помилкою.

Приватна мережа та права доступу¶

Як описано в розділі про Tailscale, обмежте доступ до PostgreSQL приватним маршрутом. Tailscale (або NetBird) обмежує шлях до сервера, але дозволи потрібно налаштувати на кожній межі:

у VPN надайте визначеним користувачам і пристроям доступ лише до сервера та порту PostgreSQL;
у брандмауері й правилах хмарного провайдера закрийте публічний доступ до PostgreSQL;
у PostgreSQL налаштуйте автентифікацію, дозволені IP-адреси та права ролей;
у S3 залишайте бакет приватним і надавайте обліковим даним доступ лише до потрібного бакета або префікса й необхідних операцій.

Через шлюз із SNAT база може бачити адресу шлюзу замість адреси ноутбука. Врахуйте це в правилах доступу за IP-адресою, але не відкривайте доступ усьому інтернету заради зручності.

Зміст · English · ← Попередня · Наступна →