Схема защиты
Объекты, угрозы, выбранный уровень шифрования и ограничения.
Шифрование пользовательских данных
Определяем, какие данные нуждаются в дополнительной защите при хранении, и внедряем согласованную схему вместе с управлением ключами и доступами.
Опишите, какие сведения хранит сайт и кто должен ими пользоваться. Согласуем модель защиты до выбора механизма шифрования.
Узнаёте свою ситуацию?
- В базе или файловых выгрузках хранятся чувствительные пользовательские сведения.
- Нужно защитить резервные копии и пересмотреть доступ к ключам.
- Текущая схема шифрования не имеет понятного восстановления и замены ключей.
Как поможем
Шифрование пользовательских данных — преобразование выбранной информации в защищённый вид с контролируемым доступом к ключам. Начинаем с модели угроз и движения данных: шифрование диска, базы и отдельных полей защищает от разных сценариев.
Что входит в работу
Что и от какого сценария нужно защищать
Составляем перечень полей, файлов, резервов, выгрузок и журналов, содержащих нужные сведения. Уточняем, кто должен читать их в рабочем процессе и что произойдёт при утрате отдельного носителя или копии базы. Также проверяем, не хранит ли приложение лишние данные, без которых процесс может обойтись.
Различаем хранение и передачу: TLS для сайта защищает соединение, но не определяет доступ к выгруженной базе. Пароли не проектируем как обратимо зашифрованные поля; рекомендации OWASP по хранению данных отдельно различают шифрование и безопасное хеширование паролей.
Как устроить доступ к ключам
Выбираем поддерживаемые механизмы платформы и библиотеки под задачу, без собственных криптографических алгоритмов. Определяем, где создаются и хранятся ключи, какое приложение может их использовать и кто имеет административные полномочия. Ключ рядом с общей выгрузкой зашифрованных данных способен свести пользу защиты к минимуму.
Продумываем замену ключа, доступ к старым данным и восстановление после потери окружения. Проверяем, что секреты не попадают в исходный код, отладочные страницы и материалы передачи. Управление жизненным циклом ключей рассматриваем как часть решения, а не как необязательную настройку после запуска.
Как внедряем схему в работающую систему
Проверяем влияние на поиск, сортировку, выгрузки и интеграции: зашифрованное поле может потребовать изменения привычной обработки. Согласуем миграцию существующих записей и способ отличать уже обработанные данные. На тестовой выборке проверяем чтение разрешённой ролью и отказ там, где доступа быть не должно.
Отдельно испытываем восстановление резервной копии вместе с необходимыми ключами в контролируемой среде. Передаём схему и инструкции без публикации секретов. В общей защите сайта сохраняем контроль прав и обновлений: шифрование не отменяет риск компрометации работающего приложения.
Начнём с карты чувствительных данных
Опишите, какие сведения хранит сайт и кто должен ими пользоваться. Согласуем модель защиты до выбора механизма шифрования.
Что вы получите
Реализация
Согласованные изменения хранения, обработки и управления доступом.
Инструкция эксплуатации
Порядок замены ключей, восстановления и проверки разрешённых операций.
Как проходит работа
-
Картируем данные
Определяем места хранения, роли и ожидаемую защиту.
-
Проектируем и проверяем
Выбираем механизм и испытываем его на тестовой выборке.
-
Внедряем и передаём
Переносим согласованные данные и проверяем рабочие процессы и возврат из резерва.
Как проверить результат
Покрытие
Понятно, какие данные защищены, а какие остаются вне выбранного механизма.
Ключи
Правила хранения и использования отделены от обычной выгрузки данных.
Восстановление
Резерв и необходимые ключи позволяют восстановить разрешённый доступ по инструкции.
Связанные услуги
Вопросы об услуге
Можно зашифровать всю базу и не менять приложение?
Некоторые уровни шифрования прозрачны для приложения, но защищают только определённые сценарии. Шифрование отдельных полей может потребовать изменения поиска и обработки. Выбираем уровень по модели угроз и проверяем его влияние на рабочие операции.
Что случится при потере ключа?
Без подходящего ключа восстановить зашифрованные сведения может оказаться невозможно. Поэтому заранее проектируем управление ключами, ограниченный резерв и контрольное восстановление. Сам архив базы не является достаточным планом возврата.
HTTPS уже шифрует данные. Зачем дополнительная работа?
HTTPS защищает передачу между участниками соединения. После получения сведения могут попасть в базу, журнал или файл в открытом виде. Дополнительная защита хранения нужна, когда этого требует модель угроз и рабочие ограничения проекта.
Обсудим задачу вашего проекта
Расскажите о сайте и о том, что хотите изменить. Уточним объём работ, обсудим сроки и подготовим предложение.
- Пришлите ссылку на сайт и опишите задачу
- На обсуждении уточним цели и ограничения
- После — предложение с составом работ и условиями
С чего начнём?
Опишите вашу ситуацию. Если сайт или CRM уже есть — добавьте ссылку и то, что хотите изменить.
На следующем шаге нужен только телефон. Остальное — по желанию.
Или напишите: info@iskariot.ru