Первое и самое распространенное заблуждение: «SQLite — это просто файл, его безопасность зависит от прав файловой системы». Это лишь часть правды. Да, контроль доступа к файлу `.db` или `.sqlite` на уровне ОС — это базовый рубеж. Файл базы данных должен быть доступен на чтение и запись только пользователю, от которого работает приложение. Однако в современных сложных атаках (например, через уязвимости в самом приложении) злоумышленник может получить доступ в контексте этого пользователя. Поэтому защита должна быть многослойной.
**Шаг 1: Валидация и параметризация входных данных.** Атака SQL-инъекции актуальна и для SQLite. Никогда, ни при каких обстоятельствах не склеивайте SQL-запросы строковой конкатенацией с пользовательским вводом. Используйте подготовленные выражения (prepared statements) и параметризованные запросы. Во всех языковых API SQLite эта возможность присутствует.
Опасный код (Python): `cursor.execute("SELECT * FROM users WHERE login = '" + user_input + "'")`
Безопасный код: `cursor.execute("SELECT * FROM users WHERE login = ?", (user_input,))`
**Шаг 2: Шифрование базы данных на rest.** Файл базы данных на диске должен быть зашифрован. Нативный SQLite не поддерживает шифрование «из коробки». Здесь российскому разработчику важно сделать выбор, соответствующий требованиям регуляторов. Использование сторонних криптопровайдеров (например, SQLCipher) — популярный путь. SQLCipher — это открытое расширение SQLite с прозрачным шифрованием AES-256 всего файла базы. Важно: ключ шифрования не должен храниться в коде приложения или в конфигурационном файле в открытом виде. Рассмотрите использование аппаратных ключей (например, Рутокен), защищенных хранилищ ОС (Android Keystore, iOS Keychain, TPM-модули на серверах) или, как минимум, вынесение ключа во внешние переменные окружения.
**Шаг 3: Защита данных в памяти (in-memory).** SQLite может работать с базами в оперативной памяти (используя специальное имя `:memory:`). Данные в памяти уязвимы для дампа процесса. Если вы работаете с конфиденциальными данными, минимизируйте время их жизни в незашифрованном виде в памяти, своевременно затирайте (zeroize) буферы и, по возможности, избегайте постоянных in-memory баз в production.
**Шаг 4: Контроль целостности и журналирование.** Включите режим WAL (Write-Ahead Logging) для повышения надежности и отказоустойчивости. Регулярно используйте команду `PRAGMA integrity_check;` для проверки целостности базы данных. Ведите журнал (аудит) критичных операций с базой (попытки доступа, изменения схемы) не в самой SQLite, а во внешней системе логирования приложения. Это поможет при расследовании инцидентов.
**Шаг 5: Минимизация прав и «укрепление» SQLite.** Создавайте для приложения пользователя БД с минимально необходимыми привилегиями. Если ваше приложение только читает данные, откройте файл базы в режиме «только для чтения». Отключайте неиспользуемые возможности SQLite на этапе компиляции или с помощью PRAGMA-директив. Например, рассмотрите отключение загрузки расширений (`PRAGMA compile_options;`, `SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION`), если они не нужны.
**Шаг 6: Юридические аспекты и российское ПО.** Если ваше приложение обрабатывает персональные данные (ПДн) граждан РФ, вы обязаны соблюдать 152-ФЗ. Использование иностранных криптографических библиотек (вроде SQLCipher) может вызывать вопросы с точки зрения требований ФСБ России о использовании сертифицированных средств криптографической защиты информации (СКЗИ). Для критически важных систем (госсектор, Финтех) необходимо рассмотреть альтернативы:
- Использование отечественных СУБД (например, Postgres Pro с соответствующими модулями) вместо SQLite.
- Интеграция SQLite с российскими сертифицированными СКЗИ для шифрования файла базы или дискового тома.
- Хранение только неконфиденциальных данных в SQLite, а ПДн — в защищенном централизованном хранилище с соответствующими сертификатами.
Безопасность SQLite — это не единовременная настройка, а комплекс мер, встроенных в жизненный цикл разработки. Проводите регулярные аудиты кода на предмет уязвимостей, тестируйте на проникновение (pentest) конечное приложение и помните, что даже самая защищенная база данных бесполезна, если пароль к ней написан на стикере на мониторе. В российских реалиях к техническим мерам всегда добавляется слой нормативных требований, учет которых с самого начала проектирования сэкономит время, деньги и репутацию.
Комментарии (14)