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

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

Как была устроена задача по разграничению доступа

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

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

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

Учётные записи и роли как единый механизм

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

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

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

Разграничение доступа к функциям системы

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

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

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

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

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

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

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

Как техническое заключение связывало решения и вывод

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

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

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

Что проверяется при согласовании подобных решений

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

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

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

Какой результат был подтверждён

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

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

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