Безопасность базы данных

редактировать

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

Риски безопасности для систем баз данных включают, например:

  • Несанкционированные или непреднамеренные действия или неправомерное использование авторизованными пользователями базы данных, администраторами баз данных или сетевыми / системными администраторами, или неавторизованными пользователями или хакерами (например, несанкционированный доступ к конфиденциальные данные, метаданные или функции в базах данных, или несоответствующие изменения программ, структур или конфигураций безопасности баз данных);
  • заражение вредоносным ПО, вызывающее такие инциденты, как несанкционированный доступ, утечка или раскрытие личных или конфиденциальных данных, удаление или повреждение данных или программ, прерывание или отказ в авторизованном доступе к базе данных, атаки на другие системы и непредвиденный сбой служб баз данных;
  • Перегрузки, ограничения производительности и проблемы с мощностью, приводящие к неспособности авторизованных пользователей к использовать базы данных по назначению;
  • Физические повреждения серверов баз данных, вызванные пожарами или наводнениями компьютерных залов, перегревом, молниями, случайными разливами жидкостей, случайный разряд, электронные поломки / отказы оборудования и устаревание;
  • недостатки конструкции и ошибки программирования в базах данных и связанных программах и системах, создающие различные уязвимости безопасности (например, несанкционированное повышение привилегий ), потеря / повреждение данных, снижение производительности и т.д.;
  • повреждение и / или потеря данных, вызванные вводом неверных данных или команд, ошибками в процессах администрирования базы данных или системы, саботаж / преступный ущерб и т. д.

Росс Дж. Андерсон часто говорил, что по своей природе большие базы данных никогда не будут свободны от злоупотреблений посредством нарушений безопасности; если большая система предназначена для легкого доступа, она становится небезопасной; если сделать его водонепроницаемым, его невозможно будет использовать. Это иногда называют правилом Андерсона.

Для баз данных подходят многие уровни и типы контроля информационной безопасности, в том числе:

Базы данных в значительной степени защищены от хакеров с помощью сетевой безопасности таких мер, как брандмауэры и сетевые системы обнаружения вторжений. Хотя меры безопасности сети остаются ценными в этом отношении, защита самих систем баз данных, а также программ / функций и данных в них, возможно, стала более важной, поскольку сети все больше открываются для более широкого доступа, в частности доступа из Интернета. Кроме того, средства управления системой, программой, функциями и доступом к данным, а также соответствующие функции идентификации, аутентификации и управления правами пользователей всегда были важны для ограничения и в некоторых случаях регистрации действий авторизованных пользователей и администраторов. Другими словами, это дополнительные подходы к безопасности базы данных, работающие как извне, так и изнутри.

Многие организации разрабатывают свои собственные «базовые» стандарты безопасности и проекты, подробно описывающие основные меры безопасности для своих систем баз данных. Они могут отражать общие требования или обязательства по информационной безопасности, налагаемые корпоративными политиками информационной безопасности и применимыми законами и нормативными актами (например, в отношении конфиденциальности, финансового управления и систем отчетности), наряду с общепринятыми передовыми методами обеспечения безопасности баз данных (такими как соответствующее усиление защиты базовых систем). и, возможно, рекомендации по безопасности от соответствующих поставщиков систем баз данных и программного обеспечения. Проекты безопасности для конкретных систем баз данных обычно определяют дополнительные функции администрирования и управления безопасностью (такие как администрирование и составление отчетов о правах доступа пользователей, управление и анализ журналов, репликация / синхронизация базы данных и резервное копирование), а также различные управляемые бизнесом средства управления информационной безопасностью в базе данных. программы и функции (например, проверка ввода данных и контрольный журнал ). Кроме того, различные действия, связанные с безопасностью (ручное управление), обычно включаются в процедуры, руководства и т. Д., Относящиеся к проектированию, разработке, настройке, использованию, управлению и обслуживанию баз данных.

Содержание

  • 1 Привилегии
    • 1.1 Системные привилегии
    • 1.2 Привилегии объекта
  • 2 Оценка уязвимостей для управления рисками и соответствия
  • 3 Абстракция
  • 4 Мониторинг активности базы данных (DAM)
  • 5 Внутренний аудит
  • 6 Процесс и процедуры
  • 7 См. Также
  • 8 Ссылки
  • 9 Внешние ссылки

Привилегии

Два типа привилегий важны для обеспечения безопасности базы данных в базе данных среда: системные привилегии и объектные привилегии.

Системные привилегии

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

Привилегии объекта

Привилегии объекта позволяют использовать определенные операции с объектами базы данных с разрешения другого пользователя. Примеры включают: использование, выбор, вставку, обновление и ссылки.

Субъект с наименьшими привилегиями и разделение обязанностей:

Базы данных, подпадающие под внутренний контроль (то есть данные, используемые для публичной отчетности, годовых отчетов, и т. д.) подлежат разделению обязанностей, то есть должно быть разделение задач между разработкой и производством. Каждая задача должна быть подтверждена (через просмотр кода / свежий взгляд) третьим лицом, которое не пишет фактический код. Разработчик базы данных не должен иметь возможность выполнять что-либо в производственной среде без независимой проверки документации / кода для выполняемой работы. Обычно роль разработчика заключается в передаче кода администратору баз данных; однако, учитывая сокращение, вызванное экономическим спадом, DBA может оказаться недоступным. Если администратор базы данных не участвует, важно, как минимум, чтобы партнер провёл проверку кода. Это гарантирует, что роли разработчика четко разделены.

Еще одним моментом внутреннего контроля является соблюдение принципа предоставления наименьшего количества привилегий, особенно на производстве. Чтобы предоставить разработчикам больше доступа для выполнения своей работы, гораздо безопаснее использовать олицетворение для исключений, требующих повышенных привилегий (например, EXECUTE AS или sudo, чтобы сделать это временно). Часто разработчики могут отклонить это как «накладные расходы» на своем пути к славе кодирования. Однако имейте в виду, что администраторы баз данных должны делать все, что считается ответственным, потому что они де-факто являются распорядителями данных в организации и должны соблюдать правила и закон.

Оценка уязвимостей для управления рисками и соблюдения требований

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

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

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

Абстракция

Уровень приложения аутентификация и механизмы авторизации могут быть эффективными средствами обеспечения абстракции от уровня базы данных. Основное преимущество абстракции - возможность единого входа для нескольких баз данных и платформ. Система единого входа хранит учетные данные пользователя базы данных и аутентифицируется в базе данных от имени пользователя.

Мониторинг активности базы данных (DAM)

Другой уровень безопасности более сложного характера включает в себя мониторинг активности базы данных в реальном времени, либо путем анализа трафика протокола (SQL) через сети, или путем наблюдения за активностью локальной базы данных на каждом сервере с помощью программных агентов, или и того, и другого. Для регистрации действий, выполняемых на сервере базы данных, которые обычно включают в себя действия администратора базы данных, требуется использование агентов или встроенного журнала. Агенты позволяют собирать эту информацию способом, который не может быть отключен администратором базы данных, который имеет возможность отключать или изменять собственные журналы аудита.

Анализ может быть выполнен для выявления известных эксплойтов или нарушений политик, или базовые показатели могут быть зафиксированы с течением времени для построения нормального шаблона, используемого для обнаружения аномальной активности, которая может указывать на вторжение. Эти системы могут обеспечивать комплексный контрольный журнал базы данных в дополнение к механизмам обнаружения вторжений, а некоторые системы также могут обеспечивать защиту путем завершения сеансов пользователей и / или помещения в карантин пользователей, демонстрирующих подозрительное поведение. Некоторые системы разработаны для поддержки разделения обязанностей (SOD), что является типичным требованием аудиторов. SOD требует, чтобы администраторы баз данных, которые обычно контролируются как часть DAM, не могли отключать или изменять функциональность DAM. Это требует, чтобы журнал аудита DAM надежно хранился в отдельной системе, не администрируемой группой администрирования базы данных.

Встроенный аудит

Помимо использования внешних инструментов для мониторинга или аудита, для многих платформ баз данных также доступны встроенные возможности аудита базы данных. Собственные контрольные журналы извлекаются на регулярной основе и передаются в назначенную систему безопасности, к которой администраторы баз данных имеют / не должны иметь доступа. Это обеспечивает определенный уровень разделения обязанностей, который может предоставить свидетельство того, что собственные контрольные журналы не были изменены аутентифицированными администраторами, и должны выполняться группой старших администраторов баз данных, ориентированной на безопасность, с правами чтения в производственной среде. Включение собственной версии влияет на производительность сервера. Как правило, собственные контрольные журналы баз данных не обеспечивают достаточных средств контроля для обеспечения разделения обязанностей; следовательно, возможности мониторинга на уровне хоста на уровне сети и / или модуля ядра обеспечивают более высокую степень уверенности для криминалистической экспертизы и сохранения доказательств.

Процесс и процедуры

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

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

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

См. Также

Ссылки

Внешние ссылки

Последняя правка сделана 2021-05-17 14:12:10
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте