Дейт К. Д27 Руководство по реляционной субд db2/ Пер с англ и предисл. М. Р. Когаловского

Вид материала

Руководство

Содержание Глава 9 безопасность и санкционирование доступа 9.1. введение 9.2. Идентификация пользователей 9.3. Представления и безопасность 9.4. Предложения grant и revoke Предложение GRANT Предложение REVOKE Факультативная возможность GRANT Пакетированные (административные) привилегии Ответы к некоторым упражнениям

Подобный материал:

• Рич Р. К. Политология. Методы исследования: Пер с англ. / Предисл. А. К. Соколова, 6313.17kb.
• Рич Р. К. Политология. Методы исследования: Пер с англ. / Предисл. А. К. Соколова, 6313.29kb.
• Сорокин П. А. С 65 Человек. Цивилизация. Общество / Общ ред., сост и предисл., 11452.51kb.
• The guilford press, 6075kb.
• The guilford press, 6075.4kb.
• Курс лекций "Базы данных и субд" Ульянов В. С. Лекция. Целостная часть реляционной, 213.79kb.
• Дэвид Дайчес, 1633.42kb.
• Mathematics and the search for knowledge morris kline, 498.28kb.
• Лекция №1: Стандарты языка sql, 1420.56kb.
• Курс лекций "Базы данных и субд" Ульянов В. С. Лекция. Манипулирование реляционными, 276.31kb.

ГЛАВА 9

БЕЗОПАСНОСТЬ И САНКЦИОНИРОВАНИЕ ДОСТУПА

9.1. ВВЕДЕНИЕ

В контексте баз данных термин «безопасность» означает защиту данных в базе данных (или в базах данных) от несанкционированного раскрытия, изменения или уничтожения. По степени безопасности, которую она обеспечивает, система DB2 в значительной мере превосходит возможности большинства известных систем. Единица данных, которая может индивидуально защищаться, варьируется от целой таблицы до конкретного значения данных, занимающего позицию на пересечении конкретных строки и столбца в такой таблице. Для некоторых операций защищаемая единица данных на самом деле может быть больше, чем одна таблица. Например, для команд START и STOP, выдаваемых оператором с консоли, такой единицей является вся база данных. Данный пользователь может иметь различные привилегии доступа к различным объектам, например привилегии на выполнение только операций SELECT над одной таблицей, операций SELECT и UPDATE — над другой и т. д. Различные пользователи также могут, конечно, иметь различные привилегии доступа к одному и тому же объекту. Например, пользователь А может иметь только привилегии на выполнение операций SELECT над заданной таблицей, в то время как другой пользователь В мог бы одновременно иметь привилегии на выполнение операций как SELECT, так и UPDATE над той же самой таблицей.

Для обеспечения безопасности в системе DB2 имеются две более или менее независимые возможности: 1) механизм представлений, который, как уже упоминалось в конце предыдущей главы, может использоваться для скрытия засекреченных данных от пользователей, не обладающих правом доступа, и 2) подсистема санкционирования доступа, которая позволяет имеющим определенные привилегии пользователям избирательно и динамически предоставлять эти привилегии другим пользователям и впоследствии отменять эти привилегии, если потребуется. Механизм представлений рассматривается в разделе 9 3, а подсистема санкционирования доступа (предложения GRANT — предоставить и REVOKE — отменить) — в разделе 9.4.

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

а) Результаты таких решений должны стать известными системе (это делается посредством предложений GRANT и REVOKE) и должны запоминаться системой (это делается путем сохранения их в каталоге в форме ограничений санкционирования доступа).

б) Должны иметься средства, позволяющие проверять, удовлетворяет ли данный запрос на доступ соответствующим ограничениям санкционирования доступа. Под «запросом на доступ» здесь понимается комбинация запрашиваемой операции, целевого объекта и запрашивающего пользователя. Большинство таких проверок осуществляется генератором планов прикладных задач во время связывания первоначального запроса (см. раздел 14.4).

в) Система должна быть способна решать, какие ограничения применимы к данному запросу, и поэтому распознавать источник этого запроса, т. е. распознавать, от какого конкретно пользователя исходит данный конкретный запрос. Поэтому, прежде чем перейти к обсуждению самих по себе механизма представлений и подсистемы санкционирования доступа, следует сначала что-либо сказать об идентификации пользователей в системе DB2 (раздел 9.2).

9.2. ИДЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ

Пользователи известны системе DB2 по их «идентификаторам санкционирования доступа» (для краткости, ИД санкционирования). ИД санкционирования — это то, что называлось в предшествующих главах «известным системе именем» пользователя. Если Вы — законный пользователь системы, некоторое ответственное лицо в Вашей организации, вероятно, администратор системы (см. ниже раздел 9.4), назначит для Вашего конкретного использования некоторый ИД санкционирования. На Вас возлагается обязанность идентифицировать себя с помощью этого ИД при предъявлении пароля системе. Заметим, что Вы при этом не предъявляете пароль непосредственно самой системе DB2. Пароль предъявляется соответствующей подсистеме MVS (IMS, CICS или TSO—вспомните из главы 1, что каждая прикладная задача DB2 должна исполняться под управлением в точности одной из этих трех подсистем). Эта подсистема передаст затем Ваш ИД системе DB2, когда будет передавать ей управление. Таким образом, проверка достоверности или подтверждение подлинности Вашего ИД осуществляется каждый раз соответствующей подсистемой, а не DB2. Если о каком-либо пользовательском запросе системе DB2 сообщается, что он исходит от пользователя, скажем, xyz, она предполагает, что это действительно так.

Рассмотрение подробностей процедуры предъявления пароля (а следовательно, информации о том, как в точности специфицируется ИД санкционирования) для каждого из возможных вариантов операционной обстановки выходит за рамки данной книги.

9.3. ПРЕДСТАВЛЕНИЯ И БЕЗОПАСНОСТЬ

Чтобы проиллюстрировать использование представлений для целей безопасности, приведем ряд примеров, основанных (по большей части) опять-таки на базе данных поставщиков и деталей.

1. Пользователю разрешен доступ к полным записям поставщиков, но лишь для поставщиков, находящихся в Париже:

CREATE VIEW ПАРИЖСКИЕ_ПОСТАВЩИКИ

AS SELECT НОМЕР_ПОСТАВЩИКА, ФАМИЛИЯ,

СОСТОЯНИЕ, ГОРОД

FROM S

WHERE ГОРОД = 'Париж';

Пользователи этого представления видят «горизонтальное подмножество» (или, точнее, подмножество строк, подмножество, зависящее от значений) базовой таблицы S.

2. Пользователю разрешен доступ ко всем записям поставщиков, но не к рейтингам поставщиков (значение поля СОСТОЯНИЕ):

CREATE VIEW СКРЫТОЕ_СОСТОЯНИЕ

AS SELECT НОМЕР_ПОСТАВЩИКА, ФАМИЛИЯ,

ГОРОД

FROM S;

Пользователи этого представления видят «вертикальное подмножество» (или, точнее, подмножество столбцов, независимое от значений) подмножество базовой таблицы S.

3. Пользователю разрешен доступ к записям поставщиков только для поставщиков, находящихся в Париже, но не к рейтингам поставщиков:

CREATE VIEW ПАРИЖСКИЕ_БЕЗ_РЕЙТИНГОВ

AS SELECT НОМЕР_ПОСТАВЩИКА, ФАМИЛИЯ, ГОРОД

FROM S

WHERE ГОРОД = 'Париж';

Пользователи этого представления видят подмножество строк и столбцов базовой таблицы S.

4. Пользователю разрешен доступ к записям каталога, т. е. к строкам таблицы SYSTABLES, только для таблиц, созданных этим пользователем:

CREATE VIEW МОИ_ТАБЛИЦЫ

AS SELECT *

FROM SYSIBM.SYSTABLES

WHERE CREATOR = USER;

Ключевое слово USER (пользователь) обозначает системную переменную, значение которой представляет собой ИД санкционирования. Оно может входить во фразу SELECT, во фразу WHERE, во фразу SET предложения UPDATE, либо как вставляемое значение — в предложение INSERT. Идентификатор санкционирования в запросе — это ИД санкционирования для пользователя, исполняющего фразы SELECT или WHERE (либо предложения UPDATE или INSERT), в которые он входит. В приведенном примере, следовательно, он представляет не ИД пользователя, который создает это представление, а ИД пользователя, который использует это представление. Если, например, пользователь xyz издает предложение:

SELECT *

FROM МОИ_ТАБЛИЦЫ;

то DB2, а фактически генератор планов прикладных задач, по существу, преобразует это предложение в следующее:

SELECT *

FROM SYSIBM.SYSTABLES

WHERE CREATOR = 'xyz';

Аналогично представлению из приведенного выше первого примера, это представление является «горизонтальным подмножеством» лежащей в основе базовой таблицы. Однако в данном примере различные пользователи видят здесь различные подмножества. Фактически эти подмножества не пересекаются ни для каких двух пользователей. Такие подмножества иногда называются контекстно-зависимыми.

5. Пользователю разрешен доступ к средним объемам поставок по поставщикам, но не к каким-либо индивидуальным объемам поставок:

CREATE VIEW AVG (НОМЕР_ПОСТАВЩИКА, СРЕДНИЙ_ОБЪЕМ)

AS SELECT НОМЕР_ПОСТАВЩИКА, AVG (КОЛИЧЕСТВО)

FROM SP

GROUP BY НОМЕР_ПОСТАВЩИКА;

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

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

Как показывают приведенные примеры, механизм представлений системы DB2 «задаром» обеспечивает очень важные средства безопасности — «задаром» во всяком случае потому, что механизм представлений включен в систему для иных целей, как указывалось в главе 8. Более того, многие проверки полномочий доступа, даже проверки, зависимые от значений, могут осуществляться на стадии компиляции (во время связывания), а не на стадии исполнения, что обеспечивает существенный выигрыш производительности. Однако подход к безопасности, основанный на представлениях, иногда оказывается несколько тяжеловесным, в частности, если некоторому конкретному пользователю необходимы различные привилегии доступа к различным подмножествам одной и той же таблицы в одно и то же время. Рассмотрим следующий пример. Предположим, что данному пользователю разрешена выборка (операция SELECT) рейтингов, т. е. значений состояния, для всех поставщиков, а обновлять их (операция UPDATE) разрешается только для поставщиков из Парижа. Тогда потребуется два следующих представления:

CREATE	VIEW	ВСЕ_РЕЙТИНГИ	CREATE	VIEW	ПАРИЖСКИЕ_ РЕЙТИНГИ
AS	SELECT	НОМЕР_ ПОСТАВЩИКА, СОСТОЯНИЕ	AS	SELECT	НОМЕР_ ПОСТАВЩИКА, СОСТОЯНИЕ
	FROM	S;		FROM	S
				WHERE	ГОРОД=' ПАРИЖ';

При этом операции SELECT могут быть адресованы представлению ВСЕ_РЕЙТИНГИ, а операции обновления — только представлению ПАРИЖСКИЕ_РЕЙТИНГИ. В связи с этим программирование становится довольно невразумительным. В этом можно, например, убедиться, рассматривая структуру программы, которая просматривает и печатает рейтинги всех поставщиков, а также обновляет некоторые из них (рейтинги поставщиков из Парижа), когда это требуется.

Другой недостаток связан с тем, что при вставке (операция INSERT) или обновлении (операция UPDATE) записей при помощи представления система DB2 не требует, чтобы новая или обновленная запись удовлетворяла предикату, определяющему это представление. Такое требование можно ввести с помощью спецификации CHECK, но эта возможность, как пояснялось в главе 8, не всегда может быть использована и во всяком случае это факультативная возможность — пользователь не обязан ее специфицировать. Таким образом, приведенное выше представление ПАРИЖСКИЕ_ПОСТАВЩИКИ, например, может не дать пользователю возможности видеть поставщиков, которые находятся не в Париже, но при отсутствии спецификации CHECK оно не может помешать пользователю создать такого поставщика или переместить какого-либо существующего парижского поставщика в некоторый другой город. Такая операция, конечно, приведет к тому, что новая или обновленная запись немедленно исчезнет из этого представления, но она однако же появится в соответствующей базовой таблице.

9.4. ПРЕДЛОЖЕНИЯ GRANT И REVOKE

Рассмотренный в разделе 9.3 механизм представлений концептуально позволяет различными способами подразделить базу данных на подмножества таким образом, чтобы секретные сведения могли быть скрыты от пользователя, не обладающего правом доступа. Однако в нем не предусматривается спецификация тех операций, которые разрешается выполнять над этими подмножествами полномочному пользователю. Эту функцию выполняют предложения GRANT (предоставить) и REVOKE (отменить) языка SQL, которые обсуждаются ниже.

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

SELECT *

FROM S;

пользователь должен обладать привилегией на выполнение операции SELECT над таблицей S. В системе DB2 предусматривается широкий диапазон привилегий. Вообще говоря, каждая привилегия попадает, однако, в один из следующих классов:

а) привилегии на таблицы., связанные с такими операциями, как SELECT, которые выполняются над таблицами — как над базовыми таблицами, так и над представлениями;

б) привилегии на планы, которые имеют отношение к таким вещам, как полномочия на выполнение заданного плана прикладной задачи;

в) привилегии на базу данных, которые касаются таких операций, как создание таблицы в конкретной базе данных;

г) привилегии на использование, которые связаны с использованием определенных объектов среды хранения, а именно: с группами хранения, табличными пространствами и буферными пулами (см. главу 13);

и, наконец,

д) системные привилегии, имеющие отношение к некоторым общесистемным операциям, таким, как операция создания новой базы данных.

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

Итак, когда система DB2 впервые устанавливается, некоторая часть процесса установки требует назначения одного особо привилегированного пользователя системным администратором этой установленной системы. Для DB2 системный администратор идентифицируется идентификатором санкционирования доступа, точно так же, конечно, как и все другие пользователи. Этот пользователь, который автоматически получает привилегию SYSADM, становится ответственным за общее управление системой в течение всей продолжительности ее жизни. Например, в обязанности системного администратора входит текущий контроль за функционированием системы, сбор статистики о ее производительности и учетной информации. Но мы обсуждаем здесь лишь вопросы безопасности. Поэтому вернемся к главной теме обсуждения. Сначала имеется, таким образом, один пользователь, который может делать все, в частности, он или она может предоставлять привилегии другим пользователям, и никто иной не может делать вообще все.

Отметим, между прочим, что, хотя системный администратор является, конечно, обладателем привилегии SYSADM, не все обладатели привилегии SYSADM являются системными администраторами. Привилегия SYSADM может быть в дальнейшем предоставлена также другим пользователям, но эта привилегия может быть впоследствии снова отменена. Для системного администратора привилегия SYSADM никогда не может быть отменена¹⁸.

Далее, пользователь, который создает некоторый объект, например базовую таблицу, автоматически получает полные привилегии на этот объект, включая, в частности, привилегию предоставления таких привилегий другому пользователю. Конечно, «полные привилегии» не включают здесь привилегий, которые не имеют смысла. Если, например, пользователь U обладает только привилегией на выполнение операции SELECT над базовой таблицей Т и создает некоторое представление V, которое основано на Т, то U, естественно, не получает привилегии на выполнение операции UPDATE над V. Подобным же образом, если U создает представление С, которое является соединением таблиц А и В, то U не получает привилегии на выполнение операции UPDATE над С, независимо от того, обладал ли он такими привилегиями для таблиц А и В, поскольку система DB2 не допускает каких-либо операций обновления по отношению к представлению, являющемуся соединением.


Предложение GRANT

Предоставление привилегий осуществляется с помощью предложения GRANT (предоставить). Общий формат этого предложения:

GRANT привилегии [ON тип — объектов объекты] ТО пользователи;

где «привилегии» — список, состоящий из одной или более привилегий, разделенных запятыми, либо фраза ALL PRIVILEGES (все привилегии); «пользователи» — это список, включающий один или более идентификаторов санкционирования, разделенных запятыми, либо специальное ключевое слово PUBLIC (общедоступный); «объекты» — это список имен одного или более объектов одного и того же типа, разделенных запятыми; наконец, «тип — объектов» указывает тип этого объекта или этих объектов. Фраза ON не используется, если предоставляемые привилегии являются системными.

Приведем несколько примеров.

Привилегии на таблицы

GRANT SELECT ON TABLE S TO ЧАРЛИ;

GRANT SELECT, UPDATE (СОСТОЯНИЕ, ГОРОД) ON TABLE S

TO ДЖУДИ, ДЖЕК, ДЖОН;

GRANT ALL PRIVILEGES ON TABLE S, P, SP TO УОЛТ, ТЕД;

GRANT SELECT ON TABLE P TO PUBLIC;

GRANT DELETE ON S TO ФИЛ;

Примечание. Если «тип—объектов»—TABLE (таблица), его можно опустить, как показано в последнем примере.

Привилегии на планы:

GRANT EXECUTE ON PLAN ПЛАН1 TO ДЖУДИ;

Привилегии на базу данных:

GRANT CREATETAB ON DATABASE DBX TO ШАРОН;

Пользователю Шарону разрешается создавать таблицы в базе данных DBX. Организация баз данных в системе DB2 обсуждается в главе 13.

Привилегии на использование:

GRANT USE ON TABLESPACE TSE TO КОЛИН;

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

Системные привилегии:

GRANT CREATEDBC ТО ЖАК, МАРИАН;

Пользователям Жаку и Мариан разрешается создавать новые базы данных. Если они будут это делать, то автоматически получат привилегию DBCTRL на эти базы данных (см. в конце данного раздела).

Здесь не ставилась задача в полной мере и исчерпывающим образом рассмотреть все множество привилегий, которые признает система DB2. Однако будут полностью рассмотрены привилегии на таблицы, поскольку они, вероятно, представляют наиболее широкий интерес. К таблицам (как к базовым таблицам, так и к представлениям) относятся следующие привилегии:

SELECT

UPDATE (может относиться к конкретным столбцам)

DELETE

INSERT

Две остальные привилегии относятся только к базовым таблицам:

ALTER (привилегия на исполнение предложения ALTER TABLE над данной

таблицей)

INDEX (привилегия на исполнение предложения CREATE INDEX над данной

таблицей)

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


Предложение REVOKE

Если пользователь U1 предоставляет какую-либо привилегию некоторому другому пользователю U2, то пользователь U1 может впоследствии отменить эту привилегию для пользователя U2. Отмена привилегий осуществляется с помощью предложения REVOKE (отменить), общий формат которого очень похож на формат предложения GRANT:


REVOKE привилегии [ON тип — объектов объекты] FROM пользователи;


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

REVOKE SELECT ON TABLE S FROM ЧАРЛИ;

REVOKE UPDATE ON TABLE S FROM ДЖОН;

REVOKE CREATETAB ON DATABASE DBX FROM НАНСИ, ДЖЕК;

REVOKE SYSADM FROM СЭМ;

Отмена привилегии UPDATE не может относиться к конкретным столбцам.


Факультативная возможность GRANT

Если пользователь U1 имеет полномочия на предоставление привилегии Р другому пользователю U2, то пользователь U1 имеет также полномочия на предоставление привилегии Р пользователю U2 «с возможностью GRANT» (путем спецификации фразы WITH GRANT OPTION в предложении GRANT). Передача таким образом возможности GRANT от пользователя U1 пользователю U2 означает, что U2 теперь в свою очередь имеет полномочия на предоставление привилегии Р некоторому третьему пользователю U3. И, следовательно, U2, конечно, также обладает полномочиями на передачу возможности GRANT с таким же успехом пользователю U3 и т. д. Например:

Пользователь U1:

GRANT SELECT ON TABLE S TO U2 WITH GRANT OPTION;

Пользователь U2:

GRANT SELECT ON TABLE S TO U3 WITH GRANT OPTION;


Пользователь U3:

GRANT SELECT ON TABLE S TO U4 WITH GRANT OPTION;


и т. д. Если пользователь U1 издает теперь предложение:

REVOKE SELECT ON TABLE S FROM U2;

то отмена будет распространяться каскадом, т. е. будут автоматически отменены также передачи привилегий пользователем U2 пользователю U3 и пользователем U3 пользователю U4. Заметим, однако, что из этого не следует, что пользователи U2, U3 и U4 более не имеют привилегии SELECT на таблицу S—они могут помимо этого иметь такие привилегии, полученные от некоторого другого пользователя U5. Когда пользователь U1 издает предложение REVOKE, то фактически аннулируются только привилегии, которые предоставлялись этим пользователем. Рассмотрим, например, следующую последовательность событий.

Пользователь U1 в момент времени t₁:

GRANT SELECT ON TABLE S TO U2 WITH GRANT OPTION;

Пользователь U5 в момент времени t₂:

GRANT SELECT ON TABLE S TO U2 WITH GRANT OPTION;

Пользователь U2 в момент времени t₃:

GRANT SELECT ON TABLE S TO U3;

Пользователь U1 в момент времени t₄:

REVOKE SELECT ON TABLE S FROM U2;


Пусть при этом t₁234. Предложение REVOKE, изданное пользователем U1 в момент времени t₄, фактически не лишает пользователя U2 привилегии на таблицу S, поскольку пользователь U2 получил эту привилегию также от U5 в момент времени t₂. Поскольку далее предложение GRANT пользователя U2 для пользователя U3 было выполнено в момент времени t₃ и t₃> t₂, то, возможно, что это GRANT было привилегией, которая была получена от пользователя U5, а не от U1. Поэтому пользователь U3 также не утрачивает этой привилегии. И если бы в момент t₄ предложение REVOKE издал бы пользователь U5, а не U1, пользователи U2 и U3 также все еще сохранили бы эту привилегию. U2 сохранил бы привилегию, полученную от U1, и GRANT, изданный пользователем U2, мог бы, вероятно, служить для предоставления привилегии, полученной от U1, а не от U5, и пользователь U3 снова не утратил бы привилегию. Предположим, однако, что имела место другая последовательность событий.

Пользователь U1 в момент времени t₁:

GRANT SELECT ON TABLE S TO U2 WITH GRANT OPTION;

Пользователь U2 в момент времени t₂:

GRANT SELECT ON TABLE S TO U3 WITH GRANT OPTION;

Пользователь U5 в момент времени t ₃:

GRANT SELECT ON TABLE S TO U2 WITH GRANT OPTION;

Пользователь U1 в момент времени t₄:

REVOKE SELECT ON TABLE S FROM U2;


Тогда REVOKE пользователя U1 в момент времени t₄ не будет лишать пользователя U3 привилегии SELECT на таблицу S, поскольку пользователь U2 получил эту привилегию также от U5 в момент t₃. Однако, в противоположность предыдущему примеру, U3, утратит привилегию в этот момент времени, поскольку GRANT пользователя U2, возможно, имел дело с привилегией, полученной от пользователя U1.

Возможность GRANT нельзя отменить, не отменяя в то же время привилегии, к которой эта возможность относится.


Пакетированные (административные) привилегии

Для справочных целей завершим этот раздел кратким обзором пяти «пакетированных» привилегий, а именно: SYSADM, DBADM, DBCTRL, DBMAINT, SYSOPR.

— SYSADM

Привилегия SYSADM («системный администратор») позволяет ее обладателю выполнять любую операцию, которую поддерживает система.

— DBADM

Привилегия DBADM («администрирование базой данных»)

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

— DBCTRL

Привилегия DBCTRL («управление базой данных») относительно конкретной базы данных позволяет ее обладателю выполнять любую операцию, которую поддерживает система для этой базы данных, за исключением операций доступа к значениям данных в этой базе данных, т. е. такие обслуживающие операции, как «восстановить базу данных», допускаются, а операции манипулирования данными языка SQL—нет.

— DBMAINT

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

— SYSOPR

Привилегия SYSOPR («системный оператор») позволяет ее обладателю выполнять системные функции оператора консоли, например операции начала и завершения трассировки функционирования системы.

Для конкретной базы данных привилегии категории DBADM включают DBCTRL, а привилегии DBCTRL включают DBMAINT. И конечно же, SYSADM включает привилегии всех других категорий.

9.5. ЗАКЛЮЧЕНИЕ

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

1. Прежде всего, прикладному программисту вообще не требуется каких-либо полномочий для прекомпиляции исходной прикладной программы, а следовательно, для создания модуля запросов к базе данных — DBRM.

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

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

4. Пользователь, издающий команду BIND, обычно должен обладать соответствующими привилегиями для всех предложений SQL в тех DBRM, которые должны связываться (но: см. 14.4).

5. Исполнение программы, обращающейся к какому-либо плану прикладной задачи, требует привилегии EXECUTE (привилегия на планы) для этого плана. Каких-либо привилегий на таблицы и т. п. при этом не требуется. Примечание. Привилегия BIND подразумевает привилегию EXECUTE.

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

Завершим данный раздел следующими двумя наблюдениями.

1. Не имеет никакого смысла обеспечивать в системе управления базами данных широкое множество проверок с целью безопасности, если эти проверки можно обойти. Механизм безопасности системы DB2 был бы почти всегда бесполезным, если можно было бы, например, обращаться к данным DB2 из обычной программы, исполняемой под управлением операционной системы MVS, путем обычных обращений к методу доступа VSAM (напомним из главы 1, что базы данных системы DB2 строятся над наборами данных VSAM). По этой причине DB2 функционирует согласованно с различными сопутствующими ей системами — MVS, TSO, VSAM, IMS, CICS — с тем, чтобы гарантировать безопасность полной системы. В частности, наборы данных VSAM системы DB2 могут быть защищены любым (или всеми) из следующих способов: пароли MVS, пароли метода доступа VSAM, а также с помощью RACF (средства управления доступом к ресурсам)¹⁹. Кроме того, для обеспечения всех стандартных функций управления безопасностью могут использоваться средства безопасности IMS и CICS. Они позволяют, например, ограничивать множество терминалов, с которых могут вызываться конкретные прикладные задачи или команды.

2. Наконец, весь механизм безопасности в системе DB2 необязателен. Если это желательно, его можно исключить во время установки системы. Если это сделано, то, конечно, каждый может делать все. Само собой разумеется, здесь имеется в виду все, что имеет смысл. Например, невозможно все же уничтожить какую-либо таблицу каталога.

упражнения

В следующих упражнениях используется базовая таблица СТАТУС, определенная следующим образом

CREATE TABLE СТАТУС

(ИД_ПОЛЬЗОВАТЕЛЯ CHAR(8),

ПОЛ CHAR(1),

ЧИСЛО_ИЖДИВЕНЦЕВ DECIMAL(2),

ПРОФЕССИЯ CHAR(20),

ЗАРПЛАТА DECIMAL(7),

НАЛОГ DECIMAL(7),

КОНТРОЛЬНЫЙ_КОД DECIMAL(2));

9.1. Запишите предложения SQL, которые представляют:

а) привилегию SELECT на всю таблицу пользователю Форду;

б) привилегию INSERT и DELETE на всю таблицу пользователю Смиту;

в) привилегию SELECT каждому пользователю только на собственную запись этого пользователя;

г) привилегию SELECT на всю таблицу и привилегию UPDATE только на поля ЗАРПЛАТА и НАЛОГ пользователю Нашу;

д) привилегию SELECT только на поля ИД_ПОЛЬЗОВАТЕЛЯ, ЗАРПЛАТА и НАЛОГ пользователю Тодду;

е) привилегию SELECT, как для Тодда, и привилегию UPDATE только на поля ЗАРПЛАТА и НАЛОГ пользователю Уорду;

ж) полные привилегии (SELECT, UPDATE, INSERT, DELETE) только на записи проповедников пользователю Попу;

з) привилегию SELECT, как для Тодда, и привилегию UPDATE только на поля НАЛОГ и КОНТРОЛЬНЫЙ_КОД пользователю Джоунзу;

и) привилегию SELECT на максимальную и минимальную зарплату по классам профессий, но никаких других привилегий, пользователю Кингу;

к) привилегию DROP на данную таблицу пользователю Кларку.

9.2. Для каждого из упражнений 9.1 а)—к) запишите предложения языка SQL, которые отменяют указанные привилегии для заданных пользователей.

9.3. Пусть р предоставляет некоторую привилегию, a Ul, U2, . . ., U8—множество идентификаторов санкционирования. Пусть также Ul и U5 первоначально являются единственными обладателями привилегии р. Предположим далее, что Ul и U5 обладают возможностью GRANT для р. Рассмотрим следующую последовательность событий, предполагая, что все перечисленные предложения GRANT включают спецификацию WITH GRANT OPTION:

Пользователь U1 в момент t1 : GRANT р ТО U2

Пользователь U1 в момент t2 : GRANT р ТО U3

Пользователь U1 в момент t3 : GRANT р ТО U4

Пользователь U2 в момент t4 : GRANT р ТО U6

Пользователь U5 в момент t5 : GRANT р ТО U2

Пользователь U5 в момент t6 : GRANT р ТО U3

Пользователь U5 в момент t7 : GRANT р ТО U6

Пользователь U4 в момент t8 : GRANT p TO U7

Пользователь U1 в момент t9 : REVOKE p FROM U2

Пользователь U1 в момент t10: REVOKE p FROM U4

Пользователь U3 в момент t11 : GRANT p TO U1

Пользователь U1 в момент t12 : REVOKE p FROM U3

Пользователь U3 в момент t13 : GRANT p TO U7

Пользователь U5 в момент t14 : REVOKE p FROM U6

Пользователь U1 в момент t15: GRANT p TO U5

Пользователь U5 в момент t16 : GRANT p TO U8

Пользователь U8 в момент t17 : GRANT p TO U5

Пользователь U1 в момент t18 : GRANT p TO U8

Пользователь U5 в момент t19 : REVOKE p FROM U8

Пользователь U1 в момент t20 : GRANT p TO U3

Кто в конце этой последовательности все еще обладает привилегией р?

ОТВЕТЫ К НЕКОТОРЫМ УПРАЖНЕНИЯМ

9.1.

a) GRANT SELECT ON TABLE СТАТУС ТО ФОРД;

6) GRANT INSERT, DELETE ON TABLE СТАТУС ТО СМИТ;

в) CREATE VIEW МОЯ_ЗАПИСЬ

AS SELECT *

FROM СТАТУС

WHERE ИД_ПОЛЬЗОВАТЕЛЯ = USER;

GRANT SELECT ON TABLE МОЯ_ЗАПИСЬ ТО PUBLIC;

г) GRANT SELECT, UPDATE (ЗАРПЛАТА, НАЛОГ)

ON TABLE СТАТУС ТО НЭШ;

д) CREATE VIEW ИЗН

AS SELECT ИД_ПОЛЬЗОВАТЕЛЯ, ЗАРПЛАТА, НАЛОГ

FROM СТАТУС;

GRANT SELECT ON TABLE ИЗН ТО ТОДД;

е) CREATE VIEW ИЗН

AS SELECT ИД_ПОЛЬЗОВАТЕЛЯ, ЗАРПЛАТА, НАЛОГ

FROM СТАТУС;

GRANT SELECT, UPDATE (ЗАРПЛАТА, НАЛОГ ON TABLE

ИЗН ТО УОРД;

ж) CREATE VIEW ПРОПОВЕДНИКИ

AS SELECT *

FROM СТАТУС

WHERE ПРОФЕССИЯ = 'Проповедник';

GRANT ALL PRIVILEGES ON TABLE ПРОПОВЕДНИКИ ТО ПОП;

Заметим, что спецификация ALL PRIVILEGES (все привилегии) на таблицу обычно включает привилегии ALTER (изменить) и INDEX (индекс), но эти операции не применяются к представлениям.

з) CREATE VIEW ИЗН

AS SELECT ИД_ПОЛЬЗОВАТЕЛЯ, ЗАРПЛАТА, НАЛОГ

FROM СТАТУС;

CREATE VIEW ИНК

AS SELECT ИД_ПОЛЬЗОВАТЕЛЯ, НАЛОГ,

КОНТРОЛЬНЫЙ_КОД

FROM СТАТУС;

GRANT SELECT ON TABLE ИЗН TO ДЖОУНЗ;

GRANT UPDATE (НАЛОГ, КОНТРОЛЬНЫЙ_КОД) ON TABLE ИНК ТО ДЖОУНЗ;

и) CREATE VIEW ГРАНИЦЫ_ЗАРПЛАТЫ (ПРОФЕССИЯ,

МАКС_ЗАРПЛАТА, МИН_ЗАРПЛАТА)

AS SELECT ПРОФЕССИЯ, MAX (ЗАРПЛАТА), MIN

(ЗАРПЛАТА)

FROM СТАТУС

GROUP BY ПРОФЕССИЯ;

GRANT SELECT ON ГРАНИЦЫ_ЗАРПЛАТЫ ТО КИНГ;

к) GRANT SYSADM TO КЛАРК;

Уничтожение таблицы не является привилегией, предоставляемой в явном виде. Таблица может быть уничтожена только ее создателем или кем-либо, обладающим привилегией SYSADM либо привилегией DBADM на базу данных, содержащую эту таблицу.

9.2.

a) REVOKE SELECT ON TABLE СТАТУС FROM ФОРД;

6) REVOKE INSERT, DELETE ON TABLE СТАТУС FROM СМИТ;

в) REVOKE SELECT ON TABLE МОЯ_ЗАПИСЬ FROM PUBLIC;

Или, может быть, просто:

DROP VIEW МОЯ_ЗАПИСЬ;

В упражнениях г)—к) ниже вообще игнорируется возможность простого уничтожения представления, если она применима.

г) REVOKE SELECT, UPDATE ON TABLE СТАТУС FROM НЭШ;

д) REVOKE SELECT ON TABLE ИЗН FROM ТОДД;

e) REVOKE SELECT, UPDATE ON TABLE ИЗН FROM УОРД;

ж) REVOKE ALL PRIVILEGES ON ПРОПОВЕДНИКИ FROM ПОП;

з) REVOKE SELECT ON TABLE ИЗН FROM ДЖОУНЗ;

REVOKE UPDATE ON TABLE ИНК FROM ДЖОУНЗ;

и) REVOKE SELECT ON TABLE ГРАНИЦЫ—ЗАРПЛАТЫ FROM КИНГ;

к) REVOKE SYSADM FROM КЛАРК;

9.3. Все пользователи, за исключением U4 и U6, т.e. пользователи Ul, U2, U3, U5, U7, U8, все еще обладают привилегией р.