Акт отнесения ИС к классу: как заполнять без формальности и на что смотреть до подписания

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

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

Именно поэтому к акту нужно относиться как к решению, которое определяет дальнейшую траекторию работы, а не как к шаблону, заполненному по привычке.

По каким признакам ИС вообще относят к классу

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

Если говорить грубо, логика выглядит так. Для каждого вида информации есть два уровня: класс 4 — если подключений к открытым каналам передачи данных нет, и класс 3 — если такие подключения есть. При этом внутри этих уровней система попадает в соответствующую категорию в зависимости от вида обрабатываемой информации: персональные данные, специальные персональные данные, биометрические и генетические персональные данные, коммерческая или иная охраняемая законом тайна юридического лица, либо служебная информация ограниченного распространения.

Поэтому хороший акт отнесения — это не попытка «обосновать серьёзность» системы общими словами, а точное отражение двух вещей: что именно в ней обрабатывается и подключена ли она к открытым каналам передачи данных.

Что нужно понять до подписания

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

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

Иначе говоря, акт короткий по форме, но совсем не простой по основанию. За одной строчкой в нём стоит уже разобранная система, а не догадка о ней.

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

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

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

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

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

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

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

Поэтому хороший акт отнесения — это не формально заполненная форма, а короткий итог уже выполненного анализа системы.

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

Как проверять акт перед подписанием

Перед подписанием полезно смотреть на акт не как на заполненный шаблон, а как на короткое отражение уже понятой системы. Проверять нужно не только поля, но и основание, из которого они выросли.

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

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