Аннотация
Целью данного курсового проектаявляется закрепление, систематизация, углубление и развитие теоретических ипрактических знаний, полученных студентами в процессе изучения дисциплины«Надёжность и безопасность программного обеспечения». Курсовая работапосвященна проблемам политики безопастности баз данных, гарантированности исредств подотчётности. Основная цель курсового проектирования состоит визучении и анализе вопросов, связанных со специальными аспектами надёжности ибезопасности программного обеспечения.
Содержание
Введение
Индивидуальное задание
1. Проектирование таблиц
2. Управление родями
2.1 Регистрация субъектов безопасности
2.1.1 Регистрация субъектов
2.1.2 Наследование ролей
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 EvaliationCriteria, 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, CREATEGROUP. Для изменения параметров пользователя или группы ипользовались командыALER USER и ALTER GROUP, соответственно. В версиях СУБД PostgreSQL начиная с 8.1появился более гибкий механизм — роли.2.1 Регистрация субъектов безопасности
Информационная система банка.
Групповые субъекты: клиенты,операционисты, директор филиала, работники филиала.
Индивидуальные субъекты: клиент«ABC», клиент “IBM”, клиент Иванов А.А., клиент Петров П.П., клиентСидоров В. Г, операционист Джавров В.Г., операционист Салмин Ю.Л., операционистКиричук А.Г., директор Корниенко В.А., работник Манько А.А., работник ЯновскийГ.Х.2.1.1 Регистрация субъектов
Регистрация индивидуальныхсубъектов:
Alter Role ABClogin;
Alter Role IBMlogin;
Alter RoleIvanov login;
Alter RolePetrov login;
Alter RoleSidorov login;
Alter RoleDjavr login;
Alter RoleSalmin login;
Alter RoleKirich login;
Alter RoleKornienko login;
Alter RoleManko login;
Alter Role Yanovskiy login;
Регистрация групповых субъектов:
Alter RoleKlient nologin;
Alter RoleDirector_Filii nologin;
Alter RoleWorker_Filii nologin;
Alter Role Opernologin;2.1.2 Наследование ролей
Группировка индивидуальныхсубъектов безопасности.
Grant Klient To ABC;
Grant Klient ToIBM;
Grant Klient ToIvanov;
Grant Klient ToPetrov;
Grant Klient ToSidorov;
GrantDirector_Filii To Kornienko;
Grant Oper ToDjavr;
Grant Oper ToSalmin;
Grant Oper ToKirich;
GrantWorker_Filii To Manko;
GrantWorker_Filii To Yanovskiy;2.2 Избирательное управление доступом
Механизм представлений языка SQLпозволяет различными способами разделить базу данных на части таким образом,чтобы очень важная информация была скрыта от несанкционированных пользователей.
2.2.1 Описание привилегий доступа для клиентов
Create Table Klients
(Klient_ID, — -идентификаторклиента
Name_Klient, — -имя клиента
Data_BD — -дата рождения клиента)Without oids;
Alter tableKlients owner to Klient;
Comment ontable Klient IS ’Информация о клиентах
Comment oncolumn Klient. Klient_ID IS ‘Идентификатор клиента
Comment oncolumn Klient. Name IS ‘Имя клиента
Comment oncolumn Klient. Data_BD IS ‘Дата рождения клиента
Для установки привиллегийдоступа используется команда:
GRANT список_привиллегий ONтаблица TO роль
Grant select,insert ON Klients TO Klient2.2.2 Описание привилегий доступа для директоров
Create Table Dirs
(Dir_ID, — -идентификатор
Name_Dir, — -имя
Data_BD — -датарождения) Without oids;
Alter tableDirs owner to Director_Filii;
Comment ontable Dirs IS ’Информация о директорах
Comment oncolumn Dirs. Dir_ID IS ‘Идентификатор
Comment oncolumn Dirs. Name_Dir IS ‘Имя
Comment oncolumn 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 tableOpers owner to Oper;
Comment ontable Opers IS ’Информация о операционистах
Comment oncolumn Opers. Oper_ID IS ‘Идентификатор
Comment oncolumn Opers. Name_Oper IS ‘Имя
Comment oncolumn Opers. Data_BD IS ‘Дата рождения
Для установки привиллегийдоступа используется команда:
GRANT список_привиллегий ONтаблица TO роль
Grant select,insert, update, ON Opers TO Oper2.2.4 Описание привилегий доступа для работников филиала
Create TableWorkers
(Worker_ID, — -идентификатор
Name_Worker, — -имя
Data_BD — -датарождения) Without oids;
Alter tableWorkers owner to Worker_Filii;
Comment ontable Workers IS ’Информация о работниках филии
Comment oncolumn Workers. Worker_ID IS ‘Идентификатор
Comment oncolumn Workers. Name_Worker IS ‘Имя
Comment oncolumn Workers. Data_BD IS ‘Дата рождения
Для установки привиллегийдоступа используется команда:
GRANT список_привиллегий ONтаблица TO роль
Grant select ONWorkers TO Worker_Filii
2.3 Создание представления субъекта об объекте
В действующем стандарте языкаSQL предусматривается поддержка только избирательного управления доступом. Онаоснована на двух более или менее независимых частях SQL. Одна из них называетсямеханизмом представлений, который может быть использован для скрытия оченьважных данных от несанкционированных пользователей. Другая называетсяподсистемой полномочий и наделяет одних пользователей правом избирательно идинамично задавать различные полномочия другим пользователям, а также отбиратьтакие полномочия в случае необходимости.2.3.1 Создание схемы для директоров
CREATE SCHEMA DIRECTOR;
‘Для включения пользователя всхему используется команда:
ALTER SCHEMADIRECTOR OWNER TO KORNIENKO;
‘выполнении запросов к схеме:
SELECT FROM DIRECTOR. KORNIENKO;
‘установления порядка доступа ксхемe
SETSEARCH_PATH TO public;
SETSEARCH_PATH TO director, public;2.3.2 Создание схемы для клиентов
CREATE SCHEMA KLIENT;
‘Для включения пользователя всхему используется команда:
ALTER SCHEMAKLIENT OWNER TO ABC;
ALTER SCHEMAKLIENT OWNER TO IBM;
ALTER SCHEMAKLIENT OWNER TO IVANOV;
ALTER SCHEMAKLIENT OWNER TO PETROV;
ALTER SCHEMAKLIENT OWNER TO SIDOROV;
‘выполнении запросов к схеме:
SELECT FROM KLIENT. ABC;
SELECT FROMKLIENT. IBM;
SELECT FROMKLIENT. IVANOV;
SELECT FROMKLIENT. PETROV;
SELECT FROMKLIENT. SIDOROV;
‘установленияпорядка доступа к схемe
SETSEARCH_PATH TO public;
SETSEARCH_PATH TO klient, public;2.3.3 Создание схемы для операционистов
CREATE SCHEMA OPER;
‘Для включения пользователя всхему используется команда:
ALTER SCHEMAOPER OWNER TO SALMIN;
ALTER SCHEMAOPER OWNER TO DJAVR;
ALTER SCHEMAOPER OWNER TO KIRICH;
‘выполнении запросов к схеме:
SELECT FROM OPER. SALMIN;
SELECT FROMOPER. DJAVR;
SELECT FROM OPER. KIRICH;
‘установления порядка доступа ксхемe
SETSEARCH_PATH TO public;
SETSEARCH_PATH TO oper, public;2.3.4 Создание схемы для работников филиала
CREATE SCHEMA WORKER;
‘Для включения пользователя всхему используется команда:
ALTER SCHEMAWORKER OWNER TO MANKO;
ALTER SCHEMAWORKER OWNER TOYANOVSKIY;
‘выполнении запросов к схеме:
SELECT FROM WORKER. MANKO;
SELECT FROMWORKER. YANOVSKIY;
‘установленияпорядка доступа к схемe
SETSEARCH_PATH TO public;
SETSEARCH_PATH TO worker, public;
3. Реализация требований стандарта по критерию«Политика безопасности»
Политика безопасности — наборзаконов, правил и норм поведения, определяющих, как организация обрабатывает,защищает и распространяет информацию.
Политика безопасности должнавключать в себя по крайней мере следующие элементы: произвольное управлениедоступом, безопасность повторного использования объектов, метки безопасности,принудительное управление доступом.
С точки зрения работы СУБДрассмотрим три элемента:
произвольное управление доступом;
метки безопасности;
принудительное управлениедоступом.
Описание концепции использованияметок безопасности
Полномочное (принудительное) управлениедоступом в промышленных СУБД не реализовано на уровне ядра управления. Но вСУБД присутствуют программные средства для программирования такого управления.
Для реализации полномочногоуправления доступом с субъектами и объектами ассоциируются метки безопасности. Меткасубъекта описывает его благонадежность, метка объекта — степень закрытостисодержащейся в нем информации.
Метки безопасности состоят издвух частей — уровня секретности и списка категорий. Уровни секретности,поддерживаемые системой, образуют упорядоченное множество, которое можетвыглядеть, например, так: совершенно секретно, секретно, конфиденциально,несекретно.
Категории образуютнеупорядоченный набор. Их назначение — описать предметную область, к которойотносятся данные. В военном окружении каждая категория может соответствовать,например, определенному виду вооружений.
Главная проблема, которуюнеобходимо решать в связи с метками, это обеспечение их целостности:
не должно быть непомеченныхсубъектов и объектов, иначе в меточной безопасности появятся легко используемыебреши;
при любых операциях с даннымиметки должны оставаться правильными.
Управление метками безопасностив СУБД
Для реализации полномочногоуправления доступом необходимо разрабатывать
дополнительный механизм,включающий:
дополнительные структуры данных,хранящие значение меток конфиденциальности обьектов БД (записей таблиц или ихотдельных атрибутов);
дополнительные структуры данных,хранящие значение уровней доступа субьектов БД (пользователей или их групп);
В СУБД PostgreSQL вышеописанныепункты механизма можно создать через:
добавление поля таблицы,содержащего значения метки конфиденциальности
создание таблицы уровней доступас двумя полями: имя группы или пользователя, уровень доступа.3.1 Создания механизма по управлению метками в СУБД3.1.1 Таблица с информацией о клиентах
CREATE SEQUENCE KLIENTS_ID;
CREATE TABLEKLIENTS (KLIENTS_ID INTEGER NOT NULL PRIMARY KEY DEFAULT NEXTVAL ('KLIENTS_ID'),
NAME VARCHAR (30),
SEX CHAR (1),
BIRTHDAY DATE,
CONSTRAINTVALID_SEX CHECK (SEX IN ('Ж','М',’ФИРМА’)));
COMMENT ONTABLE PERSONS IS
'ТАБЛИЦАИНФОРМАЦИИ О КЛИЕНТАХ;
Для создания механизмауправления метками при доступе пользователей и групп пользователей к таблицеpersons выполним следующую последовательность шагов.
Шаг 1. Создать справочникуровней доступа с помощью команды, пример которой представлен ниже.
CREATE TABLEACCESS_LEVELS (ACCESS_LEVEL_ID INTEGER PRIMARY KEY,
ACCESS_LEVELVARCHARUNIQUE) ;
INSERT INTOACCESS_LEVELS VALUES (1,'дляобщегодоступа');
INSERT INTOACCESS_LEVELS VALUES (2,'для внутреннего использования');
INSERT INTOACCESS_LEVELS VALUES (3,'секретно');
INSERT INTOACCESS_LEVELS VALUES (4,'совершенносекретно');
Шаг 2. Создать таблицу,содержащую матрицу уровней доступа групп пользователей, пример которойпредставлен ниже.
DROP TABLEGROUPS_ACCESS_LEVEL;
CREATE TABLEGROUPS_ACCESS_LEVEL (GROUP_NAME VARCHAR PRIMARY KEY,
ACCESS_LEVELINTEGER REFERENCES
ACCESS_LEVELS(ACCESS_LEVEL_ID));
Шаг 3. Разграничить права натаблицу groups_access_level:
REVOKE ALLON GROUPS_ACCESS_LEVEL FROM GROUP USERS;
GRANT SELECTON GROUPS_ACCESS_LEVEL TO GROUP USERS;
Шаг 4. Присвоить группе usersнеобходимый уровень доступа
INSERT INTOGROUPS_ACCESS_LEVEL VALUES ('users',2);
Шаг 5. Добавить в таблицу БДKlients поле с описанием меток конфиденциальности записей spot_conf:
ALTER TABLEKLIENTS ADD COLUMN SPOT_CONF INTEGER DEFAULT 1
REFERENCESACCESS_LEVELS (ACCESS_LEVEL_ID);3.1.2 Таблица с информацией о директорах
CREATE SEQUENCEDIRS_ID;
CREATE TABLEDIRS (DIRS_ID INTEGER NOT NULL PRIMARY KEY DEFAULT NEXTVAL ('KLIENTS_ID'),
NAME VARCHAR (30),
SEX CHAR (1),
BIRTHDAY DATE,
CONSTRAINTVALID_SEX CHECK (SEX IN ('Ж','М’)));
COMMENT ON TABLE PERSONS IS
'ТАБЛИЦА ИНФОРМАЦИИ О ДИРЕКТОРАХ;
Для создания механизмауправления метками при доступе пользователей и групп пользователей к таблицеpersons выполним следующую последовательность шагов.
Шаг 1. Создать справочникуровней доступа с помощью команды, пример которой представлен ниже.
CREATE TABLEACCESS_LEVELS (ACCESS_LEVEL_ID INTEGER PRIMARY KEY,
ACCESS_LEVELVARCHARUNIQUE) ;
INSERT INTOACCESS_LEVELS VALUES (1,'дляобщегодоступа');
INSERT INTOACCESS_LEVELS VALUES (2,'для внутреннего использования');
INSERT INTOACCESS_LEVELS VALUES (3,'секретно');
INSERT INTOACCESS_LEVELS VALUES (4,'совершенносекретно');
Шаг 2. Создать таблицу,содержащую матрицу уровней доступа групп пользователей, пример которойпредставлен ниже.
DROP TABLEGROUPS_ACCESS_LEVEL;
CREATE TABLEGROUPS_ACCESS_LEVEL (GROUP_NAME VARCHAR PRIMARY KEY,
ACCESS_LEVELINTEGER REFERENCES
ACCESS_LEVELS(ACCESS_LEVEL_ID));
Шаг 3. Разграничить права натаблицу groups_access_level:
REVOKE ALLON GROUPS_ACCESS_LEVEL FROM GROUP USERS;
GRANT SELECTON GROUPS_ACCESS_LEVEL TO GROUP USERS;
Шаг 4. Присвоить группе usersнеобходимый уровень доступа
INSERT INTOGROUPS_ACCESS_LEVEL VALUES ('users',2);
Шаг 5. Добавить в таблицу БДKlients поле с описанием меток конфиденциальности записей spot_conf:
ALTER TABLEDIRS ADD COLUMN SPOT_CONF INTEGER DEFAULT 1
REFERENCESACCESS_LEVELS (ACCESS_LEVEL_ID);
3.1.3 Таблица с информацией об операционистах
CREATE SEQUENCE OPERS_ID;
CREATE TABLEOPERS (OPERS_ID INTEGER NOT NULL PRIMARY KEY DEFAULT NEXTVAL ('KLIENTS_ID'),
NAME VARCHAR (30),
SEX CHAR (1),
BIRTHDAY DATE,
CONSTRAINTVALID_SEX CHECK (SEX IN ('Ж','М’)));
COMMENT ON TABLE PERSONS IS
'ТАБЛИЦА ИНФОРМАЦИИ ОБОПЕРАЦИОНИСТАХ;
Для создания механизмауправления метками при доступе пользователей и групп пользователей к таблицеpersons выполним следующую последовательность шагов.
Шаг 1. Создать справочникуровней доступа с помощью команды, пример которой представлен ниже.
CREATE TABLEACCESS_LEVELS (ACCESS_LEVEL_ID INTEGER PRIMARY KEY,
ACCESS_LEVELVARCHARUNIQUE) ;
INSERT INTOACCESS_LEVELS VALUES (1,'дляобщегодоступа');
INSERT INTOACCESS_LEVELS VALUES (2,'для внутреннего использования');
INSERT INTOACCESS_LEVELS VALUES (3,'секретно');
INSERT INTOACCESS_LEVELS VALUES (4,'совершенносекретно');
Шаг 2. Создать таблицу,содержащую матрицу уровней доступа групп пользователей, пример которойпредставлен ниже.
DROP TABLEGROUPS_ACCESS_LEVEL;
CREATE TABLEGROUPS_ACCESS_LEVEL (GROUP_NAME VARCHAR PRIMARY KEY,
ACCESS_LEVELINTEGER REFERENCES
ACCESS_LEVELS(ACCESS_LEVEL_ID));
Шаг 3. Разграничить права натаблицу groups_access_level:
REVOKE ALLON GROUPS_ACCESS_LEVEL FROM GROUP USERS;
GRANT SELECTON GROUPS_ACCESS_LEVEL TO GROUP USERS;
Шаг 4. Присвоить группе usersнеобходимый уровень доступа
INSERT INTOGROUPS_ACCESS_LEVEL VALUES ('users',2);
Шаг 5. Добавить в таблицу БДKlients поле с описанием меток конфиденциальности записей spot_conf:
ALTER TABLEOPERS ADD COLUMN SPOT_CONF INTEGER DEFAULT 1
REFERENCESACCESS_LEVELS (ACCESS_LEVEL_ID);
3.1.4 Таблица с информацией о работниках филиала
CREATE SEQUENCEWORKERS_ID;
CREATE TABLEWORKERS (WORKERS_ID INTEGER NOT NULL PRIMARY KEY DEFAULT NEXTVAL ('KLIENTS_ID'),
NAME VARCHAR (30),
SEX CHAR (1),
BIRTHDAY DATE,
CONSTRAINTVALID_SEX CHECK (SEX IN ('Ж','М’)));
COMMENT ON TABLE PERSONS IS
'ТАБЛИЦА ИНФОРМАЦИИ О РАБОТНИКАХФИЛИАЛА;
Для создания механизмауправления метками при доступе пользователей и групп пользователей к таблицеpersons выполним следующую последовательность шагов.
Шаг 1. Создать справочникуровней доступа с помощью команды, пример которой представлен ниже.
CREATE TABLEACCESS_LEVELS (ACCESS_LEVEL_ID INTEGER PRIMARY KEY,
ACCESS_LEVELVARCHARUNIQUE) ;
INSERT INTOACCESS_LEVELS VALUES (1,'дляобщегодоступа');
INSERT INTOACCESS_LEVELS VALUES (2,'для внутреннего использования');
INSERT INTOACCESS_LEVELS VALUES (3,'секретно');
INSERT INTOACCESS_LEVELS VALUES (4,'совершенносекретно');
Шаг 2. Создать таблицу,содержащую матрицу уровней доступа групп пользователей, пример которойпредставлен ниже.
DROP TABLEGROUPS_ACCESS_LEVEL;
CREATE TABLEGROUPS_ACCESS_LEVEL (GROUP_NAME VARCHAR PRIMARY KEY,
ACCESS_LEVELINTEGER REFERENCES
ACCESS_LEVELS(ACCESS_LEVEL_ID));
Шаг 3. Разграничить права натаблицу groups_access_level:
REVOKE ALLON GROUPS_ACCESS_LEVEL FROM GROUP USERS;
GRANT SELECTON GROUPS_ACCESS_LEVEL TO GROUP USERS;
Шаг 4. Присвоить группе usersнеобходимый уровень доступа
INSERT INTOGROUPS_ACCESS_LEVEL VALUES ('users',2);
Шаг 5. Добавить в таблицу БДKlients поле с описанием меток конфиденциальности записей spot_conf:
ALTER TABLEWORKERS ADD COLUMN SPOT_CONF INTEGER DEFAULT 1
REFERENCESACCESS_LEVELS (ACCESS_LEVEL_ID);3.2 Реализация принудительного управления доступомв СУБД
Принудительное управлениедоступом основано на сопоставлении меток безопасности субъекта и объекта. Способуправления доступом называется принудительным, поскольку он не зависит от волисубъектов (даже системных администраторов). После того, как зафиксированы меткибезопасности субъектов и объектов, оказываются зафиксированными и права доступа.
Правила использования меток:
субъект может читать информацию изобъекта, если уровень секретности субъекта не ниже, чем у объекта, а всекатегории, перечисленные в метке безопасности объекта, присутствуют в меткесубъекта;
субъект может записыватьинформацию в объект, если метка безопасности объекта совпадает (или доминирует)с меткой субъекта.
Реализация принудительногоуправления доступом в СУБД
Для реализации полномочногоуправления доступом необходимо разрабатывать
дополнительный механизм,включающий:
механизмы ограничения доступа почтению субьектами данных таблиц с учетом имен правил управления доступом почтению данных;
механизмы ограничения доступа помодификации субьектами данных таблиц (внесение, изменение, удаление) с учетомимен правил управления доступом по модификации данных.
В СУБД PostgreSQL вышеописанныепункты механизма можно создать через:
создание виртуальной таблицы (view),учитывающей таблицу БД, таблицу уровней доступа и имя текущего пользователя,работающего с БД;
создание правил (rules),перехватывающих операции внесения, изменения и удаления, выполняемыхпользователями над таблиц БД3.2.1 Реализация принудительного управлениядоступом в таблице «КЛИЕНТЫ»
Для реализации принудительногоуправления доступом к таблице KLIENTS со стороны пользователей и групппользователей СУБД необходимо выполнить следующие шаги.
Шаг 1. Создать виртуальнуютаблицу (view), учитывающую таблицу KLIENTS, таблицу уровней доступа, имятекущего пользователя, работающего с БД, позволяющую в дальнейшем разграничитьдоступ пользователей к отдельным записям таблицы KLIENTS.
CREATE ORREPLACE VIEW KLIENTS_LIST AS
SELECTPERSON_ID, NAME, SEX, BIRTHDAY
FROM PG_GROUPG, PG_USER U, KLIENTS P,
GROUPS_ACCESS_LEVELL
WHERE
USENAME =CURRENT_USER AND
U. USESYSID =ANY (G. GROLIST) AND
L. GROUP_NAME =G. GRONAME AND
P. SPOT_CONF
При создании таблицыиспользуется:
функция CURRENT_USER, возвращающаяимя текущего пользователя.
функция ANY (G. GROLIST) возвращающаялюбое из значений массива G. GROLIST
Шаг 2. Для того, чтобыпользователи могли работать только с виртуальной таблицей,
необходимо снять права доступа среальной таблицы БД и установить права на чтение на виртуальную.
Снять права доступа к реальнойтаблицы:
REVOKE ALL ONKLIENTS FROM GROUP USERS;
Установить права доступа навиртуальную таблицу:
GRANT SELECT ONKLIENTS_LIST TO GROUP USERS;
Шаг 3. Проверить работумеханизма
Заполнить таблицу personsтестовыми данными:
INSERT INTOKLIENTS_LIST VALUES (1,'ABC','ФИРМА','12-11-1980');
UPDATE KLIENTSSET SPOT_CONF = 1;
INSERT INTOKLIENTS _LIST VALUES (1,'IBM','ФИРМА','30-12-1988');
UPDATE KLIENTSSET SPOT_CONF = 1;
INSERT INTOKLIENTS_LIST VALUES (1,'IVANOV','М','11-10-1965');
UPDATE KLIENTSSET SPOT_CONF = 1;
INSERT INTOKLIENTS_LIST VALUES (1,'PETROV','М','17-02-1989');
UPDATE KLIENTSSET SPOT_CONF = 1;
INSERT INTOKLIENTS_LIST VALUES (1,'SIDOROV','М','23-05-1975');
UPDATE KLIENTSSET SPOT_CONF = 1;
Для проверки работы механизманеобходимо соединиться с БД, используя имя пользователя ABC.
Выполнить пользователем directorдва запроса для проверки работы механизма:
SELECT FROMKLIENTS;
SELECT FROMKLIENTS_LIST;
Изменить меткуконфиденциальности отдельных записей пользователем-администратором:
UPDATE KLIENTSSET SPOT_CONF = 3 WHERE KLIENTS_ID = 2;
Повторно проверить работумеханизма пользователем ABC:
SELECT FROMKLIENTS_LIST;
Шаг 4. Создатьправила (rules), перехватывающие операции внесения, изменения и
удаления, выполняемыепользователями над таблиц KLIENTS
Создать правило на операциивнесения, пример которого представлен ниже:
DROP RULEKLIENTS_LIST_INSERT ON KLIENTS_LIST;
CREATE RULEKLIENTS_LIST_INSERT AS ON INSERT TO
KLIENTS _LIST
DO INSTEAD
INSERT INTOKLIENTS
SELECT CASEWHEN 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_GROUPG, 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 ONKLIENTS _LIST TO GROUP USERS;
GRANTSELECT,UPDATE ON KLIENTS _ID TO GROUP USERS;
Проверить работу механизма:
INSERT INTOKLIENTS _LIST VALUES (21,'IVANOV','М','10-10-1980');
Создать правило на операцииизменения, пример которого представлен ниже:
DROP RULEKLIENTS _LIST_UPDATE ON KLIENTS _LIST;
CREATE RULEKLIENTS _LIST_UPDATE AS ON UPDATE
TO KLIENTS_LIST
DO INSTEAD
UPDATE KLIENTSSET KLIENTS _ID = NEW. KLIENTS _ID,
NAME = NEW. NAME,SEX = NEW. SEX, BIRTHDAY = NEW. BIRTHDAY,
SPOT_CONF = L. ACCESS_LEVEL
FROM PG_GROUPG, PG_USER U, GROUPS_ACCESS_LEVEL L
WHERE
KLIENTS _ID =OLD. KLIENTS _ID AND
SPOT_CONF = L. ACCESS_LEVELAND
U. USENAME =CURRENT_USER AND
U. USESYSID =ANY (G. GROLIST) AND
L. GROUP_NAME =G. GRONAME;
Предоставить права на изменениезаписей в виртуальной таблице:
GRANT UPDATE ONKLIENTS _LIST TO GROUP USERS;
Проверить работу правила:
UPDATE KLIENTS_LIST SET NAME = 'IVANOV' WHERE KLIENTS _ID = 21;
Создание правил на операцииудаления, пример которого представлен ниже:
DROP RULEKLIENTS _LIST_DELETE ON KLIENTS _LIST;
CREATE RULEKLIENTS _LIST_DELETE AS ON DELETE TO
KLIENTS _LIST
DO INSTEAD
DELETE FROMKLIENTS 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 ONKLIENTS_LIST TO GROUP USERS;
Проверить работу механизма:
DELETE FROMKLIENTS_LIST WHERE KLIENTS_ID = 2;3.2.2 Реализация принудительного управлениядоступом в таблице «ОПЕРАЦИОНИСТЫ»
Для реализации принудительногоуправления доступом к таблице OPERS со стороны пользователей и групппользователей СУБД необходимо выполнить следующие шаги.
Шаг 1. Создать виртуальнуютаблицу (view), учитывающую таблицу OPERS, таблицу уровней доступа, имятекущего пользователя, работающего с БД, позволяющую в дальнейшем разграничитьдоступ пользователей к отдельным записям таблицы OPERS.
CREATE ORREPLACE VIEW OPERS_LIST AS
SELECTOPERS_ID, NAME, SEX, BIRTHDAY
FROM PG_GROUPG, PG_USER U, KLIENTS P,
GROUPS_ACCESS_LEVELL
WHERE
USENAME =CURRENT_USER AND
U. USESYSID =ANY (G. GROLIST) AND
L. GROUP_NAME =G. GRONAME AND
P. SPOT_CONF
При создании таблицыиспользуется:
функция CURRENT_USER, возвращающаяимя текущего пользователя.
функция ANY (G. GROLIST) возвращающаялюбое из значений массива G. GROLIST
Шаг 2. Для того, чтобыпользователи могли работать только с виртуальной таблицей,
необходимо снять права доступа среальной таблицы БД и установить права на чтение на виртуальную.
Снять права доступа к реальнойтаблицы:
REVOKE ALL ONOPERS FROM GROUP USERS;
Установить права доступа навиртуальную таблицу:
GRANT SELECT ONOPERS_LIST TO GROUP USERS;
Шаг 3. Проверить работумеханизма
Заполнить таблицу personsтестовыми данными:
INSERT INTOOPERS_LIST VALUES (1,'SALMIN','M','15-10-1988');
UPDATE OPERSSET SPOT_CONF = 1;
INSERT INTOOPERS_LIST VALUES (1,KIRICHUK','M','30-12-1988');
UPDATE OPERSSET SPOT_CONF = 1;
Для проверки работы механизманеобходимо соединиться с БД, используя имя пользователя ABC.
Выполнить пользователем directorдва запроса для проверки работы механизма:
SELECT FROMOPERS;
SELECT FROMOPERS_LIST;
Изменить меткуконфиденциальности отдельных записей пользователем-администратором:
UPDATE OPERSSET SPOT_CONF = 3 WHERE OPERS_ID = 2;
Повторно проверить работумеханизма пользователем ABC:
SELECT FROMOPERS_LIST;
Шаг 4. Создатьправила (rules), перехватывающие операции внесения, изменения и
удаления, выполняемыепользователями над таблиц OPERS
Создать правило на операциивнесения, пример которого представлен ниже:
DROP RULEOPERS_LIST_INSERT ON OPERS_LIST;
CREATE RULEOPERS_LIST_INSERT AS ON INSERT TO
OPERS_LIST
DO INSTEAD
INSERT INTOOPERS
SELECT CASEWHEN 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_GROUPG, 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 ONOPERS_LIST TO GROUP USERS;
GRANTSELECT,UPDATE ON OPERS_ID TO GROUP USERS;
Проверить работу механизма:
INSERT INTOKLIENTS _LIST VALUES (21,'IVANOV','М','10-10-1980');
Создать правило на операцииизменения, пример которого представлен ниже:
DROP RULEOPERS_LIST_UPDATE ON OPERS_LIST;
CREATE RULEOPERS_LIST_UPDATE AS ON UPDATE
TO OPERS_LIST
DO INSTEAD
UPDATE OPERSSET OPERS_ID = NEW. OPERS_ID,
NAME = NEW. NAME,SEX = NEW. SEX, BIRTHDAY = NEW. BIRTHDAY,
SPOT_CONF = L. ACCESS_LEVEL
FROM PG_GROUPG, PG_USER U, GROUPS_ACCESS_LEVEL L
WHERE
OPERS_ID = OLD.OPERS_ID AND
SPOT_CONF = L. ACCESS_LEVELAND
U. USENAME =CURRENT_USER AND
U. USESYSID =ANY (G. GROLIST) AND
L. GROUP_NAME =G. GRONAME;
Предоставить права на изменениезаписей в виртуальной таблице:
GRANT UPDATE ONOPERS_LIST TO GROUP USERS;
Проверить работу правила:
UPDATEOPERS_LIST SET NAME = 'SALMIN' WHERE OPERS_ID =1;
Создание правил на операцииудаления, пример которого представлен ниже:
DROP RULEOPERS_LIST_DELETE ON OPERS_LIST;
CREATE RULEOPERS_LIST_DELETE AS ON DELETE TO
OPERS_LIST
DO INSTEAD
DELETE FROMOPERS 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 ONOPERS_LIST TO GROUP USERS;
Проверить работу механизма:
DELETE FROMOPERS_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 — outserver. 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веб-серверами):
#=================================================
# OpenSSLconfiguration 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/webrequest. Pem
/>
/>
В результате выполнения этихкоманд будет подписан сертификат (файл signed. pem), который будет находится вкаталоге $SSLDIR/newcerts, и в файле $SSLDIR/signed. pem.4.3.6 Аннулирование сертификатов
Для местных СА в случаекомпрометации сертификата строго рекомендуется аннулировать сертификат иинформировать пользователей о том, что сертификат больше не действительный. Дляаннулирования сертификата необходимо отыскать его серийный номер в файле$SSLDIR/index. txt.
V 031237770121C01 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-файла (CertificateRevocation 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 — еxtensionsssl_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.