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

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

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

Управление доступом начиналось с учётной записи пользователя

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

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

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

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

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

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

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

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

Защищённая передача данных была отдельным элементом проектного решения

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

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

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

Как подтверждённые решения сложились в положительный результат

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

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

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

Что нельзя подтвердить одной проектной проверкой

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

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

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