Введение
Знание критериев оценки информационной безопасности способно помочь при выборе и комплектовании аппаратно-программной конфигурации. Кроме того, в своей повседневной работе администратор безопасности вынужден хотя бы до некоторой степени повторять действия сертифицирующих органов, поскольку обслуживаемая система, скорее всего, время от времени претерпевает изменения и нужно, во-первых, оценивать целесообразность модификаций и их последствия, а, во-вторых, соответствующим образом корректировать повседневную практику пользования и администрирования. Если знать, на что обращают внимание при сертификации, можно сконцентрироваться на анализе критически важных аспектов, экономя время и силы и повышая качество защиты.
Одним из первых стандартов сертификации систем защиты стал стандарт Национального комитета компьютерной безопасности (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. 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 );
Управление ролями
В версиях СУБД PostgreSQL меньших 8.1 при управлении субъектами использовались понятия "пользователь" и "группа" и соответствующие команды создания CREATE USER, CREATE GROUP. Для изменения параметров пользователя или группы ипользовались команды ALER USER и ALTER GROUP, соответственно. В версиях СУБД PostgreSQL начиная с 8.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;
Наследование ролей
Группировка индивидуальных субъектов безопасности.
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;
Создание схемы для клиентов
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;
Таблица с информацией о клиентах
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);
Таблица с информацией о директорах
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);
Таблица с информацией об операционистах
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);
Таблица с информацией о работниках филиала
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);
Обеспечение надежного пути
Аннулирование сертификатов
Для местных СА в случае компрометации сертификата строго рекомендуется аннулировать сертификат и информировать пользователей о том, что сертификат больше не действительный. Для аннулирования сертификата необходимо отыскать его серийный номер в файле $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).
Список литературы
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.
Введение
Знание критериев оценки информационной безопасности способно помочь при выборе и комплектовании аппаратно-программной конфигурации. Кроме того, в своей повседневной работе администратор безопасности вынужден хотя бы до некоторой степени повторять действия сертифицирующих органов, поскольку обслуживаемая система, скорее всего, время от времени претерпевает изменения и нужно, во-первых, оценивать целесообразность модификаций и их последствия, а, во-вторых, соответствующим образом корректировать повседневную практику пользования и администрирования. Если знать, на что обращают внимание при сертификации, можно сконцентрироваться на анализе критически важных аспектов, экономя время и силы и повышая качество защиты.
Одним из первых стандартов сертификации систем защиты стал стандарт Национального комитета компьютерной безопасности (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. 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 );
Управление ролями
В версиях СУБД PostgreSQL меньших 8.1 при управлении субъектами использовались понятия "пользователь" и "группа" и соответствующие команды создания CREATE USER, CREATE GROUP. Для изменения параметров пользователя или группы ипользовались команды ALER USER и ALTER GROUP, соответственно. В версиях СУБД PostgreSQL начиная с 8.1 появился более гибкий механизм - роли.
Регистрация субъектов безопасности
Информационная система банка.
Групповые субъекты: клиенты, операционисты, директор филиала, работники филиала.
Индивидуальные субъекты: клиент "ABC", клиент “IBM”, клиент Иванов А.А., клиент Петров П.П., клиент Сидоров В. Г, операционист Джавров В.Г., операционист Салмин Ю.Л., операционист Киричук А.Г., директор Корниенко В.А., работник Манько А.А., работник Яновский Г.Х.
Регистрация субъектов
Регистрация индивидуальных субъектов:
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;
Наследование ролей
Группировка индивидуальных субъектов безопасности.
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;
Дата: 2019-07-30, просмотров: 171.
