Управление доступом к данным

Основные концепции

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

1. Предприятие является собственником любой служебной информации, полученной его подразделениями или служащими.

2. Подразделение или служащий является владельцем полученной им информации и может использовать её в интересах предприятия без ограничений.

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

4. Служащий имеет право выполнять те и только те манипуляции доступными сведениями, которые обусловлены его служебными обязанностями.

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

· порядок регистрации и обработки входных документов (счетов, накладных, заказов и т.д.);

· форматы и порядок ведения внутренней документации (журналов хозяйственных операций, складских ведомостей, регистрационных книг и т.п.);

· порядок обмена информацией между ее владельцами.

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

Пользователем в этом контексте является зарегистрированный в системном каталоге идентификатор (user’s ID). Любая операция в БД выполняется системой от имени определённого ID.

Под привилегией понимается право пользователя выполнять определённое действие с определённым объектом.

Подходы к обеспечению безопасности

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

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

Обязательный подход заключается в том, что каждому объекту защиты присваивается определенный уровень классификации, а каждому пользователю – уровень допуска с теми же градациями. Эти уровни образуют иерархии. Например, особой важности > совершенно секретно > секретно > для служебного пользования > открыто. Теперь можно сформулировать два очень простых (и жестких) правила безопасности:

· пользователь i имеет доступ к объекту j, только если его уровень допуска больше или равен уровню классификации объекта j;

· пользователь i может модифицировать объект j, только если его уровень допуска равен уровню классификации объекта j.

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

Обязательный подход используется специальными системами, предназначенными для государственных, военных и других организаций с жёсткой структурой. Более подробные сведения о нём можно найти в [1, гл.16].

Основные понятия избирательного подхода

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

· пользователь – системный ID, от имени которого СУБД выполняет определенные действия над определенными объектами;

· объект защиты – часть БД, на которую распространяется действие конкретного правила безопасности; это может быть группа отношений, отдельное отношение, подмножества атрибутов и т.д.;

· привилегия – действие над объектом защиты, которое может быть совершено от имени конкретного ID.

Информация о привилегиях ID сохраняется в системном каталоге. Она используется системой для принятия решения о выполнении запрошенных ID операций над данными. При этом действует принцип: запрещено всё, что не разрешено явно.

Выделяют два типа привилегий:

· системные привилегии – права на создание и модификацию объектов СБД (пользователей, именованных отношений, правил и т.п.);

· объектные привилегии – права на использование объектов в операциях манипулирования данными.

Владельцем базы данных является АБД. Ему предоставлены все системные и объектные привилегии. В частности, он имеет право регистрации новых пользователей и предоставления им привилегий, как системных, так и объектных.

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

Привилегия входа

Минимальной системной привилегией является право подключения к СБД – привилегия входа. Она должна быть предоставлена каждому служащему, который в силу своих служебных обязанностей имеет такое право. Для того чтобы предоставить эту привилегию, АБД может ввести следующую команду:

GRANT CONNECT TO user’s_ID IDENTIFIERED BY пароль;

где user’s_ID – системное имя пользователя;

пароль – в общем случае процедура установления личности пользователя.

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

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

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

Команда регистрации пользователя с системным именем Иванов и паролем ‘Иван’ может быть такой:

GRANT CONNECT TO Иванов IDENTIFIERED BY ‘Иван’;

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

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

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

Защита «вопрос–ответ». Более сложный вариант защиты входа может быть таким. Владелец ID вводит при регистрации серию вопросов вместе с ответами. Вопросы имеют личный характер, поэтому правильные ответы на них невозможно угадать. Например:

“На какую школьную кличку отзывается Ваш племянник?”

«Где родилась Ваша бабушка?»

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

Предопределённый алгоритм. Если потенциальный злоумышленник может подключиться к коммуникационной линии, связывающей компьютер-клиент с сервером, то для защиты входа можно использовать предопределенный алгоритм, известный владельцу ID и системе. При попытке входа система предъявляет пользователю случайное число. Пользователь должен выполнить нужные преобразования и ввести результат. Посторонний наблюдатель на линии может увидеть только исходное и конечное числа.

Идентификация терминала. Если имеется возможность подключения к системе не только с одного из системных терминалов, но и «со стороны», то желательно предусмотреть автоматическую идентификацию терминала. Если терминал не известен системе или пытающийся подключиться ID не имеет права использовать этот терминал, то вход не разрешается.

Здесь перечислены наиболее примитивные и широко распространённые варианты защиты входа. В большинстве коммерческих СУБД используются именно они и этого вполне достаточно.

Правила безопасности

Первоначально все привилегии принадлежат Администратору базы данных. Он может передать некоторые из них другим пользователям. Для этого нужно сообщить системе, какая именно привилегия, для какого объекта и какому ID предоставляется. Система должна сохранить эти сведения. Тогда при обработке запроса пользователя она сможет проверить, имеет ли запрашивающий ID нужную привилегию.

Сведения о привилегиях пользователей составляют содержание специальных объектов БД – правил безопасности. Существует два типа правил безопасности – системные и объектные. Они определяют соответственно системные и объектные привилегии. Привилегия создания системных правил безопасности принадлежит исключительно АБД. Пользователи, имеющие привилегии создания объектов, автоматически наделяются привилегией создания объектных правил безопасности.[1]

Правило безопасности, как любой объект БД, может быть уничтожено его владельцем. С концептуальной точки зрения правило должно удаляться автоматически, если удалён связанный с ним объект защиты или все ID, для которых оно определено. Для явной отмены следует использовать специальную директиву, например:

DESTROY SECURITY RULE имя_правила;

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

В двух следующих подразделах уточняется понятие правила безопасности в РБД. Для этой цели используется синтаксис определений, предложенный К. Дейтом [1]. Все приводимые примеры относятся к «учебной» БД «Поставщик–Деталь–Изделие» (см. приложение А).