Екатерина Гайнуллина, Security Vision

Базы данных превращаются в «открытую книгу», когда конфиденциальная информация из них становится доступна злоумышленникам или широкой публике из-за утечек. К сожалению, 2024-2025 годы принесли множество таких утечек – в самых разных отраслях. Согласно данным Роскомнадзора, только в России за 2024 год было зафиксировано 135 утечек баз данных, затронувших более 710 млн записей о россиянах. Лидерами по количеству утечек стали торговый сектор и государственные организации. В мире тенденция схожая: глобально число утечек и скомпрометированных записей бьёт рекорды. В этой статье будут разобраны недавние громкие кейсы утечек по секторам (энергетика, госсектор, e-commerce и др.), проанализируем технические причины: от открытых портов NoSQL и слитых резервных копий до уязвимых CI/CD-пайплайнов, а также практические рекомендации, как не допустить, чтобы ваша база данных стала общедоступной библиотекой. Мы в Security Vision также рассматриваем эти задачи как ключевые в разработке решений нового поколения, в том числе в области автоматизации защиты баз данных и безопасной разработки.

Утечки 2024-2025: панорама по отраслям

Почти нет отрасли, которая бы избежала утечек данных в последние два года. Ниже рассмотрим некоторые показательные случаи из разных секторов, их причины и последствия.

Энергетический сектор (ТЭК)

Компании топливно-энергетического комплекса также пережили немало утечек и киберинцидентов. Отрасль считается критической инфраструктурой, и атаки на неё могут иметь далеко идущие последствия. Согласно отчёту Cybernews, более 50% крупнейших нефтегазовых компаний мира пережили хотя бы одну утечку данных за 30-дневный период (на май 2025 г.). Это ошеломляющая статистика, отражающая широкие пробелы в кибербезопасности энергетических компаний: 69% из них получили низшие оценки (D или F) по уровню защиты. Часто виной становятся банальные вещи: неприменённые патчи, уязвимые веб-службы, утечки учётных данных сотрудников. В том же отчёте отмечено, что учетные данные (логины/пароли) оказались украдены у 80% компаний отрасли, а скомпрометированные пароли администраторов нередко ведут к прямому доступу в критичные системы, включая SCADA и базы данных.

Одним из громких эпизодов стал несанкционированный доступ в компанию Halliburton – крупного поставщика сервисов для нефтедобычи. В августе 2024 Halliburton обнаружила неавторизованный доступ к своим системам, после чего отключила часть сетей и сообщила регуляторам о факте взлома. Несмотря на скудность официальной информации о природе атаки, известно, что компания понесла убытки порядка $35 млн вследствие простоя и реакции на инцидент (по оценкам из СМИ). Вероятно, атакующие проникли через уязвимость во внутренней сети либо через скомпрометированный доступ в энергетике всё чаще фиксируются подобные целевые атаки. Например, годом ранее, в марте 2023, Hitachi Energy подтвердила утечку данных в результате атаки вымогателей Clop, которые эксплуатировали 0-day в ПО для обмена файлами GoAnywhere. То есть несанкционированный доступ к данным энергетических компаний часто достигается через уязвимые сторонние сервисы: файловые хранилища, VPN-концентраторы или почтовые шлюзы, после чего атакующие уже копируют базы данных с конфиденциальной информацией.

Особенно опасны для ТЭК утечки, связанные с операционными технологиями. Представим, что в открытый доступ попадает база, содержащая параметры работы оборудования, схемы сетей или логи SCADA-систем. Это буквально инструкция для злоумышленников, как вывести из строя критичные объекты. Пока крупнейших катастрофических утечек в энергетике, к счастью, не произошло, но тренд настораживает: атаки с вымогательствами данных на отрасль идут волнами. В 2024 пострадали также электросети Румынии (Electrica) группа компаний заявила о шифровании части данных в результате атаки типа ransomware в декабре 2024, а также нефтепереработчик Suncor (Канада), где атака летом 2023 привела к утечке корпоративных секретов и остановкам систем. Вывод напрашивается сам собой, что данные в энергетике требуют не меньшей защиты, чем сами промышленные объекты.

Государственные данные и подрядчики госсектора

Государственные организации оперируют громадными массивами данных граждан – поэтому их утечки наиболее резонансны. В 2024-2025 гг. продолжилась печальная серия компрометации данных госсектора по всему миру. Часто мишенью становятся IT-подрядчики и сервис-провайдеры для государства, через них злоумышленники получают доступ к базам ведомств.

Так, в середине 2023 произошёл масштабный взлом сервиса передачи файлов MOVEit, которым пользовались сотни организаций, включая госструктуры. Под удар попали, например, Министерство энергетики США и контракторы минздрава. Одной из жертв стала американская компания Maximus, обрабатывающая данные по медицинскому страхованию для правительства. Хак-группа Clop, эксплуатируя уязвимость MOVEit, похитила у Maximus личную информацию 8–11 млн человек (граждане США, чьи данные обрабатывались в рамках социальных программ). Утечка включала ФИО, контактные данные, номера социального страхования, сведения о здоровье – фактически целый реестр клиентов госуслуг оказался в руках вымогателей. Этот случай подчёркивает проблему цепочки поставщиков (supply chain): даже если сами правительственные базы защищены, слабое звено в виде стороннего ПО или подрядчика приводит к компрометации данных.

Другой пример – утечка 237 тысяч записей сотрудников федерального правительства США из систем Министерства транспорта (DOT). Об этом объявили в июле 2023: выяснилось, что данные сотрудников, участвующих в компенсационной программе проезда (транзитные льготы), стали доступны злоумышленникам. В данном случае, вероятно, взломали внутреннее приложение DOT, связанное с администрированием льгот, и извлекли из базы реестры с именами, должностями и частично финансовой информацией чиновников. Подобная утечка может использоваться для целевых фишинговых атак на госслужащих, шантажа и т.п.

E-commerce и онлайн-сервисы

Электронная коммерция и онлайн-сервисы обладают огромными базами пользовательских данных – и нередко именно они становятся «открытой книгой» после утечек. Злоумышленники охотятся за учетными записями, историей заказов, платежной информацией покупателей интернет-магазинов, сервисов доставки, бронирования и т.д.

В мае 2024 года прогремела утечка данных Ticketmaster – глобального билетного оператора (Live Nation). Хакеры проникли в системы Ticketmaster и вывели ошеломляющий объём данных – 560 миллионов записей заказов и персональных данных клиентов. В даркнете появились предложения о продаже этой базы. Утекшая информация включала имена, адреса, email, историю заказов и частично платёжные реквизиты пользователей Ticketmaster. Технические подробности взлома не раскрывались, но известно, что злоумышленники имели длительный доступ к внутренней сети. Вероятно, они воспользовались уязвимостью в веб-приложении или API, либо же скомпрометировали учётные данные администратора. Этот инцидент – один из крупнейших по числу затронутых людей в 2024 году, и он демонстрирует, что компании e-commerce должны защищаться не только от DDoS и кардеров, но и от целевых атак на их базы. Последствия для Ticketmaster включали проверки регуляторов, судебные иски и необходимость уведомить миллионы пользователей по всему миру.

E-commerce платформы также часто становятся жертвами банальных ошибок конфигурации. Например, исследователи в 2024 году обнаружили множество открытых баз, используемых веб- и мобильными приложениями (в т.ч. торговыми площадками). Свыше 900 сайтов неверно настроили свои облачные базы, в результате чего общедоступными оказались данные 125 млн пользователей, включая имена, телефоны, адреса электронной почты, пароли в открытом виде, переписки и даже банковские реквизиты. Среди пострадавших онлайн-сервисы из разных сфер (обучающие платформы, CRM-системы, рестораны с онлайн-заказами и др.). Это не результат хакерской атаки как таковой – просто базы данных оказались открыты из-за отсутствия правил доступа. Фактически любой желающий мог прочитать (а в ряде случаев и изменить) эти данные, просто послав запрос к Firebase. Примечательно, что некоторые компании даже не отреагировали на уведомления исследователей об уязвимости. Такой масштабный инцидент показывает, насколько человеческий фактор и ошибки конфигурации могут обнулить все усилия по безопасности.

Как данные становятся «открытой книгой»: пути утечек

Как видно из вышеописанных кейсов, далеко не всегда злоумышленник напрямую «взламывает» вашу СУБД, подбирая пароль к PostgreSQL или эксплуатируя уязвимость MongoDB. Чаще утечке предшествует цепочка событий, которая и превращает закрытые данные в общедоступные. Рассмотрим основные векторы, через которые конфиденциальные данные из баз «просачиваются» наружу – зачастую неожиданным путём.

Открытые порты, пароли по умолчанию и уязвимые настройки

Прямая экспозиция базы данных в интернет без должной защиты – до сих пор один из самых частых факторов компрометации. Сюда относится тривиальное: «DB-сервер доступен по публичному IP и использует слабый пароль или вообще не требует аутентификации». В 2024 году всё ещё находятся тысячи таких случаев:

• Поиск Shodan’ом регулярно выявляет открытые MongoDB и Elasticsearch без пароля. Автоматизированные боты мгновенно находят такие узлы, копируют данные и нередко оставляют записку с выкупом. Например, известна кампания ransomware против администраторов MongoDB, в ходе которой злоумышленники стерли содержимое ~23 000 баз данных MongoDB и вместо них сохранили письмо с требованием выкупа (~0,015 BTC). Они угрожали опубликовать похищенные данные и заявить на компанию в регуляторы (за нарушение GDPR), если им не заплатят. Такой вид атаки впервые наблюдался ещё в 2017 г., но всплески происходят регулярно — всё потому, что админы продолжают разворачивать NoSQL по принципу «стало и работает», забывая включить аутентификацию и закрыть порт.
  

• Redis — ещё одна любимая цель. Эта память‑ориентированная БД часто используется внутри локальных сетей, но иногда её ошибочно открывают наружу. Без пароля Redis позволяет выполнять ряд команд, и известны техники, как записать SSH‑ключ в файл ~/.ssh/authorized_keys через открытую Redis, получив таким образом доступ к серверу. Были инциденты, когда на серверах жертв появлялись файлы типа backup.sql с требованием выкупа — злоумышленники с помощью Redis скачивали и запускали вредонос, эксфильтровали другие данные.
  
  

• Microsoft SQL Server (MSSQL) тоже подвергается массированным атакам. Исследования показали, что ботнеты активно brute‑force атакуют MSSQL с целью заполучить доступ к серверам с тривиальными паролями. В 2023–2024 появилась кампания вымогателей FreeWorld/Mimic, в рамках которой была обнаружена последовательность действий: бот подбирает пароль администратора на открытом MSSQL, затем использует полученный доступ как плацдарм — запускает через xp_cmdshell загрузку вредоносных DLL, развертывает Cobalt Strike Beacon, крадет другие пароли и в конце шифрует файлы на сервере. Такая атака получила название DB#JAMMER. Примечательно, что основное условие её успеха — открытый порт MSSQL и слабые учётные данные. Аналитики Securonix отмечают: на скомпрометированных серверах почти всегда стояли пароли по умолчанию или очень простые («12345», «password» и так далее). Кроме того, службы были доступны извне, тогда как рекомендация № 1 — не публиковать СУБД напрямую в интернет. В общем, если ваша база SQL торчит на всеобщее обозрение да ещё и под учёткой sa/sa123, ждите беды.
  

Вывод: Не экспонируйте базы данных без необходимости. Если нужен внешний доступ – применяйте файрволлы, списки разрешённых IP, VPN, шифрование соединения и надёжные пароли. Отключайте или ограничивайте опасные функции (например, xp_cmdshell в MSSQL). И постоянно мониторьте, не «светятся» ли ваши порты 3306/5432/27017/6379 и т.д. на просторах интернета.

CI/CD и DevOps как новый периметр: утечки через pipeline

Современная разработка предполагает использование непрерывной интеграции и доставки (CI/CD), систем контроля версий, контейнеризации – всего того, что делает жизнь разработчика удобной. Но ошибка в этих инструментах способна открыть доступ к данным даже более широко, чем уязвимость самой БД.

Вспомним кейс Byte Federal: уязвимость в GitLab привела к компрометации сервера с пользовательскими данными. Похожих случаев множество:

• В январе 2023 произошёл взлом популярного сервиса CI — CircleCI. Атакующие получили доступ к переменным окружения множества проектов (включая ключи доступа к базам и облачным хранилищам). Компании были вынуждены срочно ротировать все секреты. Этот случай — предупреждение: хранить секреты (пароли, ключи API) напрямую в переменных pipeline или в репозитории — опасно. Лучше задействовать службы Secrets Management (Vault, AWS Secrets Manager) или, как минимум, шифровать переменные.
  
  

• Инцидент с Uber 2022 (чуть ранее нашего периода, но показательный): хакер получил административный доступ к внутренним ресурсам Uber, найдя в публичном репозитории PowerShell‑скрипт с паролем от менеджера привилегий. Дальше — дело техники: будучи администратором домена, он выгрузил отчёты из внутренних БД Uber. То есть одна забытая учётка в скрипте на GitHub обернулась утечкой чувствительных данных и полным компрометированием инфраструктуры.
  
  

• Leaked secrets в GitHub — колоссальная проблема. По данным GitHub, за 2024 год их автоматический сканер обнаружил более 39 миллионов секретов, случайно загруженных в публичные репозитории (включая API‑ключи, пароли и другие учётные данные). Каждый такой утёкший секрет — потенциальный ключик к базе данных или хранилищу. Github отмечает, что разработчики зачастую жертвуют безопасностью ради удобства: коммитят конфиги с паролями, потому что «так быстрее», или не успевают убрать секрет из истории коммитов. Решение: строгие pre‑commit хуки и использование fake credentials в коде (а реальные подставлять из переменных окружения на сервере). Также стоит включить функцию Push Protection, которая блокирует пуш коммита, если находит там образец ключа.
  
  Компрометация CI/CD может привести и к другим последствиям. Например, если злонамеренный код попадает в pipeline, он может выполнить pg_dump вашей базы и отправить результат злоумышленникам. Или внедриться в образы контейнеров.

  Пример уязвимого сценария: Представьте Dockerfile, который копирует внутрь контейнера всё содержимое проекта:

FROM python:3.11-slim

WORKDIR /app

COPY . . # копирует все файлы проекта в образ

RUN pip install -r requirements.txt

Если в папке проекта лежит файл .env с DATABASE_URL, паролями и прочим, то такой Dockerfile включит эти секреты в итоговый образ. Если этот образ публикуется в общий реестр (например, Docker Hub), злоумышленники могут его скачать и извлечь конфиденциальную информацию. Правильнее было бы добавить .env в .dockerignore и не копировать его. Но человеческий фактор рулит: по статистике, сотни открытых репозиториев на GitHub содержат Compose-файлы с паролями к БД или ключами к Firebase. Эти утечки «по глупости» – одни из самых распространённых.

Таким образом, DevOps-оборудование и процессы нужно считать частью атакуемой поверхности. Регулярно проводите аудит CI/CD-конфигураций:

• Проверяйте, что логи сборки не содержат чувствительных данных (иначе кто угодно с доступом к CI может их увидеть).

• Используйте отдельные учетные записи/роль с ограниченными правами для деплоя приложений к БД (чтобы даже если pipeline скомпрометирован, злоумышленник не получил полный DBA доступ).

• Изолируйте окружения: staging и test не должны иметь доступ к продакшн‑данным. И наоборот, продакшн БД не должна «знать» о существовании CI.

• Применяйте сканеры IaC (Infrastructure as Code). Они автоматически находят потенциальные misconfigurations. Пример: при помощи Open Policy Agent или специализированных продуктов можно анализировать ваши манифесты Terraform/CloudFormation на предмет правил вроде «S3 бакет не должен быть публичным», «Ресурс типа DBInstance не должен иметь публичного IP» и так далее

Резервные копии, бэкапы и staging

Ещё один огромный канал утечек – это резервные копии баз данных. Админы и разработчики часто делают дампы для бэкапа или для переноса на тестовый сервер. Однако если процесс не организован безопасно, такой дамп может «уплыть».

Типичные проблемы:

• Бэкап‑файл оставлен на открытом файловом сервере или в облачном бакете без ограничения доступа. Например, известен случай, когда резюме соискателей и данные сотрудников крупной корпорации утекли, потому что HR‑департамент слил дамп из Oracle и положил его на общий FTP‑сервер «для удобства». Этот FTP кто‑то индексировал, и в итоге файлы появились в поисковой выдаче. Сейчас вместо FTP чаще фигурирует AWS S3: есть масса инцидентов, когда чувствительные документы или SQL‑дампы лежали в S3-бакете с политикой public‑read. Так, исследователи обнаружили открытый бакет Breastcancer.org (благотворительный фонд), где были тысячи записей пациентов онкологического профиля — всё из‑за ошибки в политике доступа.
  

• Копирование боевой базы на тестовый стенд (staging) без обезличивания. Разработчики берут дамп продакшн‑БД, чтобы протестировать на актуальных данных, и разворачивают его на тестовом сервере. Но часто staging окружение плохо защищено: может использовать простой пароль, а то и вовсе стоять открытым, чтобы «клиент посмотрел». В результате, утечка происходит именно с тестового стенда. Пример: в 2023 один из сервисов доставки еды в РФ был взломан через незащищённый тестовый кабинет, оттуда атакующий получил доступ к базе заказов (актуальной, так как её просто копировали раз в неделю из продакшна). Решение — никогда не использовать реальные ПДн на тесте, либо хотя бы хорошо их анонимизировать. Если уж крайне необходимо — защищайте staging так же, как боевую среду (VPN, мониторинг доступа, отдельные учётные записи).

• Хранение резервных копий «за печкой». Если у компании нет централизованной системы бэкапа, разработчики могут хранить копии локально: на ноутбуках, внешних дисках. Потерянный ноут или флешка = компрометация базы. Или еще вариант: дампы складируются на удалённом сервере без должной защиты. Известны случаи, когда компания обращалась за услугами аутсорсера, передавала им SQL‑дамп для анализа, а тот аутсорсер хранил все клиентские файлы в открытой папке на своем сайте — откуда их могли скачать поисковыми ботами. Управление резервными копиями должно быть неотъемлемой частью политики безопасности: шифрование, учёт мест хранения, контроль доступа.

Простой пример неправильной конфигурации S3-бакета для бэкапов:

 {

  "Version": "2012-10-17",

  "Statement": [{

    "Effect": "Allow",

    "Principal": "*",

    "Action": "s3:GetObject",

    "Resource": "arn:aws:s3:::my-app-backups/*"

  }]

}

Эта политика означает, что любой в интернете может скачивать объекты из бакета my-app-backups. Если там лежит prod-db-dump.sql, утечка — вопрос времени. Правильный подход – ограничить Principal конкретными сервисными аккаунтами/ролями, а публичный доступ вообще отключить.

Метаданные и вспомогательные утечки

Иногда данные становятся открытой книгой не напрямую, а через утечки служебной информации. Что это может быть:

• Конфигурации инфраструктуры. Например, файл terraform.tfstate часто содержит в открытом виде параметры, в т.ч. адреса БД, имена и даже пароли, если их не пометить как sensitive. Если кто‑то публикует (или ворует) ваш tfstate, он может узнать много о вашей среде — от имен серверов до хешей паролей администраторов. Аналогично, Kubernetes‑манифесты, docker‑compose.yml и др. могут содержать строки подключения к БД. Поэтому никогда не хардкодьте пароли в конфиги; используйте внешние поставщики секретов или по крайней мере шаблоны с плейсхолдерами.
  

• Облачные метаданные. В знаменитом взломе Capital One (2019) злоумышленница через SSRF получила доступ к AWS Metadata Instance, вытащила временные ключи IAM‑роли, а через них скачала конфиденциальные данные из S3. Это урок: метаданные cloud‑инстансов должны быть изолированы, и лишние права у ролей в облаке — сведены к минимуму. В контексте БД: если, скажем, у EC2-инстанса, на котором крутится база, привязана роль с доступом к резервным копиям — получив тот же SSRF внутрь сети, атакующий может скачать бэкап БД прямо из AWS, даже не ломая саму базу.
  

• Неочевидные каналы. Сюда попадают случаи, когда кусочки конфиденциальных данных утекли через, казалось бы, безобидные вещи: скриншоты интерфейса, выложенные в общий доступ (на скриншоте может быть видна часть базы или ключ API); файлы подкачки или дампы памяти, случайно оставленные на публичных ресурсах; старое оборудование. Курьёзный пример: в 2025 году на Avito продавался старый сервер, и новый владелец обнаружил, что на нём остались незашифрованные файлы баз данных предыдущего хозяина — небольшого провайдера SaaS‑сервиса. Никто не потрудился очистить диск! Поэтому утечка может произойти и «в офлайне», если не следить за процедурой утилизации носителей.

Лучшие практики DevSecOps для предотвращения утечек

Наконец, перейдём к самому важному: как предотвратить превращение вашей базы данных в открытый доступ. Нужно выстроить многоуровневую защиту на всех этапах жизненного цикла данных – от разработки до эксплуатации:

На этапе разработки

• Принудительное использование Git hooks: настройте pre‑commit и pre‑push хуки, которые сканируют код на присутствие секретов, ключевых слов (пароль, PRIVATE KEY, etc.) и больших двоичных файлов. Существуют готовые решения, например git‑secrets или Gitleaks. Цель — блокировать коммит, если разработчик случайно добавил в код пароль БД или дамп.

• Моделирование угроз (Threat Modeling): при проектировании новых функций учитывайте, какие данные затронуты и как они могут утечь. Если фича предполагает создание временного файла с данными — сразу планируйте его шифрование и удаление.

• Минимизировать данные в тестах: разработчикам зачастую нужны данные для тестирования. Внедрите практику использования генерированных или обезличенных данных. Есть инструменты, которые по схеме БД генерируют фейковые ФИО, адреса, номера карт — этого достаточно для функциональных тестов. Настоящие данные не должны гулять по ноутбукам разработчиков.

• Secure coding практики: обучайте команды распознавать опасные конструкции (как та SQL‑инъекция выше). Проведите тренинги по OWASP Top 10. Код‑ревью должно включать вопросы: «А что если сюда вставят кавычку?», «А можно ли прочесть это хранилище извне?» и тому подобное

В CI/CD и средах тестирования

• Secrets Management: используйте централизованные хранилища секретов. Интегрируйте их с CI/CD, чтобы пайплайн получал доступ к паролям и ключам только на время выполнения сборки/деплоя и не хранил их в переменных в чистом виде. Например, HashiCorp Vault или встроенные средства GitHub Actions (encrypted secrets) помогают в этом.

• Разделение прав: сервисные аккаунты, выполняющие деплой, должны иметь минимальный доступ. CI не должен подключаться к боевой БД под суперпользователем. Сделайте отдельного пользователя в БД с ограниченными правами, который может выполнять только необходимые миграции схемы, к примеру, но не читать все таблицы.

• Обфускация логов: настройте в CI‑системе маскирование секретов в логах (большинство поддерживает это: вы можете указать шаблоны, которые нужно скрывать). Тогда даже если кто‑то просмотрит лог сборки, он не увидит содержимое переменных окружения с паролями.
  

• Чистка после тестов: автоматизируйте удаление тестовых данных и бэкапов, которые создаются при прогоне тестов. Ничего не должно «зависать» на агенте сборки или в облачном хранилище после завершения пайплайна.
  

• Пентесты и сканирование staging: регулярно сканируйте тестовые стенды так же, как боевые, на открытые порты, слабые пароли, известные уязвимости. Старайтесь проводить penetration testing хотя бы раз в год, включая попытки достать данные через CI/CD.

При деплое и настройке инфраструктуры

• Принцип минимальных привилегий (PoLP): аккаунт базы данных, который использует приложение, должен иметь ровно столько прав, сколько нужно. Не запускайте веб‑приложение под db_owner или root в БД. Если приложение только читает справочники и пишет пару таблиц — дайте права только на них. Это ограничит масштаб утечки, если приложение скомпрометируют.
  

• Сегментация сети: базы данных должны находиться в закрытых сегментах (VPC), без прямого выхода в интернет. Доступ к ним — только с апп‑серверов или через VPN администраторам. Межсетевые экраны на уровне облака (Security Groups) или контейнеров должны разрешать соединения лишь от определённых хостов. Даже если вы почему‑то вынуждены сделать БД публичной (например, для мобильного приложения), используйте allowlist конкретных IP или хотя бы нестандартный порт + таргетирование по CDN.
  

• Безопасные конфиги: убедитесь, что в конфигах БД отключены опасные функции (например, в MongoDB — выключен открытый доступ по умолчанию и включена авторизация, в Redis — настроен requirepass + bind 127.0.0.1, в MySQL — удалён анонимный пользователь и запрещён remote login для root и так далее). В облачных сервисах (типа AWS RDS) используйте шаблоны параметров с шифрованием данных покоя (Encryption at rest) и включёнными логами аудита.
  

• Terraform и IaC‑политики: если вы используете инфраструктуру как код, внедрите проверки, например, через Open Policy Agent, которые не позволят прокатить изменения, нарушающие правила безопасности. Пример политики: «реляционная БД должна иметь publicly_accessible = false» для AWS RDS. Тогда даже по ошибке никто не откроет базу наружу.
  

• Контейнеры и оркестрация: если база развёрнута в контейнере, не забывайте о безопасности orchestration‑систем. В Kubernetes: конфигурируйте NetworkPolicy, чтобы ограничить, какие поды могут стучаться к поду с базой. В Docker Compose: не выставляйте порт БД на 0.0.0.0 без необходимости, лучше используйте сеть контейнеров.

В эксплуатации (продакшн)

• Мониторинг аномалий: настройте оповещения на подозрительную активность в БД. Например, DLP‑системы могут отслеживать массовую выгрузку данных — если вдруг кто‑то прочитал 100 тыс. записей вне типичного сценария, сработает триггер. Многие СУБД (Oracle, MS SQL) имеют встроенные средства аудита — их стоит включить и регулярно анализировать логи.
  

• Data Discovery и классификация: знайте, какие данные где хранятся и какой чувствительности. Внедрите практику Data Stewardship — назначьте ответственных за наборы данных. Тогда в случае инцидента вы быстро поймёте, что именно утекло и каковы риски. Кроме того, это поможет применять шифрование там, где нужны более строгие меры (например, персональные данные vs. справочная информация).
  

• Регулярные аудиты безопасности: проводите хотя бы раз в квартал сканирование вашей инфраструктуры на известные проблемы. Можно использовать как сторонние услуги (тот же UpGuard, Detectify, Shodan Monitor), так и open‑source утилиты. Цель — найти открытые порты, торчащие панели управления, индексы Elasticsearch и тому подобное до того, как их найдут злоумышленники.
  

• Обновления и патчи: банально, но критично — своевременно обновляйте СУБД и софт. Многие утечки — следствие эксплуатации уязвимостей, для которых уже есть патч. Пример: упомянутая атака на MOVEit, приведшая к утечкам в госсекторе, произошла потому, что эксплуатировалась 0-day уязвимость. Как только был выпущен патч, нужно было установить его в течение часов. Чем меньше «окно уязвимости», тем ниже шанс утечки.
  

• План реагирования: будьте готовы к худшему. Иметь Incident Response план на случай утечки — значит сократить ущерб. Если утечка случилась — важно быстро обнаружить (в этом помогут мониторинги даркнета на упоминание вашей компании, например), изолировать уязвимый сегмент, проинформировать затронутых лиц и улучшить защиту, чтобы не повторилось.

Заключение

Помните, что не бывает мелочей в вопросах утечки информации. Один открытый порт или один закоммиченный пароль способен обнулить миллионные вложения в безопасность. Подходите к защите баз данных так же творчески, как атакующие подходят к их компрометации. Постоянно задавайте себе вопросы: «Что будет, если этот файл увидят чужие глаза?», «Нет ли способа вытащить данные обходным путём?». Если такая паранойя становится частью культуры, шансы, что ваша база данных останется недоступной злоумышленникам, значительно возрастают.

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