Аутентификация пользователей

Пользователи

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

На практике ограничения на имена идентификаторов зависят от реализации СУБД. Стандарт SQL1 позволяет идентификатору пользователя иметь длину до восемнадцати символов и требует, чтобы он был допустимым SQL-именем. В некоторых СУБД для мэйнфреймов длина идентификаторов ограничивалась восемью символами. В Sybase и SQL Server идентификатор пользователя может иметь до 30 символов. Если важна переносимость, то лучше всего, чтобы у идентификатора пользователя было не более восьми символов. Следует иметь в виду также и то, что всем пользователям в одном определенном отделе можно присвоить один и тот же идентификатор, так как все они имеют идентичные привилегии.

В стандарте ANSI/ISO вместо термина “идентификатор пользователя” (user-id) употребляется термин идентификатор прав доступа (authorization-id), и он встречается иногда в документации по SQL. С технической точки зрения второй термин является более правильным, так как в действительности идентификатор определяет права или привилегии. Бывают ситуации, когда имеет смысл присвоить нескольким пользователям одинаковый идентификатор. В других ситуациях один пользователь может пользоваться двумя или тремя различными идентификаторами. В промышленной базе данных идентификатор прав доступа может относиться к программам и группам программ, а не к отдельным людям.

Безопасность базы данных обеспечивается с помощью идентификаторов пользователей. Однако в стандарте ничего не говорится о механизме связи идентификатора пользователя с инструкциями SQL. Например, на сервере баз данных может существовать программа генерации отчетов, запланированная на выполнение каждый вечер, каков в этом случае идентификатор, если нет самого пользователя? Наконец, как обрабатываются запросы к базе данных по сети, если на локальном компьютере у пользователя может быть один идентификатор, а на удаленном компьютере – другой?

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

Как правило, в начале сеанса необходимо ввести как идентификатор пользователя, так и связанный с ним пароль. Пароль служит для подтверждения того, что пользователь действительно имеет право работать под введенным идентификатором. Идентификаторы и пароли применяются в большинстве реляционных СУБД, однако способ, которым пользователь вводит свой идентификатор и пароль, меняется в зависимости от СУБД.

В некоторых СУБД реализована своя собственная система безопасности с идентификаторами пользователей и паролями. Например, когда в СУБД ORACLE вы работаете с интерактивной SQL-утилитой, которая называется SQL*Plus, вы вводите имя пользователя и соответствующий пароль.