Проверка управления учётными записями, ролями и доступом в автоматизированной системе

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

Связь авторизации, ролей и прав доступа

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

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

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

Документы, по которым проверялась модель доступа

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

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

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

Почему роль пользователя была важна для разграничения доступа

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

Для экспертной оценки это существенно потому, что отдельно существующая учётная запись отвечает лишь на вопрос о наличии пользователя в системе. Ролевая модель отвечает уже на другой вопрос — какие возможности пользователь получает после авторизации и на каком основании они ему предоставляются.

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

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

Защищённая передача как продолжение модели доступа

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

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

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

Что было подтверждено в проектной документации

В результате рассмотрения были подтверждены следующие характеристики проектной модели:

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

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

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

Где проходит граница подтверждённого результата

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

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

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

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

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

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

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

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

Другие завершённые задачи с отдельными предметами проверки собраны в разделе «Кейсы».