Системы паролей в СУБД. Механизм ролей

Некоторые СУБД (Oracle, Sybase) используют собственную систему паролей, в других (Ingres, Informix) применяется идентификатор пользователя и его пароль из операционной системы.

Для современных баз данных с большим количеством поль­зователей актуальна проблема их объединения в группы. Тради­ционно применяются два способа определения групп пользова­телей:

• один и тот же идентификатор используется для доступа к базе данных целой группы физических лиц (например, со­трудников одного отдела). Это упрощает задачу админист­ратора базы данных, так как достаточно один раз устано­вить привилегии для этого «обобщенного» пользователя. Однако такой способ в основном предполагает разрешение на просмотр, быть может, на включение, но ни в коем случае — на удаление и обновление. Как только идентифика­тор (и пароль) становится известен большому числу людей, возникает опасность несанкционированного доступа к дан­ным посторонних лиц;

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

Современные СУБД позволяют исправить эти неудобства, предлагая третий способ администрирования (Ingres, Informix). Суть его состоит в поддержке, помимо идентификатора поль­зователя, еще и идентификатора группы пользователей. Каж­дый пользователь, кроме собственного идентификатора, имеет также идентификатор группы, к которой он принадлежит. Чаще всего группа пользователей соответствует структурному подразделению организации, например отделу. Привилегии ус­танавливаются не только для отдельных пользователей, но и для их групп.

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

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

Так, в СУБД Ingres это решение обеспечивается механизмом ролей (role). Роль представляет собой именованный объект, хранящийся в базе данных. Роль связывается с конкретной при­кладной программой для придания последней привилегий досту­па к базам данных, таблицам, представлениям и процедурам базы данных. Роль создается и удаляется администратором базы данных, ей может быть придан определенный пароль. Как толь­ко роль создана, ей можно предоставить привилегии доступа к объектам базы данных.

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

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

предоставляет новой роли привилегии на выполнение операций выбора и обновления таблицы Заработная плата. Когда поль­зователь Петров запускает программу Контроль заработной платы, то она получает привилегии роли Обновить заработную плату. Тем самым данный пользователь, сам не обладая приви­легиями на обновление таблицы, тем не менее может выполнить эту операцию, но только запустив прикладную программу. Она же, в свою очередь, должна играть определенную роль, которой приданы соответствующие привилегии доступа к таблице.

Многоуровневая защита

Выше речь шла о реализациях схемы безопасности, которые ограничиваются схемой «данные — владелец». В них пользователь, работающий с базой данных, является владельцем некоторых ее объектов, а для доступа к другим объектам должен получить привилегии. Он может получить статус пользователя СУБД и некоторые привилегии доступа к объектам БД, войти в группу пользователей и получить соответствующие привилегии доступа, получить права на запуск некоторых прикладных про­грамм. Это — так называемый добровольный или дискрецион­ный контроль доступа (discretionary access control). Называется он так потому, что владелец данных по собственному усмотре­нию ограничивает круг пользователей, имеющих доступ к дан­ным, которыми он владеет.

Несмотря на то, что в целом этот метод обеспечивает безо­пасность данных, современные информационные системы тре­буют другую, более изощренную схему безопасности — обяза­тельный или принудительный контроль доступа (mandatory access control). Он основан на отказе от понятия владельца дан­ных и опирается на так называемые метки безопасности (security abels), которые присваиваются данным при их создании. Каждая из меток соответствует некоторому уровню безопасности. Метки служат для классификации данных по уровням. Например, для правительственных и коммерческих организаций такая классификация выглядит следующим образом (рис. 8.6).

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

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

Защита информации в сетях