Политика безопасности баз данных (стр. 3 из 5)

ALTER TABLE OPERS ADD COLUMN SPOT_CONF INTEGER DEFAULT 1

REFERENCES ACCESS_LEVELS (ACCESS_LEVEL_ID);

3.1.4 Таблица с информацией о работниках филиала

CREATE SEQUENCE WORKERS_ID;

CREATE TABLE WORKERS (WORKERS_ID INTEGER NOT NULL PRIMARY KEY DEFAULT NEXTVAL ('KLIENTS_ID'),

NAME VARCHAR (30),

SEX CHAR (1),

BIRTHDAY DATE,

CONSTRAINT VALID_SEX CHECK (SEX IN ('Ж','М ’)));

COMMENT ON TABLE PERSONS IS

'ТАБЛИЦА ИНФОРМАЦИИ О РАБОТНИКАХ ФИЛИАЛА;

Для создания механизма управления метками при доступе пользователей и групп пользователей к таблице persons выполним следующую последовательность шагов.

Шаг 1. Создать справочник уровней доступа с помощью команды, пример которой представлен ниже.

CREATE TABLE ACCESS_LEVELS (ACCESS_LEVEL_ID INTEGER PRIMARY KEY,

ACCESS_LEVELVARCHAR UNIQUE) ;

INSERT INTO ACCESS_LEVELS VALUES (1,'дляобщегодоступа');

INSERT INTO ACCESS_LEVELS VALUES (2,'для внутреннего использования');

INSERT INTO ACCESS_LEVELS VALUES (3,'секретно');

INSERT INTO ACCESS_LEVELS VALUES (4,'совершенносекретно');

Шаг 2. Создать таблицу, содержащую матрицу уровней доступа групп пользователей, пример которой представлен ниже.

DROP TABLE GROUPS_ACCESS_LEVEL;

CREATE TABLE GROUPS_ACCESS_LEVEL (GROUP_NAME VARCHAR PRIMARY KEY,

ACCESS_LEVEL INTEGER REFERENCES

ACCESS_LEVELS (ACCESS_LEVEL_ID));

Шаг 3. Разграничить права на таблицу groups_access_level:

REVOKE ALL ON GROUPS_ACCESS_LEVEL FROM GROUP USERS;

GRANT SELECT ON GROUPS_ACCESS_LEVEL TO GROUP USERS;

Шаг 4. Присвоить группе users необходимый уровень доступа

INSERT INTO GROUPS_ACCESS_LEVEL VALUES ('users',2);

Шаг 5. Добавить в таблицу БД Klients поле с описанием меток конфиденциальности записей spot_conf:

ALTER TABLE WORKERS ADD COLUMN SPOT_CONF INTEGER DEFAULT 1

REFERENCES ACCESS_LEVELS (ACCESS_LEVEL_ID);

3.2 Реализация принудительного управления доступом в СУБД

Принудительное управление доступом основано на сопоставлении меток безопасности субъекта и объекта. Способ управления доступом называется принудительным, поскольку он не зависит от воли субъектов (даже системных администраторов). После того, как зафиксированы метки безопасности субъектов и объектов, оказываются зафиксированными и права доступа.

Правила использования меток:

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

субъект может записывать информацию в объект, если метка безопасности объекта совпадает (или доминирует) с меткой субъекта.

Реализация принудительного управления доступом в СУБД

Для реализации полномочного управления доступом необходимо разрабатывать

дополнительный механизм, включающий:

механизмы ограничения доступа по чтению субьектами данных таблиц с учетом имен правил управления доступом по чтению данных;

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

В СУБД PostgreSQL вышеописанные пункты механизма можно создать через:

создание виртуальной таблицы (view), учитывающей таблицу БД, таблицу уровней доступа и имя текущего пользователя, работающего с БД;

создание правил (rules), перехватывающих операции внесения, изменения и удаления, выполняемых пользователями над таблиц БД

3.2.1 Реализация принудительного управления доступом в таблице "КЛИЕНТЫ"

Для реализации принудительного управления доступом к таблице KLIENTS со стороны пользователей и групп пользователей СУБД необходимо выполнить следующие шаги.

Шаг 1. Создать виртуальную таблицу (view), учитывающую таблицу KLIENTS, таблицу уровней доступа, имя текущего пользователя, работающего с БД, позволяющую в дальнейшем разграничить доступ пользователей к отдельным записям таблицы KLIENTS.

CREATE OR REPLACE VIEW KLIENTS_LIST AS

SELECT PERSON_ID, NAME, SEX, BIRTHDAY

FROM PG_GROUP G, PG_USER U, KLIENTS P,

GROUPS_ACCESS_LEVEL L

WHERE

USENAME = CURRENT_USER AND

U. USESYSID = ANY (G. GROLIST) AND

L. GROUP_NAME = G. GRONAME AND

P. SPOT_CONF <= L. ACCESS_LEVEL;

При создании таблицы используется:

функция CURRENT_USER, возвращающая имя текущего пользователя.

функция ANY (G. GROLIST) возвращающая любое из значений массива G. GROLIST

Шаг 2. Для того, чтобы пользователи могли работать только с виртуальной таблицей,

необходимо снять права доступа с реальной таблицы БД и установить права на чтение на виртуальную.

Снять права доступа к реальной таблицы:

REVOKE ALL ON KLIENTS FROM GROUP USERS;

Установить права доступа на виртуальную таблицу:

GRANT SELECT ON KLIENTS_LIST TO GROUP USERS;

Шаг 3. Проверить работу механизма

Заполнить таблицу persons тестовыми данными:

INSERT INTO KLIENTS_LIST VALUES (1,'ABC','ФИРМА','12-11-1980');

UPDATE KLIENTS SET SPOT_CONF = 1;

INSERT INTO KLIENTS _LIST VALUES (1,'IBM','ФИРМА','30-12-1988');

UPDATE KLIENTS SET SPOT_CONF = 1;

INSERT INTO KLIENTS_LIST VALUES (1,'IVANOV','М','11-10-1965');

UPDATE KLIENTS SET SPOT_CONF = 1;

INSERT INTO KLIENTS_LIST VALUES (1,'PETROV','М','17-02-1989');

UPDATE KLIENTS SET SPOT_CONF = 1;

INSERT INTO KLIENTS_LIST VALUES (1,'SIDOROV','М','23-05-1975');

UPDATE KLIENTS SET SPOT_CONF = 1;

Для проверки работы механизма необходимо соединиться с БД, используя имя пользователя ABC.

Выполнить пользователем director два запроса для проверки работы механизма:

SELECT FROM KLIENTS;

SELECT FROM KLIENTS_LIST;

Изменить метку конфиденциальности отдельных записей пользователем-администратором:

UPDATE KLIENTS SET SPOT_CONF = 3 WHERE KLIENTS_ID = 2;

Повторно проверить работу механизма пользователем ABC:

SELECT FROM KLIENTS_LIST;

Шаг 4. Создать правила (rules), перехватывающие операции внесения, изменения и

удаления, выполняемые пользователями над таблиц KLIENTS

Создать правило на операции внесения, пример которого представлен ниже:

DROP RULE KLIENTS_LIST_INSERT ON KLIENTS_LIST;

CREATE RULE KLIENTS_LIST_INSERT AS ON INSERT TO

KLIENTS _LIST

DO INSTEAD

INSERT INTO KLIENTS

SELECT CASE WHEN NEW. KLIENTS _ID IS NULL

THEN NEXTVAL (' KLIENTS _ID') ELSE NEW. KLIENTS _ID END,

NEW. NAME, NEW. SEX, NEW. BIRTHDAY, L. ACCESS_LEVEL

FROM PG_GROUP G, PG_USER U, GROUPS_ACCESS_LEVEL L

WHERE

U. USENAME = CURRENT_USER AND

U. USESYSID = ANY (G. GROLIST) AND

L. GROUP_NAME = G. GRONAME;

Предоставить права на внесение записей в виртуальной таблице:

GRANT INSERT ON KLIENTS _LIST TO GROUP USERS;

GRANT SELECT,UPDATE ON KLIENTS _ID TO GROUP USERS;

Проверить работу механизма:

INSERT INTO KLIENTS _LIST VALUES (21,'IVANOV','М','10-10-1980');

Создать правило на операции изменения, пример которого представлен ниже:

DROP RULE KLIENTS _LIST_UPDATE ON KLIENTS _LIST;

CREATE RULE KLIENTS _LIST_UPDATE AS ON UPDATE

TO KLIENTS _LIST

DO INSTEAD

UPDATE KLIENTS SET KLIENTS _ID = NEW. KLIENTS _ID,

NAME = NEW. NAME, SEX = NEW. SEX, BIRTHDAY = NEW. BIRTHDAY,

SPOT_CONF = L. ACCESS_LEVEL

FROM PG_GROUP G, PG_USER U, GROUPS_ACCESS_LEVEL L

WHERE

KLIENTS _ID = OLD. KLIENTS _ID AND

SPOT_CONF = L. ACCESS_LEVEL AND

U. USENAME = CURRENT_USER AND

U. USESYSID = ANY (G. GROLIST) AND

L. GROUP_NAME = G. GRONAME;

Предоставить права на изменение записей в виртуальной таблице:

GRANT UPDATE ON KLIENTS _LIST TO GROUP USERS;

Проверить работу правила:

UPDATE KLIENTS _LIST SET NAME = 'IVANOV' WHERE KLIENTS _ID = 21;

Создание правил на операции удаления, пример которого представлен ниже:

DROP RULE KLIENTS _LIST_DELETE ON KLIENTS _LIST;

CREATE RULE KLIENTS _LIST_DELETE AS ON DELETE TO

KLIENTS _LIST

DO INSTEAD

DELETE FROM KLIENTS WHERE

KLIENTS _ID = OLD. PERSON_ID AND

SPOT_CONF = GROUPS_ACCESS_LEVEL. ACCESS_LEVEL AND

PG_USER. USENAME = CURRENT_USER AND

PG_USER. USESYSID = ANY (PG_GROUP. GROLIST) AND

GROUPS_ACCESS_LEVEL. GROUP_NAME = PG_GROUP. GRONAME;

Предоставить права на удаление записей в виртуальной таблице:

GRANT DELETE ON KLIENTS_LIST TO GROUP USERS;

Проверить работу механизма:

DELETE FROM KLIENTS_LIST WHERE KLIENTS_ID = 2;

3.2.2 Реализация принудительного управления доступом в таблице "ОПЕРАЦИОНИСТЫ"

Для реализации принудительного управления доступом к таблице OPERS со стороны пользователей и групп пользователей СУБД необходимо выполнить следующие шаги.

Шаг 1. Создать виртуальную таблицу (view), учитывающую таблицу OPERS, таблицу уровней доступа, имя текущего пользователя, работающего с БД, позволяющую в дальнейшем разграничить доступ пользователей к отдельным записям таблицы OPERS.

CREATE OR REPLACE VIEW OPERS_LIST AS

SELECT OPERS_ID, NAME, SEX, BIRTHDAY

FROM PG_GROUP G, PG_USER U, KLIENTS P,

GROUPS_ACCESS_LEVEL L

WHERE

USENAME = CURRENT_USER AND

U. USESYSID = ANY (G. GROLIST) AND

L. GROUP_NAME = G. GRONAME AND

P. SPOT_CONF <= L. ACCESS_LEVEL;

При создании таблицы используется:

функция CURRENT_USER, возвращающая имя текущего пользователя.

функция ANY (G. GROLIST) возвращающая любое из значений массива G. GROLIST

Шаг 2. Для того, чтобы пользователи могли работать только с виртуальной таблицей,

необходимо снять права доступа с реальной таблицы БД и установить права на чтение на виртуальную.

Снять права доступа к реальной таблицы:

REVOKE ALL ON OPERS FROM GROUP USERS;

Установить права доступа на виртуальную таблицу:

GRANT SELECT ON OPERS_LIST TO GROUP USERS;

Шаг 3. Проверить работу механизма

Заполнить таблицу persons тестовыми данными:

INSERT INTO OPERS_LIST VALUES (1,'SALMIN','M','15-10-1988');

UPDATE OPERS SET SPOT_CONF = 1;

INSERT INTO OPERS_LIST VALUES (1,KIRICHUK','M','30-12-1988');

UPDATE OPERS SET SPOT_CONF = 1;

Для проверки работы механизма необходимо соединиться с БД, используя имя пользователя ABC.

Выполнить пользователем director два запроса для проверки работы механизма:

SELECT FROM OPERS;

SELECT FROM OPERS_LIST;

Изменить метку конфиденциальности отдельных записей пользователем-администратором:

UPDATE OPERS SET SPOT_CONF = 3 WHERE OPERS_ID = 2;

Повторно проверить работу механизма пользователем ABC:

SELECT FROM OPERS_LIST;

Шаг 4. Создать правила (rules), перехватывающие операции внесения, изменения и

удаления, выполняемые пользователями над таблиц OPERS

Создать правило на операции внесения, пример которого представлен ниже:

DROP RULE OPERS_LIST_INSERT ON OPERS_LIST;

CREATE RULE OPERS_LIST_INSERT AS ON INSERT TO

OPERS_LIST

DO INSTEAD

INSERT INTO OPERS

SELECT CASE WHEN NEW. OPERS _ID IS NULL

THEN NEXTVAL (‘ OPERS _ID') ELSE NEW. OPERS_ID END,

NEW. NAME, NEW. SEX, NEW. BIRTHDAY, L. ACCESS_LEVEL

FROM PG_GROUP G, PG_USER U, GROUPS_ACCESS_LEVEL L

WHERE

U. USENAME = CURRENT_USER AND

U. USESYSID = ANY (G. GROLIST) AND

L. GROUP_NAME = G. GRONAME;

Предоставить права на внесение записей в виртуальной таблице:

GRANT INSERT ON OPERS_LIST TO GROUP USERS;

GRANT SELECT,UPDATE ON OPERS_ID TO GROUP USERS;

Проверить работу механизма:

INSERT INTO KLIENTS _LIST VALUES (21,'IVANOV','М','10-10-1980');

Создать правило на операции изменения, пример которого представлен ниже:

DROP RULE OPERS_LIST_UPDATE ON OPERS_LIST;

CREATE RULE OPERS_LIST_UPDATE AS ON UPDATE

TO OPERS_LIST

DO INSTEAD

UPDATE OPERS SET OPERS_ID = NEW. OPERS_ID,

NAME = NEW. NAME, SEX = NEW. SEX, BIRTHDAY = NEW. BIRTHDAY,

SPOT_CONF = L. ACCESS_LEVEL