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

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

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

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

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

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

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

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

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

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

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

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