Курсовая работа: Политика безопасности баз данных
Аннотация
Целью данного курсового проекта является закрепление, систематизация, углубление и развитие теоретических и практических знаний, полученных студентами в процессе изучения дисциплины "Надёжность и безопасность программного обеспечения". Курсовая работа посвященна проблемам политики безопастности баз данных, гарантированности и средств подотчётности. Основная цель курсового проектирования состоит в изучении и анализе вопросов, связанных со специальными аспектами надёжности и безопасности программного обеспечения.
Содержание
2.1 Регистрация субъектов безопасности
2.2 Избирательное управление доступом
2.2.1 Описание привилегий доступа для клиентов
2.2.2 Описание привилегий доступа для директоров
2.2.3 Описание привилегий доступа для операционистов
2.2.4 Описание привилегий доступа для работников филиала
2.3 Создание представления субъекта об объекте
2.3.1 Создание схемы для директоров
2.3.2 Создание схемы для клиентов
2.3.3 Создание схемы для операционистов
2.3.4 Создание схемы для работников филиала
3. Реализация требований стандарта по критерию "Политика безопасности"
3.1 Создания механизма по управлению метками в СУБД.
3.1.1 Таблица с информацией о клиентах
3.1.2 Таблица с информацией о директорах.
3.1.3 Таблица с информацией об операционистах
3.1.4 Таблица с информацией о работниках филиала
3.2 Реализация принудительного управления доступом в СУБД
3.2.1 Реализация принудительного управления доступом в таблице "КЛИЕНТЫ"
3.2.2 Реализация принудительного управления доступом в таблице "ОПЕРАЦИОНИСТЫ"
4. Реализация требований стандарта по критерию "подотчётность"
4.1 Обеспечение идентификации и аутентификации
4.2 Построим таблицу для пользователей нашей БД
4.3 Обеспечение надежного пути
4.3.1 Способы обеспечения надежного пути
4.3.2 Общие подходы использования сертификатов в web-технологиях
4.3.3 Создание сертификата, подписанного доверенным центром сертификации
4.3.4 Создание самоподписанного сертификата (сертификата местного центра сертификации)
4.3.5 Подписание сертификатов с использованием сертификата центра сертификации
4.3.6 Аннулирование сертификатов
4.3.7 Создание клиентского сертификата
Введение
Знание критериев оценки информационной безопасности способно помочь при выборе и комплектовании аппаратно-программной конфигурации. Кроме того, в своей повседневной работе администратор безопасности вынужден хотя бы до некоторой степени повторять действия сертифицирующих органов, поскольку обслуживаемая система, скорее всего, время от времени претерпевает изменения и нужно, во-первых, оценивать целесообразность модификаций и их последствия, а, во-вторых, соответствующим образом корректировать повседневную практику пользования и администрирования. Если знать, на что обращают внимание при сертификации, можно сконцентрироваться на анализе критически важных аспектов, экономя время и силы и повышая качество защиты.
Одним из первых стандартов сертификации систем защиты стал стандарт Национального комитета компьютерной безопасности (National Committee of Computer Security, NСSC)"Критерии оценки доверенных компьютерных систем" (Trusted Computer System Evaliation Criteria, TCSEC) или "Orange Book" ("Оранжевая книга").
По стандарту "Оранжевая книга" критериями оценки надежной компьютерной системы являются:
политика безопасности;
гарантированность;
подотчетность (протоколирование);
документация.
Политика безопасности должна включать в себя по крайней мере следующие элементы:
произвольное управление доступом;
безопасность повторного использования объектов;
метки безопасности;
принудительное управление доступом.
Гарантированность:
операционная;
технологическая.
Средства подотчетности делятся на три категории:
идентификация и аутентификация;
предоставление надежного пути;
анализ регистрационной информации.
Документация
руководство пользователя по средствам безопасности;
руководство администратора по средствам безопасности;
тестовая документация;
описание архитектуры.
Цель работы - научиться включать элементы безопасности в информационные системы (ИС) на основе существующих стандартов проверки качества системы безопасности. Из национального стандарта США "Оранжевая книга" выбраны критерии оценки качества создания надежности, которые реализуются средствами системы управления базами данных на примере СУБД PostgreSQL.
Индивидуальное задание
Банк.
| 8 | Банк | 13,14,15 |
Інформаційна система банку.
Скорочений опис концептуальної схеми БД.
13. Інформація про операції філій, що не пройшли контроль (prohibitions):
порядковий номер заборони, назва філії, номер операції перекладу платежів для даної філії, код заборони, повідомлення про причину відхилення
14. Довідник з інформацією про об'єкти контролю (control_objects): тип об`єкту контролю. Типи об'єктів контролю: сума платежу операції, сума залишку по рахунках, сума обороту по рахунках.
15. Довідник з інформацією про час дії контролю (control_time): час дії. Типи часу дії контролю: постійний, щомісячний, тимчасовий.
1. Проектирование таблиц
Таблица 1. Prohibitions.
Информация про операции филиала, которые не прошли контроль.
| Порядковый номер запрета | Целое |
| Название филиала | Строка |
| Номер операции перевода платежей для даного филиала | Целое |
| Код запрета | Целое |
| Сообщение о причине отказа | Строка |
Create table “Prohibitions”
(“Порядковый номер запрета" integer,
“Название филиала", char (50)“Номер операции перевода платежей для даного филиала" integer,
“Код запрета" integer,
“Сообщение о причине отказа” char (100));
Таблица 2. Control_objects.
Справочник с информацией про обьекты контроля.
| Сумма платежа | Денежный |
| Сумма остатка на счету | Денежный |
| Сумма оборота на счету | Денежный |
Create table “Control_objects"
(“ Сумма платежа ” double,
"Сумма остатка на счету ” double,
"Сумма оборота на счету ” double);
Таблица 2. Control_time.
Справочник с информацией о времени действия контроля.
| Постоянный | Boolean |
| Ежемесячный | Boolean |
| Временный | Boolean |
Create table “Control_time”
( “ Постоянный ” Boolean,
“ Ежемесячный ” Boolean,
“ Временный ” Boolean );
2. Управление ролями
В версиях СУБД PostgreSQL меньших 8.1 при управлении субъектами использовались понятия "пользователь" и "группа" и соответствующие команды создания CREATE USER, CREATE GROUP. Для изменения параметров пользователя или группы ипользовались команды ALER USER и ALTER GROUP, соответственно. В версиях СУБД PostgreSQL начиная с 8.1 появился более гибкий механизм - роли.
2.1 Регистрация субъектов безопасности
Информационная система банка.
Групповые субъекты: клиенты, операционисты, директор филиала, работники филиала.
Индивидуальные субъекты: клиент "ABC", клиент “IBM”, клиент Иванов А.А., клиент Петров П.П., клиент Сидоров В. Г, операционист Джавров В.Г., операционист Салмин Ю.Л., операционист Киричук А.Г., директор Корниенко В.А., работник Манько А.А., работник Яновский Г.Х.
2.1.1 Регистрация субъектов
Регистрация индивидуальных субъектов:
Alter Role ABC login;
Alter Role IBM login;
Alter Role Ivanov login;
Alter Role Petrov login;
Alter Role Sidorov login;
Alter Role Djavr login;
Alter Role Salmin login;
Alter Role Kirich login;
Alter Role Kornienko login;
Alter Role Manko login;
Alter Role Yanovskiy login;
Регистрация групповых субъектов:
Alter Role Klient nologin;
Alter Role Director_Filii nologin;
Alter Role Worker_Filii nologin;
Alter Role Oper nologin;
2.1.2 Наследование ролей
Группировка индивидуальных субъектов безопасности.
Grant Klient To ABC;
Grant Klient To IBM;
Grant Klient To Ivanov;
Grant Klient To Petrov;
Grant Klient To Sidorov;
Grant Director_Filii To Kornienko;
Grant Oper To Djavr;
Grant Oper To Salmin;
Grant Oper To Kirich;
Grant Worker_Filii To Manko;
Grant Worker_Filii To Yanovskiy;
2.2 Избирательное управление доступом
Механизм представлений языка SQL позволяет различными способами разделить базу данных на части таким образом, чтобы очень важная информация была скрыта от несанкционированных пользователей.
2.2.1 Описание привилегий доступа для клиентов
Create Table Klients
(Klient_ID, - -идентификатор клиента
Name_Klient, - -имя клиента
Data_BD - -дата рождения клиента) Without oids;
Alter table Klients owner to Klient;
Comment on table Klient IS ’Информация о клиентах
Comment on column Klient. Klient_ID IS ‘Идентификатор клиента
Comment on column Klient. Name IS ‘Имя клиента
Comment on column Klient. Data_BD IS ‘Дата рождения клиента
Для установки привиллегий доступа используется команда:
GRANT список_привиллегий ON таблица TO роль
Grant select, insert ON Klients TO Klient
2.2.2 Описание привилегий доступа для директоров
Create Table Dirs
(Dir_ID, - -идентификатор
Name_Dir, - -имя
Data_BD - -дата рождения) Without oids;
Alter table Dirs owner to Director_Filii;
Comment on table Dirs IS ’Информация о директорах
Comment on column Dirs. Dir_ID IS ‘Идентификатор
Comment on column Dirs. Name_Dir IS ‘Имя
Comment on column Dirs. Data_BD IS ‘Дата рождения
Для установки привиллегий доступа используется команда:
GRANT список_привиллегий ON таблица TO роль
Grant select, insert, update, delete ON Dirs TO Director_Filii
2.2.3 Описание привилегий доступа для операционистов
Create Table Opers
(Oper_ID, - -идентификатор
Name_Oper, - -имя
Data_BD - -дата рождения) Without oids;
Alter table Opers owner to Oper;
Comment on table Opers IS ’Информация о операционистах
Comment on column Opers. Oper_ID IS ‘Идентификатор
Comment on column Opers. Name_Oper IS ‘Имя
Comment on column Opers. Data_BD IS ‘Дата рождения
Для установки привиллегий доступа используется команда:
GRANT список_привиллегий ON таблица TO роль
Grant select, insert, update, ON Opers TO Oper
2.2.4 Описание привилегий доступа для работников филиала
Create Table Workers
(Worker_ID, - -идентификатор
Name_Worker, - -имя
Data_BD - -дата рождения) Without oids;
Alter table Workers owner to Worker_Filii;
Comment on table Workers IS ’Информация о работниках филии
Comment on column Workers. Worker_ID IS ‘Идентификатор
Comment on column Workers. Name_Worker IS ‘Имя
Comment on column Workers. Data_BD IS ‘Дата рождения
Для установки привиллегий доступа используется команда:
GRANT список_привиллегий ON таблица TO роль
Grant select ON Workers TO Worker_Filii
2.3 Создание представления субъекта об объекте
В действующем стандарте языка SQL предусматривается поддержка только избирательного управления доступом. Она основана на двух более или менее независимых частях SQL. Одна из них называется механизмом представлений, который может быть использован для скрытия очень важных данных от несанкционированных пользователей. Другая называется подсистемой полномочий и наделяет одних пользователей правом избирательно и динамично задавать различные полномочия другим пользователям, а также отбирать такие полномочия в случае необходимости.
2.3.1 Создание схемы для директоров
CREATE SCHEMA DIRECTOR;
‘Для включения пользователя в схему используется команда:
ALTER SCHEMA DIRECTOR OWNER TO KORNIENKO;
‘выполнении запросов к схеме:
SELECT FROM DIRECTOR. KORNIENKO;
‘установления порядка доступа к схемe
SET SEARCH_PATH TO public;
SET SEARCH_PATH TO director, public;
2.3.2 Создание схемы для клиентов
CREATE SCHEMA KLIENT;
‘Для включения пользователя в схему используется команда:
ALTER SCHEMA KLIENT OWNER TO ABC;
ALTER SCHEMA KLIENT OWNER TO IBM;
ALTER SCHEMA KLIENT OWNER TO IVANOV;
ALTER SCHEMA KLIENT OWNER TO PETROV;
ALTER SCHEMA KLIENT OWNER TO SIDOROV;
‘выполнении запросов к схеме:
SELECT FROM KLIENT. ABC;
SELECT FROM KLIENT. IBM;
SELECT FROM KLIENT. IVANOV;
SELECT FROM KLIENT. PETROV;
SELECT FROM KLIENT. SIDOROV;
‘установления порядка доступа к схемe
SET SEARCH_PATH TO public;
SET SEARCH_PATH TO klient, public;
2.3.3 Создание схемы для операционистов
CREATE SCHEMA OPER;
‘Для включения пользователя в схему используется команда:
ALTER SCHEMA OPER OWNER TO SALMIN;
ALTER SCHEMA OPER OWNER TO DJAVR;
ALTER SCHEMA OPER OWNER TO KIRICH;
‘выполнении запросов к схеме:
SELECT FROM OPER. SALMIN;
SELECT FROM OPER. DJAVR;
SELECT FROM OPER. KIRICH;
‘установления порядка доступа к схемe
SET SEARCH_PATH TO public;
SET SEARCH_PATH TO oper, public;
2.3.4 Создание схемы для работников филиала
CREATE SCHEMA WORKER;
‘Для включения пользователя в схему используется команда:
ALTER SCHEMA WORKER OWNER TO MANKO;
ALTER SCHEMA WORKER OWNER TOYANOVSKIY;
‘выполнении запросов к схеме:
SELECT FROM WORKER. MANKO;
SELECT FROM WORKER. YANOVSKIY;
‘установления порядка доступа к схемe
SET SEARCH_PATH TO public;
SET SEARCH_PATH TO worker, public;
3. Реализация требований стандарта по критерию "Политика безопасности"
Политика безопасности - набор законов, правил и норм поведения, определяющих, как организация обрабатывает, защищает и распространяет информацию.
Политика безопасности должна включать в себя по крайней мере следующие элементы: произвольное управление доступом, безопасность повторного использования объектов, метки безопасности, принудительное управление доступом.
С точки зрения работы СУБД рассмотрим три элемента:
произвольное управление доступом;
метки безопасности;
принудительное управление доступом.
Описание концепции использования меток безопасности
Полномочное (принудительное) управление доступом в промышленных СУБД не реализовано на уровне ядра управления. Но в СУБД присутствуют программные средства для программирования такого управления.
Для реализации полномочного управления доступом с субъектами и объектами ассоциируются метки безопасности. Метка субъекта описывает его благонадежность, метка объекта - степень закрытости содержащейся в нем информации.
Метки безопасности состоят из двух частей - уровня секретности и списка категорий. Уровни секретности, поддерживаемые системой, образуют упорядоченное множество, которое может выглядеть, например, так: совершенно секретно, секретно, конфиденциально, несекретно.
Категории образуют неупорядоченный набор. Их назначение - описать предметную область, к которой относятся данные. В военном окружении каждая категория может соответствовать, например, определенному виду вооружений.
Главная проблема, которую необходимо решать в связи с метками, это обеспечение их целостности:
не должно быть непомеченных субъектов и объектов, иначе в меточной безопасности появятся легко используемые бреши;
при любых операциях с данными метки должны оставаться правильными.
Управление метками безопасности в СУБД
Для реализации полномочного управления доступом необходимо разрабатывать
дополнительный механизм, включающий:
дополнительные структуры данных, хранящие значение меток конфиденциальности обьектов БД (записей таблиц или их отдельных атрибутов);
дополнительные структуры данных, хранящие значение уровней доступа субьектов БД (пользователей или их групп);
В СУБД PostgreSQL вышеописанные пункты механизма можно создать через:
добавление поля таблицы, содержащего значения метки конфиденциальности
создание таблицы уровней доступа с двумя полями: имя группы или пользователя, уровень доступа.
3.1 Создания механизма по управлению метками в СУБД
3.1.1 Таблица с информацией о клиентах
CREATE SEQUENCE KLIENTS_ID;
CREATE TABLE KLIENTS (KLIENTS_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 KLIENTS ADD COLUMN SPOT_CONF INTEGER DEFAULT 1
REFERENCES ACCESS_LEVELS (ACCESS_LEVEL_ID);
3.1.2 Таблица с информацией о директорах
CREATE SEQUENCE DIRS_ID;
CREATE TABLE DIRS (DIRS_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 DIRS ADD COLUMN SPOT_CONF INTEGER DEFAULT 1
REFERENCES ACCESS_LEVELS (ACCESS_LEVEL_ID);
3.1.3 Таблица с информацией об операционистах
CREATE SEQUENCE OPERS_ID;
CREATE TABLE OPERS (OPERS_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 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
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.