Объемы корпоративных данных продолжают расти, и, как следствие, увеличивается количество информационных систем, обеспечивающих их обработку и хранение. Так, если еще 15 лет назад наличие 20 баз данных считалось значительной нагрузкой, то сегодня 200 баз уже воспринимаются как норма.
Однако важно не только защищать данные на всех этапах их жизненного цикла, но и обеспечивать безопасную конфигурацию СУБД – среды, в которой эти данные хранятся и обрабатываются. СУБД нередко становятся мишенью для киберпреступников. При этом для успешной атаки хакеру совсем не нужно быть гением: как правило, достаточно базовых инструментов из открытых источников. Современные сканеры уязвимостей находят критические слабости – открытые порты, стандартные учетные записи, слабые алгоритмы шифрования – за считанные минуты.
Если вы работали с корпоративными СУБД, то наверняка встречали такие артефакты:
роль
admin_temp_2020, которую никто не трогал уже пять лет;тестовую базу, у которой «временно» открыт доступ в прод;
логины
test_user / qwerty123;встроенную учетку postgres, которой работает половина инфраструктуры.
Парадокс в том, что эти ошибки не выглядят как что-то страшное. Они «не горят», их удобно игнорировать, и почти всегда они остаются наследием старых решений. Пока в какой-то момент не становятся точкой входа для атаки, утечки или простоя.
В этой статье разберем семь конфигурационных антипаттернов, которые мы встречаем чаще всего, а также предложим способы, как их исправить.
Использовать системные учетки
Системные учетные записи (СУЗ) – это встроенные, суперпривилегированные логины, созданные самой СУБД. Как правило, они нужны только для решения редких административных задач. Однако на практике СУЗ испо��ьзуют для всего подряд:
запуска серверов приложений;
выполнения ETL-джобов;
разовых вмешательств администраторов в работу систем (когда специалисты заходят «на минутку что-то поправить»).
Это удобно, быстро, но крайне опасно. В случае компрометации даже одной СУЗ злоумышленник может получить полный контроль над системой, обойдя все уровни защиты.
Мы подготовили чек-лист с рекомендациями. В нем постарались наглядно продемонстрировать, почему рискованно использовать системные учетные записей в повседневной эксплуатации, и как правильно настроить доступ без ущерба для безопасности.
Ставить простой пароль
Кажется, что «слабые» пароли давно канули в прошлое. На уровне пользователей – да. Но где-то глубоко в инфраструктуре всегда найдутся такие артефакты, как:
test_user/ 1234,
service_account / qwerty123,
или даже вход без пароля через Trust (да-да, такое тоже встречается).
На одном проекте мы обнаружили у PostgreSQL строку в pg_hba.conf:
host all postgres 0.0.0.0/0 trust.Это означает, что любой хост из сети может подключиться под postgres без пароля. Уязвимость заметили случайно (по алерту на обращение к системному представлению pg_hba).
Такие находки – отнюдь не экзотика, а классика ИБ-аудитов.
Ниже делимся приемами, которые помогут повысить уровень защищенности СУБД.
Пренебрегать безопасностью тестовых данных и контуров
Тестовые данные и контуры являются одним из главных скрытых источников утечек. Безусловно, они удобны для разработки, но с точки зрения безопасности – это идеальное место для ошибок.
Разумеется, гораздо лучше тестировать приложение или новый релиз сразу же в боевых условиях. Однако в погоне за time-to-market специалисты могут забыть почистить тестовые данные и аккаунты. В итоге тестовая СУБД становится точкой входа, открывающей хакерам доступ к персональным данным клиентов, партнеров и сотрудников.
В чек-листе представлены приемы, которые помогут минимизировать риски, связанные с эксплуатацией тестовых сред.
Выдавать избыточные привилегии
Еще один антипаттерн, упрощающий хакерам доступ к корпоративным данным – выдача избыточных привилегий. Это, наверное, самая распространенная уязвимость в настройках СУБД.
Чаще всего избыточные привилегии возникают не из злого умысла, а по вполне понятным причинам. Главная из которых – стремление команды решить задачу здесь и сейчас. Ведь гораздо проще и быстрее выдать пользователю права админа, чем тратить время на анализ, какие именно права ему на самом деле требуются.
В результате привилегии накапливаются, но ни у кого не хватает времени, чтобы нормально провести их ревизию. А если в компании к тому же нет актуальной матрицы доступа, то становит��я почти невозможно разобраться, какие роли еще нужны, а какие давно устарели.
Именно так появляются:
роли, которые никто не аудировал годами;
подрядчики, до сих пор имеющие доступ к схемам;
технические логины с
GRANT ALL PRIVILEGES, оставленные после отладки и благополучно забытые.
Надеяться на встроенный аудит, как на манну небесную
Во всех СУБД есть встроенные механизмы аудита. Но у этих механизмов есть несколько фундаментальных проблем. Далее разберем основные ограничения встроенного аудита:
логи фиксируют запросы, но не результаты (без данных сложно собрать доказательства утечки);
привилегированный пользователь может отключить аудит;
настройки детализации легко понизить;
при тысячах запросов лог превращается в «портянку», в которой сложно найти аномалии;
многие настройки аудирования в PostgreSQL нужно включать вручную (например, last login).
Все эти ограничения делают встроенный аудит недостаточно эффективным инструментом для полноценного контроля за безопасностью баз данных, особенно в условиях растущих угроз. Ниже, делимся приемами, которые позволяют решить эту проблему.
Выставлять неверные сетевые настройки СУБД
Иногда самые опасные уязвимости кроятся не внутри БД, а вокруг нее. Так, компании сами дают хакерам зеле��ый свет, когда:
помещают базу демилитаризованную зону (DMZ, Demilitarized Zone), которая по определению «смотрит» в интернет;
открывают порты
5432/3306;оставляют «временный» SSH-туннель, который никто не закрыл;
используют стандартный порт, который сканируют боты.
Если никто не проверяет сетевые правила, то «временные заплатки» становятся постоянными источниками угроз.
Почему важно контролировать сетевые настройки БД?
Сегодня интернет-сканеры находят открытые порты за минуты. Если сетевые правила настроены плохо, злоумышленник просто выбирает уязвимую точку.
Допускать хаос при управлении правами в больших БД
В крупных компаниях зачастую права раздаются и отзываются вручную. Но людям зачастую трудно долго удержать в голове информацию о том, кто и к чему имеет доступ, особенно если объем данных регулярно растет.
И казалось бы, чем больше корпоративных данных, тем лучше будут их защищать, но на практике возникает примерно такая картина:
люди меняются, а роли остаются;
отсутствует документация, а значит и нет понимания, кто и что может;
никто не знает, какие роли по факту открывают доступ к данным;
при отзыве роли ломается приложение, и все возвращают «как было».
В чем тут риски?
В крупных СУБД некорректное управление правами быстро приводит к следующим неприятным последствиям:
уязвимости «тихо» копятся в СУБД;
транзитивные привилегии позволяют пользователям получать доступ к данным, на которые у них формально нет прав;
запутанная иерархия ролей делает отзыв доступа крайне сложным.
В этих условиях трудно расследовать инциденты безопасности, поскольку сложно проследить, кто и как получил доступ к чувствительной информации.
Заключение
Ошибки, перечисленные в этой статье не уникальны: они регулярно встречаются в банках, IT-компаниях, крупных ритейлерах, госорганизациях. Причем корень проблемы кроется отнюдь не в уровне компетентности сотрудников. Проблема в том, что конфигурация СУБД – это не одноразовая настройка, а живой процесс.
Cреда меняется, появляются новые сервисы, меняются разработчики, мигрируют данные. И если не выстраивать системный подход, база превращается в набор непредсказуемых настроек, где что-то работает «по привычке».
А какие СУБД у вас доминируют – PostgreSQL, MySQL, Oracle, MS SQL, ClickHouse? И главное – кто на самом деле отвечает за их настройку, мониторинг и адаптацию под рост нагрузки: БД-администратор,DevOps или кто-то другой?
Пишите в комментариях – очень интересно собрать народную статистику.
