Методологии построения систем безопасности
2.4.8 Документирование концептуальной архитектуры безопасности
Если заданы согласованные цели разработки, можно создать концептуальную модель для безопасности в ИТ-решении. На рис. 2.12 и 2.13 как раз представлена концептуальная архитектура безопасности. Для ясности функции безопасности объединены в группы по цели разработки.
Схема представляет окружение решения, разделенное на сегменты по профилю риска либо по операционному сходству, а также представлены иконки для функций безопасности. Для схем легенда ставит в соответствие подсистемы безопасности иконкам. У подсистемы контроля информационного потока имеется широкий диапазон функций. По этой причине для обозначения оценки политики и функции контроля за выполнением применяются прямоугольники, в то время как функцию потока данных представляет овал, так же как и коммуникационный протокол со встроенными возможностями безопасности.
На основании перспективы размещения решения в корпорации только целями дизайна безопасности будет диктоваться, где именно требуется функциональность безопасности; однако соответствие некоторым или всем требованиям безопасности может быть ограничено исполнительными возможностями политик вне пределов границ корпорации. Тот факт, могут ли быть эти мандатные подсистемы и подсистемы контроля доступа интегрированы в архитектуру безопасности и каким образом, может очень сильно повлиять на кредитоспособность всего решения в целом. Подобные вопросы и зависимости следует рассматривать и документировать в архитектурных решениях.
Такой тип концептуальной модели формирует основу для разработки и оценки "подтверждения концепции" и дальнейшего усовершенствования функциональных аспектов безопасности в целевом окружении.
2.4.9 Интеграция безопасности в архитектуру общего решения
В процессе перевода концептуальных функций подсистем безопасности в спецификации уровня компонентов и руководство по интеграции выделяются несколько шагов. В них входят: создание моделей окружения решения, документирование архитектурных решений, разработка вариантов использования, усовершенствование функционального дизайна и интеграция требований безопасности в архитектуры компонентов.
Модели решения
Создание первоначальной модели решения является критическим шагом в процессе дизайна. При наличии навыков и опыта для удовлетворения данному набору требований можно разработать и некие своеобразные модели решения. Для сложных же решений повсеместной практикой становится использование шаблонов, полученных из предыдущих решений.
Структура корпоративных решений (ESS, Enterprise Solutions Structure) предоставляет целый ряд шаблонных архитектур для решений электронного бизнеса.
Документирование архитектурных решений
Ранее было описано понятие дуальной природы дизайна безопасности, т. е. гарантирование правильной и надежной работы и защита от ошибок и преднамеренного вредительства. Обе эти мотивировки основаны на управлении риском для бизнеса как в самом решении, так и в его окружении. Риск представляет собой вероятность того, что в результате атаки злоумышленников, непредвиденного события, функциональной ошибки и т. п. произойдут нежелательные последствия. Риск либо принимается как неотъемлемая плата за функционирование, либо переводится в поле деятельности каких-нибудь других частей системы, либо перекрывается гарантийными обязательствами, либо уменьшается правильной организацией архитектуры безопасности.
Именно архитектурными решениями будет диктоваться, какой следует быть надежной архитектуре системы безопасности: какие подсистемы безопасности должны входить в системную архитектуру, какие функции и механизмы следует разместить в каждой из подсистем, где будут находиться эти механизмы и как будет осуществляться управление всей системой.
Примеры архитектурных решений включают:
- жизнеспособность контрмер, куда входят адресуемые угрозы, ограничения и изъяны решения и конечное окно риска;
- расширяемость дизайна, куда входит, будет или нет дизайн служить всему населению, и если да, то будут ли отдельные дизайны для разных заданных сегментов населения;
- удобство работы с дизайном, куда входит, будут или нет механизмы интегрироваться с технологической базой и размер накладных расходов в угоду пользователям;
- управляемость дизайна, куда входит размер накладных расходов управления одного полного цикла.
2.4.10 Варианты использования
Архитектурные решения также будут проводить оценку прототипов и моделей функций в решении. Одна форма прототипа называется вариантом использования. При помощи вариантов использования можно проверить как угрозы для безопасности, так и нормальные взаимодействия и потоки.
Пример 1. Перехват ошибочного пакета или потока сообщения
На рис. 2.14 представлены несколько уровней подробностей работы подсистемы контроля информационного потока, предназначенного для слежения за операциями отправки и получения при пересечении границы между двумя сетями.
Компьютерные системы представлены с точки зрения физики. С позиции компонентов находящийся между источником и точкой назначения интерфейс контроля информационного потока будет рассматривать один или более аспектов пакетов или сообщений, посланных вдоль границы. В обзоре с точки зрения логики показаны некоторые компоненты подсистемы контроля информационного потока, где на основе набора правил выполняются отслеживаемые условия и запрограммированные действия. Правильные пакеты могут пересекать границу; но пакеты или сообщения заранее установленного формата, из неверного источника или с неверно указанной точкой назначения отклоняются подсистемой безопасности. При этом вызовом интерфейса подсистемы аудита безопасности создается запись события.
Данный пример демонстрирует типы фильтрации, анализа и ответа, выполняемые в пакетной фильтрации брандмауэров и в шлюзах электронной почты.
На каждом шаге дизайна существует множество архитектурных решений, которые следует учитывать. Важными факторами являются влияние на производительность задержек при выполнении плюс влияние сбора данных и анализа на общую работу решения.
Пример 2. Трехъярусный клиент-серверный входной поток
Рис. 2.15 иллюстрирует входной поток для трехъярусного клиент-серверного процесса, т. е. типичной интеграции компьютерной системы предприятия в интернет-окружение.
увеличить изображение
Рис. 2.15. Трехъярусный клиент-серверный входной поток с подсистемами безопасности
На рисунке изображено несколько примеров подсистем безопасности, разбросанных по трем сетевым доменам безопасности. Подсистема контроля информационного потока расположена в пограничных точках между сетями. Подсистема контроля доступа расположена между принимающим компонентом и соответствующим ему компонентом приложений. Интерфейсы, связанные с мандатными подсистемами и с подсистемами аудита безопасности, изображены на уровне логики подсистем безопасности. Никаких функций подсистемы проверки целостности в этом примере нет. Сценарий примера следующий:
- Пользователем или процессом вызывается интерфейс бизнес-процесса, и через отправляющий компонент посылаетя запрос.
- Запрос некоторым образом проходит по домену безопасности, т. е. он принимается отправляющим и принимающим компонентами на основании предопределенных правил контроля информационным потоком.
- Принимаются решения по идентификации, аутентификации и контролю доступа на основании внешней идентичности, связанной с запросом через подсистему контроля доступа, относящуюся к приложению среднего уровня.
- Посредством привязки пользовательских настроек вызывается приложение среднего уровня. Фактическая реализация этого процесса здесь не приводится – в нее может входить представление о бизнесе и логика сопоставления данных либо она может выполняться подсистемой контроля информационного потока уровня приложений, например прокси-сервером.
- Приложение среднего уровня инициализирует (или передает) запрос приложению конечного уровня. Запрос тщательно обрабатывается в еще одной контрольной точке на границе сетей.
- В приложении конечного уровня по запросу относительно представленной приложением среднего уровня идентичности пользователя может быть вынесено решение, которое будет зависеть от дизайна приложения и используемых протоколов обмена.
- Если решение системы контроля доступа будет положительным, пользовательской привязкой запускается бизнес-процесс.
Все это демонстрирует, как распределены по решению функции безопасности из нескольких подсистем. Как и в первом примере, архитектурные решения будут обусловливать дизайн функций подсистемы безопасности, которые, в свою очередь, могут наложить ограничения на весь бизнес-поток для достижения целей управления риском.
Усовершенствование функционального дизайна
Наше прохождение по полным бизнес-процессам, включая процессы исключительных ситуаций и их обработки, поможет в создании эскиза жизнеспособного решения и в уточнении требований и взаимозависимостей между строительными блоками решения.
Пример 3. Регистрация цифрового сертификата инфраструктуры открытого ключа (PKI)
Данный пример в качестве первого шага при разработке архитектуры системы безопасности использует модель мандатной подсистемы для описания обобщенного потока для регистрации пользователя в системе мандатов или проверки подлинности, основанной на цифровых сертификатах PKI. В этот процесс входит сочетание модели подсистемы с предположениями о бизнес-окружении, бизнес-процессах, требованиях управления риском, технических спецификациях и, возможно, требованиях юридического и бизнес-соответствия, связанных с вопросами использования цифровых сертификатов PKI.
На рис. 2.16 ручные процессы представлены блоками под номером 1. Автоматические процессы обозначены блоками с цифрой 2. Точкам автоматического снятия данных аудита соответствуют блоки 3. 4 номер имеют пиктограммы хранилищ данных, изображающие важные хранилища. Пиктограммы с цифрой 5 соответствуют криптографическим секретам, фигуры с номером 6 представляют собой уникальное содержимое сертификата, и 7 пиктограмма связана с самим сертификатом.Изображенное на рисунке протекание процесса регистрации демонстрирует обмен важной пользовательской информацией и секретами плюс экспорт мандата за пределы области контроля запрашивающего. В полный сценарий регистрации еще следует включить процессы соответствующих подсистем контроля информационного потока. Для мандатов открытого ключа наряду с подробной информацией о том, как мандаты форматируются, перемещаются и хранятся, важным вопросом дизайна является формат сертификатов. Все сценарии должны быть проверены и подтверждены относительно существующих и предложенных бизнес-процессов. Подтверждение сценариев усиливает архитектурные решения, которые обсуждались ранее. Последующие шаги дизайна требуются для разработки и постановки в соответствие функций подсистем безопасности спецификациям Общих критериев и в конечном итоге узлам и физическим компонентам.