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

ОР8$-бюджеты (мы будем продолжать называть их так) полезны во многих обстоятельствах, но у них все же есть определенные недостатки. Во-первых, в более старых операционных системах для ПК, например в Windows 3.1 и OS/2, средств регистрации пользователей нет. Для этой среды придется задать стандартное имя пользователя в файле конфигурации, но это безопасно лишь в той степени, которую обеспечивает физическая безопасность машины. Если не принять некоторые дополнительные меры, то любой человек, имеющий доступ к вашему ПК, может воспользоваться вашим стандартным именем пользователя Oracle.

0Р8$-бюджеты могут также быть совершенно незащищенными в средах клиент/сервер, где клиентские машины требуют от пользователя регистра-

, ции. Пользователь может управлять несколькими рабочими станциями или, зная пароль системного администратора (в Unix - пароль root), может

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

I Спуфинг означает создание пользователя, о котором известно, что он

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

Поэтому не удивительно, что в Oracle есть параметр инициализации сервера, который не дает клиентским машинам пользоваться OPSS-perncT-рацией. Наш совет - отключите удаленную ОР8$-регистрацию.

Необходимо также отметить еще одно достоинство ОР8$-регистрации - она существенно затрудняет определенные типы воплощения. В частности, 0Р8$-регистрация не позволяет администраторам БД менять пользовательские пароли, чтобы подключиться к базе данных в качестве конкретного пользователя и внести какие-то полезные изменения (которые при последующем аудите определяются как сделанные этим пользователем, а не администратором). Знающий администратор может потом вернуть пароль пользователя в исходное значение, даже если оно ему не известно. Конечно, с проектированием это практически не связано, но на случай, если в это верится с трудом, вот соответствующий код:

SQIj> connect sys/whatever

SQL> col password new value Spw

SQL> SELECT password FROM dba users WHERE username = USER A PASSWORD

88f10186D82B38F2

SQL> alter user user a identified by xx; - изменение пароля

User altered.

SQL> connect user a/xx Connected.

SQL> alter user user a identified by values &pw User altered.

SQL> - пароль пользователя user a возвращен в исходное состояние

Еще одно замечание о безопасности систем клиент/сервер. Если разрешены соединения по глобальной сети, то решительный взломщик может проследить за данными между клиентом и сервером, увидеть запрос на соединение и прорваться с помощью такого же запроса в систему. В этом случае может помочь клиентский параметр ORA ENCRYPT LOGIN. Если он установлен, то регистрационная строка между клиентом и сервером шифруется. Отметим также, что продукт SQL*Net Secure Network Sei-vices версии 2.0 и выше поддерживает службы аутентификации промышленного стагщарта, такие как Kerberos и Sesame.

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

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

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

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

Безопасность доступа а меню

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

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

Мы предпочитаем скрывать пункты меню от пользователей, не имеющих права на доступ к ним, а не просто делать их затененными. Наличие таких пунктов на экране в любой форме может послужить стимулом поиска черного хода к ним.

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

Пакетные процессы

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