Документация по Oracle УСТАНОВЛЕНИЕ ПОЛИТИКИ ЗАЩИТЫ
ЗАЩИТА БАЗЫ ДАННЫХ
----------------------------------------------------------------
ЧАСТЬ IV
ЗАЩИТА БАЗЫ ДАННЫХ
ГЛАВА 10
----------------------------------------------------------------
УСТАНОВЛЕНИЕ ПОЛИТИКИ ЗАЩИТЫ
Эта глава содержит рекомендации для выработки политики защиты в
следующих сферах работы с базой данных:
* определение того, кто управляет и наблюдает за
безопасностью каждой базы данных
* установление уровня защиты системы
* установление уровня защиты объекта
* установление уровня защиты для различных типов
пользователей:
* защита конечного пользователя
* защита администратора
* защита разработчика приложений
* установление политики аудитинга базы данных
[Trusted]
Если вы используете Trusted ORACLE, вы должны рассмотреть
дополнительные вопросы защиты; обратитесь к документу Trusted
ORACLE7 Server Administrator's Guide.
Установление политики защиты 10-1
----------------
Администратор защиты
Каждая база данных имеет одного или нескольких администраторов,
отвечающих за поддержание всех аспектов политики защиты, т.е.
администраторов защиты (или безопасности). В небольшой базе
данных эти обязанности могут быть возложены на АБД. Однако, если
система базы данных велика, может быть выделено специальное лицо
или группа лиц, чьи обязанности ограничены обязанностями
администратора защиты.
После определения того, кто будет управлять защитой системы, для
каждой базы данных должна быть выработана политика защиты. Эта
политика должна включать в себя несколько задач, как объясняется
в следующих секциях этой главы.
----------------
Политика защиты системы
Проблема защиты системы баз данных должна включать в себя много
вопросов. Эта секция обсуждает вопросы, касающиеся любой базы
данных.
Управление пользователями базы данных
-------------------------------------
Пользователи (или, точнее, учетные имена) - это пути доступа к
информации в базе данных ORACLE. Поэтому управление
пользователями базы данных должно сопровождаться жесткой
системой защиты. В зависимости от размера системы базы данных и
от объема работы, необходимой для управления пользователями базы
данных, администратор защиты может быть единственным
пользователем с привилегиями, требуемыми для создания, изменения
и удаления пользователей базы данных, либо может существовать
целая группа администраторов с такими привилегиями. В любом
случае, лишь особо доверенные лица должны обладать мощными
привилегиями для администрирования пользователями базы данных.
Идентификация пользователей
---------------------------
Пользователи базы данных могут идентифицироваться (проверяться
ORACLE на достоверность) либо с помощью операционной системы,
либо с помощью базы данных. В большинстве случаев
предпочтительнее идентификация с помощью операционной системы,
по следующим причинам:
* Пользователи могут подключаться к ORACLE быстрее и
удобнее (не указывая свое имя или пароль).
* Контроль за идентификацией пользователей централизован в
операционной системе: нет необходимости поддерживать в
базе данных имена и пароли пользователей, если между
пользователями операционной системы и базы данных имеется
соответствие.
10-2 Руководство администратора
* Аудиторские записи о пользователях в базе данных и
операционной системе соответствуют друг другу.
Идентификация пользователей средствами базы данных используется
обычно тогда, когда операционная система не в состоянии
поддерживать эту возможность. См. "Создание пользователей" на
странице 11-7 для дополнительной информации об идентификации
пользователей.
Защита операционной системы
---------------------------
Если нужно, некоторые соображения защиты должны быть рассмотрены
также для окружения операционной системы, в котором выполняются
как ORACLE, так и приложения базы данных. Например:
* Администраторы базы данных должны иметь привилегии
операционной системы для создания и удаления файлов.
* Обычные пользователи базы данных не должны иметь
привилегий операционной системы, которые позволяли бы им
создавать или удалять файлы, связанные с базой данных.
* Если для идентификации ролей для пользователей
используется операционная система, то администраторы
защиты должны иметь привилегии операционной системы,
позволяющие модифицировать домены защиты для учетных имен
в операционной системе.
Обратитесь к вашему руководству по инсталляции [IUG] для
дополнительной информации, касающейся вопросов защиты
операционной системы для баз данных ORACLE.
----------------
Политика защиты данных
Определенные решения должны быть приняты относительно политики
защиты данных в базе данных. Например, может быть приемлемым
иметь весьма слабую защиту данных в базе данных; может считаться
терпимым позволять любому пользователю создавать любой объект
схемы и назначать привилегии для этих объектов любому другому
пользователю в системе. Альтернативно, может быть признан
необходимым жесткий контроль за безопасностью данных; АБД или
администратор безопасности может быть единственным лицом,
обладающим привилегиями создавать объекты и назначать привилегии
для этих объектов ролям и другим пользователям.
Общая защита данных должна основываться на чувствительности
(конфиденциальности) данных. Если информация не чувствительна,
политика защиты данных может быть ослаблена. Однако, если
данные чувствительны, то должна быть выработана благоразумная
политика защиты, позволяющая поддерживать жесткий контроль над
доступом к объектам.
Установление политики защиты 10-3
----------------
Политика защиты пользователей
Определенные решения должны быть приняты относительно политики
защиты пользоваталей в базе данных. Каждый тип пользователей
базы данных (конечные пользователи, администраторы, разработчики
приложений) требует рассмотрения специфических вопросов защиты.
Общая защита пользователей
--------------------------
Для всех типов пользователей базы данных, рассмотрите следующие
вопросы:
Защита паролей
Если идентификация пользователей осуществляется базой данных, то
должна быть выработана политика защиты паролей. Например, от
пользователей базы данных можно требовать, чтобы они изменяли
свое пароли через регулярные интервалы времени или в случае,
когда пароль стал известен другому лицу. Заставляя
пользователей изменять свои пароли в таких ситуациях, можно
уменьшить вероятность несанкционированного доступа к базе
данных.
Управление привилегиями
Общие решения должны быть приняты для управления привилегиями
для всех типов пользователей. Например, в базе данных с большим
числом пользователей может оказаться выгодным использовать роли,
чтобы управлять привилегиями, назначаемыми пользователям.
Альтернативно, в базе данных, имеющей лишь пригоршню учетных
имен, может быть легче явно назначать привилегии пользователям,
избегая применения ролей.
База данных, имеющая много пользователей, приложений или
объектов, должна извлекать преимущества из возможностей,
предоставляемых ролями. Роли значительно упрощают задачу
управления привилегиями в сложных окружениях.
Защита конечных пользователей
-----------------------------
Защита конечных пользователей должна обеспечиваться принятой
политикой. Например, если база данных велика и имеет много
пользователей, администратор защиты может решить, на какие
группы разбить пользователей, создать пользовательские роли для
этих групп, назначить необходимые привилегии или роли приложений
каждой пользовательской роли, и назначить пользовательские роли
пользователям. Чтобы учесть исключения, администратор защиты
должен также решить, какие привилегии должны быть явно назначены
индивидуальным пользователям.
Использование ролей в управлении привилегиями конечных пользователей
Роли предоставляют самый легкий способ назначения и управления
общими привилегиями, необходимыми различным группам
пользователей базы данных.
Пример
Рассмотрим следующую ситуацию:
* Каждому пользователю в бухгалтерском отделе компании
нужны привилегии для запуска приложений ACCTS_RECEIVABLE
и ACCTS_PAYABLE.
10-4 Руководство администратора
* С каждым из этих приложений ассоциированы роли, которые
содержат привилегии, необходимые для выполнения этих
приложений.
Чтобы разрешить эту простую ситуацию, АБД или администратор
защиты должен выполнить следующие действия:
1. Должна быть создана роль с именем ACCOUNTANT.
2. Роли для приложений ACCTS_RECEIVABLE и ACCTS_PAYABLE должны
быть назначены вновь созданной роли ACCOUNTANT.
3. Роль ACCOUNTANT должна быть назначена каждому пользователю в
бухгалтерском отделе.
Эта модель защиты проиллюстрирована на рис.10-1.
Рис.10-1
Пользовательские роли
------------¬ ------------¬ -----------¬ ------------¬ ------------¬
¦ User 1 ¦ ¦ User 2 ¦ ¦ User 3 ¦ ¦ User 4 ¦ ¦ User 5 ¦
L----T------- L----T------- L-T--------- L----T------- L----T-------
¦ ¦ ¦ ¦ ¦
L--------------+-----------+----------------+---------------
-----------+------¬ Роли
¦ Роль ACCOUNTING ¦ пользова-
L-----T------------ телей
¦
---------------+-----------¬
---------+-------¬ --------+--------¬ Роли
¦ Роль ACCTS_PAY ¦ ¦ Роль ACCTS_REC ¦ приложений
L--------T-------- L-------T---------
¦ ¦
---------+-------¬ --------+--------¬ Привилегии
¦ Привилегии для ¦ ¦ Привилегии для ¦ приложений
¦ выполнения ¦ ¦ выполнения ¦
¦ предложения ¦ ¦ приложения ¦
¦ ACCTS_PAY ¦ ¦ ACCTS_REC ¦
L----------------- L-----------------
Этот план отвечает следующим потенциальным будущим ситуациям:
* Если бухгалтерам впоследствиии потребуется роль для
нового приложения базы данных, эту роль приложения можно
будет назначить роли ACCOUNTANT, и все пользователи в
бухгалтерском отделе автоматически получат привилегии,
Установление политики защиты 10-5
ассоциированные с этим новым приложением базы данных. Не
потребуется назначать роль нового приложения каждому
пользователю, который должен иметь право выполнять это
приложение.
* Аналогично, если бухгалтерскому отделу перестанет быть
необходимым конкретное приложение, то достаточно будет
удалить роль этого приложения из роли ACCOUNTANT.
* Если привилегии, требуемые приложениями ACCTS_RECEIVABLE
и ACCTS_PAYABLE, изменятся, то соответственно изменятся
роли этих приложений. При этом домен защиты как роли
ACCOUNTANT, так и всех пользователей, которым назначена
роль ACCOUNTANT, автоматически отразят эти модификации
ролей приложений.
Роли следует применять во всех возможных ситуациях, чтобы
сделать управление привилегиями конечных пользователей простым и
эффективным.
Защита администраторов
----------------------
Определенная политика должна быть выработана для защиты
администраторов. Например, если база данных велика, и есть
несколько типов администраторов, то администратор защиты может
принять решение разбить взаимосвязанные привилегии
администраторов на несколько административных ролей. Эти
административные роли могут затем назначаться соответствующим
лицам. Альтернативно, если база данных мала, может оказаться
более удобным создать всего одну административную роль и
назначить ее всем администраторам.
Защита соединений для SYS и SYSTEM
После создания базы данных, НЕМЕДЛЕННО измените пароли для
административных учетных имен SYS и SYSTEM, чтобы предотвратить
несанкционированный доступ к базе данных. Соединения под
именами SYS или SYSTEM дают пользователю мощные привилегии,
позволяющие модифицировать базу многими способами. Поэтому
доступ к этим учетным именам должен быть крайне ограничен и
доступен лишь избранным администраторам базы данных.
Пароли для этих учетных имен могут быть модифицированы с помощью
процедур, описанных в секции "Изменение пользователей" на
странице 11-11.
Защита соединений для INTERNAL
Только администраторы базы данных должны иметь возможность
подключаться к базе данных, используя ключевое слово INTERNAL.
Подключение в режиме INTERNAL дает пользователю неограниченные
привилегии как для самой базы данных (запуск, останов,
восстановление), так и для объектов в базе данных (создание и
удаление). Поэтому доступ к этому ключевому слову должен быть
крайне ограничен и доступен лишь избранным администраторам базы
данных.
Если ваш сервер ORACLE поддерживает идентификацию ролей через
операционную систему, то ключевое слово INTERNAL защищается
ролями OSOPER и OSDBA. Каждая из этих ролей предоставляет свой
10-6 Руководство администратора
уровень возможностей при соединении как INTERNAL. См. секцию
"Альтернативы INTERNAL: OSOPER и OSDBA" на странице 1-5 для
дополнительной информации о ролях OSOPER и OSDBA и их функциях.
Замечание: Чтобы иметь возможность конфигурировать учетное имя
администратора базы данных в операционной системе этими ролями,
администратор защиты должен обладать полномочиями изменять
защиту для учетных имен операционной системы.
Если ваш сервер ORACLE не поддерживает идентификацию ролей через
операционную систему, то использование ключевого слова INTERNAL
защищается способом, специфичным для операционной системы
(обычно с помощью паролей). Для подробностей обратитесь к
секции "Подключение в режиме INTERNAL" на странице 1-4, а также
к вашему руководству по инсталляции [IUG].
Использование ролей для управления привилегиями администраторов
Роли предоставляют самый легкий способ ограничивать
использование мощных системных привилегий и ролей, необходимых
административному персоналу базы данных.
Пример
Предположим, что обязанности администратора базы данных на
большой вычислительной установке разделяются между несколькими
лицами, каждый из которых отвечает за специфические задачи
сопровождения базы данных. Такими лицами могут быть:
* Администратор, ответственный за создание и поддержание
объектов
* Администратор, ответственный за настройку и
производительность базы данных
* Администратор безопасности, ответственный за создание
новых пользователей, назначение им ролей и привилегий и
т.п.
* Администратор базы данных, отвечающий за рутинные
операции базы данных (например, запуск, останов,
копирование)
* Администратор, отвечающий за исключительные ситуации,
такие как восстановление базы данных
* Новые, неопытные администраторы базы данных, которым
нужны ограниченные возможности для экспериментов по
сопровождению базы данных
В этой ситуации, администратор безопасности может следующим
способом структурировать защиту для административного персонала:
1. Шесть ролей следует определить для различных привилегий,
требуемых для выполнения каждого типа задач (например,
DBA_OBJECTS, DBA_TUNE, DBA_SECURITY, DBA_MAINTAIN, DBA_RECOV,
DBA_NEW).
2. Каждой из ролей назначить соответствующие привилегии.
Установление политики защиты 10-7
3. Каждому администратору назначить соответствующую роль.
Этот план позволяет легко разрешать потенциальные будущие
проблемы:
* Если перечень обязанностей администратора изменится так,
что потребуется больше обязанностей, то этому
администратору можно будет назначить другие
административные роли, которые соответствуют его новым
обязанностям.
* Если перечень обязанностей администратора изменится так,
что потребуется меньше обязанностей, то у этого
администратора можно будет отозвать соответствующие
административные роли.
* Информация о каждой роли и каждом пользователе хранится в
словаре данных, так что всегда можно раскрыть задачи
каждого администратора.
Защита разработчиков приложений
-------------------------------
Для защиты разработчиков приложений должна быть выработана
специальная политика. Например, разработчикам могут быть
предоставлены привилегии для создания необходимых объектов.
Альтернативно, такими привилегиями может быть наделен только
АБД, который принимает от разработчиков запросы на создание
объектов.
Разработчики приложений и их привилегии
Разработчик приложений - это особый тип пользователя базы
данных, которому требуются специальные группы привилегий для
выполнения его задач. В отличие от конечных пользователей,
разработчикам необходимы системные привилегии, такие как CREATE
TABLE, CREATE PROCEDURE, и.т.п. Однако для ограничения общих
возможностей доступа к базе данных разработчикам следует
предоставлять лишь некоторые, специфичные, системные привилегии.
Окружение разработчика: тестовая и производственная базы данных
Во многих случаях разработка приложений ограничивается тестовыми
базами данных, и не допускается на производственных базах
данных. Соблюдая это ограничение, вы добиваетесь следующих
целей:
* разработчики приложений не конкурируют с конечными
пользователями за ресурсы базы данных
* разработчики приложений не могут оказать разрушительное
воздействие на производственную базу данных
После того, как приложение тщательно разработано и
протестировано, ему разрешается доступ к производственной базе
данных, и оно становится доступным конечным пользователям этой
базы данных.
Свободная разработка против управляемой
Администратор базы данных имеет две возможности при определении
привилегий, которые должны быть предоставлены разработчикам
приложений:
10-8 Руководство администратора
Свободная Разработчику приложения разрешается создавать
разработка новые объекты схемы, включая таблицы, индексы,
процедуры, пакеты и т.д. Этот режим позволяет
разработчику создавать приложение независимо от
других объектов.
Управляемая Разработчику приложения не разрешается создавать
разработка новые объекты схемы. Все требуемые таблицы,
индексы, процедуры и т.п. создаются
администратором базы данных по запросу
разработчика приложения. Этот режим позволяет
администратору базы данных полностью
контролировать использование памяти базы данных
и пути доступа к информации в базе данных.
Хотя некоторые системы баз данных могут придерживаться одного из
этих режимов в чистом виде, на других системах может
использоваться смесь обоих вариантов. Например, разработчикам
может быть позволено создавать новые хранимые процедуры и
пакеты, но не разрешено создавать таблицы или индексы. Решение
администратора защиты в этом вопросе должно основываться на
следующих факторах:
* желаемой степени контроля над использованием памяти базы
данных
* желаемой степени контроля над путями доступа к объектам
схем
* базе данных, используемой для разработки приложений -
если для разработки используется тестовая база данных,
политика может быть более либеральной
Роли и привилегии для разработчиков приложений
Роли могут создаваться администратором защиты для управления
привилегиями, необходимыми типичному разработчику приложений.
Например, типичная роль с именем APPLICATION_DEVELOPER может
включать системные привилегии CREATE TABLE, CREATE VIEW и CREATE
PROCEDURE. Обратите внимание на два важных момента при
определении ролей для разработчиков приложений:
* Системные привилегии CREATE обычно назначаются
разработчикам так, чтобы они могли создавать лишь свои
собственные объекты. Однако системные привилегии CREATE
ANY, позволяющие создавать объект в домене любого
пользователя (такие как CREATE ANY TABLE, CREATE ANY
PROCEDURE и т.п.), обычно не назначаются разработчикам.
Это ограничивает создание новых объектов учетным именем
разработчика.
* Объектные привилегии редко назначаются ролям,
используемым разработчиками приложений. Как правило, это
непрактично, потому что назначение объектных привилегий
через роли часто ограничивает способность создавать
другие объекты (прежде всего обзоры и хранимые
Установление политики защиты 10-9
процедуры). Более практично разрешить разработчикам
создавать для целей приложения свои собственные объекты.
Ограничения памяти для разработчиков приложений
В то время как разработчикам приложений обычно предоставляются
привилегии для создания объектов как частьб процесса разработки,
ажминистраторы защиты должны поддерживать лимиты на то, где и
сколько памяти базы данных может использовать каждый
разработчик. Например, вы, как администратор защиты, должны
специально установить или ограничить следующие лимиты для
каждого разработчика индивидуально:
* табличные пространства, в которых разработчик может
создавать таблицы или индексы
* квоту в каждом табличном пространстве, доступном
разработчику
Оба этих ограничения можно установить путем изменения домена
защиты разработчика приложения. Для дополнительной информации
см. "Изменение пользователей" на странице 11-11.
Защита администратора приложений
--------------------------------
В больших базах данных, имеющих много приложений (например,
приложений прекомпиляторов, приложений SQL*Forms), вы можете
захотеть иметь специальных администраторов приложений.
Администратор приложений отвечает за следующие типы задач:
* создание ролей для приложения и управление привилегиями
для каждой роли этого приложения
* создание и сопровождение объектов, используемых
приложением базы данных
* сопровождение и обновление кода приложения и связанных с
ним процедур и пакетов ORACLE
Во многих случаях администратором приложения является
разработчик, создавший это приложение. Однако эти задачи могут
и не входить в обязанности разработчика, и могут быть возложены
на другое лицо, знакомое с приложением базы данных.
----------------
Политика аудитинга
Определенная политика должна быть выработана для процедур
аудитинга каждой базы данных. Например, может быть решено не
включать аудитинг, если не подозревается сомнительная
деятельность в базе данных. Если аудитинг требуется, то
администратор защиты должен решить, на каком уровне детализации
отслеживать базу данных; обычно сначала осуществляется более
общий аудитинг системы, за которым следуют более специфичные
типы аудитинга, когда определены источники подозрительных
действий.
10-10 Руководство администратора