Логическая схема ИС по приказу № 66: как показывать потоки, сегменты и средства защиты

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

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

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

Что логическая схема должна показывать на самом деле

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

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

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

Где логическую схему обычно ломают

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

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

Третья ошибка — превратить логическую схему в технический дамп. В неё переносят всё подряд: каждый порт, каждую маршрутную деталь, все протоколы, внутренние таблицы, группы пользователей и иные сведения, которые уместнее вынести в приложения. Приказ № 66 прямо допускает, что часть сведений отражается на схемах и в приложениях к ним при наличии таких сведений. Это важная оговорка: логическая схема должна оставаться читаемой, а не превращаться в свалку деталей, которую никто не будет анализировать. :contentReference[oaicite:1]{index=1}

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

Представим систему, в которой есть веб-приложение, база данных, доменная аутентификация, удалённый доступ администраторов через jump host, отдельный сервер журналирования и внешний обмен с другой ИС через защищённый канал. Если логическую схему сделать формально, на ней будут просто “веб”, “БД”, “AD”, “логи” и “VPN”. Это выглядит аккуратно, но почти бесполезно.

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

При этом часть технических деталей — IP-адреса серверов, сведения о средствах защиты, открытых транспортных портах и IP-адресах администрирования — может и должна уходить в приложения к схеме. Это как раз тот случай, когда перегружать сам рисунок не нужно, но и терять эти сведения нельзя.

Приведу пример одного из возможных вариантов логической схемы.

Как собирать логическую схему без хаоса

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

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

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

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

P.S. Примеры схем и приложений к ним размещу в следующих публикациях.