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

Database security

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

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

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

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

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

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

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

Привилегии

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

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

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

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

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

Принципал с наименьшими привилегиями и разделением обязанностей:

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

Еще один момент внутреннего контроля - соблюдение принцип предоставления наименьшего количества льгот, особенно в производстве. Чтобы предоставить разработчикам больше доступа для выполнения своей работы, гораздо безопаснее использовать олицетворение для исключений, требующих повышенных привилегий (например, ВЫПОЛНИТЬ КАК или sudo, чтобы сделать это временно). Часто разработчики могут отклонить это как «накладные расходы» на своем пути к славе кодирования. Однако имейте в виду, что администраторы баз данных должны делать все, что считается ответственным, потому что они де-факто данные стюардов организации и должны соблюдать правила и закон.[3]

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

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

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

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

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

Абстракция

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

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

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

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

Нативный аудит

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

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

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

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

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

Смотрите также

Рекомендации

  1. ^ Статья в газете Guardian о нарушении безопасности, в которой сформулировано правило Андерсона.
  2. ^ Стивенс, Райан (2011). Sams научится SQL за 24 часа. Индианаполис, Индиана: Sams. ISBN 9780672335419.
  3. ^ «Лучшие практики безопасности баз данных». technet.microsoft.com. Архивировано из оригинал на 2016-09-15. Получено 2016-09-02.
  4. ^ Сима Кедар (1 января 2009 г.). Системы управления базами данных. Технические публикации. п. 15. ISBN 978-81-8431-584-4.

внешняя ссылка