Как определить границы ИС и состав активов так, чтобы потом не переделывать СЗИ, схемы и документы

Ошибка с границами информационной системы почти никогда не выглядит как ошибка в моменте. На старте всё кажется понятным: вот серверы, вот пользователи, вот приложение, вот межсетевой экран. Но потом именно из-за этой мнимой понятности начинают расходиться схемы, документы и фактическая среда. В проекте одно, в эксплуатации другое, на аттестации всплывает третье. И почти всегда корень проблемы один и тот же: владелец ИС слишком рано решил, что он уже понял, где заканчивается система и какие активы в неё действительно входят.

На практике границы ИС нельзя определять по принципу «что стоит в одной стойке» или «что относится к одному проекту». Приказ № 66 заставляет смотреть на систему взрослее: через её структуру, информационные потоки, состав и размещение активов, физические и логические границы. А это значит, что вопрос нужно ставить не так: «что нам удобно включить в схему», а так: «без каких компонентов система не сможет обрабатывать защищаемую информацию, администрироваться, взаимодействовать с внешними узлами и поддерживать нужный режим защиты».

Именно на этом этапе закладывается качество всей дальнейшей работы. Если границы ИС и состав активов определены правильно, дальше уже можно проектировать СЗИ, выбирать меры, собирать документы и готовиться к аттестации без постоянных переделок. Если неправильно, всё остальное начинает ехать следом.

Что считать системой, а что — только окружением

По закону информационная система — это совокупность банков данных, информационных технологий и комплекса программно-технических средств. В реальной работе это определение полезно не само по себе, а как отправная точка. Оно помогает убрать одну вредную привычку: сводить ИС только к прикладному программному комплексу. На деле система почти всегда шире. Если приложение работает на виртуальной инфраструктуре, использует СУБД, аутентифицируется через каталог, администрируется через выделенный узел, передаёт данные во внешние системы и зависит от межсетевого экранирования, то всё это нельзя выкинуть за пределы анализа только потому, что оно не называется «основным приложением».

При этом обратная ошибка тоже встречается постоянно: включать в ИС вообще всё подряд, что есть в инфраструктуре организации. Так получается раздутый контур, с которым потом никто не может нормально работать. Поэтому границы нужно определять по функциональной и защитной связи с системой. Если компонент участвует в обработке защищаемой информации, обеспечивает её хранение, передачу, управление доступом, администрирование, журналирование, резервирование или защиту, его нельзя автоматически выносить наружу. Но если он живёт в той же организации, однако не влияет на функционирование и защиту конкретной ИС, его искусственное включение тоже будет ошибкой.

Проще говоря, границы ИС определяются не инвентарным номером и не названием подразделения, а реальной ролью компонента в жизни системы.

Где границы обычно ломаются

Чаще всего путаница начинается на стыке «основных» и «обеспечивающих» активов. Например, прикладные серверы включили в ИС, а доменный контроллер, DNS, NTP, jump host, узел резервного копирования или систему централизованного журналирования решили считать «общей инфраструктурой» и поэтому вынесли наружу. Формально это выглядит аккуратно. На практике — нет. Если без этих узлов невозможно нормально управлять доступом, вести время, собирать логи, выполнять резервное копирование или администрировать систему, они уже влияют на защищённость ИС и должны быть хотя бы явно отражены в её архитектуре и в логике проектирования СЗИ.

Вторая точка провала — каналы связи и внешние взаимодействия. Пока система существует только в одном сегменте, соблазн упростить картину велик. Но как только появляются удалённые пользователи, сервисные офисы, филиалы, облачные площадки, интеграции с внешними системами или каналы между ЦОД, границы ИС перестают быть чем-то локальным. Их уже нельзя рисовать только внутри серверной. Приказ № 66 прямо привязывает разработку структурной и логической схем к анализу внутренних и внешних информационных потоков, а значит, все такие связи нужно разбирать заранее, а не задним числом.

И, наконец, третья проблема — виртуализация. Как только система уходит на виртуальную платформу, многие начинают путать логические компоненты с физическими. В документах рисуют только виртуальные машины и забывают, что физическая база, гипервизор, виртуальные сети и механизмы управления тоже образуют реальную среду, без которой система не существует. Это не значит, что всё подряд нужно одинаково глубоко втаскивать в каждую схему, но это точно значит, что их нельзя игнорировать как несущественный фон.

Практический пример

Представим типичную ситуацию. У организации есть прикладной веб-комплекс, который размещён на нескольких виртуальных машинах: фронтенд, сервер приложений и база данных. Пользователи работают из офиса и через удалённый доступ. Аутентификация идёт через домен, журналы событий собираются на отдельный сервер, резервное копирование выполняется сторонним средством, а административный доступ идёт через выделенный jump host.

Если смотреть узко, в ИС можно попытаться включить только три виртуальные машины приложения. Но тогда сразу ломается вся практическая картина. Кто управляет доступом? Домен. Где собираются события? Лог-сервер. Через что идёт административный доступ? Jump host. Как обеспечивается восстановление? Система резервного копирования. Чем ограничиваются сетевые взаимодействия? Межсетевой экран и виртуальные сегменты. Если эти элементы никак не отражены в границах, схемах и проектных решениях, то владелец ИС потом неизбежно сталкивается с тем, что документы описывают одну систему, а защищается и эксплуатируется другая.

Правильный подход здесь не в том, чтобы механически включить в ИС всю инфраструктуру организации, а в том, чтобы честно выделить те активы и взаимодействия, без которых не существует либо сама обработка информации, либо управление и защита этой ИС. Именно они и должны попасть в анализ, схемы и дальнейшее проектирование СЗИ.

Как практически определять границы и состав активов

Самый рабочий способ — идти не от списка оборудования, а от маршрута жизни информации. Где она создаётся, где передаётся, где хранится, где обрабатывается, через какие точки к ней получают доступ пользователи и администраторы, какие компоненты участвуют в защите, журналировании, резервировании и восстановлении. Когда этот маршрут становится понятен, активы начинают раскладываться почти сами собой.

Дальше полезно разделить активы не по отделам, а по роли. Обычно получается несколько слоёв: основные прикладные компоненты; обеспечивающие сервисы; средства защиты информации; каналы и узлы взаимодействия; административные точки входа; внешние системы и внешние связи. Такая разбивка удобна тем, что она сразу помогает и для схем, и для проектирования мер, и для объяснения логики системы на проверке.

• сначала выделяются компоненты, без которых невозможно обрабатывать защищаемую информацию;
• затем — обеспечивающие сервисы, влияющие на управление, доступ, время, журналирование, резервирование и восстановление;
• после этого — средства защиты и узлы, через которые проходят критичные информационные потоки;
• отдельно фиксируются внешние взаимодействия, удалённый доступ и административные каналы;
• на финальном шаге проверяется, нет ли лишнего расширения контура и нет ли критичных элементов, которые забыли включить.

Именно после такой раскладки уже имеет смысл финализировать структурную и логическую схемы. Приказ № 66 прямо связывает их с анализом структуры ИС, информационных потоков, состава, количества и мест размещения активов, а также физических и логических границ системы. Это значит, что схемы должны быть итогом анализа, а не способом его заменить.

Где чаще всего ошибаются

• сводят ИС только к прикладному комплексу и забывают про обеспечивающие сервисы и административные точки входа;
• включают в контур вообще всю инфраструктуру организации и тем самым раздувают систему без необходимости;
• игнорируют внешние потоки и удалённый доступ, пока не начинают готовить логическую схему;
• путают логические компоненты виртуальной среды с физической базой, на которой они реально работают;
• рисуют схемы раньше, чем по-настоящему поняли состав активов и границы ИС.

Правильно определить границы ИС — значит заранее снять половину будущих проблем. В этот момент владелец ИС ещё не выбирает конкретные меры и не готовится к аттестации в узком смысле, но именно здесь решается, будет ли вся дальнейшая работа опираться на реальную систему или на её упрощённую картинку. Если границы и состав активов определены честно и без самообмана, дальше и СЗИ, и схемы, и документы собираются значительно спокойнее.