Экспертиза проектных решений по ролям, правам доступа и защищённым каналам

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

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

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

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

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

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

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

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

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

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

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

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

Защищённая передача данных

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

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

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

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

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

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

Подтверждены четыре связанные составляющие:

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

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

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

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

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

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

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

Как применять результат при изменении проекта

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

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

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

Разберём состав проектной документации и задачу экспертизы

Пришлите материалы — подскажем порядок проведения негосударственной экспертизы

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