Защита баз данных

 

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, а вызывающий пользователь — нет. Когда пользователь выполняет хранимую процедуру, т.е., по сути, использует представление, он действует с разрешением на доступ, предоставленным ее владельцу.

Наша первая попытка  создать такой пакет представлена в примере 10.2. Пакетk_payroll гарантирует, что записи могут удаляться только начальником отдела и что устанавливать значение столбца SALARY может только начальник отдела.

Пример  построения пакета для обеспечения безопасности доступа к данным

CREATE OR REPLACE PACKAGE k_payroll AS my_dept payroll.dept%TYPE; mgr     BOOLEAN;

PROCEDURE del (p_emp_id INTEGER);

PROCEDURE ins (p_emp_id INTEGER, p_name VARCHAR2              

 ,p_dept INTEGER, p_payment_period VARCHAR2             

 ,p_salary INTEGER);

PROCEDURE upd (p_emp__id INTEGER, p_name VARCHAR2              

 ,p_payment_penod VARCHAR2 ,p_salary INTEGER);

END k_payroll;

/

 

CREATE OR REPLACE PACKAGE BODY k_payroll AS

mgr_flag payroll.mgr_flag%TYPE;

CURSOR c_me IS     

  SELECT dept,       

       mgr_flag    

   FROM  mysys_users      

 WHERE  username = USER;

FUNCTION checkdept (p_emp_id INTEGER) RETURN BOOLEAN IS

dept payroll.dept%TYPE;

CURSOR cjpayroll IS      

 SELECT pay.dept      

 FROM  payroll pay      

 WHERE  id = p_emp_id;

BEGIN 

OPEN  c_payroll ; 

FETCH cjpayroll INTO dept; 

CLOSE c_payroll; 

IF dept <> my_dept THEN   

 RETURN FALSE; 

END IF; 

RETURN TRUE;

END checkdept;

PROCEDURE del (p_emp_id INTEGER) IS

—  Удалять сотрудников могут только начальники их отделов

—  Записи таблицы Payroll 
BEGIN 

IF checkdept(p_emp_id) AND mgr THEN   

 DELETE payroll   

 WHERE  id = p_emp_id; 

ELSE   

 raise_application_error (-20001, 'Insufficient Privilege');                                      END IF;

END del;

PROCEDURE ins (p_emp_id INTEGER, p_name VARCHAR2              

 ,p—dept INTEGER             

 ,payment_period VARCHAR2             

 ,p_salary INTEGER) IS

— Можете вставлять записи Payroll только в свой отдел 
~ Устанавливать зарплату может только начальник отдела

(в противном случае  устанавливается в пустое значение)

 

l_salary payroll.salary%TYPE;

BEGIN  

 IF NOT checkdept(p_emp_id) THEN     

 raise_application_error (-20001, 'Insufficient Privilege');  

 END IF;

IF NOT mgr THEN  

 l_salary := NULL; 

ELSE  

 l_salary := p_salary;

END IF; 

 INSERT INTO payroll (id,name,dept,payment_period, salary) 

 VALUES (p_erap_id,p_name,p_dept,p_payraent_period,l_salary);

END ins;

PROCEDURE upd (p_emp_id INTEGER, p_name VARCHAR2              

 ,p_payment_period VARCHAR2 ,p_salary INTEGER) IS

- Можете обновлять  записи Payroll только в своем отделе

- Обновлять зарплату может только начальник отдела 

 (в противном случае остается без изменений)

- Отдел изменять нельзя

l_salary payroll.salary%TYPE;

CURSOR c_old_salary IS      

 SELECT pay.salary      

 FROM  payroll pay      

 WHERE  id = p_erap_id;

BEGIN 

IF NOT checkdept (p_emp_id) THEN  

 raise applicatiori_error (-20001, 'Insufficient Privilege'); 

END IF; 

IF NOT mgr THEN  

 OPEN c_old_salary;  

 FETCH c__old_s alary INTO l__salary;  

 CLOSE c_old_salary, 

ELSE  

 l_salary := p_salary; 

END IF; 

UPDATE payroll 

SET    name = p_name      

 ,payment_period = p_payment_period      

 ,salary = l_salary 

WHERE  id = p_emp_id;

END upd;

-Код инициализации  пакета

BEGIN 

OPEN  c_me; 

FETCH c_me 

INTO ray_dept    

 ,mgr_flag; 

CLOSE c_me; 

IF mgr_flag = 'Y' THEN   

 mgr := TRUE; 

ELSE   

 mgr := FALSE; 

END IF;

END k_payroll;

/

 

Юридическая защита авторских прав на базы данных

 

Вопросы правовой защиты программ для ЭВМ и базы данных от незаконного использования являются очень актуальными в настоящий  момент. Для иллюстрации этого приведем несколько фактов. По данным Ассоциации производителей компьютерного обеспечения, уровень компьютерного пиратства в России составляет 94%. Уровень пиратства в странах Запада существенно ниже: в Германии - 50%, в США - 35%. По данным МВД РФ, потери российского бюджета от неуплаты налогов продавцами компьютерных программ составляют 85 млн. долл. Деньги, полученные от продажи, часто уходят в распоряжение криминальных структур. Кроме того, 105 млн. долл. теряют российские предприятия. В области разработки компьютерных программ и баз данных в стране работает около шести тысяч фирм, обеспечивающих занятость более 200 тыс. человек. Данной сфере производства грозит стагнация - программисты попросту теряют стимулы к созданию новых передовых программных продуктов.

 

Признание права –  первый из перечисленных в п. 1 ст. 18 Закона РФ «О правовой охране программ для ЭВМ и баз данных» способов защиты авторских прав. Этот способ защиты играет в основном превентивную роль и служит установлению определенности во взаимоотношениях субъектов гражданского права. Признание права как способ защиты применяется, когда оспаривается или отрицается принадлежность определенному лицу исключительных авторских прав на программу для ЭВМ или базу данных. Признание права как средство его защиты может быть реализовано лишь в судебном порядке путем подтверждения наличия или отсутствия у лица отдельных авторских правомочий или их совокупности.

 

П. 1 ст. 17 Закона РФ «О правовой охране программ для ЭВМ и баз  данных» определяет нарушителя авторского права как физическое или юридическое лицо, которое не выполняет требований настоящего закона в отношении исключительных прав правообладателей, в том числе ввозит в Российскую Федерацию экземпляры программы для ЭВМ или базы данных, изготовленные без разрешения их правообладателя. Это может выражаться в присвоении авторства, осуществлении перечисленных в ст. 10 Закона РФ «О правовой охране программ для ЭВМ и баз данных»  действий без разрешения правообладателя и т. д. Отдельное выделение импорта экземпляров программы для ЭВМ или базы данных, изготовленных без разрешения их правообладателей объясняется тем, что в государстве, где данные экземпляры были изготовлены, это действие может считаться законным и не влекущим ответственности.

 

Заключение 

 

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

 

К сожалению, подобная динамичность объективно затрудняет обеспечение надежной защиты. Причин тому несколько:

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

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

• появление новых информационных сервисов ведет и к появлению новых угроз как «внутри» сервисов, так и на их стыках;

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