🤔 InfoSec Reco СУБД

Салют,

Думаю сегодня классно будет посмотреть, вместе, на то как лучше подойти к защищенности БД, брокеру очередей для записи в БД и, конечно, частично к frontend части при взаимодействии с БД.

Мои реко строятся на базе опыта и того, что я чаще всего замечаю, надеюсь, для твоей практики, это будет полезно и ты сможешь более глубоко и сразу смотреть в правильном направлении, - потому что это важно при анализе и не важно аналитики ты или инженер, главное понимать архитектуру и как это построено. В некоторых пунктах отмечу, что плохо и думаю ты поймешь почему.

Реляционные СУБД

• Плохая практика: выдавать приложению db_owner, sysadmin или доступ на всю схему без ограничений

• Чувствительные данные хранить так, чтобы прямой доступ к базовым таблицам был ограничен: использовать views, stored procedures или сервисный слой

• Размещать СУБД в отдельном сетевом сегменте и запрещать прямой доступ из внешних и полупубличных зон

• Плохая практика: использовать plaintext-подключения или отключать проверку сертификата

• Включать аудит критичных операций: чтение, изменение, удаление, DDL-изменения и административные действия

• Строки подключения, ключи и пароли хранить только во внешнем хранилище секретов.

• Использовать отдельные учётные записи для каждого приложения и среды, без shared-паролей между командами

• Никогда не передавать пользовательский JSON напрямую в фильтры запросов без проверки и нормализации

• Использовать типизированные запросы, драйверные API или строго ограниченные схемы фильтрации

• При работе с произвольными документами проверять, что в них нет операторов, начинающихся с $, и других опасных конструкций

• Плохая практика: пропускать $where, $gt, $regex и похожие операторы без whitelist

Redis и in-memory cache

• Привязывать сервис только к внутренним интерфейсам и не публиковать его в публичную сеть

• Плохая практика: слушать 0.0.0.0 и оставлять Redis доступным извне

• Обязать аутентификацию и использовать длинные случайные пароли или эквивалентный механизм авторизации

• Плохая практика: оставлять доступными FLUSHALL, CONFIG, EVAL, SCRIPT, DEBUG

• Плохая практика: выдавать приложению полный ACL или использовать один пользователь для всех ролей.

• Использовать namespace-префиксы для ключей, чтобы изолировать кэши, сессии и служебные данные

• Не хранить в Redis долгоживущие секреты или критичные данные без дополнительной защиты

Очереди и брокеры сообщений

• Плохая практика: оставлять guest или аналогичные заводские учётки

• Создавать отдельных пользователей для producer, consumer и административных задач

• Изолировать окружения через отдельные virtual host/ namespace/ tenant-механизмы, если они поддерживаются

• Плохая практика: смешивать dev, test и prod в одном пространстве имён

• Producer должен иметь право только на публикацию в разрешённые exchange или topic

• Consumer должен иметь право только на чтение из разрешённых очередей и не должен публиковать сообщения

• Проверять сертификаты клиентов и сервера, если брокер используется в чувствительном контуре

• Ограничивать размер сообщений и задавать квоты, чтобы снизить риск flooding и abuse

JavaScript и frontend

• Не использовать опасные DOM-операции с пользовательским вводом: innerHTML, outerHTML, document.write

• Любой HTML, пришедший извне, санитайзить перед отображением

• Запрещать небезопасные redirect-механизмы на основе пользовательского ввода без whitelist

• Применять CSP с минимально необходимыми источниками и без unsafe-inline, где это возможно

• Для inline-скриптов использовать nonce или hash-подход

• Для внешних библиотек и CDN использовать Subresource Integrity

• Плохая практика: грузить библиотеку с CDN без проверки целостности

#reco #devsecops #appsec #specialty