В финансовой сфере и госогранах требования к защите баз данных предъявляют регуляторы, а безопасность СУБД коммерческих компаний остается на совести владельцев бизнеса. Хотя на первый взгляд вопрос безопасности баз данных кажется достаточно понятным, универсального решения для защиты СУБД нет. Автоматизированные банковские системы АБС, CRM, ERP, системы документооборота, интернет-банкинг, системы дистанционного банковского обслуживания (ДБО) - после первой попытки разобраться в «зоопарке» различных систем в одной компании любой специалист задумывается о специализированном решении для защиты баз данных.
Первая линия безопасности баз данных должна исходить от IT-отдела компании и от администраторов СУБД в частности. Базовая защита БД - это настройка межсетевых экранов перед СУБД, чтобы заблокировать любые попытки доступа от сомнительных источников, настройка и поддержание в актуальном состоянии парольной политики и ролевой модели доступа. Это действенные механизмы, которым должно уделяться внимание. Следующий этап защиты информации в базах данных - аудит действий пользователей, прямая задача отдела информационной безопасности. Значимость аудита объясняется тем, что в промышленной системе сложно тонко настроить права доступа к данным, к тому же бывают и исключительные ситуации.
Например, сотруднику отдела “А” временно понадобился доступ к клиенту отдела “Б”. С большой вероятностью внесение изменений в матрицу доступа к данным не будет иметь обратного характера, что в конечном итоге приводит к наличию учетных записей с сильно расширенными привилегиями, за использованием которых стоит следить.
Для проведения такого мониторинга многие организации пользуются «штатным аудитом» – средствами защиты баз данных, входящими в состав коммерческих СУБД. Штатный режим защиты включает ведение журнала подключения к СУБД и выполнения запросов теми или иными пользователями. Если коротко, принцип работы штатного аудита – это включение и настройка триггеров и создание специфичных функций – процедур, которые будут срабатывать при доступе к чувствительной информации и вносить данные о подобном доступе (кто, когда, какой запрос делал) в специальную таблицу аудита. Этого бывает достаточно для выполнения ряда отраслевых требований регуляторов, но не принесет практически никакой пользы для решения внутренних задач информационной безопасности, таких как расследование инцидентов.
Ключевые недостатки штатного аудита как защиты баз данных:
Более эффективный подход – использование специализированных систем информационной безопасности в области защиты бд – решений классов DAM и DBF.
Такие системы позволяют разбирать трафик взаимодействия пользователей с базами данных, классифицировать SQL-запросы по принадлежности к определенных группам. Вести полный аудит SQL-запросов и ответов на них. Кроме того, решения обладают глубокой системой фильтрации, позволяющей из сотен миллионов запросов выявить потенциальные инциденты и сохранять полный архив действий пользователей, как для удовлетворения требований регуляторов, так и для задач ретроспективного анализа при расследовании инцидентов. Кроме того, специализированные системы DAM позволяют синхронизоваться с защищаемыми базами данных с целью:DAM (Database Activity Monitoring) – это решение независимого мониторинга действий пользователей в СУБД. Под независимостью здесь понимается отсутствие необходимости переконфигурации и донастройки самих СУБД. Системы такого класса могут ставиться пассивно, работая с копией трафика и не оказывая никакого влияния на бизнес-процессы, частью которых являются базы данных.
Преимущество систем такого класса – гибкая система отчетности и интеграции с SIEM-системами большинства вендоров, для более глубокого корреляционного анализа выполняемых запросов.
Учитывая достаточно большие риски при таком способе внедрения, крайне редко компании выбирают активную защиту промышленных СУБД и ограничиваются функциями мониторинга. Происходит это по причине возможности неоптимальной настройки правил блокировки. В этом случае ответственность за ложно заблокированные запросы будет лежать на плечах офицера информационной безопасности. Еще одна причина в том, что в сетевой схеме появляется дополнительный узел отказа, - главный блокирующий фактор при выборе такого способа внедрения решения.DBF (Database Firewall) – это смежное по классу решение, которое также обладает возможностью «проактивной» защиты информации. Достигается это блокировкой нежелательных запросов. Для решения этой задачи уже недостаточно работы с копией трафика, а требуется установка компонентов системы защиты «в разрыв».
На российском рынке представлено решение класса DAM «Гарда БД» от компании "Гарда Технологии". Это программно-аппаратный комплекс, который проводит непрерывный мониторинг всех запросов к базам данных и веб-приложениям в реальном времени и хранит их в течение длительного срока. Система проводит сканирование и выявление уязвимостей СУБД, такие как незаблокированные учётные записи, простые пароли, неустановленные патчи. Реагирование на инциденты происходит мгновенно в виде оповещений на e-mail и в SIEM-систему.
Система защиты баз данных устанавливается пассивно, то есть не влияет на производительность сети компании. Интеллектуальная система хранения позволяет формировать архив запросов и ответов к базам данных за любой период времени для дальнейшего ретроспективного анализа и расследования инцидентов. Это первая система класса DAM, вошедшая в реестр отечественного ПО и установленная в ряде крупных российских банков.
В следующей статье мы более подробно рассмотрим задачи, которые часто стоят перед DAM-системами, расскажем, почему для DAM так важно умение работы с http/http’s трафиком и как обеспечить защиту от SQL инъекций.
Под безопасностью подразумевается, что некоторому пользователю разрешается выполнять некоторые действия.
СУБД должны соблюдать 3 основных аспекта информационной безопасности:
1. Конфиденциальность
2. Целостность
3. Доступность
В этом посте мы поговорим о конфиденциальности
А) Управление безопасностью
В современных СУБД поддерживается как избирательный, так и обязательный подходы к обеспечению безопасности данных.
В случае избирательного управления, некий пользователь обладает различными правами, или привилегиями, и полномочиями при работе с различными объектами. Поскольку разные пользователи могут обладать различными правами доступа к одному и тому же объекту, такие системы очень гибкие.
В случае обязательного управления, каждому объекту присваивается некий квалификационный уровень, ну а каждому пользователю предоставляются права доступа к тому или иному уровню; и соответственно, если у вас есть права доступа на какой-то уровень — все, что на этот уровень записано, ко всему у вас имеется доступ. Считается, что такие системы жесткие, статичные, но они проще в управлении: легко всем объектам дать какой-либо номер (1,2,3,4…) и пользователю потом присвоить доступ кому до 5-го, кому до 6-го, кому до 7-го уровня и т.д. в порядке повышения приоритета.
В обычных СУБД для идентификации и проверки подлинности пользователя применяется либо соответствующий механизм операционной системы, либо то, что имеется в SQL-операторе connect (там есть специальные параметры для доступа при подключении). В момент начала сеанса работы с сервером базы данных пользователь идентифицирует контакт, или логин, своим именем, а средством аутентификации служит пароль.
Идентификатор – это краткое имя, однозначно определяющее пользователя для СУБД. Является основой систем безопасности. Для пользователей создаются соответствующие учетные записи.
Идентификация позволяет субъекту (т.е. пользователю или процессу, действующему от имени пользователя) назвать себя, т.е. сообщить свое имя (логин).
По средствам аутентификации (т.е. проверки подлинности) вторая сторона (операционная система или собственно СУБД) убеждается, что субъект действительно тот, за кого он себя выдает.
Для особо уязвимых систем (например, банковским и т.п.) используются более сложные системы защиты. Так, например, известны системы с последовательным созданием нескольких вопросов личного характера, с ограничением времени на их ответ и количества попыток (как в любом мобильнике).
В стандарте ANSI ISO вместо термина «идентификатор пользователя» (user ID) используется термин «идентификатор прав доступа» (authorization ID).
Система безопасности на сервере может быть организована 3-мя способами:
1. стандартная безопасность: когда на сервер требуется отдельный доступ (т.е. в операционную систему вы входите с одним паролем, а на сервер базы данных с другим);
2. интегрированная безопасность (достаточно часто используют): входите в операционную систему с каким-то пользовательским паролем, и это же имя с этим же паролем зарегистрировано в СУБД. Второй раз входить не надо. Раз попал человек на сервер, ну да ладно, пусть пользуется всем, что есть.
3. смешанная система, которая позволяет входить и первым, и вторым способом.
Б) Управление доступом
Обычно в СУБД применяется произвольное управление доступом: когда владелец объекта (в крайнем случае, администратор базы данных, но чаще владелец) передает права доступа (permissions) кому-нибудь. При этом права могут передаваться отдельным пользователям, группам пользователей, или ролям.
1. Учетная запись создается для отдельных пользователей с логином и паролем. Как правило, это делает администратор базы данных.
2. Группа – именованная совокупность пользователей, чаще всего в группы объединяют на основе какой-либо организации (по отделам, по комнатам, по бригадам и т.п.). Формально говоря, пользователь может входить в разные группы и входить в систему с разной возможностью (должен указать от имени какой группы он входит).
3. Роль – некий, часто служебный, перечень возможностей. Например, бухгалтер, кладовщик и т.п. Приходит человек на работу, ему присваивают такие права доступа, и он с ними может входить. Такой вариант сейчас довольно хорошо используется, т.к. это достаточно удобно оговорить на предприятии. При желании можно пересмотреть эту роль, и она сразу всех потом поменяет. Как правило, считается, что привилегии роли имеют приоритет перед привилегиями групп.
Более высокие требования по безопасности в настоящее время мы рассматривать не будем. Такие многоуровневые системы безопасности были разработаны еще в 70х годах ХХ века. Известные фамилии: Bella, Lapadula.
B) Основные категории пользователей
В общем случае пользователи СУБД могут быть разбиты на 3 основные большие группы:
1. администратор сервера базы данных (и его помощники): ведают установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей, и т.д. Обладает всеми правами базы данных.
2. администратор отдельной базы данных (сервер может обслуживать тысячи баз данных).
3. прочие конечные пользователи: программисты (создают программы для управления теми или иными процессами: бухгалтерскими, кадровыми…), работники фирм и т.д.
Как правило, для администраторов баз данных сделана первоначальная учетная запись, чтоб сделать первоначальный вход в систему. Например, в InterBase: SISDBA с masterkey. В SQL-server: SA и пустой пароль. В Oracle есть 3 изначальных учетных записи: SIS, SYSTEM и MANAGER.
Г) Виды привилегий
Фактически их две:
. привилегии безопасности: выделяются конкретному пользователю, создаются, как правило, команды типа create user. Но создать пользователя в базе данных – это не значит предоставить ему права на все. Просто он может войти в базу данных, но там ничего не увидеть. После создания ему еще надо дать права.
. привилегии доступа или права доступа (permissions): предоставляют созданному пользователю те или иные привилегии. Здесь используются другие 2 команды: Grant – предоставить право на что-то (чтение, добавление, удаление, изменение записи…), Revolce.
Каким образом реализуются или ограничиваются права доступа:
. есть операционные ограничения – право на выполнение тех или иных операторов. Чаше всего это select, insert, delete и update. Во многих СУБД (в том числе Oracle) порядка 25 разных операционных прав можно предоставлять.
. Ограничения по значениям, реализуемые с помощью механизма представлений (View).
. Ограничения на ресурсы, реализуемые за счет привилегий доступа к базам данных.
. Привилегии системного уровня (для Oracle). Когда пользователю разрешается выполнять до 80 различных операторов.
Совокупность всех привилегий, которыми можно обладать называется PUBLIC. Администратор базы данных по умолчанию имеет PUBLIC-права – права на все объекты и действия.
Д) Контрольные исследования
Поскольку абсолютно неуязвимых систем не бывает, или, по крайней мере, в определенном смысле неуязвимых, то при работе с очень важными данными или при выполнении очень серьезных критических операций используют регистрацию каких-то действий (т.е. при выполнении какого-то действия автоматически записывается lok-файл, обычно это текстовый файл, его легко сделать через триггеры). Таким образом, если в этом файле более подробно все написать, то можно следить, кто когда что делал.
Е) Протоколирование и аудит
Под протоколированием понимается сбор и накопление информации о событиях, происходящих в информационной системе. В том числе с помощью lok-файлов.
Под аудитом понимается анализ накопленной информации, проводимый либо оперативно (почти в реальном времени), либо периодически (раз в сутки, раз в неделю…).
Для чего используется протоколирование и аудит?
Тут есть несколько основных целей:
. Обеспечение подотчетности пользователей и администратора. За счет этого можно определить, кто куда обращался, и не появились ли у кого-нибудь непонятные права, не подглядел ли кто-нибудь пароль и т.д.
. Для того, чтоб иметь возможность реконструировать последовательность событий. Какие-то нежелательные изменения – можно вернуть назад.
. Обнаружение попыток нарушения информационной безопасности (взлома).
. Выявление различных проблем в работе информационной системы (например, кому-то мало дали данных для работы, кому-то много)
Если говорить о СУБД Oracle, как о флагмане базостроения, там ведется 3 контрольных журнала:
. Журнал привилегий (происходит отслеживание использования привилегий)
. Журнал операторов (отслеживает, какие операторы используются часто для объектов, потом можно что-то превращать в процедуры, улучшать быстродействие, важный журнал)
. Журнал объектного уровня (контролирует доступ к объектам)
В современных условиях любая деятельность сопряжена с оперированием большими объемами информации, которое производится широким кругом лиц. Защита данных от несанкционированного доступа является одной из приоритетных задач при проектировании любой информационной системы. Следствием возросшего в последнее время значения информации стали высокие требования к конфиденциальности данных. Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом в этой области. Обеспечение информационной безопасности СУБД приобретает решающее значение при выборе конкретного средства обеспечения необходимого уровня безопасности организации в целом.
ля СУБД важны три основных аспекта информационной безопасности - конфиденциальность, целостность и доступность. Темой настоящей статьи является первый из них - средства защиты от несанкционированного доступа к информации. Общая идея защиты базы данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в «Критериях оценки надежных компьютерных систем» .
Политика безопасности определяется администратором данных. Однако решения защиты данных не должны быть ограничены только рамками СУБД. Абсолютная защита данных практически не реализуема, поэтому обычно довольствуются относительной защитой информации - гарантированно защищают ее на тот период времени, пока несанкционированный доступ к ней влечет какие-либо последствия. Разграничение доступа к данным также описывается в базе данных посредством ограничений, и информация об этом хранится в ее системном каталоге. Иногда дополнительная информация может быть запрошена из операционных систем, в окружении которых работают сервер баз данных и клиент, обращающийся к серверу баз данных.
онфиденциальная информация (sensitive information) - информация, которая требует защиты.
Доступ к информации (access to information) - ознакомление с информацией, ее обработка (в частности, копирование), модификация, уничтожение.
Субъект доступа (access subject) - лицо или процесс, действия которого регламентируются правилами разграничения доступа.
Объект доступа (access object) - единица информации автоматизированной системы, доступ к которой регламентируется правилами разграничения доступа. Объектами доступа (контроля) в СУБД является практически все, что содержит конечную информацию: таблицы (базовые или виртуальные), представления, а также более мелкие элементы данных: столбцы и строки таблиц и даже поля строк (значения). Таблицы базы данных и представления имеют владельца или создателя. Их объединяет еще и то, что все они для конечного пользователя представляются как таблицы, то есть как нечто именованное, содержащее информацию в виде множества строк (записей) одинаковой структуры. Строки таблиц разбиты на поля именованными столбцами.
Правила разграничения доступа (security policy) - совокупность правил, регламентирующих права субъектов доступа к объектам доступа.
Санкционированный доступ (authorized access to information) - доступ к информации, который не нарушает правил разграничения доступа.
Несанкционированный доступ (unauthorized access to information) - доступ к информации, который нарушает правила разграничения доступа с использованием штатных средств, предоставляемых средствами вычислительной техники или автоматизированными системами.
Идентификатор доступа (access identifier) - уникальный признак объекта или субъекта доступа.
Идентификация (identification) - присвоение объектам и субъектам доступа идентификатора и (или) сравнение предъявляемого идентификатора с перечнем присвоенных идентификаторов.
Пароль (password) - идентификатор субъекта, который является его секретом.
Аутентификация (authentification) - проверка принадлежности субъекту доступа предъявленного им идентификатора, подтверждение подлинности.
В СУБД на этапе подключения к БД производится идентификация и проверка подлинности пользователей. В дальнейшем пользователь или процесс получает доступ к данным согласно его набору полномочий. В случае разрыва соединения пользователя с базой данных текущая транзакция откатывается, и при восстановлении соединения требуется повторная идентификация пользователя и проверка его полномочий.
Уровень полномочий субъекта доступа (subject privilege) - совокупность прав доступа субъекта доступа (для краткости в дальнейшем мы будем использовать термин «привилегия»).
Нарушитель правил разграничения доступа (security policy violator) - субъект доступа, который осуществляет несанкционированный доступ к информации.
Модель нарушителя правил разграничения доступа (security policy violator model) - абстрактное (формализованное или неформализованное) описание нарушителя правил разграничения доступа.
Целостность информации (information integrity) - способность средства вычислительной техники (в рассматриваемом случае - информационной системы в целом) обеспечить неизменность информации в условиях случайного и (или) преднамеренного искажения (разрушения).
Метка конфиденциальности (sensitivity label) - элемент информации, характеризующий конфиденциальность объекта.
Многоуровневая защита (multilevel secure) - защита, обеспечивающая разграничение доступа субъектов с различными правами доступа к объектам различных уровней конфиденциальности.
ользователей СУБД можно разделить на три группы:
В смысле защиты данных программист может быть как пользователем, имеющим привилегии создания объектов данных и манипулирования ими, так и пользователем, имеющим привилегии только манипулирования данными.
Современных СУБД достаточно развиты средства дискреционной защиты.
Дискреционное управление доступам (discretionary access control) - разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту.
Дискреционная защита является многоуровневой логической защитой.
Логическая защита в СУБД представляет собой набор привилегий или ролей по отношению к защищаемому объекту. К логической защите можно отнести и владение таблицей (представлением). Владелец таблицы может изменять (расширять, отнимать, ограничивать доступ) набор привилегий (логическую защиту) . Данные о логической защите находятся в системных таблицах базы данных и отделены от защищаемых объектов (от таблиц или представлений).
Информация о зарегистрированных пользователях базы данных хранится в ее системном каталоге. Современные СУБД не имеют общего синтаксиса SQL-предложения соединения с базой данных, так как их собственный синтаксис сложился раньше, чем стандарт ISO. Тем не менее часто таким ключевым предложением является CONNECT. Ниже приведен синтаксис данного предложения для Oracle и IBM DB2 соответственно:
CONNECT [ ] пользователь/пароль[@база_данных] CONNECT TO база_данных USER пользователь USING пароль
В данных предложениях отражен необходимый набор атрибутов, а также показано различие синтаксиса. Формат атрибута база_данных, как правило, определяется производителем СУБД, так же как и имя пользователя, имеющего по умолчанию системные привилегии (SYSDBA/SYSOPER в случае Oracle).
Соединение с системой не идентифицированных пользователей и пользователей, подлинность идентификации которых при аутентификации не подтвердилась, исключается. В процессе сеанса работы пользователя (от удачного прохождения идентификации и аутентификации до отсоединения от системы) все его действия непосредственно связываются с результатом идентификации. Отсоединение пользователя может быть как нормальным (операция DISCONNECT), так и насильственным (исходящим от пользователя-администратора, например в случае удаления пользователя или при аварийном обрыве канала связи клиента и сервера). Во втором случае пользователь будет проинформирован об этом, и все его действия аннулируются до последней фиксации изменений, произведенных им в таблицах базы данных. В любом случае на время сеанса работы идентифицированный пользователь будет субъектом доступа для средств защиты информации от несанкционированного доступа (далее - СЗИ НСД) СУБД.
Следуя технологии открытых систем, субъект доступа может обращаться посредством СУБД к базе данных только из программ, поставляемых в дистрибутиве или подготовленных им самим, и только с помощью штатных средств системы.
Все субъекты контроля системы хранятся в таблице полномочий системы и разделены для системы на ряд категорий, например CONNECT, RESOURCE и DBA. Набор таких категорий определяется производителем СУБД. Мы не случайно предлагаем указанный порядок рассмотрения - именно так происходит нарастание возможностей (полномочий) для каждого отдельного вида подключения:
Следует особо отметить, что в некоторых реализациях административные действия также разделены, что обусловливает наличие дополнительных категорий. Так, в Oracle пользователь с именем DBA является администратором сервера баз данных, а не одной-единственной базы данных. В СУБД «Линтер» компании РЕЛЭКС понятие администратора сервера баз данных отсутствует, а наличествует только понятие администратора конкретной базы данных. В IBM DB2 существует ряд категорий администраторов: SYSADM (наивысший уровень; системный администратор, обладающий всеми привилегиями); DBADM (администратор базы данных, обладающий всем набором привилегий в рамках конкретной базы данных). Привилегии управления сервером баз данных имеются у пользователей с именами SYSCTRL (наивысший уровень полномочий управления системой, который применяется только к операциям, влияющим на системные ресурсы; непосредственный доступ к данным запрещен, разрешены операции создания, модификации, удаления базы данных, перевод базы данных или экземпляра (instance) в пассивное состояние (quiesce), создание и удаление табличных пространств), SYSMAINT (второй уровень полномочий управления системой, включающий все операции поддержки работоспособности экземпляра (instance); непосредственный доступ к данным этому пользователю запрещен, разрешены операции изменения конфигурационных файлов базы данных, резервное копирование базы данных и табличных пространств, зеркалирование базы данных). Для каждой административной операции в IBM DB2 определен необходимый набор административных категорий, к которым должен принадлежать пользователь, выполняющий тот или иной запрос администрирования. Так, выполнять операции назначения привилегий пользователям может SYSADM или DBADM, а для того чтобы создать объект данных, пользователь должен обладать привилегией CREATETAB.
Администратор каждой базы занимается созданием круга возможных пользователей создаваемой им БД и разграничением полномочий этих пользователей. Данные о разграничениях располагаются в системном каталоге БД. Очевидно, что данная информация может быть использована для несанкционированного доступа и поэтому подлежит защите. Защита этих данных осуществляется средствами самой СУБД.
СУБД позволяет зарегистрировать пользователя и хранить информацию о его уникальном идентификаторе. Например, подсистема безопасности Oracle позволяет создавать пользователей базы данных посредством предложения:
CREATE USER IDENTIFIED пользователь BY пароль
Подсистема безопасности IBM DB2 может использовать идентификаторы пользователей операционной системы; ее синтаксис SQL не содержит предложения, аналогичного предложению CREATE USER. Microsoft SQL Server может использовать аутентификацию как базы данных, так и операционной системы. Но мы не станем здесь обсуждать достоинства и недостатки выбранных производителями способов аутентификации - все они позволяют строить корректные схемы определения подлинности пользователей. Использование дополнительных средств аутентификации в рамках информационной системы не запрещается.
Набор привилегий можно определить для конкретного зарегистрированного пользователя или для группы пользователей (это могут быть собственно группы пользователей, роли и т.п.). Объектом защиты может являться таблица, представление, хранимая процедура
и т.д. (подробный список объектов защиты имеется в документации к используемой СУБД). Субъектом защиты может быть пользователь, группа пользователей или роль, а также хранимая процедура, если такое предусматривается используемой реализацией. Если из используемой реализации следует, что хранимая процедура имеет «двойной статус» (она и объект защиты, и субъект защиты), то нужно очень внимательно рассмотреть возможные модели нарушителей разграничения прав доступа и предотвратить эти нарушения, построив, по возможности, соответствующую систему защиты.
При использовании хранимых процедур следует обращать особое внимание на то, от имени какого пользователя выполняется данная хранимая процедура в каждом конкретном случае. Так, в Oracle до недавнего времени хранимые процедуры выполнялись от имени владельца хранимой процедуры, а не от имени пользователя, выполнившего ее вызов. Текущая версия Oracle предоставляет возможность указать, под чьим именем будет выполняться вызванная хранимая процедура, пользователь же должен иметь только привилегию EXECUTE для данной процедуры. В «Линтер», например, выполнение хранимых процедур всегда происходит от имени пользователя, вызвавшего процедуру.
Привилегии конкретному пользователю могут быть назначены администратором явно и неявно, например через роль. Роль - это еще один возможный именованный носитель привилегий. С ролью не ассоциируют перечень допустимых пользователей - вместо этого роли защищают паролями, если, конечно, такая возможность поддерживается производителем СУБД. Роли удобно использовать, когда тот или иной набор привилегий необходимо выдать (или отобрать) группе пользователей. С одной стороны, это облегчает администратору управление привилегиями, с другой - вносит определенный порядок в случае необходимости изменить набор привилегий для группы пользователей сразу. Нужно особо отметить, что при выполнении хранимых процедур и интерактивных запросов может существовать зависимость набора привилегий пользователя от того, как они были получены: явно или через роль. Имеют место и реализации, например в Oracle, где в хранимых процедурах используются привилегии, полученные пользователем явно. Если используемая вами реализация обладает подобным свойством, то изменение привилегий у группы пользователей следует реализовать как набор команд или как административную процедуру (в зависимости от предпочтений администратора).
Предложения управления привилегиями:
Если субъект=пользователь, то привилегия назначается ему явно. Если субъект=роль, то для управления привилегиями используются соответственно:
GRANT ROLE имя_роли TO субъект REVOKE ROLE имя_роли FROM субъект
Назначение привилегии всем пользователям системы осуществляется следующим образом:
GRANT привилегия TO PUBLIC
В этом случае каждый новый созданный пользователь автоматически получит такую привилегию. Отмена привилегии осуществляется так:
REVOKE привилегия FROM PUBLIC
Необходимо иметь в виду, что некоторые реализации, например IBM DB2, используют группы пользователей, определенные в операционной системе. Поэтому следует обращать внимание на особенности реализации аналогов ролей в СУБД. Нужно выяснить, содержит ли реализация SQL-предложения вида:
CREATE ROLE имя_роли DROP ROLE имя_роли
При управлении доступом к таблицам и представлениям набор привилегий в реализации СУБД определяется производителем.
Привилегии выборки и модификации данных:
SELECT - привилегия на выборку данных;
INSERT - привилегия на добавление данных;
DELETE - привилегия на удаление данных;
UPDATE - привилегия на обновление данных (можно указать определенные столбцы, разрешенные для обновления).
Привилегии изменения структуры таблиц:
ALTER - изменение физической/логической структуры базовой таблицы (изменение размеров и числа файлов таблицы, введение дополнительного столбца и т.п.);
INDEX - создание/удаление индексов на столбцы базовой таблицы;
ALL - все возможные действия над таблицей.
В реализациях могут присутствовать другие разновидности привилегий, например: CONTROL (IBM DB2) - комплексная привилегия управления структурой таблицы, REFERENCES - привилегия создания внешних ключей, RUNSTAT - выполнение сбора статистической информации по таблице и другие.
Однако дискреционная защита является довольно слабой, так как доступ ограничивается только к именованным объектам, а не собственно к хранящимся данным. В случае реализации информационной системы с использованием реляционной СУБД объектом будет, например, именованное отношение (то есть таблица), а субъектом - зарегистрированный пользователь. В этом случае нельзя в полном объеме ограничить доступ только к части информации, хранящейся в таблице. Частично проблему ограничения доступа к информации решают представления и использование хранимых процедур, которые реализуют тот или иной набор бизнес-действий.
Представление (view) - это сформированная выборка кортежей, хранящихся в таблице (таблицах). К представлению можно обращаться точно так же, как и к таблицам, за исключением операций модификации данных, поскольку некоторые типы представлений являются немодифицируемыми. Часто в реализациях view хранится как текст, описывающий запрос выборки, а не собственно выборка данных; выборка же создается динамически на момент выполнения предложения SQL, использующего view. Но разграничить доступ, например, к двум документам, которые удовлетворяют одному и тому же условию выборки, уже нельзя. Это связано с тем, что даже если ввести отдельный атрибут, который будет хранить информацию о метке конфиденциальности документа, то средствами SQL можно будет получить выборку данных без учета атрибута данной метки. Фактически это означает, что либо сам сервер баз данных должен предоставить более высокий уровень защиты информации, либо придется реализовать данный уровень защиты информации с помощью жесткого ограничения операций, которые пользователь может выполнить посредством SQL. На некотором уровне такое разграничение можно реализовать с помощью хранимых процедур, но не полностью - в том смысле, что само ядро СУБД позволяет разорвать связь «защищаемый объект Ц метка конфиденциальности».
редства мандатной защиты предоставляются специальными (trusted) версиями СУБД.
Мандатное управление доступом (mandatory access control) - это разграничение доступа субъектов к объектам данных, основанное на характеризуемой меткой конфиденциальности информации, которая содержится в объектах, и на официальном разрешении (допуске) субъектов обращаться к информации такого уровня конфиденциальности.
Для чего же нужна мандатная защита? Средства произвольного управления доступом характерны для уровня безопасности C. Как правило, их, в принципе, вполне достаточно для подавляющего большинства коммерческих приложений. Тем не менее они не решают одной весьма важной задачи - задачи слежения за передачей информации. Средства произвольного управления доступом не могут помешать авторизованному пользователю законным образом получить секретную информацию и затем сделать ее доступной для других, неавторизованных, пользователей. Нетрудно понять, почему это так. При произвольном управлении доступом привилегии существуют отдельно от данных (в случае реляционных СУБД - отдельно от строк реляционных таблиц), в результате чего данные оказываются «обезличенными» и ничто не мешает передать их кому угодно даже средствами самой СУБД; для этого нужно лишь получить доступ к таблице или представлению.
Физическая защита СУБД главным образом характеризует данные (их принадлежность, важность, представительность и пр.). Это в основном метки безопасности, описывающие группу принадлежности и уровни конфиденциальности и ценности данных объекта (таблицы, столбца, строки или поля). Метки безопасности (физическая защита) неизменны на всем протяжении существования объекта защиты (они уничтожаются только вместе с ним) и территориально (на диске) располагаются вместе с защищаемыми данными, а не в системном каталоге, как это происходит при логической защите.
СУБД не дает проигнорировать метки конфиденциальности при получении доступа к информации. Такие реализации СУБД, как правило, представляют собой комплекс средств как на машине-сервере, так и на машине-клиенте, при этом возможно использование специальной защищенной версии операционной системы. Кроме разграничения доступа к информации посредством меток конфиденциальности, защищенные СУБД предоставляют средства слежения за доступом субъектов к объектам защиты (аудит).
Использование СУБД с возможностями мандатной защиты позволяет разграничить доступ собственно к данным, хранящимся в информационной системе, от доступа к именованным объектам данных. Единицей защиты в этом случае будет являться, в частности, запись о договоре N, а не таблица или представление, содержащее информацию об этом договоре. Пользователь, который будет пытаться получить доступ к договору, уже никак не сможет обойти метку конфиденциальности. Существуют реализации, позволяющие разграничивать доступ вплоть до конкретного значения конкретного атрибута в конкретной строке конкретной таблицы. Дело не ограничивается одним значением метки конфиденциальности - обычно сама метка представляет собой набор значений, отражающих, например, уровень защищенности устройства, на котором хранится таблица, уровень защищенности самой таблицы, уровень защищенности атрибута и уровень защищенности конкретного кортежа.
За исключением атрибута собственности (логическая защита), разбивающего данные (таблицы) на собственные (принадлежащие данному субъекту) и чужие, физическая защита разбивает данные более тонко. Но можно ли обойтись без физической защиты или, по крайней мере, попытаться, реализовав, например, сложный набор хранимых процедур. В общем-то некоторое подобие такой защиты реализуемо в случае, когда метки добавляются в таблицу в качестве дополнительного атрибута, доступ к таблицам запрещается вообще и ни одно приложение не может выполнить интерактивный SQL-запрос, а только хранимую процедуру и т.п. Ряд реализаций подобного уровня защиты использует вызов набора хранимых процедур с весьма абстрактными (что очень желательно) именами. Система реализации защиты информации в данном случае достаточно сложна и предполагает определенный уровень доверия к администратору безопасности, так как он имеет право изменять структуру базы данных, а значит, и хранимые процедуры, представления. Физически же администратор безопасности в данном случае не изолирован от управления секретными данными.
Кроме того, защищенные СУБД позволяют разграничить доступ к информационной системе с тех или иных рабочих станций для тех или иных зарегистрированных пользователей, определить режимы работы, наложить ограничения по времени работы тех или иных пользователей с тех или иных рабочих станций. В случае реализации данных опций на прикладном уровне задача, как правило, сводится к созданию сервера приложений, который занимается отслеживанием, «кто и откуда пришел». Отдельный комплекс серверных приложений (обычно - хранимых процедур, если в СУБД отсутствует мандатная защита) обеспечивает аудит.
Рассмотрим мандатную защиту подробнее. В качестве примера возьмем мандатную защиту СУБД «Линтер», которая получила признание в весьма специфическом секторе - силовых структурах, как единственная СУБД, имеющая сертификат по второму классу защиты от несанкционированного доступа, что соответствует классу B3 по американскому национальному стандарту.
Во-первых, все перечисленные объекты (независимо от их иерархии в базе данных) разбиваются здесь на группы принадлежности. Объект может принадлежать только одной из групп (это может быть, например, разбиение по отделам организации). Группы принадлежности напрямую связаны с группами субъектов (см. ниже). Субъект вправе видеть только данные своей группы, если между группами субъектов не установлены отношения доверия.
Во-вторых, все объекты выстроены в иерархию по уровням конфиденциальности и по уровням ценности или важности. Уровень конфиденциальности разбивает объекты по доступности на чтение (и даже на просмотр). Пользователь с более низким уровнем доступа не будет знать даже о существовании объектов с более высоким уровнем конфиденциальности. Уровень ценности, напротив, разбивает данные (объекты) по важности, ограничивая возможность их удаления и модификации.
В уже упоминавшихся «Критериях оценки надежных компьютерных систем» применительно к системам уровня безопасности B описан механизм меток безопасности, реализованный в рассматриваемых данной статьей СУБД.
Метка объекта включает следующее:
Метка субъекта выглядит аналогично:
Все пользователи базы данных считаются разбитыми на непересекающиеся группы. Группа описывает область доступных пользователю данных. Для каждой группы существует администратор группы (уровень DBA для группы), созданный администратором системы. При этом пользователи одной группы не видят данных, принадлежащих пользователям другой группы. В этом плане у СУБД «Линтер» имеется особенность: в системе реализовано такое понятие, как «уровень доверия между группами». При этом уровни доверия не могут быть вложенными. Группа представляет собой числовое значение в диапазоне . Группа 0 - группа администратора системы. Только администратор системы может создать пользователя в группе, отличной от своей. Все данные, созданные от имени пользователя, помечаются его группой.
Уровни доступа вводятся для проверки прав на осуществление чтения-записи информации. Вводятся следующие уровни доступа:
Создать пользователя с произвольными уровнями может только администратор системы. Остальные администраторы (DBA) могут создавать пользователей (или изменять уровень пользователям) лишь в пределах отведенных им уровней. Пользователь может принудительно пометить вводимые данные, указав в списке атрибутов уровни доступа для соответствующих записей и полей (при выполнении операторов INSERT или UPDATE). По умолчанию вносимые данные наследуют уровни пользователя, вносящего/изменяющего данные. Защищаемые объекты: пользователи, таблицы, столбцы, записи (вносится при выполнении INSERT), поля записей (изменяются при выполнении UPDATE). Уровни, как и группы, нельзя использовать в случае, если они не созданы специальными запросами.
Конфигурация, к которой имеет доступ хотя бы один программист, не может считаться безопасной. Поэтому обеспечение информационной безопасности баз данных - дело весьма сложное, и во многом вследствие самой природы реляционных СУБД.
Помимо систематического применения арсенала средств, описанных выше, необходимо использовать административные и процедурные меры, в частности регулярное изменение паролей пользователей, предотвращение доступа к физическим носителям информации и т.п.
КомпьютерПресс 3"2002
Атаки на хранилища и БД являются одними из самых опасных для предприятий и организаций. Согласно статистике компании infowatch , в последние годы количество утечек данных в мире неуклонно растет, при этом на 2015 год более тридцати процентов из них приходятся на внешних нарушителей и более шестидесяти выполнено с участием сотрудников организации. Даже если предположить, что в ряде случаев утечка включала данные, к которым сотрудник имеет легальный доступ, каждый третий случай приходился на внешнюю атаку. Также нужно отметить, что, согласно приведенным в данным, на внешние атаки приходятся семь из восьми утечек объемом более десяти миллионов записей.
Злоумышленников интересуют такие виды информации, как внутренняя операционная ин- формация, персональные данные сотрудников, финансовая информация, информация о заказчиках/клиентах, интеллектуальная собственность, исследования рынка/анализ деятельности конкурентов, платежная информация . Эти сведения в итоге хранятся в корпоративных хранилищах и БД различного объема.
Все это приводит к необходимости обеспечения защиты не только коммуникаций, операционных систем и других элементов инфраструктуры, но и хранилищ данных как еще одного барьера на пути злоумышленника. Однако на сегодняшний день работы в области обеспечения безопасности БД направлены в основном на преодоление существующих и уже известных уязвимостей, реализацию основных моделей доступа и рассмотрение вопросов, специфичных для конкретной СУБД. Целью данной работы являются комплексное рассмотрение и систематизация вопросов безопасности раз- личных БД в свете новых угроз, общих тенденций развития информационной безопасности и возрас- тающей роли и разнообразия хранилищ данных.
Вопросы комплексной безопасности БД привлекают внимание исследователей, им ежегодно посвящается ряд работ как в России, так и за рубежом. Можно отметить такие исследования, как классическая работа . В ней рассматриваются подходы к обеспечению конфиденциальности, целостности и доступности СУБД, предотвращение, определение и игнорирование атак. Предлагаются подходы к обеспечению мандатного и ролевого дискреционного доступа к реляционному серверу. Данную тему развивает работа , затрагивающая те же вопросы обеспечения разделения доступа, привилегий, аудита и шифрования данных, а также вопросы применения для обеспечения защищенного доступа встроенных механизмов, таких как триггеры, представления и хранимые процедуры. Резюмирующая их работа обобщает развитие подходов к безопасности в историческом аспекте.
Среди зарубежных работ, освещающих современные направления исследований, можно отметить . Работы российских исследователей в основном посвящены узким вопросам безопасности СУБД, например .
Нельзя не отметить также монографии . Однако эти работы, как и известные учебные пособия и материалы, в частности , также не выходят за рамки вышеозначенных тем или же, как например , отражают специфику конкретной СУБД.
Аналогичную ситуацию можно наблюдать и в работе . STIG включает известные вопросы безопасности и критерии уровневой сертификации программных средств СУБД, оценивая безопас- ность ПО на основании известных угроз, без учета специфики хранимых данных.
Таким образом, сегодняшние исследования в области безопасности СУБД ограничиваются развитием концепции конфиденциальности, целостности и доступности данных, что не соответствует современным требованиям к системам защиты и информационной безопасности программных решений (например ), причем в контексте конкретных методов защиты, а не целостного рассмотрения проблемы. При этом они зачастую посвящены конкретным программным продуктам, а не всему классу соответствующего ПО.
Эволюция систем безопасности БД
Исторически развитие систем безопасности БД происходило как реакция на действия злоумышленников в соответствии с этапами эволюции самих хранилищ (БД) и изменениями типа и вида возрастающих угроз. Эти изменения были обусловлены общим развитием БД от решений на мейнфреймах до облачных хранилищ.
В архитектурном плане можно выделить следующие подходы:
Полный доступ всех пользователей к серве- ру БД;
Разделение пользователей на доверенных и частично доверенных средствами СУБД (системы управления БД);
Введение системы аудита (логов действий пользователей) средствами СУБД;
Введение шифрования данных; вынос средств аутентификации за пределы СУБД в опе- рационные системы и промежуточное ПО; отказ от полностью доверенного администратора данных.
Тем не менее, введение средств защиты как реакции на угрозы не обеспечивает защиту от новых способов атак и формирует разрозненное представление о самой проблеме обеспечения безопасности. С одной стороны, крупные компании могут выделить достаточное количество средств обеспечения безопасности для своих продуктов, с другой стороны, именно по этой причине имеется большое количество разнородных решений, отсутствует понимание комплексной безопасности данных (и ее компоненты разнятся от производителя к производителю), нет общего, единого подхода к безопасности хранилищ данных и, как следствие, возможности. Усложняются прогнозирование будущих атак и перспективная разработка защитных механизмов, для многих систем сохраняется актуальность уже давно известных атак, усложняется подготовка специалистов по безопасности.
Именно разработка программных средств перспективной защиты (на опережение злоумышленника), обеспечение возможности внедрения такой технологии представляются авторам статьи наиболее актуальными задачами на текущем этапе.
Современные проблемы обеспечения безопасности БД
Список основных уязвимостей хранилищ данных, актуальный на сегодняшний день , не претерпел существенных изменений за последние более чем пять лет. Проанализировав средства обеспечения безопасности СУБД, архитектуру БД, интерфейсы, известные уязвимости и инциденты безопасности, можно выделить следующие причины возникновения такой ситуации:
Проблемами безопасности серьезно занимаются только крупные производители прежде всего в ведущих продуктах линеек для хранения данных;
Программисты БД, прикладные программисты и администраторы БД не уделяют должного внимания вопросам безопасности;
Разные масштабы и виды хранимых данных требуют разных подходов к безопасности;
Различные СУБД используют разные языковые диалекты для доступа к данным, организованным на основе одной и той же модели;
Появляются новые виды и модели хранения данных.
Рассмотрим эти положения более подробно на примере линейки продуктов от Oracle. СУБД Oracle Database Server имеет достаточно развитую систему безопасности, включающую основные и дополнительные модули и содержащую средства гранулирования доступа до уровня записи и маскирования данных. Отметим, что продукт компании СУБД MySQL не может похвастаться таким уровнем защищенности. Это достаточно серьезная проблема, так как MySQL - широко применяемая СУБД как в электронной коммерции, так и в БД государственных структур.
Многие уязвимости, обозначенные в исследованиях (например в ), сохраняют актуальность за счет невнимания или незнания администраторами систем БД вопросов безопасности. Например, известные техники простой SQL-инъек-ции широко эксплуатируются сегодня в отношении различных web и иных приложений, в которых не уделяется внимание контролю входных данных запроса. Причинами этого являются как недостаточная информированность или внимание администраторов СУБД и прикладных программистов, так и отсутствие встроенных средств контроля известных уязвимостей в большинстве СУБД. Хорошим решением были бы автоматизация и перенос контроля таких угроз на уровень сервера, однако многообразие языковых диалектов не позволяет это сделать.
Также нужно отметить, что применение различных средств обеспечения информационной безо-пасности является для организации компромиссом в финансовом плане: внедрение более защищенных продуктов и подбор более квалифицированного персонала требуют больших затрат. К тому же ком- поненты безопасности могут отрицательно влиять на производительность систем управления БД, например уровни согласованности транзакций. Полное соответствие модели ACID - самый медленный способ обеспечения целостности при многопользовательской работе. Такие подходы, как маскирование данных или введение проверок безо-пасности доступа, также замедляют работу .
Еще одна причина такой ситуации - разрозненность диалектов языка запросов к СУБД. Если рассматривать только известные реляционные СУБД, несмотря на наличие развивающегося стандарта SQL (SQL-92, SQL-99, SQL-2003, SQL-2008), даже крупные производители не только используют собственные расширения языка, но и не поддерживают до конца операции принятой версии стандарта. Этот факт осложняет разработку единых механизмов защиты БД уровня сервера.
Приведенные выше проблемы усугубляются с появлением и широким распространением нереляционных хранилищ данных и СУБД, оперирующих другой моделью данных, однако построенных по тем же принципам и имеющих аналогичное назначение, что и традиционные, реляционные серверы. По сути многообразие современных так называемых NoSQL (нереляционных) решений приводит к разнообразию применяемых моделей данных и размывает границу понятия БД.
Следствием этих проблем и отсутствия единых методик является нынешняя ситуация с безопасностью NoSQL-систем. Эти решения появились на рынке недавно и еще не успели пройти «путь ошибок и уязвимостей», характерный для их более зрелых реляционных аналогов. В большинстве NoSQL-систем отсутствуют не только общепринятые механизмы безопасности вроде шифрования, поддержки целостности и аудита данных, но даже развитые средства аутентификации пользователей.
Особенности систем БД как объекта защиты
В связи с появлением новых решений в области нереляционных хранилищ, размывающих границу традиционного представления о СУБД (например, система кэширования данных в памяти MemcasheDB или Hadoop HDFS), определим функции, отличающие СУБД от файлового хранилища и других типов программных продуктов. В этом ключе в выделено несколько признаков. Переформулировав первый признак - «поддержание логически согласованного набора файлов», в силу активного развития in memory СУБД, осуществляющих хранение и все операции над данными в оперативной памяти, приведем эти критерии в следующей редакции:
Поддержание логически согласованного набора данных;
Обеспечение языка манипулирования дан- ными;
Восстановление информации после разного рода сбоев;
Реальная параллельная работа нескольких пользователей (процессов).
Используя такой подход, можно отделить именно СУБД от файловых систем и ПО другого вида.
Отличительной особенностью систем БД от остальных видов прикладного ПО является (относительно информационной безопасности и не только) их двойственная природа. С этой точки зрения СУБД включает в себя два компонента: хранимые данные (собственно БД) и программы управления (СУБД).
Обеспечение безопасности хранимой инфор- мации, в частности, невозможно без обеспечения безопасного управления данными. Исходя из этой концепции, все уязвимости и вопросы безопасности СУБД можно разделить на две категории: зависимые от данных и независимые от данных.
Отметим, что уязвимости, независимые от данных (их структуры, организации и т.д.), являются характерными для всех прочих видов ПО. К этой группе можно отнести несвоевременное обновление ПО или наличие неиспользуемых функций.
Зависимыми от данных (в той или иной степени) является большое число аспектов безопасности. В частности, зависимыми напрямую можно назвать механизмы логического вывода и агрегирования данных, называемые специфичными проблемами СУБД. В то же время многие уязвимости являются косвенно зависимыми от данных. Например, современные СУБД (считая и реляционные, и нереляционные решения) поддерживают запросы к данным с использованием некоторого языка запросов. В свою очередь, в этом качестве используются специализированные языки запросов (SQL, CQL, OQL и других), наборы доступных пользователю функций (которые, в свою очередь, тоже можно считать операторами запросного языка) или произвольные функции на языке программирования (чаще всего Java). Обобщенные интерфейсы работы с данными представлены на рисунке.
Архитектура применяемых языков, по крайней мере, то, что касается специализированных языков (запросов) и наборов функций, напрямую связана с моделью данных, применяемой для хранения информации. Таким образом, модель определяет особенности языка, а особенности языка - наличие в нем тех или иных уязвимостей. Причем уязвимости общего типа, например инъекция (под инъекцией будем понимать атаку на БД путем модификации входных запросов, заставляющую сервер СУБД выполнить нелегитимный набор действий), выполняются по-разному (SQL-инъекция, JAVA-инъек-ция) в зависимости от синтаксиса и семантики языка, которые, как уже сказано выше, отчасти определяются моделью данных и, следовательно, являются зависимым от данных компонентом.
Требования к безопасности БД
Таким образом, на основании разделения уязвимостей можно выделить зависимые и независимые от данных меры обеспечения безопасности хранилищ информации. Независимыми от данных мож-но назвать следующие требования к безопасной системе БД.
· Функционирование в доверенной среде.
Под доверенной понимается информационная среда, интегрирующая совокупность защитных механизмов, которые обеспечивают обработку информации без нарушения политики безопасности . В данном случае СУБД должна функционировать в доверенной информационной системе с соответствующими методами обмена данными.
· Организация физической безопасности файлов данных.
Данный вопрос требует более детального изучения, так как применяемые структуры данных в различных моделях данных СУБД могут иметь значение при шифровании и защите файлов данных. Однако в первом приближении вопрос физической безопасности файлов данных сходен с вопросом физической безопасности любых других файлов пользователей и приложений.
· Организация безопасной и актуальной настройки СУБД.
К данному аспекту относятся такие общие вопросы обеспечения безопасности, как своевременная установка обновлений, отключение неиспользуемых модулей или применение эффективной политики паролей.
Следующие требования можно назвать зависимыми от данных.
· Безопасность пользовательского слоя ПО.
· Безопасная организация данных и манипулирование ими.
Вопрос организации данных и управления ими является ключевым в системах хранения информации. Несмотря на то, что в приведенном перечне он указан последним, именно в эту область входят задачи организации данных с контролем целостности, обеспечение защиты от логического вывода и другие, специфичные для СУБД проблемы безо-пасности. Фактически эта задача включает в себя основной пул зависимых от данных уязвимостей и защиты от них.
Пути создания защищенных БД
Для преодоления названных проблем обеспечения информационной безопасности СУБД необходимо перейти от метода закрытия уязвимостей к комплексному подходу обеспечения безопасности хранилищ информации. Основными этапами этого перехода, по мнению авторов, должны стать следующие положения.
1. Разработка комплексных методик обеспечения безопасности хранилищ данных на текущем этапе.
Создание комплексных методик позволит применять их (или их соответствующие версии) при разработке хранилищ данных и пользовательского ПО. Основой для создания таких документов могут стать обобщающие проблематику работы, например или . Следование комплексной методике позволит избежать многих ошибок управления СУБД и защититься от наиболее распространенных на сегодняшний день уязвимостей.
2. Оценка и классификация угроз и уязвимостей СУБД.
Специализированная классификация угроз и уязвимостей СУБД позволит упорядочить их для последующего анализа и защиты, даст возможность установить зависимость между уязвимостями и причинами (источниками) их возникновения. В результате при введении конкретного механизма в СУБД появится возможность установить и спрогнозировать связанные с ним угрозы и заранее подготовить соответствующие средства обеспечения безопасности.
3. Разработка стандартных (применимых к различным СУБД без внесения изменений или с минимальными изменениями) механизмов обеспечения безопасности.
Стандартизация подходов и языков работы с данными позволит создать мультиплатформенные средства обеспечения безопасности, применимые к разным СУБД. С одной стороны, это методические и теоретические подходы, применимые в рамках модели данных. На сегодняшний день есть наработки таких механизмов по реляционной модели, однако они не решают всех насущных вопросов безопасности. С другой - это разработка теоретического базиса для новых СУБД, в частности, конкретизация и формализация агрегатных моделей данных. Появление готовых программных средств во многом зависит от производителей и разработчиков СУБД и их следования стандартам, а также достаточности определенных в стандарте средств для построения развитых механизмов безопасности.
4. Разработка теоретической базы информационной защиты систем хранения и манипулирования данными.
Выше отмечен ряд характерных особенностей, специфичных для хранилищ данных: двойственная природа СУБД, зависимость уязвимостей и механизмов управления от данных и описывающей их организацию модели, угрозы логического вывода, различная значимость сочетаний данных. Все это определяет специфический характер безопасности СУБД и требует новых теоретических подходов к обеспечению защиты данных в программных системах такого рода. Отдельный большой вопрос - развитие теоретического базиса в контексте формализации модели данных, а также разработка подходов обеспечения целостности информации для новых NoSQL-хранилищ.
На основании изложенного сделаем следующие выводы. В результате рассмотрения российских и зарубежных работ, а также ситуации на рынке СУБД в статье выделены текущий подход к обеспечению безопасности, принцип и основные эволюционные этапы систем БД. Сформулированы проблемы информационной безопасности современных СУБД: разнообразие языковых средств, появление новых моделей данных, не подкреп- ленных теоретическим базисом, необходимость поиска баланса между безопасностью и ее стоимостью, развитие систем защиты как реакции на потерю средств и престижа, а также общее невнимание к вопросам безопасности.
Сформулированы критерии, выделяющие СУБД из сходных программных продуктов, с учетом новых кластерных и in memory решений, особенности этого класса ПО с точки зрения информационной безопасности и предложено базовое деление уязвимостей на зависимые и независимые от данных и их организации.
В результате сформулированы общие требования к безопасности БД, перспективные пути исследования и развития систем защиты для построения надежных и защищенных серверов по обработке информации. В них вошли как систематизация и развитие существующих подходов в виде выработки методик и стандартизации механизмов защиты, так и направления новых исследований, например, классификация уязвимостей СУБД и формализация новых моделей данных, построение прогнозирующих средств защиты.
Литература
1. Исследование утечек информации за первое полугодие 2015 года. URL: http://www.infowatch.ru/analytics/reports/16340 (дата обращения: 26.02.2016).
2. Информационная безопасность бизнеса. Исследование текущих тенденций в области информационной безопасности бизнеса. 2014. URL: http://media.kaspersky.com/pdf/IT_risk_ report_Russia_2014.pdf (дата обращения: 26.02.2016).
3. Sandhu Ravi S., Jajodia Sushil. Data and database security and controls. Handbook of Information Security Management, Auerbach Publishers, 1993, pp. 181-199.
4. Qiu M., Davis S. Database security mechanisms and implementation. IACIS, Issues in Inform. Syst. 2002, vol. 03, pp. 529-534.
5. Lesov P. Database security: a historical perspectiv. 2010. URL: http://arxiv.org/ftp/arxiv/papers/1004/1004.4022.pdf (дата обращения: 26.02.2016).
6. Burtescu E. Database security - attacks and control me- thods. Journ. of Applied Quantitative Methods, 2009, vol. 4, no. 4, pp. 449-454.
7. Rohilla S., Mittal P.K. Database Security: Threads and Challenges. Intern. Journ. of Advanced Research in Computer Science and Software Engineering, 2013, vol. 3, iss. 5, pp. 810-813.
8. Потапов А.Е., Манухина Д.В., Соломатина А.С., Бадмаев А.И., Яковлев А.В., Нилова А.С. Безопасность локальных баз данных на примере SQL Server Compact // Вестн. Тамбов. ун-та. Серия: Естественные и технические науки. 2014. № 3. С. 915-917.
9. Бортовчук Ю.В., Крылова К.А., Ермолаева Л.В. Информационная безопасность в современных системах управления базами данных // Современные проблемы экономического и социального развития. 2010. № 6. С. 224-225.
10. Горбачевская Е.Н., Катьянов А.Ю., Краснов С.С. Информационная безопасность средствами СУБД Oracle // Вестн. ВУиТ. 2015. № 2 (24). С. 72-85.
11. Ткаченко Н.О. Реализация монитора безопасности СУБД MySQL в dbf/dam системах // ПДМ. Приложение. 2014. № 7. С. 99-101.
12. Полтавцева М.А. Задача хранения прав доступа к данным в РСУБД на примере Microsoft SQL Server // Актуальные направления фундаментальных и прикладных исследований: матер. V Междунар. науч.-практич. конф. 2015. С. 118-120.
13. Баранчиков А.И., Баранчиков П.А., Пылькин А.Н. Алгоритмы и модели доступа к записям БД. М.: Горячая линия-Телеком, 2011. 182 с.
14. Поляков А.М. Безопасность Oracle глазами аудитора: нападение и защита. М.: ДМК Пресс, 2014. 336 с.
15. Смирнов С.Н. Безопасность систем баз данных. М.: Гелиос АРВ, 2007. 352 с.
16. Murray M.C. Database security: what students need to know. JITE:IIP, vol. 9, 2010, pp. 61-77.
17. Database Security Technical Implementation Guide (STIG). US Department of Defense. Vers. 7. Release 1. 2004. URL: https://www.computer.org/ cms/s2esc/s2esc_excom/Minutes/2005-03/DISA%20STIGs/DATABASE-STIG-V7R1.pdf (дата обращения: 26.02.2016).
18. Зегжда П.Д. Обеспечение безопасности информации в условиях создания единого информационного пространства // Защита информации. Инсайд. 2007. № 4 (16). С. 28-33.
19. Top Ten Database Security Threats. URL: http://www.imperva.com/docs/wp_topten_database_threats.pdf IMPREVA 2015 (дата обращения: 26.02.2016).
20. Кузнецов С.Д. Базы данных: учебник для студ. М.: Академия, 2012. 496 с.
21. Зегжда Д.П., Калинин М.О. Обеспечение доверенности информационной среды на основе расширения понятия «целостность» и управления безопасностью // Проблемы информ. безопасности. Компьютерные системы. 2009. № 4. С. 7-16.
22. Полтавцева М.А., Зегжда Д.П., Супрун А.Ф. Безопасность баз данных: учеб. пособие. СПб: Изд-во СПбПУ, 2015. 125 с.
С увеличением использования баз данных, частота нападения на базы данных также возросла. В наши дни атаки на базы данных являются растущей тенденцией. В чём причина нападения на БД? Одна из причин — это увеличение доступа к данным, хранящимся в базе данных. Когда данные использовались многими людьми, шансы кражи данных увеличиваются. Отсюда следует, что безопасность баз данных — это диапазон методов, которые используют для защиты информации, хранящейся в базе данных. Так как попытки взлома БД являются наиболее частыми, вам необходимо будет подумать о безопасности информационной базы, так как существует множество и других опасностей.
Физическое повреждение компьютера, неправильная кодировка или коррупция, и перезагрузка данных, вот практически все потенциальные угрозы для базы данных. А это означает, что есть много мер безопасности - от брандмауэров до аудита и резервного копирования дисков - свести любой возможный ущерб к минимуму и предотвратить потерю всей базы данных. Большинство предприятий имеют собственные протоколы безопасности данных для защиты от определенных атак и возможного ущерба.
Установка межсетевого экрана для базы данных , своеобразный защитный барьер, который запрещает все неизвестные соединения, это является самой основной формой защиты баз данных. Межсетевые экраны установлены на большинстве компьютеров и сделаны таким образом, что хакеры будут иметь трудности с подключением к компьютеру жертвы. Брандмауэры работают путем фильтрации подключений к сети и только доверенные компьютеры или пользователи могут получить доступ к базе данных. В то время как опытные хакеры могут обойти это, брандмауэр обеспечивает высокий уровень безопасности.
Шифрование — это другая мера безопасности для базы данных, в которой данные шифруются, или были сделаны неразборчивыми для всех, кто обращается к базе данных. При использовании шифрования, алгоритм кодирует символы в бред, поэтому он не может быть прочитан. Это означает, что если хакер имеет определенные знания о ключах шифрования, информацию, которая вам нужна для изменения зашифрованных данных из неразборчивых символов обратно в понятную форму, нет никакого способа, чтобы он или она могли прочитать базу данных.
Аудит — это, когда руководитель или менеджер, проверяет базу данных, чтобы убедиться, что в ней ничего не изменилось. Этот тип защиты БД обычно выполняют физически, кем-то, кто может читать базу данных, или для больших баз данных с помощью программы, чтобы увидеть, что целостность БД осталась такая же. Кроме того, аудит может включать проверку доступа к базе данных и, увидеть, что человек сделал, когда он получил доступ к базе данных. Это предотвращает кражи данных или, по крайней мере, позволяет администраторам, чтобы выяснить, кто совершил кражу данных.
Регулярное резервное копирование БД — это мера безопасности баз данных, которая может защищать БД от различных угроз. Когда резервное копирование базы данных выполняется регулярно, то это означает, что данные будут храниться на другом жёстком диске или сервере. Если база данных теряет любую или всю информацию, она может быть быстро перезапущена с минимальными потерями, используя резервную копию. Делая резервное копирование базы данных, администраторы могут предотвратить физическое повреждение компьютера, например от пожара, повреждения базы данных или базы данных выключением от перегрузки.
