ГОСТ Р МЭК 62443-3-3-2016. Национальный стандарт Российской Федерации. Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности

6.3 SR 2.1 - Контроль выполнения авторизаций

 

6.3.1 Требование

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

6.3.2 Целесообразность и дополнительная методологическая основа

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

После того как система управления верифицировала идентичность пользователя (физического лица, программного процесса или устройства) (см. 5.3, SR 1.1 - Идентификация и аутентификация пользователей - физических лиц, и 5.4, SR 1.2 - Идентификация и аутентификация программных процессов и устройств), она должна также верифицировать правомерность запрашиваемой операции в рамках установленных политик и регламентов безопасности. Например, в случае политики управления доступом на основе ролей система управления проверит, какие роли закреплены за верифицированным пользователем или объектом и какие привилегии приписаны этим ролям: если полномочия распространяются на запрашиваемую операцию, то она выполняется, в противном случае запрос отклоняется. Это позволяет контролировать соблюдение ранжирования обязанностей и минимальных привилегий. По возможности не должно допускаться, чтобы механизмы контроля выполнения обращений отрицательно воздействовали на эксплуатационные характеристики системы управления.

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

6.3.3 Расширения требований

6.3.3.1 SR 2.1 RE1 - Контроль выполнения авторизаций для всех пользователей

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

6.3.3.2 SR 2.1 RE2 - Соотнесение полномочий с ролями

Система управления должна обеспечивать возможность для того или иного авторизованного пользователя или роли определять и корректировать соответствия полномочий ролям применительно ко всем пользователям - физическим лицам.

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

Примечание 2 - Это RE применимо в равной мере к программным процессам и устройствам.

 

6.3.3.3 SR 2.1 RE3 - Приоритетность диспетчерского управления

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

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

 

6.3.3.4 SR 2.1 RE4 - Двойное подтверждение

Система управления должна поддерживать двойное подтверждение на случай, если то или иное действие может серьезно отразиться на производственном процессе.

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

 

6.3.4 Уровни безопасности

Далее приведены требования для уровней SL, относящихся к SR 2.1 - Контроль выполнения авторизаций:

- SL-C (UC, система управления) 1: SR 2.1;

- SL-C (UC, система управления) 2: SR 2.1 (1) (2);

- SL-C (UC, система управления) 3: SR 2.1 (1) (2) (3);

- SL-C (UC, система управления) 4: SR 2.1 (1) (2) (3) (4).