Діліться конфіденційною інформацією з Cellar. Кінцеве шифрування, завжди безкоштовно. Реєстрація не потрібна.

Найкращі практики безпеки

INFO

Ця документація охоплює функції безпеки, доступні в Cellar API v3.2.0+

Cellar розроблено з пріоритетом безпеки. На цій сторінці висвітлено функції безпеки, найкращі практики та міркування щодо розгортання.

Безпека завантаження файлів

При використанні API v2 для завантаження файлів, Cellar реалізує кілька заходів безпеки для захисту від поширених векторів атак.

Обмеження розміру файлів

Параметр конфігурації APP_MAX_FILE_SIZE_MB контролює максимальний розмір файлу, який можна завантажити. Значення за замовчуванням 8 МБ розроблено для:

  • Підтримки поширених випадків використання (QR-коди, скріншоти, PDF, облікові дані, конфігураційні файли)
  • Сумісності з розгортаннями AWS Lambda (API Gateway має обмеження у 10 МБ для корисного навантаження)
  • Запобігання атакам відмови в обслуговуванні через завантаження великих файлів
  • Балансування використання пам’яті під час шифрування (файли буферуються в пам’яті)

Файли, які вміщуються в 8 МБ:

  • QR-коди та штрих-коди (< 1 МБ)
  • Скріншоти та стиснуті зображення (2-5 МБ)
  • PDF з текстом та зображеннями (1-6 МБ)
  • Приватні ключі, сертифікати та файли облікових даних (< 1 МБ)
  • Архіви вихідного коду та конфігураційні файли (1-5 МБ)
  • Короткі аудіозаписи (1-2 МБ)

Збільшення ліміту:

Для Docker або традиційних серверних розгортань ви можете збільшити ліміт, встановивши вище значення. Зверніть увагу, що розгортання Lambda обмежені лімітом API Gateway у 10 МБ.

APP_MAX_FILE_SIZE_MB=20  # Збільшити до 20 МБ для Docker розгортань

Автоматичний захист

Cellar автоматично застосовує наступні заходи безпеки до завантаження та завантаження файлів:

Перевірка введення:

  • Порожні файли (0 байтів) відхиляються
  • Розмір файлу перевіряється перед шифруванням
  • Неправильно сформовані multipart запити відхиляються

Захист завантаження:

Файли обслуговуються з заголовками безпеки, які запобігають поширеним веб-вразливостям:

  • Content-Type: application/octet-stream - Змушує браузер розглядати всі файли як завантаження
  • X-Content-Type-Options: nosniff - Запобігає атакам визначення типу MIME
  • Content-Security-Policy: default-src 'none' - Блокує будь-яке виконання скриптів
  • X-Frame-Options: DENY - Запобігає атакам clickjacking
  • Cache-Control: no-store, no-cache, must-revalidate - Запобігає кешуванню конфіденційних файлів

Підтримка типів файлів:

Підтримуються всі типи файлів без обмежень. Це забезпечує максимальну гнучкість для користувачів обмінюватися будь-яким типом секрету. Одержувачі відповідають за безпечну обробку завантажених файлів. Cellar зосереджується на безпечній передачі та зберіганні, а не на фільтрації вмісту.

Найкращі практики розгортання

При розгортанні Cellar у виробництві розгляньте ці рекомендації щодо безпеки:

1. Використовуйте HTTPS

Завжди розгортайте Cellar за HTTPS у виробництві. Хоча Cellar шифрує секрети в стані спокою за допомогою вибраного вами механізму криптографії, HTTPS захищає секрети під час передачі між клієнтами та API.

Налаштуйте ваш зворотний проксі або балансувальник навантаження для:

  • Завершення TLS з дійсними сертифікатами
  • Примусового перенаправлення HTTPS для HTTP запитів
  • Використання надійних наборів шифрів (TLS 1.2+)

2. Налаштуйте відповідні обмеження розміру файлів

Встановіть APP_MAX_FILE_SIZE_MB на основі вашого:

  • Випадку використання: Які типи файлів будуть обмінюватися користувачами?
  • Середовища розгортання: Ви використовуєте Lambda (ліміт 10 МБ) чи Docker (гнучкий)?
  • Доступної пам’яті: Файли буферуються в пам’яті під час шифрування
  • Ємності Redis: Зашифровані файли зберігаються в Redis

3. Моніторинг використання сховища

Cellar зберігає всі дані в Redis. Моніторте ваш екземпляр Redis, щоб запобігти виснаженню пам’яті:

  • Відстежуйте загальне використання пам’яті
  • Налаштуйте сповіщення при наближенні до лімітів пам’яті
  • Налаштуйте політику Redis maxmemory відповідно
  • Розгляньте налаштування збереження Redis на основі ваших вимог до довговічності

4. Впровадьте обмеження швидкості

Хоча Cellar реалізує обмеження розміру файлів, розгляньте додавання обмеження швидкості на вашому зворотному проксі або API gateway:

  • Обмежте запити на IP-адресу
  • Обмежте завантаження файлів за період часу
  • Захистіться від спроб грубої сили
  • Запобігайте автоматизованому скануванню ідентифікаторів секретів

Популярні інструменти для обмеження швидкості:

  • nginx модуль limit_req
  • AWS API Gateway throttling
  • Cloudflare rate limiting
  • Traefik rate limiting middleware

5. Захистіть ваш механізм криптографії

Для HashiCorp Vault:

  • Використовуйте принцип найменших привілеїв для дозволів AppRole
  • Регулярно оновлюйте токени Vault
  • Увімкніть журналювання аудиту Vault
  • Використовуйте TLS для з’єднань Vault

Для AWS KMS:

  • Використовуйте ролі IAM з мінімально необхідними дозволами
  • Увімкніть журналювання CloudTrail для операцій KMS
  • Використовуйте політики ключів KMS для обмеження доступу
  • Розгляньте використання різних ключів для кожного середовища

6. Захистіть ваше сховище даних

Для Redis:

  • Увімкніть аутентифікацію паролем (DATASTORE_REDIS_PASSWORD)
  • Використовуйте TLS для з’єднань Redis у виробництві
  • Обмежте мережевий доступ до Redis (правила брандмауера)
  • Розгляньте Redis ACL для детального контролю доступу
  • Тримайте Redis оновленим з патчами безпеки

7. Навчіть користувачів

Інформуйте ваших користувачів про:

  • Обробку файлів: Завантажені файли слід сканувати та перевіряти
  • Закінчення терміну дії: Встановлюйте відповідний час закінчення терміну дії залежно від рівня конфіденційності
  • Обмеження доступу: Використовуйте обмеження доступу для запобігання неавторизованому обміну
  • Обмін посиланнями: Посилання на секрети слід обмінюватися через безпечні канали (не електронну пошту)

Міркування щодо безпеки

Що захищає Cellar

Cellar забезпечує:

  • Шифрування в стані спокою через ваш вибраний механізм криптографії (Vault або AWS KMS)
  • Автоматичне видалення на основі часу закінчення терміну дії або обмежень доступу
  • Ефемерне сховище без постійного збереження файлової системи
  • Перевірка введення для запобігання неправильно сформованим або зловмисним завантаженням
  • Безпечні заголовки для запобігання XSS та атакам визначення вмісту

Що не захищає Cellar

Користувачі та адміністратори відповідають за:

  • Шифрування під час передачі: Використовуйте HTTPS для захисту даних між клієнтами та API
  • Сканування вмісту: Cellar не сканує файли на віруси або зловмисне програмне забезпечення
  • Контроль доступу: Будь-хто з посиланням на секрет може отримати до нього доступ (без аутентифікації)
  • Розповсюдження посилань: Переконайтеся, що посилання на секрети обмінюються через безпечні канали
  • Безпечна обробка файлів: Одержувачі повинні перевіряти та безпечно обробляти завантажені файли

Модель загроз

Cellar розроблено для захисту від:

  • Витоків даних: Секрети шифруються в стані спокою та автоматично видаляються
  • Неавторизованого доступу після закінчення терміну дії: Секрети негайно та назавжди видаляються
  • Надмірного обміну: Обмеження доступу запобігають необмеженому розповсюдженню
  • XSS атак: Заголовки безпеки запобігають виконанню скриптів
  • DoS атак: Обмеження розміру файлів запобігають виснаженню ресурсів

Cellar не захищає від:

  • Скомпрометованих посилань на секрети: Будь-хто з посиланням може отримати доступ до секрету
  • Атак людина-посередині: Використовуйте HTTPS для захисту від цього
  • Зловмисного вмісту файлів: Cellar не перевіряє та не фільтрує вміст файлів
  • Вразливостей інфраструктури: Тримайте ваше середовище розгортання безпечним та оновленим

Відповідність та аудит

Журналювання

Cellar веде журнал всіх операцій API, включаючи:

  • Створення секретів (з метаданими, але без вмісту)
  • Спроби доступу до секретів (успішні та невдалі)
  • Видалення секретів (вручну та автоматично)
  • Зміни конфігурації

Налаштуйте LOGGING_LEVEL та LOGGING_FORMAT відповідно до ваших вимог до аудиту.

Збереження даних

Cellar забезпечує збереження даних через:

  • Час закінчення терміну дії: Секрети автоматично видаляються після закінчення терміну дії
  • Обмеження доступу: Секрети видаляються після досягнення обмеження доступу
  • Відсутність резервних копій: Видалені секрети не можуть бути відновлені

Міркування щодо відповідності

При розгортанні Cellar для вимог відповідності:

  • Задокументуйте ваші процедури управління ключами шифрування
  • Ведіть журнали аудиту всіх операцій з секретами
  • Впроваджуйте відповідний контроль доступу на рівні інфраструктури
  • Розгляньте вимоги до розташування даних при виборі регіонів хмари
  • Перегляньте політики збереження даних вашої організації

Реагування на інциденти

Якщо ви підозрюєте проблему безпеки:

  1. Для компрометації секрету: Секрети автоматично закінчуються та можуть бути видалені вручну
  2. Для компрометації інфраструктури: Негайно оновіть всі облікові дані криптографії
  3. Для звітів про вразливості: Повідомляйте про проблеми до проекту Cellar на GitLab
  4. Для проблем розгортання: Перегляньте журнали та конфігурацію на наявність неправильних налаштувань

Додаткові ресурси