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

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

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

Контур управления доступом в проектной документации

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

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

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

Авторизация и управление учётными записями

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

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

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

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

Роли связывают пользователя с конкретным объёмом доступа

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

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

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

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

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

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

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

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

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

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

Управление доступом не подменяет управление инцидентами

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

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

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

Что подтверждает результат и как его применять

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

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

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

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