Вашу информацию защитит СУБД
Стремительное развитие информационных технологий во второй половине двадцатого века поставило перед человечеством новую проблему, связанную с защитой информации. Ежегодно в мире тратятся сотни миллионов долларов с одной-единственной целью — предотвратить утечку или, что еще хуже, потерю информации. Безусловно, абсолютной защиты от посягательств на информационную собственность не существует, но это совсем не означает, что любая попытка обезопасить свой компьютер от информационных взломщиков обречена на неудачу.
Обеспечить безопасность информации можно как аппаратными, так и программными средствами. Наша цель — ознакомить читателей со способами защиты информации от несанкционированного доступа. В качестве примера программного комплекса, обеспечивающего безопасность информации, выбрана система управления базами данных (СУБД) «Линтер» воронежской фирмы «Релэкс». В 1998 году эта система была сертифицирована Гостехкомиссией при Президенте РФ по второму классу защищенности данных от несанкционированного доступа. На сегодняшний день «Линтер» — единственная СУБД, сертифицированная в России по такому высокому классу.
Система защиты информации от несанкционированного доступа (СЗИ НСД) СУБД «Линтер» реализована в виде части исполняемого кода ядра системы. Ядро системы безопасности — диспетчер доступа — получает управление на ранних этапах инициализации СУБД до запуска процедур обслуживания пользовательских запросов. Дальнейшая работа СУБД происходит под контролем СЗИ НСД. В СУБД «Линтер» информация о каждом пользователе, имеющем право подключаться к системе, находится в системных справочниках базы данных. Перед началом работы каждый пользователь проходит процедуру идентификации и аутентификации, то есть сообщает программе свое системное имя и пароль.
Правом изменения системной базы данных обладает только администратор безопасности.
Для обеспечения разграничения доступа в СУБД «Линтер» реализованы дискреционный и мандатный принципы контроля. При этом действуют два глобальных правила:
- Доступ к объектам, имеющим дискреционную и мандатную защиту, должен быть санкционирован ими обеими. Если хотя бы одна из них (дискреционная или мандатная) отвергает доступ, то запрос на доступ будет отвергнут по обоим правилам (принцип эквивалентности).
- При отсутствии у субъекта доступа к какому-либо объекту по одному из принципов (если в отношении субъекта и объекта действуют они оба) он не сможет ни управлять доступом к этому объекту, ни получить доступ к нему. В этом отношении среди пользователей выделяется только администратор безопасности, который может изменять метки доступа пользователей (но не данных).
Дискреционный принцип контроля основывается на аппарате ролей и на разделении всех пользователей системы на три категории: Connect, Resource и Dba. Connect-категория дает пользователю право на подсоединение к системе и подачу запросов к доступным ему данным. Resource-категории доступны все возможности Connect-категории плюс возможности изменения структуры базы данных путем построения своих объектов контроля (таблиц, представлений, синонимов). Dba-категория (категория администраторов базы данных) включает возможности обеих предыдущих категорий, а также возможность водить и удалять субъекты контроля или изменять их категорию.
Любая информация, вводимая в базу данных, имеет своего владельца — пользователя, который эту информацию ввел. Для других пользователей доступ к данным возможен только с разрешения владельца информации. В больших базах данных, где много субъектов и объектов контроля, очень сложно определять права каждого субъекта при работе с каждым объектом. Для упрощения этой процедуры в СУБД «Линтер» реализован аппарат ролей. Роль — это именованный набор прав на множество объектов базы данных. Введенные роли разбивают всех пользователей базы на группы. При работе с привилегиями роль рассматривается сначала как пользователь или субъект. Владелец того или иного объекта базы данных назначает определенный вид доступа для роли как для простого пользователя.
Мандатный принцип контроля основан на использовании меток конфиденциальности или меток безопасности. Эти метки хранятся вместе с объектом защиты и играют важную роль при допуске субъектов к информации помеченного объекта. Метки доступа позволяют также осуществлять многоуровневую защиту, которая обеспечивает разграничение доступа субъектов с различными правами к объектам различных уровней конфиденциальности. Уровни доступа и ценности, входящие в метку доступа защищаемых объектов, как раз и призваны обеспечить подобную многоуровневую защиту. Стоит заметить, что на уровни разбиты не только объекты, но и субъекты.
Метками доступа снабжается информация всех уровней — от таблицы до столбца, записи и даже значения полей. Как уже говорилось, все субъекты доступа также снабжаются метками.
Уровни доступа вводятся для проверки на уровне ядра СУБД «Линтер» прав на осуществление чтения/записи информации. Для пользователей системы вводятся следующие уровни доступа:
- RAL (Read Access Level) — уровень доступа. Пользователь может получать информацию, RAL-уровень которой не выше его собственного уровня доступа;
- WAL (Write Access Level) — уровень доверия на понижение уровня конфиденциальности. Пользователь не может вносить информацию с уровнем доступа (RAL-уровнем), более низким, чем данный WAL-уровень пользователя. То есть пользователь не может сделать доступную ему информацию менее конфиденциальной, чем указано в данном параметре.
Для информации:
- RAL — уровень чтения. Пользователь может получать информацию, RAL-уровень которой не выше его собственного RAL-уровня;
- WAL — уровень ценности, или уровень доступа на запись (модификацию, удаление). Пользователь может модифицировать (удалять) информацию, WAL-уровень которой не выше его RAL-уровня.
Все действия по проверке доступа производятся ядром «Линтер» прозрачно для пользователя. Выполняя поисковые операции, ядро СУБД будет принимать во внимание только доступные (видимые) пользователю данные. Вследствие этого у каждого пользователя сложится свое представление об информации, содержащейся не только во всей базе данных, но даже в той или иной ее таблице. Субъекты, обличенные большим доверием, увидят больше информации там, где другие пользователи найдут лишь небольшую часть данных, доступных им. Здесь исключены все возможные, даже косвенные лазейки, так как правило видимости касается и таких конструкций, как агрегатные функции. Так, например, информация о минимальном значении данных какого-либо столбца будет выдана исходя из доступного множества значений этого столбца. То же касается всех агрегатных функций, таких как MIN, MAX, AVG и COUNT.
В связи с тем, что «Линтер» является многопользовательской системой, для предотвращения доступа к данным с незарегистрированной рабочей станции в системной базе хранятся не только данные о пользователях, но и сетевые адреса станций, которым разрешен доступ к информации. Это позволяет не только запретить подключение незарегистрированной рабочей станции, но и предотвратить вход «легального» пользователя с «чужой» рабочей станции. Право на доступ с конкретной сетевой станции может быть предоставлено администратором безопасности. При предоставлении прав могут быть установлены временные ограничения для доступа данного пользователя с предоставляемой сетевой станции.
Как и другие системы, «Линтер» использует внешние устройства постоянного хранения информации для размещения таблиц данных и временных рабочих файлов. Расположение конкретного объекта базы данных внутри системы однозначно идентифицируется «Линтер-именем» устройства. «Линтер-имя» используется при создании новых таблиц или при изменении расположения файлов старых таблиц. Соответствие «Линтер-имен» физическим устройствам описывается специальной системной таблицей. Данная таблица создается на уровне администратора безопасности БД и доступна только ему. Таким образом, система контролирует вывод данных на внешние устройства, запрещая несанкционированное копирование информации.
Для затруднения доступа к данным базы средствами, отличными от средств СУБД «Линтер», в момент, когда ядро системы не работает (не загружено), данные любой таблицы подлежат преобразованию. При загруженном ядре системы файлы таблиц монопольно блокируются и доступны только ядру «Линтер». В файлах индексов шифрация не требуется, ибо сжатие, которому подвергаются ключи таблицы, настолько серьезно, что может потребовать многих месяцев упорного труда для получения реальной информации. Кроме того, страницы всех файлов таблицы снабжены проверочной информацией, не позволяющей незаметно изменить данные, а пароли пользователей, прежде чем записываться в базу данных, подвергаются необратимому преобразованию.
Для предотвращения возможности получения какой-либо информации из оперативной памяти компьютера после завершения сеанса работы в СУБД «Линтер» предусмотрена система очистки оперативной и внешней памяти. Перераспределение внешней памяти возможно в двух случаях: при удалении или модификации таблицы (все или некоторые ее файлы удаляются) и при выгрузке системы (усекаются ее рабочие файлы). В обоих случаях освободившееся дисковое пространство очищается с помощью трехкратной записи маскирующей информации. Во время работы система «Линтер» отслеживает занятое ею место в оперативной памяти. При выгрузке СУБД обнуляет весь отрезок оперативной памяти, который она занимала.
Для контроля доступа пользователей к данным и для ликвидации ошибок или противоречий в структуре защиты базы данных служит подсистема регистрации событий. Данная подсистема является неотъемлемой частью СЗИ НСД СУБД «Линтер». Она позволяет регистрировать следующие события: включение механизмов идентификации и аутентификации, запросы на доступ к ресурсам базы данных, создание и уничтожение объектов, действия по изменению правил разграничения доступа, все попытки доступа к данным и действия администратора базы данных. Целостность СЗИ НСД в «Линтер» эквивалентна целостности программного кода ядра системы. Для проверки целостности системы применяется утилита подсчета контрольных сумм, которая создает на выходе файл, содержащий контрольные суммы проверяемых файлов. Целостность системы считается подтвержденной в том случае, когда результирующие контрольные суммы совпали с контрольными суммами, приведенными в документации. Такая проверка выполняется перед каждым запуском ядра СУБД.
Чтобы исключить любую возможность случайной потери данных (возможно, накопленных в БД за многие годы), технологический процесс эксплуатации информационной системы должен предусматривать регулярное создание резервных копий полных или наиболее важных частей баз данных, по крайней мере, в двух экземплярах на отдельных магнитных носителях. Для этих целей в СУБД «Линтер» предусмотрена программа архивации и восстановления БД, предназначенная для полного или выборочного сохранения данных с целью последующего восстановления информации, потерянной в результате технических отказов информационной системы (например, после сбоев электропитания или оборудования).
К сожалению, в рамках журнальной статьи невозможно познакомить читателей со всеми возможностями СУБД «Линтер». Желающие подробнее ознакомиться с системой могут обратиться к ее разработчикам — фирме «Релэкс» (http://www.relex.ru).
В заключение хочется сказать, что, конечно, защита данных требует дополнительных расходов со стороны пользователя и вам самим придется решать, насколько они оправдают себя. Главное — помнить о том, какие последствия будет иметь для вас потеря или разглашение конфиденциальной информации.
КомпьютерПресс 8'1999
