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

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

К рискам безопасности систем баз данных относятся, например:

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

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

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

• Контроль доступа
• Аудит
• Аутентификация
• Шифрование
• целостности Контроль
• Резервные копии
• Безопасность приложений

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

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

Привилегии

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

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

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

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

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

Принципал с наименьшими привилегиями

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

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

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

Дополнительная информация: безопасность приложений.

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

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

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

Абстракция

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

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

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

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

Собственный аудит

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

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

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

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

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

См. также

• Отрицательная база данных
• Брандмауэр базы данных
• Федеральный стандарт США FIPS 140-2 для аутентификации криптографического модуля.
• Виртуальная частная база данных

Дальнейшее чтение

• «Руководства по технической реализации безопасности» . Кибербиржа Министерства обороны США. 2021. 2021 года Руководство по технической реализации Агентства оборонных информационных систем .