Управление доступом на уровне объектов СУБД
СУБД Informix является реляционной и поддерживает общепринятые стандарты на язык структурированных запросов к базе данных SQL. В соответствии с этим, основными объектами, для которых предусмотрено разделение, задание и отслеживание доступа, являются собственно база данных (БД), таблица внутри базы, отдельная колонка или отдельная запись внутри таблицы.
При создании в СУБД Informix любого объекта (базы данных, таблицы, хранимой процедуры и т.д.), пользователь, создавший этот объект, является его единственным владельцем. Этот владелец может передавать право на доступ к этому объекту другим пользователям.
На уровне базы данных пользователю может быть предоставлено (и, соответсвенно, отобрано) право администратора базы данных, право на управление ресурсами и право на доступ к информации в БД.
На уровне отдельной таблицы пользователю может быть предоставлено право на выборку записей (или только конкретных полей записи), на удаление записей, вставку новых записей, модификацию записей (может быть не всей записи, а только конкретных полей), изменение структуры таблицы и т.д.
Для обеспечения разграничения доступа на уровне отдельной записи (то есть для указания того, какие записи тот или иной пользователь может видеть, а какие - нет) используется механизм псевдотаблиц VIEW совместно с функцией USER, возвращающей имя пользователя.
Следовательно, внутри СУБД Informix можно обеспечивать сколь угодно гибкий способ распределения прав доступа вплоть до конкретных полей некоторого подмножества записей в таблице.
Алгоритм аутентификации
Выше мы рассмотрели как можно задавать права по доступу к данным. В качестве ключевого значения, на основе которого определяется кто и что может делать с данными, выступает идентификатор пользователя.
Возможно два подхода к тому, кто производит аутентификацию (определение и проверку) пользователя. В первом случае СУБД ведет свой собственный список пользователей, их паролей, политики смены паролей и т.д. Во втором случае СУБД использует системные имена пользователей, то есть идентификаторы пользователя в операционной системе. При использовании системных имен при аутентификации пользователя СУБД обращается к соответствующим функциям ОС.
Сервер баз данных Informix в качестве идентификатора пользователя использует системное имя, то есть идентификатор пользователя в операционной системе. Такой подход имеет некоторые преимущества:
* снижение стоимости СУБД - разработчикам СУБД нет необходимости тратить время и усилия на разработку, тестирование и поддержку собственных средств аутентификации;
* гарантированная надежность - средства аутентификации, встроенные в ОС, достаточно давно известны, проверены и обеспечивают разумную надежность;
* упрощение администрирования - администратору не надо вести два разных списка пользователей (для ИС и для ОС), следовательно, требуется меньше времени, меньше усилий и меньше вероятность ошибки.
* повышается общий уровень безопасности - как правило, пользователи предпочитают иметь один пароль для всего, следовательно, взломав одну из систем защиты (ОС или ИС), с большой вероятностью можно получить доступ и к другой системе. Поэтому в реальных условиях единая система аутентификации более надежна к раскрытию пароля, нежели две разные системы аутентификации с единым паролем, работающие не совместно, а в параллель.
Встраивание дополнительных алгоритмов шифрации
В большинстве стран использование алгогритмов шифрования находится под контролем государства и, более того, различные государствепнные учреждения и коммерческие фирмы могут иметь дополнительные внутреннии правила и методики использования шифрации данных. Именно поэтому СУБД Informix не имеет никаких встроенных алгоритмов шифрования. Интеграции механизма шифрации данных в СУБД Informix может быть обеспечивается за счет использования дополнительно встраиваемых алгоритмов, которые разрабатываются специальными фирмами.
Расмотрим это подробнее.
СУБД Informix поддерживает архитектуру "клиент-сервер". Это означает, что имеется, как минимум, два типа программ в СУБД - программы-серверы баз данных, и программы-клиенты. Программа-клиент обеспечивает интерфейс с пользователем. Программа-сервер БД обеспечивает механизмы хранения и доступа к данным и, в частности, механизмы распределения прав доступа и контроля за соблюдением прав доступа. Также поддерживается и трехзвенная архитектура с сервером приложений. Следовательно, при разработке ИС можно добавить некоторые промежуточную программную компоненту, которая будет получать от программы-клиента данные, шифровать их и отправлять на сервер БД. Соответственно, когда программа-клиент получает информацию из сервера БД, эта промежуточная программная компонента должна произвести дешифрование данных. Именно так, кстати, работает приложение одного Российского партнера, предназначенного для удаленного обмена конфиденциальной информацией (данное приложение было сертифицировано ФАПСИ).
Другой возможный подход основан на использовании Informix Dynamic Server совместно с Universal Data Option. Данный вариант сервера базы данных поддерживает объектную технологию и позволяет реализовывать новые механизмы хранения и доступа к данным. Встраивание сертифицированных механизмов шифрования в типы данных также позволяет обеспечить зашиту данных от несанкционированного доступа.
Таким образом, в СУБД Informix можно гибко реализовывать механизм защиты данных с помощью шифрования, не нарушая при этом местных законов.
Механизм аудитинга
Помимо предупреждения какого-либо действия путем установки соответствующего набора прав доступа, нужно, также, иметь возможность отслеживать действия конкретных пользователей при исполнении конкретных действий. Например, операционисты в банке по своему статусу имеют право фиксировать в ИС платежные документы. При этом операционист может ошибиться, а может указать неправильные данные по злому умыслу. Для решения такой и многих подобных проблем в СУБД должен присутствовать механизм протоколирования, возможно негласного (в виде аудитинга).
В СУБД Informix возможно два способа протоколирования. Первый основан на стандартном для SQL механизме триггеров и хранимых процедур. Недостатком такого способа является неудобное администрирование, так как внешние по отношению к БД действия (протоколирование) встраивается в схему БД. Также неудобно включать и выключать такой аудитинг. Достоинством реализации аудитинга на основе триггеров является возможность обрабатывать зафиксированные события реляционными методами.
Второй способ контроля за действиями пользователя в СУБД Informix обеспечивается с помощью специального, встроенного в сервер БД, механизма аудитинга. Встроенный механизм аудитинга позволяет фиксировать в специальных файлах (журналах) любые действия любых пользователей.
Для обеспечения работы механизма аудитинга в СУБД Informix дополнительно вводятся два новых типа пользователей - "заведующий безопасностью базы данных" и "аналитик". Первый конфигурирует механизм аудитинга, при необходимости включает или выключает его и т.д. Второй имеет право просматривать журнал действий пользователя.
Конфигурирование механизма аудитинга подразумевает:
* указание действий, которые в обязательном порядке будут фиксироваться в журналах для любого пользователя;
* указание пользователей, для которых надо (или, наоборот, не надо) фиксировать те или иные действия;
* указание действий, которые надо протоколировать для того или иного пользователя.
В качестве фиксируемых действий могут выступать практически любые действия по доступу и модификации данных в БД, а также и административные действия.
Следует отметить, что никто, кроме заведующих безопасностью базы данных и системных администраторов не может знать, включен в данный момент времени аудитинг или нет. А если аудитинг включен, то невозможно узнать, протоколируется ли то или иное действие для того или иного пользователя, или нет. Следовательно, никто не может быть уверен, что его попытка прочесть или поменять какие-либо данные в БД останется незамеченной. Сама возможность негласного документированного контроля может предупредить попытки несанкционированного доступа к данным. Это верно, конечно, только в том случае, когда пользователи проинформированы о возможностях аудитинга.
Формальные критерии
Во многих странах, в том числе и в России, использовать те или иные программные продукты для некоторых типов задач можно только после проведения формальной сертификации. В процессе этой формальной сертификации программный продукт проверяется на соответствие некоторым формальным спецификациям, как-то наличие специальных средств аудитинга, неоставление в ОЗУ фрагментов данных после выгрузки программы, разделение функций администратора сервера базы данных и аудитинга и т.д. Кроме того, в процессе такой сертификации программные продукты проверяются на отсутствие "закладок".
Учитывая важность формальной сертификации, фирма Informix прилагает усилия по сертификации своих продуктов в разных странах. К настоящему моменту сервера Informix Dynamic Server прошли сертификацию по следующим известным формальным спецификациям (это не полный список):
* Аттестат соответствия министерства обороны РФ;
* C2 министерства обороны США;
* B1 министерства обороны США;
Стандартный процесс сертификации обычно предполагает сертификацию конкретной версии на конкретной аппаратной платформе (например, тестируется не вообще все сервера Informix, а конкретно сервер Informix 7.23.UC2 на аппаратной платформе HP K200 под управлением ОС HP-UX 10.01). Так как для всех серверов Informix Dynamic Server вне зависимости от платформы, используется одно и то же ядро, это позволяет говорить о том, что все сервера данной архитектуры (все сервера Informix Dynamic Server) удовлетворяют указанным выше формальным сертификациям.