Информационная безопасность: роли, права доступа и защищённые каналы

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

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

Логика доступа в рассмотренной системе

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

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

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

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

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

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

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

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

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

Учётная запись связана с ролью, а роль — с полномочиями

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

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

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

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

Разграничение распространяется на функции и источники видеонаблюдения

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

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

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

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

Защищённые каналы выделены отдельным проектным условием

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

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

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

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

Почему этот кейс отличается от задачи хранения событий

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

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

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

Что подтверждено техническим заключением

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

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

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

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

Как применять эту логику при проверке аналогичного проекта

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

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

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

Предел проектного подтверждения

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

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

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