Сзи, используемые в псб защищенной субд

Элементы архитектуры СУБД как СЗИ

СУБД ЛИНТЕР - открытая система. По технологии построения открытых систем, все ее алгоритмы открыты для всех пользователей и работают для всех одинаково. Прикладные пользовательские программы отделены от системы. Общение между ядром СУБД и приложением ее использующим проходит только через Call-интерфейс системы. Тексты/алгоритмы Call-интерфейса открыты, не содержат элементов СЗИ НСД. Алгоритм Call-интерфейса устроен таким образом, что раз установленная связь субъекта и СУБД идентифицируется еще идентификатором (каждая операционная система присваивает задаче уникальный идентификатор) прикладной задачи (см. п. Ошибка! Источник ссылки не найден.), что исключает возможность перехвата ответов от ядра ЛИНТЕР. Это означает, что ответ, посланный задаче на ее запрос, придет именно к этой задаче и ни к какой другой.

Все утилиты системы ЛИНТЕР написаны с использованием того же Call-интерфейса (т.е. штатных средств) и не используют никаких других, скрытых особенностей системы. Следуя технологии открытых систем, субъект контроля может обращаться посредством СУБД ЛИНТЕР к базе данных только из программ (поставляемых в дистрибутиве или подготовленных им самим) и только с помощью штатных средств системы.

ПСБ СУБД ЛИНТЕР реализована в виде части исполняемого кода ядра системы. Основа системы безопасности - диспетчер доступа получает управление на ранних этапах инициализации СУБД до запуска процедур обслуживания пользовательских запросов. Диспетчер доступа реализован в виде четырех взаимосвязанных программных частей, каждая из которых контролирует свою область действий системы.

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

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

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

Четвертая часть диспетчера доступа СУБД ЛИНТЕР обеспечивает изоляцию параллельно выполняющихся запросов. Он также выполняет планирование обработки запросов, контролирует их квантование и отслеживает все возможные нарушения изоляции процессов выполняющихся по разным логическим связям.

Все части диспетчера доступа в процессе работы обращаются к подсистеме регистрации событий СУБД ЛИНТЕР, которая может принять решение в соответствии со своими параметрами о регистрации соответствующих событий в таблице событий.

СУБД ЛИНТЕР в процессе обработки запросов не оперирует непосредственно с данными пользователя. Она оперирует только управляющей информацией, характеризующей их. Данная информация представляет собой в основном массивы ссылок на файлы данных. Вся эта управляющая информация хранится в управляющей структуре соответствующего канала. При параллельном исполнении запросов, диспетчер доступа просто выбирает очередную структуру управления каналом в соответствии с приоритетами исполнения запросов. Дальнейшая работа СУБД ЛИНТЕР вплоть до передачи управления диспетчеру доступа ведется в контексте параметров и информации данной структуры.

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

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

Информация о всех элементах и свойствах ПСБ хранится в системных таблицах СУБД, например, субъектах, ролях, их возможности по отношению к каждому из объектов – в таблице привилегий $$$USR.

Аутентификация

Каждый пользователь, начинающий работу с СУБД ЛИНТЕР должен пройти процедуру аутентификации - проверку соответствия зарегистрированному пользователю системы с помощью пароля.

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

Ядро ЛИНТЕР для каждого канала связи с приложением хранит у себя в памяти следующую информацию:

-идентификатор субъекта;

-идентификатор приложения (процесса и даже нити);

-при сетевой работе адрес клиентской станции и тип сетевого протокола.

Возможны следующие ситуации:

-имя и пароль пользователя введены правильно - пользователь допускается в систему;

-имя пользователя введено неверно - выдается код сообщения о том, что имя пользователя введено неверно (Illegal user name). Пользователь в систему не допускается.

-пароль пользователя введен неверно - выдается код сообщения о том, что пароль пользователя введен неверно (Illegal password). Пользователь в систему не допускается.

Методы и средства разграничения доступа

С учетом реализации в СУБД ЛИНТЕР дискреционного и мандатного принципов контроля доступа в системе действуют два глобальных правила:

-доступ к объектам, имеющим дискреционную и мандатную защиту, должен быть санкционирован ими обоими, в противном случае запрос на доступ будет отвергнут по обоим правилам (принцип эквивалентности);

-при отсутствии у субъекта доступа к какому-либо объекту по одному из принципов (если в отношении субъекта и объекта действуют оба принципа), он не сможет ни управлять доступом к этому объекту, ни получить доступ к этому объекту.

Разграничение доступа на основе дискреционного принципа контроля:

1). Для каждой пары субъект-объект владелец объекта может задать явное и недвусмысленное перечисление возможных действий других субъектов (групп):

-SELECT - чтение данных объекта;

-INSERT - добавление новых данных в объект;

-DELETE - удаление некоторых/всех данных объекта;

-UPDATE - изменение данных объекта;

-ALTER - изменение физической/логической структуры базовой таблицы (изменение размеров и числа файлов таблицы, введение дополнительного столбца и т.п.);

-INDEX - создание/удаление индексов на столбцы базовой таблицы;

-ALL- равнозначно SELECT+INSER+DELETE+ UPDATE+ ALTER+ INDEX.

2). С помощью аппарата ролей можно строить иерархические взаимоотношения пользователей (старший - подчиненный) и другие структуры доступа:

-создать роль (и, значит стать ее владельцем) может только субъект Dba-категории;

-назначить/отнять роль может только ее владелец/создатель;

-владельцы объектов могут в процессе работы отменить некоторые права, ранее данные ролям, что повлечет за собой изменение иерархии прав на более высоких уровнях;

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

Разграничение доступа на основе мандатного принципа:

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

Метка объекта включает:

-группу субъекта, который внес данный объект;

-уровень доступа на чтение - RAL (Read Access Level);

-уровень доступа на запись - WAL (Write Access Level).

Метка субъекта выглядит аналогично:

-группа, к которой принадлежит субъект;

-RAL-уровень субъекта, который представляет собой максимальный RAL-уровень доступной субъекту информации;

-WAL-уровень субъекта, т.е. минимальный RAL-уровень объекта, который может быть создан данным субъектом.

Все пользователи базы данных считаются разбитыми на непересекающиеся группы:

-Группа описывает область доступных пользователю данных.

-Для каждой группы существует администратор группы (DBA группы), созданный администратором SYSTEM (группа 0). Принадлежность группе задается командой ALTER.

-Пользователи одной группы не видят данных пользователей другой группы.

-Все данные, созданные от имени пользователя, помечаются его группой.

-Описания групп хранятся в таблице групп $$$GROUP.

Уровни доступа:

Для пользователя (субъекта):

-RAL - уровень доступа. Пользователь может получать (читать) информацию, RAL-уровень которой не выше его собственного уровня доступа;

-WAL - уровень доверия на понижение уровня конфиденциальности. Пользователь не может вносить информацию с уровнем доступа (RAL-уровнем) более низким, чем данный WAL-уровень пользователя. Т.е. пользователь не может сделать доступную ему информацию менее конфиденциальной, чем указано в данном параметре.

Для информации:

-RAL - уровень чтения. Пользователь может получать (читать) информацию, RAL-уровень которой не выше его собственного RAL-уровня (может читать менее конфиденциальные данные);

-WAL - уровень ценности или уровень доступа на запись (модификацию, удаление). Пользователь может модифицировать (удалять) информацию, WAL-уровень которой не выше его RAL-уровня.

Всего вводится до 10 уровней (0 - 10). Данные записываются в таблицу уровней $$$LEVEL.

Главным инструментом, позволяющим приложению маркировать документы (выводимые данные) является функция СУБД SECURITY.

Средства сетевой безопасности

СУБД ЛИНТЕР представляет собой многопользовательскую систему. Пользователи могут получать удаленный доступ к базе данных с различных сетевых терминальных станций. СУБД отличает различные станции сети по их протоколу обмена данными и по уникальному сетевому адресу в пределах одного протокола.

СУБД ЛИНТЕР позволяет администратору системы безопасности регулировать доступ пользователей в систему по следующим критериям:

-по времени работы пользователя;

-по количеству одновременно активных логических соединений к базе данных;

-по списку разрешенных для доступа станций;

-по уровням доступа;

-по списку разрешенных для доступа групп.

Основополагающим понятием в процессе сопоставления пользователя с устройством является понятие сетевой станции. Сетевой станцией ЛИНТЕР считает любую станцию, имеющую уникальный идентификатор - адрес в сети.

ЛИНТЕР поддерживает несколько типов сетей, что требует различного подхода к интерпретации сетевых адресов. В общем случае сетевой адрес состоит из адреса подсети (уникального в пределах всей сети) и адреса станции (уникального в пределах подсети). ЛИНТЕР позволяет управлять доступом как на уровне конечной станции, так и на уровне подсети. В последнем случае ограничения, наложенные на всю подсеть, влияют на все станции, расположенные в данной сети. Каждый сетевой адрес в ЛИНТЕР характеризуется следующими параметрами:

-типом сети (определяет внутреннюю структуру адреса);

-типом адреса (указывает на подсеть или конкретный узел);

-адресом в сети (собственно сетевой адрес, в зависимости от типа сети может включать адрес подсети, а может не включать его);

-маской разрешенных групп (стандартная битовая маска, описывающая, разрешен ли доступ данной группы к станции);

-уровнями мандатного доступа (проверяется, возможность пользователя выполнять соответствующие операции по отношению к данной станции);

-маской разрешенного времени доступа (с точностью до получаса описывается время, разрешенное для доступа со станции).

Создать новую сетевую станцию (изменить характеристики существующей) может только администратор безопасности базы данных.

При попытке установления соединения подсистема защиты базы данных выполняет следующие действия:

-проводит стандартные проверки идентификации и аутентификации пользователя;

-проверяет наличие у пользователя категории Connect;

-получает у операционной системы тип сети и адрес сети - источника запроса на установку соединения;

-проверяет, ограничен ли доступ для данного пользователя (по временным показателям);

-проверяет, существует ли для данного пользователя список разрешенных или запрещенных сетевых станции;

-если такой список существует, то подвергает проверке совпадение меток доступа для пользователя и разрешенной станции (группа пользователя должна содержаться в маске групп пользователей у станции; уровень RAL пользователя не должен быть выше уровня RAL станции, уровень WAL пользователя не должен быть ниже уровня WAL станции);

-при успешной проверке проверяется возможность данного пользователя работать с этой станции в текущий момент времени;

-если запрещенных комбинаций не обнаружено, то доступ разрешается.

Все данные хранятся в таблице сетевых станций ($$$STATION).

Средства защиты операций ввода-вывода на внешний носитель

СУБД ЛИНТЕР использует внешние устройства постоянного хранения информации для размещения таблиц данных и временных рабочих файлов. Расположение конкретного объекта базы данных (файла таблицы, временного рабочего файла) внутри системы однозначно идентифицируется четырехсимвольным идентификатором - Линтер-именем устройства. Линтер‑имя используется при создании новых таблиц, или изменении расположения файлов старых. Соответствие Линтер-имен физическим устройствам описывается таблицей $$$DEVICE. Данная таблица создается на уровне администратора безопасности БД и доступна только ему. Описание защиты устройства включает:

-метку доступа (набор из двух значений: RAL и WAL), служащую для принудительного контроля за созданием файлов базы данных (файлов таблиц и временных файлов) на описываемом устройстве;

-RAL устройства представляет собой минимальный уровень доступа пользователя (RAL-пользователя), необходимый для создания этим пользователем объектов (таблиц и временных файлов) на данном устройстве;

- WAL устройства представляет собой максимальный WAL-уровень пользователя необходимый для удаления таблицы;

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

-маску разрешения доступа для групп пользователей.

Аудит действий пользователей.

Все действия приложений, связанные с:

-идентификацией и аутентификацией;

-запросами на доступ к объектам защиты;

-создание/уничтожение объектов защиты;

-действиями по изменению ПРД регистрируются в таблице $$$AUDIT. Кроме этого, в эту таблицу заносятся внутренние ошибки системы ЛИНТЕР (по требованию), изменения состояния пользовательских событий, установленных в системе и т.д.

Преобразование данных

Преобразованию (шифрации) в ЛИНТЕР подвергаются данные любой таблицы, содержащиеся файлах данных и BLOB-файлах.

Целью преобразования данных является затруднение доступа к данным базы средствами, отличными от средств СУБД ЛИНТЕР, в момент, когда ядро системы не работает (не загружено).

При загруженном ядре системы файлы таблиц монопольно блокируются и доступны только ядру ЛИНТЕР.

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

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

Пароли пользователей прежде, чем записываться в базу данных, подвергаются необратимому преобразованию. При этом используется алгоритм MAC (Message Authentification Code).

Средства обеспечения целостности

Механизм контроля целостности ПСБ

Целостность СЗИ НСД в ЛИНТЕР эквивалентна целостности программного кода ядра системы. Для проверки целостности системы применяется утилита подсчета контрольных сумм, которая создает на выходе файл, содержащий контрольные суммы проверяемых файлов. Целостность системы считается подтвержденной в случае, если результирующие контрольные суммы совпали с контрольными суммами, приведенными в документации. Проверка выполняется перед каждым запуском ядра СУБД.Все действия, связанные с изменениями в системе защиты, также отображаются в журнале (создание/удаление нового пользователя/группы и т.д.).

Механизм надежного восстановления СУБД ЛИНТЕР. Его основой является ведение системного журнала, в котором отображаются все изменения, которые производятся с БД всеми пользователями системы. Если пользователь получил уведомление о том, что его изменения перенесены в базу, то сбой оборудования не может привести к нарушению системы защиты.

Очистка оперативной/внешней памяти

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

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

Во время работы система ЛИНТЕР отслеживает занятое ею место в оперативной памяти.

При выгрузке СУБД ЛИНТЕР обнуляет весь отрезок оперативной памяти, который она занимала.