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

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

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

В СУБД 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

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відкритий ключ. Используя конвеер данных результаты команд пропускаются через хеш-функцию. Если результаты работы двух функций одинаковые, полученный сертификат отвечает раньше созданному закрытому ключу.

4.3.4 Создание самоподписанного сертификата (сертификата местного центра сертификации)

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

Для использования этого способа необходимо создать:

локальный закритий/відктритий ключ СА;

сертификат СА;

репозиторий СА для новых ключей.

Для обеспечения надежности всей системы сертификации необходимо выполнить

следующие условия:

локальный СА должен быть создан на отдельном сервере, который не имеет соединения

с сетью;

операционная система должна давать доступ только авторизованному персоналу;

сервер СА должен быть под охраной.

Частный СА ключ - самый важный элемент всей системы - если он будет компрометируемый, то все другие сертификаты, подписанные этим СА также будут

компрометируемые.

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

Шаг 1. Подготовить структуру каталога для нового СА:

set SSLDIR=c: \ca

mkdir%SSLDIR%

mkdir%SSLDIR%\certs

mkdir%SSLDIR%\crl

mkdir%SSLDIR%\newcerts

mkdir%SSLDIR%\private

mkdir%SSLDIR%\requests

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

созданных сертификатах.

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

идентификатору сертификата в hex-формате:

echo 01 >%SSLDIR%\serial

можно создать *. bat файл с данными командами и запустить его.

Шаг 2. Создать основной файл настроек центра сертификации

Название файла, например, openssl. cnf. Пример содержания файла (оптимизировано для

использования с SSL веб-серверами):

# =================================================

# OpenSSL configuration file

# =================================================

RANDFILE = $ENV:: SSLDIR/. rnd

[ca]

default_ca = CA_default

[CA_default]

# Название каталога CA

dir = c: \ca

# Название каталога с сертификатами

сеrts = $dir/certs

# Название каталога с новыми сертификатами, название файла в виде ідентифікатор. pem

(01. pem, 02. pem)new_certs_dir = $dir/newcerts

# Название каталога с CRL-файлами (Certificate Revocation List - Список Аннулированных

Сертификатов)crl_dir = $dir/crl

# Название текстового файла, который будет содержать информацию о созданных

сертификатах

database = $dir/index. txt

# Название текстового файла с секретным ключом CA

private_key = $dir/private/ca. key

# Название текстового файла с сертификатом CA

сеrtificate = $dir/ca. crt

# Название текстового файла, который содержит следующее значение идентификатору

сертификата в hex-формате

serial = $dir/serial

crl = $dir/crl. pem

RANDFILE = $dir/private/. rand

# Период действия сертификата

default_days = 365

# Период обновления CRL-файлов

default_crl_days = 30

# Тип хеш-функции, что используется при установлении подписи

default_md = sha1

# Тип поведения системы при определении значений DN-атрибутов сертификата

preserve = no

# название секции с характеристиками переменных, которые входят к DN-атрибутам

сертификата

policy = policy_anything

name_opt = ca_default

cert_opt = ca_default

# Секция содержит значение переменных, которые входят к DN-атрибутам сертификата менно значение, что и атрибут CA - сертификата. Если значение переменной = 'supplied', то атрибут должен содержаться в сертификате. Если значение переменной = 'optional', то атрибут может содержаться в сертификате. Атрибуты, которые не представлены в секции, будут удалены, если значение переменной preserve = on или опция - preserveDN отсутствует в командной строке.

[policy_anything]

countryName = Karamanov. Bank

stateOrProvinceName = Alexey Karaamnov

localityName = kaa

organizationName = bank

organizationalUnitName = xxx

commonName = xxxx

emailAddress = onpu@i.ua

Шаг 3. Создать пару СА закрытый/открытый ключ и самоподписанный сертификат СА:

ореnssl req \

config $SSLDIR$/openssl. cnf - new - x509 - nodes - days 3652 - sha1 - newkey rsa: 1024 \

keyout $SSLDIR$/private/ca. key - out $SSLDIR$/ca. crt \

subj

'/C=UA/ST=OdessaRegion/L=Odessa/O=Karamanov. Bank /OU=bank /CN=www.karamanov. bank. od.ua'

Команда создает новый (-new) самоподписанный root-сертификат (-x509), который будет

подписан с использованием алгоритма SHA1 (-sha1). Закрытый (частный) ключ RSA будет иметь длину 1024 бит (-newkey rsa: 1024), не будет защищен парольной фразой (-nodes). Запрос на сертификат, что включает открытый ключ, будет содержаться в файле request. pem, а закрытый ключ будет создан в файле "server. key". Параметр "-subj" говорит о том, что сертификат создан для компании, которая расположена в Украине (C=UA), в одесском регионе (ST=OdessaRegion), название компании "ONPU" (O=ONPU), название службы "kaf_SPO" (OU=kaf_SPO), и полностью определенное доменное имя "www.spo. ospu. odessa.ua" #@:. Сертификат может использоваться 10 лет #@;

После выполнения команды будут созданы файлы:

файл ca. key с закрытым ключом центра сертификации;

файл ca. crt с сертификатом.

создали закрытый ключ:

создали сертификат:

4.3.5 Подписание сертификатов с использованием сертификата центра сертификации

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

Шаг 1. Создать пар закрытый/открытый ключ веб-сервера (файл web_server. key), и запрос на сертификат (файл web_request. pem), используя команды:

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

subj '/O=karamanov. bank /OU=web-server/CN= www.karamanov. bank. od.ua'

Шаг 2. Скопировать запрос на сертификат (файл web_request. pem) в директорию $SSLDIR/requests на узле центра сертификации.

Шаг 3. Подписать запрос на сертификат:

ореnssl ca - cert%SSLDIR%/server. crt - keyfile%SSLDIR%/server. key \

config%SSLDIR%/openssl. cnf - policy policy_anything \

noemailDN - out%SSLDIR%/requests/signed. pem \

infiles%SSLDIR%/requests/web request. Pem

В результате выполнения этих команд будет подписан сертификат (файл signed. pem), который будет находится в каталоге $SSLDIR/newcerts, и в файле $SSLDIR/signed. pem.

4.3.6 Аннулирование сертификатов

Для местных СА в случае компрометации сертификата строго рекомендуется аннулировать сертификат и информировать пользователей о том, что сертификат больше не действительный. Для аннулирования сертификата необходимо отыскать его серийный номер в файле $SSLDIR/index. txt.

V 031237770121C 01 unknown /O=alexey. karamanov/OU=web_server/CN=karamanov. bank. od.ua’

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

ореnssl ca - config $SSLDIR/openssl. cnf - revoke $SSLDIR/newcerts/01. pem

Для создания CRL-файла (Certificate Revocation List - Список Аннулированных Сертификатов), необходимо выполнить команды:

ореnssl ca - config $SSLDIR/openssl. cnf - gencrl - crlexts crl_ext - md sha1 - out $SSLDIR/crl. Pem

Этот файл должен быть опубликован на сайте центра сертификации. В процессе распространения CRL-файлов также рекомендуется использовать Online Certificate Status Protocol (OCSP).

4.3.7 Создание клиентского сертификата

Создание личного клиентского сертификата очень похоже на создание сертификата web - сервера. Единственное отличие заключается в том, что используются другие расширения X.509v3 (секция "ssl_client" с openssl. cnf), а формат хранения закрытого ключа и сертификата - PKCS#12

(также называется PFX). Действия, которые необходимо выполнить для создания клиентского сертификата:

Шаг 1. Создать предназначенный для пользователя пар закрытый/открытый ключ вместе с запросом на сертификат. Если выделенный сервер не используется для обслуживания сертификата, то на машине пользователя необходимо выполнить следующие команды:

ореnssl req - new - sha1 - newkey rsa: 1024 - nodes - keyout client. key \

out request. pem - subj '/O=bank /OU=karamanov. bank/CN=director

Шаг 2. Послать запрос на сертификат (request. pem) в сервер местного центра СА для подписи.

Шаг 3. Задача местного СА - проверить или правильно пользователь заполнил поля в запросе на сертификат.

Шаг 4. После верификации запрос на сертификат (request. pem) скопировать в каталог $SSLDIR/requests на сервере СА.

Шаг 5. Местный СА должен подписать сертификат, используя команды:

ореnssl ca \

plain-config $SSLDIR/openssl. cnf - policy policy_anything - еxtensions ssl_client \

plain-out $SSLDIR/requests/signed. pem - іnfiles $SSLDIR/requests/request. pem

Шаг 6. Отослать пользователю подписанный сертификат (signed. pem).

Шаг 7. По получении подписанного сертификата пользователю необходимо сберечь закрытый ключ вместе с сертификатом в формате PKCS#12, используя команды:

ореnssl pkcs12 - еxport - clcerts - іn signed. pem - іnkey client. key - out client. p12

Список литературы

1. Бабаш А.В., Гольев Ю.И., Ларин Д.А., Шанкин Г.П. О развитии криптографии в XIX веке // Защита информации. Конфидент. №5, 2003, с.90-96. (http://www.agentura.ru)2. Гольев Ю.И., Ларин Д.А., Тришин А.Е., Шанкин Г.П. Криптографическая деятельность в США XVIII-XIX веков. // Защита информации. Конфидент. №6, 2004, с.68-74.

3. Тейер Т., Липов М., Нельсон Э. Надежность программного обеспечения. - Пер. с англ. - М.: Мир, 1981.

4. Липаев В.В. Надежность программных средств. - М.: Синтег, 1998.

5. Кузнецов И.Н. Научные работы: методика подготовки и оформления. - Минск, 2000.

6. Понимание SQL. Мартин Грубер, Вильямс, 2003.