• роли уровня сервера;
• роли уровня базы данных.
Роли уровня сервера
С помощью этих ролей предоставляются различные степени доступа к операциям и задачам сервер*. Роли уровня сервера заранее определены и действуют в пределах сервера. Они не зависят от конкретных баз данных, и их нельзя модифицировать.
В SQL Server существуют следующие типы ролей уровня сервера:
Sysadmin — дает право выполнить любое действие в SQL Server;
Serveradmin — дает право изменить параметры SQL Server и завершить его работу;
Setupadmin — дает право инсталлировать систему репликации и управлять выполнением расширенных хранимых процедур;
Securityadmin — дает право контролировать параметры учетных записей для подключения к серверу и предоставлять права доступа к базам данных;
Processadmin — дает право управлять ходом выполнения процессов в SQL Server;
Dbcreator — дает право создавать и модифицировать базы данных;
Diskadmin — дает право управлять файлами баз данных на диске.
Роли уровня базы данных
Роли уровня базы данных позволяют назначить права для работы с конкретной базой данных отдельному пользователю или группе. Роли уровня базы данных можно назначать учетным записям пользователей в режиме аутентификации Windows или SQL Server. Роли могут быть и вложенными, так что учетным записям можно назначить иерархическую группу прав доступа.
В SQL Server существует три типа ролей:
• заранее определенные роли;
• определяемые пользователем роли;
• неявные роли.
Заранее определенными являются стандартные роли уровня БД. Эти роли имеет каждая база данных SQL Server. Они позволяют легко и просто передавать обязанности.
Заранее определенные роли зависят от конкретной базы данных и не могут быть изменены. Ниже перечислены стандартные роли уровня базы данных.
db_owner — определяет полный доступ ко всем объектам базы данных, может удалять и воссоздавать объекты, а также присваивать объектные права другим пользователям. Охватывает все функции, перечисленные ниже для других стандартных ролей уровня базы данных;
db_accessadmin — осуществляет контроль за доступом к базе данных путем добавления или удаления пользователей в режимах аутентификации;
db_datareader — определяет полный доступ к выборке данных (с помощью оператора SELECT) из любой таблицы базы данных. Запрещает выполнение операторов INSERT, DELETE и UPDATE для любой таблицы БД;
db_datawriter — разрешает выполнять операторы INSERT, DELETE и UPDATE для любой таблицы базы данных. Запрещает выполнение оператора SELECT для любой таблицы базы данных;
db_ddladmin — дает возможность создавать, модифицировать и удалять объекты базы данных;
db_securityadmin — управляет системой безопасности базы данных, а также назначением объектных и командных разрешений и ролей для базы данных;
db_backupoperator — позволяет создавать резервные копии базы данных;
db_denydatareader — отказ в разрешении на выполнение оператора SELECT для всех таблиц базы данных. Позволяет пользователям изменять существующие структуры таблиц, но не позволяет создавать или удалять существующие таблицы;
db_denydatawriter — отказ в разрешении на выполнение операторов модификации данных (INSERT, DELETE и UPDATE) для любых таблиц базы данных;
public — автоматически назначаемая роль сразу после предоставления права доступа пользователя к БД.
Роли, определяемые пользователем, позволяют группировать пользователей и назначать каждой группе конкретную функцию безопасности.
Существуют два типа ролей уровня базы данных, определяемых пользователем:
• стандартная роль;
• роль уровня приложения.
Стандартная роль предоставляет зависящий от базы данных метод создания определяемых пользователем ролей. Самое распространенное назначение стандартной роли — логически сгруппировать пользователей в соответствии с их правами доступа. Например, в приложениях выделяют несколько типов уровней безопасности, ассоциируемых с тремя категориями пользователей. Опытный пользователь может выполнять в базе данных любые операции; обычный пользователь может модифицировать некоторые типы данных и обновлять данные; неквалифицированному пользователю обычно запрещается модифицировать любые типы данных.
Роль уровня приложения позволяет пользователю выполнять права некоторой роли. Когда пользователь принимает роль уровня приложения, он берет на себя выполнение новой роли и временно отказывается от всех других назначенных ему прав доступа к конкретной базе данных. Роль уровня приложения имеет смысл применять в среде, где пользователи делают запросы и модифицируют данные с помощью клиентского приложения.
Системный анализ - это применение системного подхода при обработке конкретной информации и принятию решений. Рассмотренные принципы системного подхода являются и принципами системного анализа.
Их дополняют следующие специфические принципы:
• анализ любого процесса принятия решения должен начинаться с выявления и четкой формулировки целей (желаемых результатов деятельности), которые часто определяются на основе рассмотрения системы более высокого уровня;
• необходимо рассматривать лишь те цели, вероятность достижения которых р>р0 за время t<t0, где/?0 и t0 - пороги осуществимости цели.
Данные специальные принципы предполагают некую системную стратегию анализа, требующую рассмотрения не только самой системы, но и внешней по отношению к ней среды (надсистемы или метасистемы), и определение границы между ними.
Перспективой развития документальных информационно-поисковых систем и баз данных являются банки знаний, новая концепция информационной системы, использующая результаты исследований и разработок в области искусственного интеллекта.
Безопасность данных в Oracle 7
Ограничение доступа
Если мы уверены, что подключаться к нашей базе данных могут лишь уполномоченные пользователи и что они могут запускать только те модули, на выполнение которых им явно предоставлено право, то нужно подумать о следующем уровне безопасности — ограничении доступа этих пользователей к данным.
Огромным шагом вперед в обеспечении безопасности данных стало введение ролей в Oracle7. До Oracle7 каждому пользователю приходилось явно предоставлять права доступа к каждому объекту базы данных, который ему разрешено было использовать. Этот процесс упрощается за счет того, что доступ к совокупности объектов предоставляется роли, а затем право на использование этой роли предоставляется соответствующим лицам. С помощью команды GRANT мы можем предоставить пользователям право выполнять над объектами БД (например, над таблицами) операции SELECT, INSERT, UPDATE и DELETE. Однако само по себе это не обеспечивает значительной гибкости. Мы можем ограничить доступ пользователей частями таблицы, разделив ее по горизонтали (ограничив пользователя определенными строками), по вертикали (ограничив его определенными столбцами) или и по горизонтали, и по вертикали. Как это сделать?
Вернемся к нашему примеру с таблицей PAYROLL. Мы не хотим, чтобы все пользователи видели столбец SALARY, и желаем ограничить доступ пользователей так, чтобы они могли видеть только записи о сотрудниках их отдела.
Таблица PAYROLL
| ID | NAME | DEFT | PAYMENT_PERIOD | SALARY |
| 1 | JONES | 10 | WEEKLY | 120 |
| 2 | K1RKUP | 10 | MONTHLY | 900 |
| 3 | DAVIES | 10 | WEEKLY | 150 |
| 4 | ARMSTRONG | 20 | MONTHLY | 1030 |
| 5 | KEMP | 20 | MONTHLY | 1005 |
| 6 | FISHER | 30 | WEEKLY | 150 |
Мы можем определить представление и предоставить пользователям доступ к этому представлению, а не к базовой таблице (PAYROLL). Они смогут запрашивать данные этой таблицы лишь через представление, которое ограничивает их доступ. Определение такого представления приведено ниже.
CREATE VIEW vjpayroll AS SELECT id
, name , dept
, payment_period FROM payroll WHERE dept = (SELECT dept
FROM mysys_users WHERE username = USER) WITH CHECK OPTION;
Столбец SALARY в этом примере не включен в представление, поэтому зарплату в нем увидеть нельзя, а фраза WHERE гарантирует, что пользователи смогут запрашивать данные из таблицы PAYROLL только по своему отделу.
По поводу этого решения надо сказать следующее. Во-первых, мы должны сделать так, чтобы пользователи не могли изменить свой отдел, обновив значение MYSYSJUSERS, и затем запросить записи из другого отдела. Во-вторых, с помощью этого представления пользователи могли бы обновлять, вставлять и удалять даже не относящиеся к их отделу строки таблицы PAYROLL, если бы мы не отключили эту функцию с помощью фразы WITH CHECK OPTION.
Примечание
Вряд ли представление V_PAYROLL будет обновляемым, потому что к столбцу SALARY почти наверняка применено ограничение NOT NULL. Тем не менее, мы рекомендуем использовать опцию WITH CHECK OPTION во всех ограничивающих представлениях, так как в версии 7.3 значительно увеличилось число обновляемых представлений.
Ограничение на просмотр данных с помощью представлений работает очень хорошо. Но для большой таблицы со сложными требованиями к безопасности, возможно, придется создать несколько представлений и заставить приложения решать, какое из них необходимо для конкретного пользователя. Реализовывать это внутри приложения нежелательно, поэтому нужно исследовать другие решения. Мы можем инкапсулировать все операции над таблицей PAYROLL в хранимый пакет или же разработать несколько триггеров. Давайте рассмотрим первое решение.
Использование пакетов
В пакете есть методы (процедуры/функции), позволяющие оперировать таблицей или запрашивать из нее строки. Пользователю, у которого есть разрешение на выполнение пакета, но нет полномочий на доступ к таблице, содержимое и структура таблицы непосредственно недоступны. Владелец пакета имеет полный доступ к PAYROLL, а вызывающий пользователь — нет. Когда пользователь выполняет хранимую процедуру, т.е., по сути, использует представление, он действует с разрешением на доступ, предоставленным ее владельцу.