Структурная схема ИС по приказу № 66: что в неё включать и как не ошибиться

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

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

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

Что именно должно попасть в структурную схему

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

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

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

Где структурную схему обычно портят

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

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

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

Как это выглядит на практике

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

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

При этом не нужно доводить её до абсурда. Приказ допускает объединение однотипных физических устройств и однотипных виртуальных машин в единый элемент, если это явно обозначено и не ломает понимание схемы. Это важная оговорка. Она позволяет делать схему читаемой и не превращать её в полотно из сотни одинаковых объектов.

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

Как готовить схему, чтобы не переделывать её три раза

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

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

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

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