Экспертиза механизмов разграничения доступа автоматизированной системы

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

Разграничение доступа проверялось как связанная система прав

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

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

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

Специальный раздел проекта задавал проверяемую модель доступа

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

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

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

Учётные записи и роли выполняли разные функции

В проекте были прямо описаны механизмы доступа и роли. Предусматривались логин и пароль, управление учётными записями и распределение пользователей по ролям. Эти элементы образуют разные уровни одной модели.

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

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

Права распространялись на функции и информационные ресурсы системы

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

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

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

Защищённая передача данных дополняла модель доступа

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

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

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

Результат относился к проекту после внесённых изменений

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

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

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

Проектный механизм доступа не равен доказанной защищённости системы

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

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

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