Oracle: Check List по безопасности

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

За основу составления статьи послужили следующие материалы:

1. А. Поляков, Безопасность Oracle глазами аудитора. Нападение и защита
2. Oracle9i. Database Administrator’s Guide. Release 1
3. Марлен Терьо, Аарон Ньюмен, Oracle. Руководство по безопасности
4. Сэм Р. Алапати, Oracle Database 11g. Руководство администратора баз данных

Контрольный список вопросов безопасности Oracle

Рассматриваемые вопросы:

1. Инсталляция только необходимых компонентов.
2. Явное блокирование входа в систему пользователей, создаваемых по умолчанию; явно задание для них срока истечения действия пароля.
3. Изменение паролей пользователей, создаваемых по умолчанию.
4. Включение защиты словаря данных.
5. Применение принципа минимальности привилегий.
6. Эффективное управление доступом.
7. Ограничение на сетевой доступ.
8. Применение всех “заплат” и обходных путей, рекомендуемых для исправления ошибок безопасности.
9. Поддержка контактов с Oracle Worldwide Support Services.

И так, давайте, начнем по порядку.

1. Инсталляция только необходимых компонентов

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

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

2. Явно блокируйте вход в систему пользователей, создаваемых по умолчанию

Во время инсталляции Oracle по умолчанию создается ряд преопределенных пользователей БД. Если для инсталляции используется инструментальное средство Database Configuration Assistant (DBCA), автоматически блокируется вход в систему всех пользователей, создаваемых по умолчанию (и явно устанавливается дли них истечение срока действия пароля), кроме следующих, требуемых после успешного завершения инсталляции сервера БД:

• SYS
• SYSTEM
• SCOTT
• DBSNMP
• OUTLN
• Три пользователя JSERV.

Если выполняется ручная инсталляция (без DBCA), после успешного завершения инсталляции сервера БД никакие пользователи по умолчанию не блокируются. Их требуется блокировать вручную (для этого в дистрибутиве предусмотрен соответствующий командный файл SQL).

Список созданных пользователей БД и их статус можно проверить в представлении словаря данных DBA_USERS. После типовой инсталляции Oracle9i с помощью DBCA он выглядит следующим образом:

USERNAME	ACCOUNT_STATUS
ADAMS	EXPIRED & LOCKED
AURORA$JIS$UTILITY$	OPEN
AURORA$ORB$UNAUTHENTICATED	OPEN
BLAKE	EXPIRED & LOCKED
CLARK	EXPIRED & LOCKED
CTXSYS	EXPIRED & LOCKED
DBSNMP	OPEN
HR	EXPIRED & LOCKED
JONES	EXPIRED & LOCKED
LBACSYS	EXPIRED & LOCKED
MDSYS	EXPIRED & LOCKED
OE	EXPIRED & LOCKED
OLAPDBA	EXPIRED & LOCKED
OLAPSVR	EXPIRED & LOCKED
OLAPSYS	EXPIRED & LOCKED
ORDPLUGINS	EXPIRED & LOCKED
ORDSYS	EXPIRED & LOCKED
OSE$HTTP$ADMIN	OPEN
OUTLN	OPEN
PM	EXPIRED & LOCKED
QS	EXPIRED & LOCKED
QS_ADM	EXPIRED & LOCKED
QS_CB	EXPIRED & LOCKED
QS_CBADM	EXPIRED & LOCKED
QS_CS	EXPIRED & LOCKED
QS_ES	EXPIRED & LOCKED
QS_OS	EXPIRED & LOCKED
QS_WS	EXPIRED & LOCKED
SCOTT	OPEN
SH	EXPIRED & LOCKED
SYS	OPEN
SYSTEM	OPEN

Если после инсталляции какой-то заблокированный пользователь по каким-то причинам понадобится вновь, АБД может его просто разблокировать и задать новый значащий (осмысленный) пароль.

3. Изменение паролей пользователей, создаваемых по умолчанию.

• Изменяйте пароли по умолчанию административных пользователей.
• Изменяйте пароли по умолчанию всех пользователей.
•  Используйте средства сопровождения паролей.

Самый тривиальный способ компрометации безопасности БД Oracle (включая Oracle9i) – создаваемые по умолчанию пользователи имеют задаваемый по умолчанию пароль даже после завершения инсталляции.

Изменяйте пароли по умолчанию административных пользователей

Пользователь SYS инсталлируется с паролем по умолчанию CHANGE_ON_INSTALL. Пользователь SYSTEM инсталлируется с паролем по умолчанию MANAGER.

Для предотвращения несанкционированного доступа к БД необходимо сразу же после завершения процедуры создания базы данных Oracle изменить пароли пользователей SYS и SYSTEM. Эти пароли документированы и не изменялись много лет.

Изменяйте пароли по умолчанию всех пользователей

Пользователь SCOTT инсталлируется с паролем по умолчанию TIGER. Три пользователя JSERV (AURORA$JIS$UTILITY$, AURORA$ORB$UNAUTHENTICATED и OSE$HTTP$ADMIN) инсталлируются со случайно генерируемыми паролями. У других инсталлируемых по умолчанию пользователей пароли совпадают с их именами.

После завершения инсталляции сервера БД немедленно измените пароли пользователей SCOTT, DBSNMP, OUTLN и JSERV. По представлению словаря данных DBA_USERS (ACCOUNT_STATUS = OPEN) проверьте наличие других открытых пользователей и примите решение по их блокированию или изменению их паролей.

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

Используйте средства сопровождения паролей

Oracle рекомендует использовать основные правила сопровождения паролей (длина пароля, хронология, сложность и т.п.) для всех пользователей БД, а также требовать от пользователей регулярного изменения паролей.

Парольная система Oracle включается установкой параметра инициализации RESOURCE_LIMIT = TRUE и позволяет:

• Отпугивать “взломщиков” паролей.
• Устанавливать срок действия паролей
• Требовать задания более “надежных” паролей.

Механизм сопровождения паролей в Oracle базируется на ресурсных ограничениях типа PASSWORD, устанавливаемых в профилях пользователей:

Отпугивание “взломщиков” паролей:

•    failed_login_attempts – максимальное количество неудачных попыток входа в систему;
•   password_lock_time – период времени блокирования пароля после выполнения заданного количества неудачных попыток входа в систему;
•  alter user <x> account [lock | unlock] - явное блокирование/разблокирование входа пользователей в систему.

Установка срока действия паролей:

•    password_life_time – максимальный срок действия пароля;
•    password_grace_time – период отсрочки истечения срока действия пароля;
•    alter user <x> password expire – явная установка истечения срока действия пароля.

Задание более “надежных” паролей:

•    password_reuse_time – период времени запрещения повторного использования пароля;
•    password_reuse_max – количество изменений текущего пароля до его повторного использования;
•    password_verify_function – имя процедуры проверки сложности пароля.

Шаблон процедуры проверки сложности пароля входит в состав дистрибутива сервера Oracle (см. командный файл utlpwdmg.sql). Этот шаблон можно использовать при разработке новой процедуры проверки сложности пароля, отвечающей требованиям заказчика (его политике безопасности).

В процедуре verify_function выполняются следующие явно минимальные проверки сложности пароля:

•    минимальная длина пароля – 4 символа;
•    пароль не совпадает с именем пользователя;
•    пароль содержит по крайней мере одну букву, одну цифру и один знак препинания;
•   пароль не совпадает с простыми словами, такими, как welcome, database, account, user, password, oracle, computer и abcd;
•    пароль отличается от предыдущего пароля по крайней мере на 3 символа.

Oracle также рекомендует использовать, если это возможно, опцию Oracle Advanced Security (входит в Enterprise Edition) с сервисами сетевой аутентификации (такими, как Kerberos, токен-карты, смарт-карты или сертификаты X.509). Эти сервисы обеспечивают сильную аутентификацию и, следовательно, лучшую защиту от несанкционированного доступа.

Для сильной аутентификации может быть использована централизованная аутентификация всех элементов сети (клиентов с серверами, серверов с серверами, пользователей, как с клиентами, так и с серверами), а также двухфакторная аутентификация, которая позволяет обойтись без статических паролей – пользователь знает свой персональный идентификационный номер (personal identification number – PIN) и имеет персональное устройство идентификации пользователя, например, брелок с токеном.

4. Включение защиты словаря данных.

Oracle рекомендует защищать словарь данных от доступа пользователей с системными привилегиями типа ANY. Для включения защиты следует установить параметр инициализации O7_DICTIONARY_ACCESSIBILITY:

O7_DICTIONARY_ACCESSIBILITY = FALSE

После этого доступ к словарю данных будут иметь только пользователи с административными привилегиями (например, пользователи, которые могут соединяться с БД как CONNECT / AS SYSDBA).

Если каким-то пользователям требуется, например, просмотр словаря данных, им можно выдать системную привилегию SELECT ANY DICTIONARY в Oracle9i или роль SELECT_CATALOG_ROLE в Oracle8i.

Замечания:

•    в Oracle9i в параметре O7_DICTIONARY_ACCESSIBILITY по умолчанию установлено FALSE;
•    в Oracle8i в параметре O7_DICTIONARY_ACCESSIBILITY по умолчанию установлено TRUE – для защиты словаря данных необходимо вручную установить FALSE.

1. Применение принципа минимальности привилегий

•    Выдавайте пользователям только требуемые привилегии.
•    Отбирайте ненужные привилегии у группы пользователей БД PUBLIC.
•    Ограничивайте права доступа в динамически запускаемых средствах.

Выдавайте пользователям только требуемые привилегии

Oracle обеспечивает реализацию принципа минимальности привилегий (principle of least privilege), суть которого заключается в том, что пользователи должны получать минимальный набор привилегий, требуемый для выполнения их конкретных задач.

В Oracle при создании пользователей автоматически не выдается никаких привилегий. Поэтому перед выполнением каких-либо операций вновь созданные пользователи должны явно получить требуемые привилегии, включая привилегию для соединения с базой данных (CREATE SESSION – создание сеанса). Кроме того, Oracle имеет в высокой степени детализированный набор системных и объектных привилегий, который практически ортогонален набору возможных операций в базе данных и позволяет выдавать пользователям только требуемые привилегии для выполнения конкретных операций.

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

•    ограничивайте количество системных и объектных привилегий, выдаваемых пользователям;
•    сокращайте количество соединений с БД для административных пользователей типа SYS.
•    Никогда не выдавайте пользователям, которые не выполняют администрирование БД, привилегии типа CREATE ANY TABLE – создать таблицу в любой схеме БД.

Использование ролей базы данных

Самым простым и эффективным способом предоставления и управления привилегиями является использование для этого ролей базы данных Oracle. Механизм ролей обеспечивает:

•    упрощение администрирования привилегий – привилегии можно выдавать функциональным ролям, которые затем будут назначаться соответствующим группам пользователей;
•    динамическое управление привилегиями – изменение привилегий конкретной роли автоматически приводит к изменению привилегий у всех пользователей, которым эта роль была назначена;
•    избирательную доступность привилегий – назначенные пользователю роли могут выборочно включаться и выключаться;
•    управление привилегиями из приложений – все роли базы данных хранятся в словаре данных, поэтому приложения могут быть спроектированы для автоматической выборки и включения требуемой в конкретной ситуации роли;
•    защиту на уровне приложений – включение ролей может выполняться в приложениях с парольной аутентификацией, в таком случае роли не могут явно включаться пользователями. Включение ролей приложений в инструментальных средствах Oracle, таких, как SQL*Plus, может также запрещаться с помощью штатной таблицы PRODUCT_USER_PROFILE в схеме SYSTEM.

Защищенные роли приложений

В Oracle9i появились защищенные роли приложений (Secure Application Role), которые можно включать только в авторизованных пакетах PL/SQL. Это позволяет ограничить их использование только приложениями. Преимущества защищенных ролей приложений:

• не требуется хранение паролей;
• для включения используются авторизованные пакеты PL/SQL.

В предыдущих версиях Oracle пароль нужно было вставлять в текст приложения, либо хранить в таблице БД или файле ОС. При создании защищенной роли приложений указывается пакет с правами вызывающего (домен защиты в процедурах с правами владельца изменять нельзя), авторизованный для ее включения:

CREATE ROLE роль IDENTIFIED USING [схема].пакет_с_правами_вызывающего;

В авторизованном пакете для обеспечения дополнительной защиты можно c помощью контекста приложения разрешать включение ролей, например, только для пользователей, соединяемых через proxy-сервер:

SYS_CONTEXT (’userenv’,’proxy_userid’)

SYS_CONTEXT (userenv’, ’proxy_user’)

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

Отбирайте ненужные привилегии у группы пользователей БД PUBLIC

Группа пользователей БД PUBLIC работает как роль по умолчанию, доступная всем пользователям Oracle. Любой пользователь может воспользоваться привилегиями PUBLIC, включая привилегию выполнения (EXECUTE) различных пакетов PL/SQL. Приведем список пакетов, право выполнения которых должно предоставляться только в индивидуальном порядке:

Пакет	Описание
UTL_SMPT	Разрешает отправку произвольных почтовых сообщений от одного произвольного пользователя любому другому произвольному пользователю. Обмен сообщениями должен быть санкционированным.
UTL_TCP	Разрешает установление сервером БД исходящих сетевых соединений с любыми принимающими (или ожидающими) сетевыми службами. Произвольные данные БД могут быть посланы в любую ожидающую сетевую службу.
UTL_HTTP	Разрешает серверу БД запрашивать и извлекать данные, используя HTTP. Через формы HTML данные можно послать в любой WEB-узел.
UTL_FILE	При неправильном конфигурировании разрешает текстовый доступ к любому файлу операционной системы сервера БД. Даже при правильном конфигурировании этот пакет не различает вызывающие приложения, когда приложение с доступом к пакету пишет произвольные данные в то же самое место, в которое данные записывает другое приложение.
DBMS_RANDOM	Может быть использован для шифрования хранимых данных. В общем, большинство пользователей не должно иметь привилегий для шифрования данных, т.к. они могут оказаться не восстанавливаемыми, если ключи неправильно генерируются или хранятся.

Ограничивайте права доступа в динамически запускаемых средствах

Не назначайте “все права доступа” в динамически запускаемых средствах, таких, как Oracle Java Virtual Machine (OJVM) – они могут выполнять файлы и пакеты за пределами сервера БД. Назначайте конкретные права доступа для путей доступа к корневым файлам документов.

Пример уязвимого динамического вызова:

call dbms_java.grant_permission('SCOTT',

'SYS:java.io.FilePermission'

'<<ВСЕ ФАЙЛЫ>>','read');

Пример более защищенного динамического вызова:

call dbms_java.grant_permission('SCOTT',

'SYS:java.io.FilePermission',

'<<путь доступа к реальному каталогу>>','read');

1. Эффективное управление доступом

•    Правильно выполняйте аутентификацию клиентов.
•    Ограничивайте количество пользователей операционной системы.
•    Правильно выполняйте аутентификацию клиентов

Удаленная аутентификация пользователей выполняется на удаленной клиентской машине, соединенной с Oracle. Таким образом, Oracle неявно доверяет клиентам, что они аутентифицировали себя правильно. Перекладывание аутентификации на операционную систему клиента может серьезно скомпрометировать безопасность.

В более защищенной конфигурации удаленная аутентификация должна быть выключена:

REMOTE_OS_AUTHENT = FALSE

Ограничивайте количество пользователей операционной системы

Максимально ограничивайте на сервере количество пользователей операционной системы, независимо от уровня выдаваемых им привилегий ОС.

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

2. Ограничение на сетевой доступ

•    Используйте межсетевые экраны.
•    Никогда не оставляйте “дырки” в межсетевых экранах.
•    Предотвращайте несанкционированное администрирование Oracle Listener.
•    Проверяйте IP-адреса.
•    Шифруйте сетевой трафик.
•    Ограничивайте функции операционной системы.

Используйте межсетевые экраны

Размещайте сервер БД за межсетевым экраном. Сетевая инфраструктура Oracle9i – Oracle Net (ранее известная как Net8 и SQL*Net) – обеспечивает поддержку межсетевых экранов различных производителей.Поддерживаются:

3. межсетевые экраны с proxy-возможностями, включая:

•    Gauntlet от Network Associates;
•    Raptor от Axent;

4. межсетевые экраны с фильтрацией пакетов, включая:

•    PIX Firewall от Cisco;

5. межсетевые экраны с контролем, изменяющем параметры своего состояния в процессе работы (более совершенные межсетевые экраны с фильтрацией пакетов), включая:

•    Firewall-1 от CheckPoint.

Никогда не оставляйте “дырки” в межсетевых экранах

Если сервер БД Oracle9i размещен за межсетевым экраном, ни при каких обстоятельствах не оставляйте в экране “дырки”. Например, не оставляйте открытым порт 1521 Oracle Listener для соединения с Internet.

Это приведет к появлению ряда существенных слабых мест в системе защиты, включая:

•    добавление еще одного открытого через межсетевой экран порта;
•    проблемы многопотокового сервера операционной системы;
•    раскрытие критической информации БД, размещенной за межсетевым экраном.
• Более того, в Oracle Listener, работающем без установленного пароля, могут “прощупываться” такие важные детали о БД, которую он прослушивает, как:
•    информация трассировки и протоколы;
•    заголовки;
•    дескрипторы БД;
•    имена сервисов.
• Такое изобилие информации и возможное плохое конфигурирование межсетевого экрана обеспечат взломщику достаточно удобный случай, чтобы начать злоумышленные атаки на защищаемые БД.

Предотвращение несанкционированного администрирования Oracle Listener

Для предотвращения удаленного конфигурирования Oracle Listener всегда следует устанавливать для него осмысленный, правильно сформированный пароль.

Кроме того, в управляющем файле Oracle Listener (listener.ora) следует установить параметр защищенной конфигурации:

ADMIN_RESTRICTIONS_listener_name = ON

Это будет также предотвращать несанкционированное администрирование Oracle Listener.

Проверяйте IP-адреса

Для разрешения или отказа в доступе к процессам сервера Oracle используйте возможность проверки в Oracle Net допустимых узлов ("valid node checking"). Для этого в конфигурационном файле Oracle Net (protocol.ora) следует установить параметры:

tcp.validnode_checking = YES

tcp.excluded_nodes = {список IP-адресов}

tcp.invited_nodes = {список IP-адресов}

Первый параметр включает проверку, другие два соответственно запрещают или разрешают конкретным IP-адресам клиентов соединяться с Oracle Listener (и, возможно, предотвращать потенциальные атаки типа “отказ в обслуживании”).

Шифруйте сетевой трафик

Oracle Corporation рекомендует, если возможно, шифровать сетевой трафик между клиентами, серверами баз данных и серверами приложений, используя для Oracle Advanced Security,. (опция Oracle Advanced Security доступна только в Oracle Enterprise Edition).

Предоставление информационных услуг по шифрованию регламентируется Законом о государственной тайне и Указом Президента РФ №334 от 3.04.95 “О мерах по соблюдению законности в области разработки, производства, реализации и эксплуатации шифровальных средств, а также предоставления услуг в области шифрования информации”. В соответствии с Указом запрещается деятельность физических и юридических лиц, связанная с разработкой, производством, реализацией и эксплуатацией шифровальных средств, а также защищенных технических средств хранения, обработки и передачи информации, предоставлением услуг в области шифрования информации, без лицензий, выданных ФСТЭК.

Ограничивайте функции операционной системы

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

Как UNIX, так и платформы Windows, обеспечивают разнообразные сервисы, большинство из которых не требуется для большинства прикладных систем: FTP, TFTP, TELNET и т.д.

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

Минимальная конфигурация операционной системы MS Windows NT 4.0 для сервера Oracle может иметь следующие характеристики:

•    Операционная система MS Windows NT Server 4.0.
•    Режим установки Standalone Server.
•    Установленный Service Pack 3 или более поздний.
•    Наличие одной или нескольких сетевых карт Ethernet.
•    Наличие сетевого протокола TCP/IP.
•    Отсутствие всех других сетевых протоколов.
•  Отсутствие на сервере любого программного обеспечения, кроме программного обеспечения операционной системы и сервера Oracle.

8. Применение всех “заплат” и обходных путей, рекомендуемых для исправления ошибок безопасности

Применяйте все “заплаты”, рекомендуемые для исправления ошибок безопасности.

Всегда применяйте все подходящие и текущие “заплаты” и обходные пути, рекомендуемые для исправления ошибок безопасности, как для сервера Oracle, так и всех инсталлированных опций, продуктов и компонентов, а также для операционной системы, под управлением которой работает сервер Oracle.

Регулярно следует проверять на сетевом узле безопасности Oracle Technology Network сигнальную информацию об угрозах безопасности, которую выпускает Oracle Corporation:  http://otn.oracle.com/deploy/security/alerts.htm

   http://technet.oracle.com/deploy/security/alerts.htm

Также следует следить за узлом Oracle Worldwide Support Service – Metalink, в котором размещается информация о доступных и ожидаемых исправлениях, относящихся к безопасности, http://metalink.oracle.com

9. Поддержка контактов с Oracle Worldwide Support Services

Если Вы предполагаете, что обнаружили слабое место в системе защиты Oracle, направьте в Oracle Worldwide Support Services iTAR, используя Metalink, или электронное письмо с полным описанием проблемы, включая версии продуктов и платформу, а также использованные командные файлы и/или примеры, по следующему адресу: secalert_us@oracle.com