CC BY
48
- © А.В. Малышев, 2014
УДК 004.65
А.В. Малышев
ПРАКТИЧЕСКИЕ АСПЕКТЫ АНАЛИЗА, ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ БАЗЫ ДАННЫХ ДЛЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ АНАЛИЗА РИСКОВ
Освещены практические аспекты анализа предметной области, используя стандарты IDEF0, проектирования - от концептуальной к логической, а также практическая разработка базы данных под систему управления базами данных PostgreSQL для автоматизированной системы анализа рисков.
Ключевые слова: анализ, IDEF0, проектирование, логическая модель, база данных, СУБД, PostgreSQL, OCTAVE, управление рисками, автоматизированная система, разработка.
Разработка базы данных, сложный и трудоемкий процесс. В условиях работы в небольшой команде на разработчика базы данных ложится разработка внутренней архитектуры программы. От того как правильно и грамотна будет построена база данных зависит насколько легко ее можно будет модернизировать, особенно четко это видно на примере разработки Web-приложений. Существует множество CASE-средств, которые могут значительно упростить этот процесс, сведя весь процесс разработке к обобщенному созданию концептуальной модели и преобразованием ее в несколько кликов в уже готовый SQL-запрос, который сгенерирует ее под любую СУБД. Такая дань новому дню, в плане автоматизации всего и вся, скрывает в себе множество подводных камней, наибольшим из которых является сложность развития данной базы данных. В конце концов разработчик настолько погрязнет в автоматизации своей работы что не сможет выявить чисто механические ошибки данных CASE-средств, а так же запутается в потоке, автоматически генерируемых, названиях таблиц и строк. Единственно
верным предупреждающим действием является построение вручную физической модели, в программах которые соответствуют конкретной СУБД, используют и знают ее нововведения и тонкости. Именно в использовании максимального функционала СУБД лежит залог успешной базы данных, тогда как freeware CASE-средства, как правило, обновляются крайне нерегулярно и т.к. в основном ориентированы на все СУБД сразу не могут быть на острие прогресса. Целью данной статьи будет рассмотрение проектирования базы данных, на примере создания автоматизированной системы анализа рисков.
Важнейшим этапом, в процессе построения физической модели, является анализ предметной области. Их существует множество способов, но в данной работе будет рассмотрен анализ модели построенной по стандартам IDEF0 построим 2 вида модели по принципу «AS IS => TO BE», т.е. смоделируем предметную область по принципу «Как есть», с целью получение требований к средству автоматизации, в данном, рассматриваемом, случае автоматизированная система анализа рисков, после чего построим
Таблица 1
Пример матрицы ИТ рисков
ИТ сервис Величины рисков по областям ИТ рисков
Нарушение конфиденциальности Нарушение целостности Нарушение доступности
Повреждение/ потеря данных Временный перерыв в доступности
e-mail/эл. почта умеренный несущественный катастрофичный значительный
сервис печати катастрофичный умеренный несущественный несущественный
модель «Как будет» - предметную область с уже внедренным средством автоматизации, для формализации, полученных из первой модели, требований.
Анализ информационных рисков -процесс идентификации рисков на основании определения угроз, уязви-мостей и возможного ущерба безопасности корпоративной информационной сети и выделение тех ее областей, которые нуждаются в защите. Анализ рисков первый из списка процессов управления информационными рисками, который помимо него включает в себя: выбор совокупности адекватных контрмер, анализ параметра «стоимость-эффективность», построение и испытание подсистемы ИБ. Для анализа и управления информационными рисками используется ряд методологий, являющихся стандартами в сфере информационной безопасно-
сти. Выбор оптимальной методологии достаточно сложен и зависит от множества факторов, так что в данной работе будет рассмотрена методология OCTAVE. Особое внимание из всей предметной области стоит уделить информации, способам ее передачи, условия хранения и использования.
Результатом работ по оценке ИТ рисков, на основе методологии OCTAVE, является Матрица рисков (табл. 1), представляющая собой перечень информационных активов с указанием величин рисков. На основании матрицы рисков разрабатывается план мероприятий по снижению ИТ рисков.
По методологии OCTAVE процесс анализа информационных рисков происходит в 6 этапов:
1. определение объема работ;
2. формирование рабочей группы;
3. сбор информации;
Инструктаж по методологии
Методология OCTAVE
Заработная плата
Опросный лист
План мероприятий по снижению рисков
Топ менеджмент ИТ пер сон ал
предприятия
Бизнес персонал
Цель: Анализ рисков по методологии OCTAVE Точка зрения" Генеральный директор предприятия
Рис. 1 Модель анализа рисков по методологии OCTAVE
4. оценка эффективности контролей;
5. обработка информации;
6. составление Плана мероприятий по снижению рисков.
Каждый этап из плана должен быть проанализирован отдельно, даже те, влияние которых на саму автоматизированную систему невелико, или вообще отсутствует. Наиболее ясную картину разработчик базы данных получит, построив функциональную модель данных этапов (рис. 1), по международным стандартам IDEF0 (в России ГОСТ Р 50.1.028-2001) и декомпозировав функциональный блок А0 (рис. 2).
На диаграмме в прямоугольном блоке отображен процесс, который мы анализируем, по стандартам IDEF0 в каждой декомпозированной диаграмме было не менее трех и не более шести блоков. Каждая сторона блока, как и стрелка прилегающая к ней, имеет особое, вполне определенное назначение (Код ICOM: аббревиатура: Input - Вход, Control - Управление, Output - Выход, Mechanism -Механизм), кратко разберем каждую отдельно. Левая сторона блока предназначена для входов - это материал или данные, которые преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. В данном случае на входе указана заработная плата, что по сути, ни материалом ни данными не является, однако расходуется для работы процесса A0. Верхняя сторона - для управления, это правила, стратегии, процедуры, стандарты, которые определяют условия, необходимые функции, чтобы произвести правильный выход. Неоспоримым управлением, в данном случае являются стандарты методологии OCTAVE, необходимость остальных управлений будет выявлена в процессе декомпозиции. Сторона правая, выход - данные или материальные объекты, произведенные функцией, в анализе рисков это
План мероприятий по снижению рисков. Нижняя сторона - механизмы, это ресурсы (персонал, техника, оборудование), поддерживающие выполнение функции (Рабочая группа).
На этапе Определение объема работ, руководство предприятия и ответственный за проведение анализа информационных рисков персонал, должны установить какие участки корпоративной информационной структуры будут подвергнуты анализу. на основе этого из каждого из этих сервисов выделяется сопровождающая, данный сервис, группа сотрудников предприятия, а так же бизнес - персонал, который данная группа поддерживает в использовании сервиса.
Следующим этапом является формирование Рабочей группы на основе ИТ специалистов и бизнес персонала, их непосредственного руководства, специалистов отдела безопасности предприятия, а в некоторых случаях и привлечения сторонних экспертов по интересующему направлению. После того как группа сформирована она проходит инструктаж по методологии, который включает в себя составление оценочных мнений о состоянии сервиса. Ранжирование критичности и оценочный вес каждого мнения предприятие выставляет само, в то время как критерии, в соответствии с методологией постоянны. Если представить, на мгновение, себе идеальный мир, в котором каждый пользователь обязан внимательно ознакомится с сопутствующей программе документации, появляется возможность избежать проведение инструктажа. Так что, на всякий случай, отметим, что в автоматизированную систему можно будет добавить перечень справочного материала по каждому из этапов взаимодействия пользователя с программой.
На этапе сбора информации у каждого из участников Рабочей группы, путем интервью, получаются данные
Инструктаж по методолотин
__
Опросный лист
опь«» |
—-Направлеим* работ
Заработная плата
рабочую труппу
1
Педгот сален ™й персонал
- Методология ОСТАУЕ
Вычисленные ИТ ркоп* по каждому ШСЕреИГОВ
План мероприятий по снижению рисков
Топ менеджмент предприятия
Рис. 2. Декомпозиция функционального блока АО из рис. 1
о потенциальном ущербе в случае нарушения конфиденциальности, целостности и доступности информационных активов, обрабатываемых и хранимых в том или ином ИТ сервисе, так же вероятности реализации угроз в области нарушения конфиденциальности, целостности и доступности.
Обработка информации, следующий этап, Происходит вычисление данных о состояниях контролей и сервисов. На данном этапе в автоматизированную систему информация не поступает, она из нее лишь изымается, из базы данных, и вычисляется ядром программы, в которое и заложены все математические формулы и методы методологии OCTAVE.
Заключительный этап - составление Плана мероприятий по снижению рисков. Обработанные и упорядоченные данные, ядром программы, выдаются администратору автоматизированной системы. Хранить результаты каждой проверки лишено смысла, т.к. этап Обработка информации, благодаря тому что он выполняется автоматизированной системой а не сотрудниками предприятия вручную, выполняется крайне малое количество времени. Если принять во внимание то что в процессе анализа рисков, коэффициенты которые получаются от пользователей постоянно дополняются (филиал из Хабаровска первым
закончит, а Калининград еще не приступит), если допустить сохранение всех предварительных результатов в базу, лишних записей, с устаревшей информацией будет слишком много и администратор автоматизированной системы может ошибиться взяв не те данные. Чтобы исключить возможность ошибки персонала и переизбытка ненужных данных в базе данных, результаты в базе данных не хранятся, а высчитываются автоматизированной системой каждый раз заново.
Из данной модели следует, что на каждом этапе анализа рисков задействован персонал предприятия, а для сбора информации используется стандартный опросный лист, данные из которых систематизируются в матрицы и обрабатываются. Каждый из этих этапов несет возможность человеческой ошибки при переносе данных с печатного или информационного носителя в единую Матрица рисков, к тому же, если рассматриваемое предприятие имеет большой штат и развитую ИТ структуру, множество филиалов по всей стране, то этапы А3 «Собрать информацию», А4 «Оценить эффективность контролей» и А5 «Обработать информацию» влекут за собой массу трудоемкой и однотипной работы, не говоря уже о временных задержках.
Для того чтобы формализовать требования к автоматизированной
Методология OCTAVE i
Инструктаж по методологии i
Заработная плата
Топ менеджмент
План мероприятий * по снижению рисков
Автоматизированная система
предприятия Емзнее персонал ИТ персонал
Цель: Анализ рисков по методологии OCTAVE с использованием АС Точка зрения: Генеральный директор предприятия Рис. 3. Модель анализа рисков с использованием АС
Инструктаж по методологии
эёмиы pa&rr Al
Заработная плата
•Направлен»'я
работ
рабочую группу А2
I
персонал
г!., i1
I. Собрать
АЗ
, j Г
* Собранна*
J
Методологий OCTAVE
_AJ
План мероприятии по снижению рисков
Анализ« ров« оценить ть,
обработать
- ■ ■■■ " ■ •■■'.< -.»V • -f"! 'И
t ■■ •§' ПракМИ С итниалжымкатжани
Топ менеджмент предприятие
ИТ персонал Автоматизированная сйпам
Рис. 4. Декомпозиция функционального блока АО из рис. 3
системе, и как следствие базе данных, построим модель анализов рисков (рис. 3) и ее декомпозицию (рис. 4) по методологии OCTAVE с учетом уже внедренной автоматизированной системы, автоматизирующей ее этапы.
Требования к системе:
1. Интерфейс должен быть интуитивно понятен.
2. Должны соблюдаться все методологические правила OCTAVE.
3. Доступность для всех филиалов предприятия через ЛВС.
4. Запись логов, взаимодействия пользователей с АС.
Из данных требований разработчиков базы данных напрямую касаются п. 3 и п. 4.
Для реализации всех требований разделим автоматизированную систему на функциональные части:
1. Два интерфейса, с помощью которых пользователи будут с ней взаи-
модействовать, отдельный интерфейс для работы с рабочей группой и отдельный для администратора автоматизированной системы.
2. Программное ядро, в котором автоматически будут производиться анализ, оценка и обработка данных по всем методологическим правилам OCTAVE.
3. Базу данных, в которой будет храниться вся получаемая информация.
После того как определилась структура автоматизированной системе и требования к ней, следует начинать разработку концептуально - логической модели базы данных. Выделим из анализа этапов анализа рисков данные касающиеся информации. На этапе А1, определение объема работ, в автоматизированную систему поступает информация о количестве сервисов и практик, которые решено применять к ним, следовательно, задается уникальный параметр анализа
Набор сервисов 1
Идентификатор набора 10-
Имя набора
Таблица с практиками
Название практики -
Идентификатор названия прзмики
Сервисы
Идентификатор сервиса 10 — Название сервиса Идентификатор набора Ю
00 Коэффициенты сервиса
00
Практики
Идентификатор практики 10 Название практики Идентификатор сервиса 10 -— Стоимость внедрения Коэффициенты практики
Рис. 5. Концептуально-логическая модель основных таблиц базы данных
рисков, который отличается от любых других анализов - названия сервисов и применимые к ним практики. Так как названия практик константы, а названия сервисов могут отличатся от предприятия к предприятию, будем считать что набор сервисов, это ключевые данные которые инициализируют процесс анализа рисков. Этап А3, сбор информации, на данном этапе в систему поступают коэффициенты по сервисам и практикам, все данные должны систематизироваться.
Таким образом база данных будет содержать как минимум наборы сервисов, сервисы и практики, так же понадобится отдельная таблица для названия практик. Кроме того у каждого из сервисов и практик имеются коэффициенты по конфиденциальности, целостности и по доступности (временная и полная потеря). На основе этого построим концептуально-логическую модель основных таблиц базы данных (рис. 5).
Разберем детально каждую таблицу, и на их основе создадим логическую модель базы данных. Т.к. данными, которые инициализируют процесс анализа рисков, является создание набора сервисов, первой таблицей которую
Таблица 2 Набор сервисов
следует однозначно определить это таблица «Набор сервисов» (табл. 2).
Для связи данной таблицы с другими используется «ГО набора», первичный ключ, который идентифицирует каждую запись, тип данных которого будет «Счетчик», это такой тип данных, значение которого - целое число. В столбец с таким типом нет необходимости вставлять значение вручную, т.к. оно вычисляется автоматически как следующее целое число по порядку. У каждой из таблиц будет аналог этой строки, по ней система будет идентифицировать каждую запись. «Имя набора» указываться администратором, для того чтобы ему не приходилось идентифицировать набор по «ГО набора», т.к. ориентироваться по цифрам гораздо сложнее чем по названиям, тип данных - строка. Создадим таблицу «Логи», в ней хранятся данные о взаимодействиях между пользователями и автоматизированной системой для анализа и контроля процесса автоматизации рисков. Распишем атрибуты каждой строки для нее (табл. 3).
Строка «ГО журнальной записи», тип данных которой «Счетчик», первичный ключ, который идентифицирует каждую запись. «Уровень важности» будет
Название столбца Тип данных Ключ? Может быть пустым?
ГО набора счетчик первичный ключ нет
имя набора строка, не более 100 символов нет нет
Таблица 3 Логи
Название столбца Тип данных Ключ? Может быть пустым?
ГО журнальной записи счетчик первичный ключ нет
уровень важности строка, не более 50 символов нет да
время-дата дата и время нет да
текст журнальной записи текст нет да
Набор сервисов
10 набора (РК)
Имя набора
Практики
1Р практики (РК)
10 имени практики
Ю сервиса
Стоимость внедрения
Коэффициент по конфиденциальности
Коэффициент по целостности
Коэффициент по доступности (временная потеря)
Коэффициент по доступности (полная потеря)
Сервисы
Ю сервиса (РК)
Название сервиса
10 набора
Коэффициент по кон ф иде н ци а льности
Коэффициент по целостности
Коэффициент по доступности (временная потеря!
Коэффициент по доступности (полная потеря)
Имена практик
10 имени практики (РК)
Имя практики
10 журнальной записи (РК)
Уровень важности
Время-дата
Текст журнальной записи
Рис. 6. Логическая модель базы данных 410
идентификатором для администратора по важности, тип данных - строка. «Время-дата» тип данных - «Дата и время». «Текст журнальной записи» содержит текст записи (лог, в котором отображаются действия пользователя и реакция системы на них), тип данных «Текст». По аналогии построив и объединив все полученные таблицы в единую структуру, получим логическую модель базы данных (рис. 6).
Вопрос выбора СУБД заслуживает отдельного, обстоятельного и детального анализа и решения, в этой работе будет использоваться бесплатная СУБД PostgreSQL.
Рассмотрим физическую модель базы данных, построенную на основе логической (рис. 7).
В созданной базе данных имеются 5 таблиц и 1 представление.
В таблице «Sets» хранятся наборы сервисов, т.е под каждым названием скрывается целый набор сервисов, которое предприятие или предприятии хотят проанализировать, остуда же и будет выгружаться данные в «Экспертную программу», в которую рабочая группа будет вводить данные.
В таблице «Services» хранятся сервисы и их допустимые риски, каждый сервис связан с набором из таблицы
«Sets», поэтому если удаляется набор сервисов, автоматически будут удалятся допустимые риски сервисов из этого набора, для предотвращения скапливания ненужной информации.
В таблице «Practices» хранятся практики для каждого сервиса из набора сервисов, все практики методологии OCTAVE изначально находятся в базе данных, для облегчения работы администратора автоматизированной системы, в таблице «Practicname». Каждая практика связана с сервисом, а так же хранит коэффициенты значимости практики и стоимость ее внедрения. Если удалить сервис из набора, автоматически удаляются и данные по данной практике применительно к сервису. Если удалить набор, то все лишние данные по удаляемому набору исчезнут.Данная база данных связана внешними ключами. У каждого набора сервисов, сервиса и практики существует свой идентификатор ID, который генерируется базой данных в автоматическом режиме на основании последовательности. Эта последовательность реализуется через отдельную «системную таблицу», хранящую помимо этого все идентификаторы ID, при запросе к ней выдающая следующий ID по порядку. Данная
practices
Г' >'■' ч INTEGER
Sirurctid INTEGER
pridiç*riarrrïla INTEGER
prici DOUBLE PRECISION
conitd DOUBLE PRECISION
rrrfrejr 0OUBLE PRECISION
ttrnpjose DOUBLE PRECISION
pennjcue DOUBLE PRECISION
SERVKI
services
s? servi «Id INTEGER
H« It INTEGER
■E5_mimp CHARACTER UARYINGOMl
contul DOUBLE PRECISION
integr DOUBLÉ PRÉCISION
htoB.lMi DOUBLE PRECISION
p«rmj»l DOUMgjgEOMION
SETJK
PfWCTICENAMEJ^K
Ides
j6 logid INTEGER
liVil CHARACTER(SO)
Т1ПГЕ TIMES TAK>(0) WITHOUT TIME TONE
menage TE(T
practiceiianie
£ praelieerrameid INTEGER
prjcllMrumi CHARACTER VARYIN6R80
sets
£ »lid INTEGER
nam; С НАЯАС TERj I DU )
view factors
imjiaint CHARACTER; 1001 sîrvujejume CHARACTER VARYING(Mt>) cranlot_r>jmi CHARACTER VSRVINOpiO)
тел
Рис. 7. Физическая модель базы данных
Рис. 8. Отображение готовой базы данных в pgModeler
«системная таблица» - это таблица, генерируемая СУБД автоматически, с ней невозможно взаимодействовать напрямую, возможно только сбросить счетчик, если надо, к ней обращается ¡НБЕНТ-запрос автоматически если не указать конкретное значение для идентификатора ГО. Если рассматривать ее более фундаментально то данная часть общей структуры в прямом понимании таблицей не является. Это особенность СУБД Рс^дгеБРЦ которая в ней имеет название «Последовательность». Ее составляющими являются части таблиц где указаны ГО и все процедуры с их автогенерацией.
Автогенерируемые последовательности имеют названия вида: «<название бд>_<название столбца>_эея.». Т.е для
КОРОТКО ОБ АВТОРЕ_
таблицы «Services» последовательность сгенерирует «services_serviceID_seq.»
Таблица «Logs» предназначена для хранения логов. В ней хранится дата записи, уровень важности и сообщение.
Представление «View_factors» - это заранее сохраненный Select-запрос. Результатом его выполнения является таблица, и к нему также можно обращаться Select-запросами. В нем указаны все коэффициенты значимости практик с указанием набора сервиса, сервиса и практики к которым оно принадлежит.
Снимок экрана (рис. 8), созданной базы данных в pgModeler, специализированной системе для создания баз данных к СУБД PostgreSQL, так же как и СУБД является полностью бесплатным.
Малышев Алексей Викторович - студент, e-mail: [email protected], МГИ НИТУ «МИСиС».
UDC 004.65
PRACTICAL ASPECTS OF THE ANALYSIS, DESIGN AND DEVELOPMENT OF A DATABASE FOR AUTOMATED RISK ANALYSIS
Malyshev A.V., Student, e-mail: [email protected],
Moscow Mining Institute, National University of Science and Technology «MISiS».
The paper highlights the practical aspects of the analysis domain, using standard IDEF0, design - from conceptual to logical and practical development of a database system for PostgreSQL database management system for automated risk analysis
Key words: analysis, IDEF0, design, logic model, database, database, PostgreSQL, OCTAVE, risk management, automated system, development.
