Database security

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

Угрозы безопасности[править | править код]

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

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

Привилегии[править | править код]

В среде базы данных важны два типа привилегий:

  1. Cистемные привилегии.
  2. Привилегии объектов.

Привилегии системы[править | править код]

Системные привилегии позволяют пользователю выполнять административные действия в базе данных. К ним относятся привилегии (как указано в SQL Server), такие как: создание базы данных, создание процедуры, создание представления, резервная база данных, создание таблицы, создание триггера и выполнение.[2]

Привилегии объекта[править | править код]

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

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

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

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

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

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

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

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

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

Абстракция[править | править код]

Механизмы уровня приложений authentication и authorization могут быть эффективными средствами обеспечения абстракции от уровня базы данных. Основным преимуществом абстракции является способность single sign-on к нескольким базам данных и платформам. Единая система регистрации сохраняет учетные данные пользователя базы данных и идентифицируется в базе данных от имени пользователя.

Мониторинг активности базы данных (DAM)[править | править код]

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

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

Родительский аудит[править | править код]

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

Повышение безопасности базы данных[править | править код]

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

  1. Запустите сервер баз данных на компьютере, на котором установлена система Windows Server 2003. По умолчанию эта операционная система более безопасна, чем система Windows 2000 Server. Несмотря на то, что компьютер сервера Windows 2000 Server можно заблокировать, этот процесс может быть связан с затратами времени, кроме того, существует вероятность возникновения ошибок, которыми могут воспользоваться злоумышленники для получения доступа к базе данных.
  2. Ограничьте физический доступ к серверу базы данных.
  3. Обеспечьте, чтобы разрешения базы данных и списки разграничительного контроля доступа, имеющиеся в файлах базы данных, разрешали доступ только уполномоченному персоналу. Надежными являются разрешения по умолчанию и списки DACL, настроенные службой управления правами. Следует соблюдать осторожность при изменении любых параметров по умолчанию.
  4. Не запускайте лишние службы на сервере базы данных, например службы IIS, службу очередей сообщений или службы терминалов.
  5. Кроме баз данных службы управления правами, не следует запускать на сервере баз данных никакие другие базы данных.

Примечания[править | править код]

  1. ↑ Guardian newspaper article on a security breach, in which Anderson’s Rule is formulated. Дата обращения: 11 июня 2017. Архивировано 12 сентября 2017 года.
  2. ↑ 1 2 Stephens, Ryan. Sams teach yourself SQL in 24 hours (неопр.). — Indianapolis, Ind: Sams, 2011. — ISBN 9780672335419.
  3. ↑ Database Security Best Practices. technet.microsoft.com. Дата обращения: 2 сентября 2016. Архивировано 12 сентября 2017 года.
Источник — https://ru.wikipedia.org/w/index.php?title=Database_security&oldid=126885985