Создание защищенной информационной системы (ИС) часто представляется трудоемким, почти хаотичным процессом, вызывающим у многих ступор. Однако этот взгляд — миф. В реальности проектирование защищенных ИС — это управляемая технология, которая подчиняется четкой логике и последовательности действий. Актуальность этой задачи сегодня высока как никогда, что подтверждается работами таких авторитетов в области, как А.А. Малюк, В.В. Домарев и О.В. Казарин. Ключ к успеху лежит не в героических усилиях, а в системном подходе, основанном на стандартах и понятных этапах, которые превращают кажущийся хаос в управляемый проект.
Итак, мы определили, что ключ к успеху — в системном подходе. Давайте разберем его на составляющие и начнем с самого первого, фундаментального шага.
Этап 1. Обследование как основа будущего проекта
Любой проект по созданию защиты начинается не с выбора антивируса, а с работы, похожей на труд детектива или архитектора, изучающего местность перед строительством. Этот этап — глубокое обследование существующей информационной системы. Без детального понимания «что мы имеем сейчас» невозможно построить адекватную и эффективную защиту.
В ходе обследования анализируется вся подноготная системы:
- Структура ИС: из каких серверов, рабочих станций и сетевых устройств она состоит.
- Границы ИС: где заканчивается наша зона ответственности и начинается внешний мир.
- Ключевые компоненты: какие базы данных, приложения и сервисы являются наиболее важными.
- Потоки данных: как информация перемещается внутри системы и за ее пределы.
Результатом этой работы становится не просто набор разрозненных фактов, а формальный документ — Акт обследования. Именно он служит фундаментом, на котором будут строиться все последующие этапы проектирования. Это отправная точка, фиксирующая текущее состояние дел.
Теперь, когда у нас есть полная карта «местности», мы можем перейти от простого описания к формулированию конкретных правил и требований, которые будут действовать на этой территории.
Этап 2. Формирование требований или создание «свода законов» для системы
На этом этапе аналитические данные из Акта обследования превращаются в конкретные, формализованные требования к безопасности. Если обследование отвечало на вопрос «что мы имеем?», то теперь мы отвечаем на вопрос «что должно быть?». Этот процесс можно сравнить с написанием конституции или свода законов для будущего «государства» — нашей защищенной системы.
Ключевым документом, который рождается на этом этапе, является Техническое задание (ТЗ) на создание системы защиты. В нем четко и однозначно фиксируются все необходимые меры безопасности, которым должна будет соответствовать система. ТЗ определяет:
- Какие классы угроз должны быть нейтрализованы.
- Каким нормативным требованиям (включая государственные стандарты) должна удовлетворять система.
- Какие функции безопасности должны выполнять ее компоненты.
Именно Техническое задание становится главным руководством к действию для инженеров и определяет рамки всего дальнейшего проекта. Это тот самый документ, который превращает общие пожелания «сделать безопасно» в конкретный план действий.
Мы определили, что нужно защищать и какими должны быть общие правила. Но от кого именно мы защищаемся? Следующий шаг — детально изучить нашего противника.
Этап 3. Моделирование угроз, где мы изучаем потенциального противника
Пытаться защититься «от всего на свете» — это верный путь к неэффективной трате ресурсов. Критически важно понимать, от каких именно угроз мы защищаемся и кто может их реализовать. Этот этап похож на работу аналитика спецслужб, который изучает потенциальные риски и противников. Здесь разрабатываются две ключевые модели:
- Модель угроз. Этот документ отвечает на вопрос «что плохого может случиться?». Он описывает все актуальные для нашей ИС уязвимости и сценарии их использования. Например, возможность несанкционированного доступа к базе данных через SQL-инъекцию или утечки данных через незащищенные каналы связи.
- Модель нарушителя. Этот документ отвечает на вопрос «кто может нам навредить?». Он классифицирует потенциальных злоумышленников по их уровню знаний, ресурсам и мотивации. Нарушитель может быть как внешним (хакер), так и внутренним (нелояльный сотрудник), и его возможности будут кардинально различаться.
Моделирование угроз и нарушителя позволяет перейти от абстрактной защиты «от всего» к созданию целенаправленной системы безопасности, которая сосредоточена на нейтрализации реальных, а не гипотетических рисков.
Теперь у нас есть вся информация: что защищаем, как должны защищать и от кого. Пришло время синтезировать эти знания и спроектировать саму систему защиты.
Этап 4. Проектирование системы защиты, или создание инженерного чертежа
Это кульминационный, созидательный этап, на котором все предыдущие наработки — требования, модели угроз и нарушителя — превращаются в конкретную техническую архитектуру. Здесь работает главный инженер, создающий детальный чертеж будущей системы. Это уже не абстрактные цели, а конкретные технические решения.
Ключевые задачи этого этапа включают:
- Обоснование архитектуры системы защиты. Инженеры решают, как именно будут интегрированы различные компоненты защиты, чтобы создать единый, целостный механизм.
- Выбор конкретных средств защиты. На этом шаге подбираются конкретные программные и технические решения: межсетевые экраны, антивирусы, системы обнаружения вторжений, средства шифрования и т.д. Выбор напрямую зависит от актуальных угроз и требований из ТЗ.
- Разработка документации. Результатом становится полный пакет проектной документации — технический проект и рабочие документы. В них подробно описана вся система, ее настройки и правила эксплуатации.
Система защиты охватывает разные области, например, безопасность периметра сети (контроль трафика на входе и выходе) и защиту конечных точек (компьютеров пользователей и серверов). Весь этот комплекс мер должен соответствовать нормам, таким как ГОСТ Р 51583-2014, который регламентирует порядок создания защищенных систем.
Инженерный чертеж готов, материалы закуплены. Настало время переходить от теории к практике и начинать «строительство».
Этап 5. Внедрение и пусконаладка — переход от проекта к реальности
Проект не заканчивается на бумаге. Этап внедрения — это фактическое «строительство» системы защиты по созданным чертежам. Его можно сравнить с монтажом и запуском сложного промышленного оборудования. Здесь теория сталкивается с практикой, и система начинает «оживать».
Процесс включает в себя несколько ключевых шагов:
- Установка и настройка средств защиты. Специалисты устанавливают все программные и аппаратные компоненты на свои места.
- Пусконаладочные работы. Происходит тонкая настройка всех элементов системы, чтобы они работали согласованно и корректно, как единый организм.
- Функциональное тестирование. Проверяется, выполняет ли система все заложенные в нее функции — блокирует ли атаки, правильно ли разграничивает доступ и т.д.
- Анализ уязвимостей. Проводится сканирование уже собранной и работающей системы на предмет возможных «дыр» в безопасности.
- Приемочные испытания. Финальная проверка, в ходе которой заказчик убеждается, что созданная система полностью соответствует техническому заданию.
Это итеративный процесс, в ходе которого могут выявляться и оперативно исправляться недочеты, не замеченные на этапе проектирования.
Система собрана, настроена и работает. Но как доказать, что она действительно соответствует всем требованиям, в том числе государственным стандартам?
Этап 6. Аттестация, или получение официального «паспорта безопасности»
Аттестация — это финальный и формальный этап, который многие недооценивают, считая его бюрократией. На самом деле, это независимая экспертиза, которая подтверждает, что построенная система защиты информации действительно выполняет свои функции и соответствует всем нормативным требованиям, таким как стандарты ФСТЭК России и ГОСТ.
Этот процесс можно сравнить со сдачей государственного экзамена. Специальная комиссия (лицензиат) проводит испытания и проверяет всю документацию, чтобы убедиться: система спроектирована и внедрена правильно. Успешное прохождение аттестации завершается выдачей «Аттестата соответствия». Этот документ официально подтверждает, что информационная система защищена на заявленном уровне, и является ее «паспортом безопасности».
Пройдя этот этап, мы завершаем полный цикл создания системы. Давайте оглянемся назад и подведем итоги проделанного пути.
Заключение и взгляд в будущее
Мы прошли весь путь создания защищенной информационной системы — от первичного обследования и формирования требований до внедрения и получения аттестата соответствия. Как мы видим, это не хаотичный набор действий, а последовательная и управляемая технология. Каждый из шести этапов логично вытекает из предыдущего, превращая сложную задачу в решаемый проект с предсказуемым результатом.
Важно понимать, что обеспечение безопасности — это не разовое действие, а непрерывный процесс. Технология проектирования включает не только «создание», но и «развитие» объектов информатизации. После ввода системы в эксплуатацию начинается новый цикл: мониторинг, адаптация к новым угрозам и модернизация средств защиты. Только такой подход позволяет поддерживать актуальный уровень безопасности в постоянно меняющемся мире цифровых технологий.
Список источников информации
- ГОСТ Р 51275-06 «Защита информации. Объект информатизации. Факты, воздействующие на информацию. Общие положения» // СПС Гарант 2016.
- ГОСТ Р 51583-2014 Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения
- Положение по аттестации объектов информатизации по требованиям безопасности информации от 25 ноября 1994 г. // [Электронный ресурс]: http://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty/112-polozheniya/375-polozhenie-ot-25-noyabrya-1994-g
- Объект информатизации. Классификация объектов защиты // [Электронный ресурс]: http://www.intuit.ru/studies/courses/2291/591/lecture/12689
- Кондратюк А.П. Методология создания объектов информатизации различного назначения в защищенном исполнении // Защита информации. Инсайд. 2007. № 1 (13). С. 23-31.
- Карпов А.В., Карпов В.В. Особенности применения современных методов разработки программного обеспечения защищенных автоматизированных систем // Программные продукты и системы. 2016. № 1. С. 5-12.