Анализ безопасности баз данных (Gugln[ Qy[khgvukvmn Qg[ ;guud])

Перейти к навигации Перейти к поиску

«Анализ безопасности баз данных» (англ. Database Security Assessment) – процесс исследования рисков возникновения угроз в базах данных.

Уязвимостью может быть неточность в конфигурации системы, например, отсутствие политики паролей базы данных, ошибка в программной части, например, переполнение буфера в какой-либо процедуре, или ошибка в настройке управления доступом, например, наличие публичных прав доступа к таблице, содержащей конфиденциальную информацию[1]. После определения уязвимости, оценивается ее приоритет – низкий, средний, высокий, критический и т.д.

Наконец, формируется отчет, подводящий итоги исследования. Типичный пример итогов анализа может представлять полное число обнаруженных уязвимостей, распределенных по важности. Такая сводка является по сути слепком рисков, который администратор может использовать для приоритизации шагов, необходимых для совершенствования системы безопасности базы данных. Она указывает, какие базы данных и какие уязвимости следует рассмотреть в первую очередь.

Выявление уязвимостей баз данных

[править | править код]

Фундаментальная часть наилучшей практики анализа безопасности базы данных состоит из следующих четырех частей:

  • Влияние на Производственные системы
  • Точность
  • Эффективность
  • Обширность анализа

Влияние на Производственные системы

[править | править код]

Многие методы анализа пытаются идентифицировать уязвимости, имитируя действия взломщика. Например, в процессе анализа система может эксплуатировать буфер, подверженный переполнению, или использовать метод «грубой силы», чтобы получить необходимые ключи доступа. Такие методы взлома часто используются автоматизированными веб-серверами или сетевыми инструментами анализа, часто это проекты с открытым кодом. Основная проблема такого подхода состоит в том, что в случае успеха, он способен вызвать простой или даже нанести ущерб базе данных. Например, переполнение буфера неизбежно приведет к сбою базы данных[2].

Любой шанс сбоя неприемлем в производственной среде. Это делает такие методы употребимыми только в условиях лабораторного тестирования.[3] С другой стороны, результаты тестов, проведенных в лаборатории слабо применимы к базам данных, используемых в производстве. Найденные, или, что гораздо важнее, пропущенные, уязвимости могут как существовать, так и не существовать в производстве. Следовательно, анализ безопасности баз данных, должен производиться без эксплуатирования уязвимостей.

Точность

[править | править код]

Многие способы исследования уязвимостей не используют доступную информацию достаточно глубоко, чтобы точно определить статус найденной уязвимости. В качестве примера можно рассмотреть переполнение буфера процедуры xp_sprintf в Microsoft SQL сервере. Эта процедура может быть эксплуатирована взломщиком в целях получения администраторских привилегий или обрушения сервера.[4] Можно привести два грубых подхода к исследованию такой уязвимости, которые приведут к неверному выводу.

Эксплуатационный подход

[править | править код]

В таком подходе система анализа, несмотря на риск, попытается послать данные и переполнить буфер процедуры. На основе результата эксплуатации, будет сформирован отсчет, уязвим сервер или нет.[5] Однако, точность такого метода зависит от того, есть ли у пользователя, используемого инструментом анализа, права на выполнение процедуры. У пользователя PUBLIC может не быть таких прав. Следовательно, система не сможет эксплуатировать уязвимость, в отсчет не будет занесена существующая уязвимость. Но у одного из пользователей или у веб-приложения могут быть права на запуск процедуры, в этом случае база данных обладает серьезной уязвимостью, не выявленной анализом.

Подход на основе версий

[править | править код]

Второй подход основывается на проверке версии ПО для оценки наличия уязвимостей. В таком случае, SQL сервера с версиями 6.5 SP4 и раньше обладают упомянутой уязвимостью. Следовательно, любой сервер с версией ниже будет определен уязвимым. Однако, в данном случае игнорируется факт наличия такой процедуры на сервере. Например, процедура могла быть удалена как лучшая практика[6], и тогда такой сервер на самом деле не обладает указанной уязвимостью.

Обширность анализа

[править | править код]

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

  • Известные платформенные уязвимости
  • Системная конфигурация
  • Управление привилегиями
  • Внешние объекты
  • Соответствие нормативным требованиям

Известные уязвимости

[править | править код]

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

Пример исследования безопасности и приоритизации уязвимостей без симулирования атаки
[править | править код]

Существует запись в Bugtrack c ID 2041, которая фиксирует уязвимость Microsoft SQL Server 2000, состоящая в том, что расширенная хранимая процедура xp_printstatements чувствительна к переполнению буфера, что может привести к падению системы или позволить исполнение внешнего кода[7]. Рассмотрим шаги исследования уязвимости без ее эксплуатации.

  • Тест на уязвимость: Проверка версии ПО, (выяснение) попадают ли версия в список подверженных.
    • Если версия выше (т.е. был установлен (патч), выпущенный Microsoft[8]), то уязвимость не представляет угрозы.
    • Если найдено соответствие в версии, необходимо проверить существует ли процедура на сервере. В соответствии с лучшей практикой по безопасности баз данных следует удалять все не используемые расширенные хранимые процедуры.
      • Если процедура был удалена, уязвимость не представляет угрозы.
      • Если процедура существует, уязвимость представляет угрозу безопасности.
  • Приоритизация по угрозе: Для приоритизации уязвимостей по угрозе, необходимо извлечь список пользователей, имеющих привилегии, позволяющих выполнять данную процедуру.
    • Если привилегии предоставлены большому числу пользователей или процедуру может запустить любой пользователь (PUBLIC), то угроза, представляемая уязвимостью, имеет относительно высокий приоритет.
    • Если привилегии предоставлены только системным администраторам, то угроза, представляемая уязвимостью, имеет относительно низкий приоритет.

Системная конфигурация

[править | править код]

Безопасность базы данных крайне чувствительна к проблемам системных настроек, в связи с чем, большинство из них покрыты шаблонами лучшей практики. Элементы конфигурации должны быть оценены по типу и планируемому использованию.[9] Очевидно, что база данных поддерживающая веб-приложения требует иной конфигурации, нежели та, что поддерживает группу внутренних пользователей.

Простым примером является частота смены пароля. Согласно лучшей практике, пользователь должен часто менять пароль, система анализа безопасности должна позволять администратору конфигурировать политику частоты смены пароля и автоматически применять ее к реальному возрасту паролей. После этого она должна представить статистику по аккаунтам с истекшим сроком и приоритизировать угрозу.

Управление привилегиями

[править | править код]

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

Внешние объекты

[править | править код]

Некоторые объекты, которые являются внешними по отношению к базе данных, могут быть использованы (если не настроены должным образом) для атаки на базу данных.[10] Эти внешние объекты в основном являются объектами операционной системы, такие как файлы, службы, разделы реестра и т.д. Например, DB2 включает исполняемый файл db2job, который можно использовать по умолчанию, чтобы позволить локальным пользователям выполнять код с правами администратора. Подверженность этой уязвимости может быть определена путем проверки разрешений операционной системы в файле db2job.[11]

Соответствие нормативным требованиям

[править | править код]

При оценке базы данных следует уделять особое внимание требованиям безопасности, которые относятся к соответствию нормативным требованиям. Например, закон Сарбейнза — Оксли требует отслеживания всех новых учетных записей пользователей в базах данных, в которых хранится информация финансовой отчетности. Поэтому в процессе анализа необходимо проверить словарь данных для учетных записей, дата создания которых находится в пределах настраиваемого периода времени. Любые новые учетные записи могут быть перечислены в итоговых отчетах оценки.

Препятствия анализу

[править | править код]

Несмотря на преимущества полноценного анализа баз данных, многие организации встречаются с трудностями при его организации.

Бюджет

[править | править код]

В большом числе организаций требуется письменное подтверждение необходимости выделения дополнительных средств на IT отдел. Инструменты по анализу защищенности баз данных могут представить отчет, обосновывающий потребность в улучшении систем безопасности и, соответственно, выделении бюджета. Однако, доказать необходимость совершенствования самой анализирующей системы не всегда бывает возможно.[12]

Ресурсы

[править | править код]

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

Экспертиза

[править | править код]

Сотрудники, занимающиеся обеспечением безопасности данных в компании, редко имеют необходимый уровень экспертизы в инфраструктуре баз данных и не охватывают в анализе уязвимостей весь спектр тестов.

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ Michael Gertz, Madhavi Gandhi. Security Re-engineering for Databases: Concepts and Techniques // Handbook of Database Security. — Boston, MA: Springer US. — С. 267–296. — ISBN 978-0-387-48532-4.
  2. ↑ What Is a Buffer Overflow? Learn About Buffer Overrun Vulnerabilities, Exploits & Attacks. Veracode (22 января 2015). Дата обращения: 19 декабря 2019. Архивировано 25 декабря 2019 года.
  3. ↑ Sven Türpe, Jörn Eichler. Testing Production Systems Safely: Common Precautions in Penetration Testing // 2009 Testing: Academic and Industrial Conference - Practice and Research Techniques. — IEEE, 2009. — ISBN 978-1-4244-4977-4, 978-0-7695-3820-4. — doi:10.1109/taicpart.2009.17.
  4. ↑ Microsoft SQL Server extended stored procedure xp_sprintf buffer overflow Vulnerability Report. exchange.xforce.ibmcloud.com. Дата обращения: 19 декабря 2019. Архивировано 20 декабря 2019 года.
  5. ↑ Keshav Malik. A Complete Guide on VAPT - ASTRA (амер. англ.). www.getastra.com (25 октября 2021). Дата обращения: 26 декабря 2021. Архивировано 26 декабря 2021 года.
  6. ↑ Harrison, Guy. MySQL stored procedure programming : [covers MySQL 5 ; building high-performance web applications with PHP, Perl, Python, Java & .NET]. — O'Reilly, 2006. — ISBN 0-596-10089-2, 978-0-596-10089-6, 2006285205.
  7. ↑ Microsoft SQL Server / Data Engine xp_printstatements Buffer Overflow Vulnerability. www.securityfocus.com. Дата обращения: 19 декабря 2019. Архивировано 1 марта 2020 года.
  8. ↑ Microsoft SQL Server / Data Engine xp_printstatements Buffer Overflow Vulnerability. www.securityfocus.com. Дата обращения: 19 декабря 2019. Архивировано 20 декабря 2019 года.
  9. ↑ Adrian Lane. [http://docs.media.bitpipe.com/io_10x/io_103497/item_511521/McAfee_sSecurity_IO%23103497_E-Guide_101012.pdf Best Practices for Database Security].
  10. ↑ Mr. Saurabh Kulkarni, Dr. Siddhaling Urolagin. Review of Attacks on Databases and Database Security Techniques (англ.) // International Journal of Emerging Technology and Advanced Engineering. — 2012. — ISSN 2250-2459. Архивировано 7 марта 2019 года.
  11. ↑ Juan Manuel Pascual Escribá. IBM DB2 db2job - File Overwrite (англ.). Exploit Database (5 августа 2003). Дата обращения: 19 декабря 2019. Архивировано 20 декабря 2019 года.
  12. ↑ Budgeting for information technology (англ.). www.bakertilly.com. Дата обращения: 19 декабря 2019. Архивировано 20 декабря 2019 года.
Источник — https://ru.wikipedia.org/wiki/Анализ_безопасности_баз_данных