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

FROM PG_GROUP G, PG_USER U, GROUPS_ACCESS_LEVEL L

WHERE

OPERS_ID = OLD. OPERS_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 OPERS_LIST TO GROUP USERS;

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

UPDATE OPERS_LIST SET NAME = 'SALMIN' WHERE OPERS_ID =1;

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

DROP RULE OPERS_LIST_DELETE ON OPERS_LIST;

CREATE RULE OPERS_LIST_DELETE AS ON DELETE TO

OPERS_LIST

DO INSTEAD

DELETE FROM OPERS WHERE

OPERS_ID = OLD. OPERS_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 OPERS_LIST TO GROUP USERS;

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

DELETE FROM OPERS_LIST WHERE OPERS_ID = 2;

4. Реализация требований стандарта по критерию "подотчётность"

4.1 Обеспечение идентификации и аутентификации

Записи в файле могут иметь следующие формы:

local имя_БД имя_пользователя метод_доступа

host имя_БД имя_пользователя IP-адрес метод_доступа

hostssl имя_БД имя_пользователя IP-адрес метод_доступа

Первое поле записи - тип соединения:

local - Unix-сокет соединение без использования протокола TCP/IP,

host - соединение с использованием протокола TCP/IP

hostssl - соединение с использованием протокола TCP/IP SSL-протокола

Второе поле - имя БД, может принимаит значения:

all - разрешен доступ ко всем БД СУБД

sameuser - разрешен доступ к БД, имя которой совпадает с именем пользователя

имя БД или список имен, разделенных запятой

Третье поле - имя пользователя или список имен, разделенных запятой

Четвертое поле - IP-адрес компьютера, которому разрешен доступ или маска адреса.

Пятое поле - метод доступа:

trust - доступ без пароля

reject - доступ запрещен

password - доступ по нешифруемому паролю

crypt - доступ по шифруемому паролю алгоритмом crypt

md5 - доступ по шифруемому паролю алгоритмом md5

4.2 Построим таблицу для пользователей нашей БД

Тип соединения	Имя БД	Имя пользователя	IP:	Тип аути/и:
host	Банк	АВС	183.22.12.1	md5
host	Банк	IBM	183.22.12.2	md5
hostssl	Банк	Иванов А.А.	183.22.12.3	md5
hostssl	Банк	Петров П.П.	183.22.12.4	md5
hostssl	Банк	Сидоров В.Г.	183.22.12.5	md5
hostssl	Банк	Джавров В.Г.	183.22.12.6	md5
hostssl	Банк	Салмин Ю.Л.	184.22.12.1	md5
hostssl	Банк	Киричук А.Г.	184.22.12.2	md5
hostssl	Банк	Корниенко В.А.	127.0.0.1	trust
local	Банк	Манько А.А.	183.22.12.2	md5
local	Банк	Яновский Г.Х.	184.22.12.3	md5

4.3 Обеспечение надежного пути

4.3.1 Способы обеспечения надежного пути

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

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

Распределение может осуществляться двумя способами:

1. Путем создания центра генерации и распределения ключей;

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

Недостатки первого подхода:

центр владеет полной информацией о том, кто и какой ключ использует.

компрометация центра распределения приводит к компрометации всей передаваемой между абонентами этого центра информации.

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

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

Подтверждение достоверности абонентов может осуществляться таким образом:

1. Непосредственно между абонентами.

2. С использованием посредника (арбитра).

3. С использованием двух и более посредников.

Непосредственный обмен между абонентами применяется в том случае, если абонентов всего двое. Для обмена ключами в данном случае может быть использован алгоритм распределения ключей Дифи-Хелмана. Однако такой способ имеет следующими недостатками:

в распределенных сетях, которые насчитывают не один десяток абонентов такой обмен осложняется;

возможна атаки "человек посередине".

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

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

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

4.3.2 Общие подходы использования сертификатов в web-технологиях

Эффективность использования сертификатов оказалась при создании web-технологий доступа клиентов, которые используют web-навигатор, к ресурсам, которые предоставляются web-сервером. Для того, чтобы навигатор смог успешно аутентифікувати web-сервер, необходимо создавать правильный сертификат web-сервера, который будет содержать:

открытый ключ web-сервера;

даты достоверности (начала и окончания);

поддерживаемые алгоритмы шифровки

уникальное имя (Distinguish Name - DN), которое должно содержать полностью определенное доменное имя web-сервера, званое общим именем (Common Name - CN). Опционально DN может содержать и некоторые другие атрибуты, например, страну (Country - С), штат (State - S), Расположение (Location - L), назову организации (Organization's name - ON), назову службы организации (Organization Unit's name - OU), и другие.

серийный номер сертификата;

атрибуты X.509v3, которые будут сообщать web-навигатору о типе и употреблении

имя и подпись доверенного источника сертификатов (Certification Authority - CA)создание сертификатов можно использовать утилиту ореnssl, которая включает много сервисов по криптографическим алгоритмам.

Существует три типа сертификатов, которые можно использовать в web-технологиях:

1. Самоподписанный сертификат.

2. Сертификат, подписанный доверенным центром сертификации (CA).

3. Сертификат, подписанный местным CA.

4.3.3 Создание сертификата, подписанного доверенным центром сертификации

Алгоритм создания сертификата имеет следующие шаги:

Шаг 1. Создание пара закрытого/открытого ключа (файл server. key) и запроса сертификата (файл request. pem):

ореnssl req - new - sha1 - newkey rsa: 1024 - nodes - keyout server. key - out request. pem \

subj '/O=BANK /OU=KARAMANOV. BANK /CN=www.karamanov. bank. od.ua'

Сертификат также может быть подписан алгоритмами: md5, sha1, md2, mdc2.

Для проверки подписи запроса на сертификат, расположенного в файле request. pem, и просмотр содержания запроса в текстовом виде использовать команды: ореnssl req - іn request. pem - text - verify –noout

Параметр "-text" позволяет вывести содержание сертификата в текстовом виде, параметр "verify" проверяет подпись запроса, созданную по алгоритму SHA1.

Шаг 2. Отсылка запроса на получение сертификата (request. pem) в СА и ожидание, пока он будет подписан и отослан назад в виде сертификата.

Шаг 3. По получении сертификата от доверенного СА необходимо удостовериться в том, что он закодирован в формате PEM, а не TXT или DER. Если же полученный сертификат не отвечает формату РЕМ, то необходимо конвертировать его в каком бы формате он не пришел. Команда для конвертации формата TXT + PEM в РЕМ:

ореnssl x509 -іn server. pem - out server. Crt

Шаг 4. Верификация и тестирование сертификата

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

ореnssl x509 - noout - modulus - іn server. Crt

В вышеописанных командах параметр - modulus позволяет получить из сертификата файла

server. crt или закрытого /відкритого ключа файла server. keyвідкритий ключ. Используя конвеер данных результаты команд пропускаются через хеш-функцию. Если результаты работы двух функций одинаковые, полученный сертификат отвечает раньше созданному закрытому ключу.