Принципы защиты от несанкционированного доступа пользователей к объектам баз данных и сервисам СУБД

Защита от несанкционированного доступа играет наиболее важную роль в обеспечении конфиденциальности информации. Это следует из определения конфиденциальности как свойства информации — быть известной только допущенным и прошедшим проверку (авторизованным) пользователям. Несанкционированным является доступ нелегальных и неавторизованных пользователей к информации или сервисам программной системы; результатом несанкционированного доступа является компрометация конфиденциальности информации.

В SQL Server 2005 реализована дискреционная модель управления доступом. В дискреционной модели все сущности системы подразделяются на субъекты доступа и объекты доступа. Правила доступа описываются в виде троек <субъект, объект, тип доступах

Субъектами доступа в SQL Server являются учетные записи и пользователи БД.

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

Учетные записи SQL Server 2005 хранятся в системной БД Master, в таблице syslogins. Каждая строка таблицы соответствует одной учетной записи. Вместо паролей в таблицу записываются их хеш-образы. При прохождении идентификации и аутентификации стандартными средствами SQL Server 2005 СУБД получает имя и пароль текущего пользователя, преобразует пароль в хешированное значение и ищет запись в таблице syslogins, где поля name и password совпадают с текущим именем и хешированным паролем соответственно. Если поиск дает положительный результат, то идентификация и аутентификация считаются пройденными.

Помимо указанного способа, SQL Server поддерживает аутентификацию с использованием учетной записи домена Windows NT. Непосредственная аутентификация пользователя происходит в домене Windows NT при входе в систему, после чего можно в любое время устанавливать доверительное соединение с сервером СУБД — соединение без дополнительных проверок имени и пароля.

Учетные записи Windows NT находятся в специальном хранилище системы безопасности домена, существующей отдельно от SQL Server. Каждая учетная запись имеет уникальный идентификатор (login ID), он же идентификатор безопасности (SID). Во время регистрации в домене операционная система по введенным имени и паролю находит SID учетной записи и с его помощью организует доступ пользователя ко всем ресурсам компьютера и сети. Чтобы пользователь домена мог соединяться с SQL Server, его SID должен быть предварительно сохранен в системной таблице syslogins. При этом сохраняется именно SID: имя, пароль и прочие сведения не копируются из хранилища учетных записей домена. Во время установки соединения серверу СУБД передается только SID текущей учетной записи Windows NT с клиентской рабочей станции; сервер ищет соответствующую строку в таблице syslogins, и, если находит, устанавливает соединение.

Применение доверительного соединения обладает рядом преимуществ по сравнению с использованием внутренних учетных записей SQL Server. Во-первых, вход пользователя в различные системы осуществляется под одной парой «имя—пароль», достаточно запомнить именно ее, чтобы свободно работать как в домене Windows, так и в СУБД. Во-вторых, повышается уровень защищенности паролей. При аутентификации в режиме Windows NT пароли по сети не передаются, что исключает возможность их перехвата. Кроме того, хеш-образы паролей Windows NT вскрываются гораздо труднее, чем хеши паролей SQL Server.

Однако аутентификация с использованием учетных записей SQL Server может оказаться полезной и даже неизбежной, если администрированием домена и СУБД занимаются разные люди, которые испытывают трудности при согласовании своих действий. Внутренняя аутентификация SQL Server позволяет разделить эти задачи, сделать администрирование СУБД независимым от администрирования операционной системы. Кроме того, аутентификация в режиме Windows NT невозможна для пользователей, работающих под управлением операционных систем Unix, Novell NetWare. Невозможна она и при подключении к SQL Server через Интернет.

Перечисленные способы аутентификации не следует путать с режимами аутентификации, которых в СУБД SQL Server тоже два.

1. Режим смешанной аутентификации. Работая в этом режиме, SQL Server поддерживает оба метода аутентификации. Если пользователь не имеет учетной записи в Windows NT, он не получит доступа к серверу автоматически, но у него есть возможность зайти под учетной записью SQL Server.

2. Режим аутентификации Windows. В этом режиме доступ предоставляется только пользователям, зарегистрированным в домене. Этот режим не удобен для пользователей операционных систем, несовместимых с Windows NT, однако он более защищен по сравнению с предыдущим.

Невозможно сконфигурировать систему безопасности SQL Server таким образом, чтобы применялись только внутренние учетные записи SQL Server.

Каждая учетная запись наделяется правами на установку соединения с сервером, на просмотр списка имеющихся на сервере БД, на отображенной на пользователя той или иной БД.

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

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

К числу типов доступа пользователей к объектам БД относятся:

— добавление, удаление, модификация и выборка строк из таблицы, представления;

— запуск хранимой процедуры;

— создание, модификация и удаление объектов БД;

— выполнение некоторого набора команд SQL.

Из сказанного можно заключить, что фактически управление доступом в СУБД SQL Server осуществляется на двух уровнях.

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

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

Что касается назначения прав доступа, традиционным способом здесь является назначение их субъекту «напрямую»: субъект S наделяется правами R к объекту О. Однако возможны ситуации, когда целая группа субъектов должна получить множество одинаковых прав. Чтобы избежать непосредственного назначения одинаковых прав каждому субъекту, целесообразно использовать механизм ролей.

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

Различают серверные роли, используемые для группирования учетных записей, и роли БД — для группирования пользователей БД. Набор серверных ролей в SQL Server строго фиксирован. Не существует никаких способов добавить новую серверную роль, удалить существующую или перезадать разрешения доступа для имеющейся серверной роли. Каждой роли соответствуют свои административные права.

Типичными для СУБД являются такие серверные роли, как системный администратор и администратор безопасности. Системный администратор наделяется абсолютными привилегиями по администрированию сервера, администратор безопасности — правами создания, обновления и удаления учетных записей, включения учетных записей в серверные роли, назначения прав доступа на уровне СУБД.

На уровне БД также имеется администратор безопасности. Он управляет пользователями БД, ролями БД, правами доступа пользователей к объектам БД. Абсолютными правами доступа на уровне БД обладает владелец БД.

Управление правами доступа включает разрешение, запрещение и неявное отклонение доступа.

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

Запрещение доступа пользователя (роли) к объекту гарантирует, что пользователь (роль) никакими средствами не получит возможность выполнять запрещенные операции над данным объектом. Если некоторому пользователю Userl запретить выборку данных из таблицы Tablet, то он не сможет ее производить, даже если он включен в роль, которой эта выборка разрешается. Запрещение прав доступа может каскадироваться. Допустим, имеется пользователь Userl, которому было дано некоторое разрешение доступа, и который передавал это разрешение пользователям User2,..., UserN. При замене этого разрешения на данный запрет с применением каскадирования запрещение будет распространено как на Userl, так и на User2,..., UserN. Каскадирование не является обязательным, но в некоторых случаях может оказаться полезным.

Неявное отклонение доступа является своего рода «средним состоянием», когда отсутствует явное разрешение или явное запрещение. Пользователь, которому явно не запрещен и не разрешен доступ к объекту, может получить (или потерять) его через членство в роли. В этом заключается принципиальная разница между неявным отклонением и запрещением: запрещение не может быть преодолено через участие в роли. Неявное отклонение, как и запрещение, может каскадироваться.