РД 1-16
Базовый состав мер по идентификации и аутентификации субъектов логического доступа применительно к уровням защиты информации
РД.1 (Т-Т-Н)
Идентификация и однофакторная аутентификация пользователей.
Уровень защиты информации 3-Т, 2-Т, 1-Н.
Реализация - Т
Реализуется встроенными средствами ресурсов доступа в отношении пользователей (включая клиентов в системах ДБО) путём исключения возможности доступа к защищаемой информации (в том числе доступа к функциям обработки информации ресурса доступа) без идентификатора и пароля (или других типов аутентификации), а также запрет анонимного доступа.
Проверочные процедуры (свидетельства)
Для каждого типа ресурса доступа демонстрация с помощью скриншотов наличия процедур идентификации и аутентификации пользователя до момента доступа пользователя к защищаемой информации (стартовые экраны, страницы, требующие совместного указания логина и пароля (или иного типа аутентификации)).
Скриншоты отсутствия анонимного (гостевого) доступа к защищаемой информации.
Выборочные скриншоты с нескольких ресурсов доступа неудачных попыток входа без пароля.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.2 (Н-Н-Т)
Идентификация и многофакторная аутентификация пользователей.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Реализация - Т
Реализуется одновременным применением:
встроенных средств идентификации и аутентификации ресурсов доступа путём исключения возможности доступа к защищаемой информации (в том числе доступа к функциям обработки информации ресурса доступа) без пароля или других элементов аутентификации, а также запрет анонимного доступа;
использованием как минимум еще одного фактора аутентификации.
Факторы аутентификации первой и второй составляющий должны различаться.
Ниже указаны примеры комбинаций факторов аутентификации.
Ф1 - пароль. Ф2 - одноразовый код подтверждения.
Проверочные процедуры (свидетельства)
Для каждого типа ресурса доступа демонстрация с помощью скриншотов наличия процедур идентификации и аутентификации до момента доступа пользователя к защищаемой информации (стартовые экраны, страницы, требующие совместного указания логина и пароля (или иного фактора аутентификации). Дополнительно должно быть продемонстрировано с помощью скриншота использование второго фактора аутентификации другого типа (ввод пароля и использование сертификата, ввод пароля и использование разового кода подтверждения и пр.).
Скриншоты отсутствия анонимного (гостевого) доступа к защищаемой информации.
Выборочные скриншоты с нескольких ресурсов доступа неудачных попыток входа без пароля (иного типа аутентификации). Дополнительно должно быть продемонстрировано с помощью скриншота использование второго фактора аутентификации другого типа.
Скриншот невозможности доступа только с одним фактором аутентификации (например, только с паролем или только по разовому коду подтверждения).
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Многофакторная аутентификация определена как использование двух и более различных факторов аутентификации, что в ряде ситуация может трактоваться проверяющими как различные категории факторов аутентификации, в связи с чем может произойти необоснованное расширение требований проверяющих.
РД.3 (Т-Н-Н)
Идентификация и однофакторная аутентификация эксплуатационного персонала.
Уровень защиты информации 3-Т, 2-Н, 1-Н.
Реализация - Т
Реализуется встроенными средствами ресурсов доступа в отношении эксплуатационного персонала путём исключения возможности доступа эксплуатационного персонала к защищаемой информации (в том числе доступа к функциям обработки информации ресурса доступа) без идентификатора и пароля (или других типов аутентификации), а также запрет анонимного доступа.
Проверочные процедуры (свидетельства)
Для каждого типа ресурса доступа демонстрация с помощью скриншотов наличия процедур идентификации и аутентификации эксплуатационного персонала до момента доступа пользователя к защищаемой информации (стартовые экраны, страницы, требующие совместного указания логина и пароля (или иного типа аутентификации)).
Скриншоты отсутствия анонимного (гостевого) доступа к защищаемой информации.
Выборочные скриншоты с нескольких ресурсов доступа неудачных попыток входа без пароля.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.4 (Н-Т-Т)
Идентификация и многофакторная аутентификация эксплуатационного персонала.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Реализация - Т
Реализуется одновременным применением:
встроенных средств идентификации и аутентификации ресурсов доступа путём исключения возможности доступа к защищаемой информации (в том числе доступа к функциям обработки информации ресурса доступа) без пароля или других элементов аутентификации, а также запрет анонимного доступа;
использованием как минимум еще одного фактора аутентификации.
Факторы аутентификации первой и второй составляющий должны различаться.
Проверочные процедуры (свидетельства)
Для каждого типа ресурса доступа демонстрация с помощью скриншотов наличия процедур идентификации и аутентификации до момента доступа пользователя к защищаемой информации (стартовые экраны, страницы, требующие совместного указания логина и пароля (или иного фактора аутентификации). Дополнительно должно быть продемонстрировано с помощью скриншота использование второго фактора аутентификации другого типа (ввод пароля и использование сертификата, ввод пароля и использование разового кода подтверждения и пр.).
Скриншоты отсутствия анонимного (гостевого) доступа к защищаемой информации.
Выборочные скриншоты с нескольких ресурсов доступа неудачных попыток входа без пароля (иного типа аутентификации). Дополнительно должно быть продемонстрировано с помощью скриншота использование второго фактора аутентификации другого типа.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.5 (Т-Т-Т)
Аутентификация программных сервисов, осуществляющих логический доступ с использованием технических учетных записей.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Реализация - Т
Мера реализуется путем реализации в программных сервисах обязательной функции аутентификации, если в программном сервисе может быть указана учетная запись.
Либо путем реализации использования в программном сервисе функции использования учетной записи в составе операционной системы в целях работы программного сервиса.
Таким образом должна быть исключена программно возможность использования в программном сервисе такой функции, при которой использование учетной записи возможно без обязательной аутентификации.
Проверочные процедуры (свидетельства)
Определить состав используемых программных сервисов. Для установленного состава программных сервисов определить те, в которых возможно использование учетных записей. Наличие возможности использования технической учетной записи в программном сервисе определяется
скриншотом из интерфейса управления учетными записями операционной системы, в которой запускается программный сервис и составом связанных с учетными записями операционной системы программных сервисов;
скриншотом из интерфейса программного сервиса управления учетными записями;
составом конфигурационных файлов программного сервиса.
Для установленного состава технических учетных записей скриншотами продемонстрировать:
обязательное наличие пароля у технических учетных записей;
невозможность запуска программного сервиса при использовании пустого пароля.
Типичные недостатки
Хранение пароля технической учетной записи в открытом виде в составе конфигурационных файлов программного сервиса.
Использование учетной записи администратора под видом технической учетной записи.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.6 (Н-Т-Т)
Аутентификация АРМ эксплуатационного персонала, используемых для осуществления логического доступа.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Реализация - Т
NAC (в частности 802.1x и другие вариации port-based authentication) - т.е. именно аутентификация, где проверяются аутентификационные данные субъекта доступа (в данном случае сам АРМ).
В частности, возможны реализации когда УЗ эксплуатационного персонала может быть активирована только на выделенном АРМ, имеющим сертификат в службе каталогов, и далее при входе на АРМ Radius сервер аутентифицирует человека и позволяет ему подключится к сети.
Другие реализации подразумевают использование характерных для VPN протоколов решений во внутренних сетях компаний (например, вот описание решения предлагаемого в рамках экосистемы Vip Net https://infotecs.ru/about/press-centr/publikatsii/printsipy-marshrutizatsii-i-preobrazovaniya-ip-trafika-v-vpn-seti-sozdannoy-s-ispolzovaniem-tekhnolo.html ).
Дополнительные источники:
Проверочные процедуры (свидетельства)
Фрагмент сетевой конфигурации (возможно в виде выгрузки или скриншота) коммутаторов с настройкой NAC (в том числе port-based authentication).
Фрагмент конфигурации Radius-сервера (возможно в виде выгрузки или скриншота) с демонстрацией настройки 802.1x.
Демонстрация невозможности подключения к сети без прохождения аутентификации.
Типичные недостатки
Забывая об определении аутентификации, согласно п. 3.17 ГОСТ Р 57580.1, люди пытаются реализовать меру с помощью Port Security. Данная технология априори не достигает цели меры и направлена не против спуфинга АРМ эксплуатационного персонала, но для защиты коммутаторов (L2 устройств) и контроля несанкционированной смены MAC-адресов хостов. Подробнее можно прочитать тут:
Компенсационные меры
Не выявлены.
Выявленные коллизии
Необходимо определить корректность ранее предлагаемых решений:
Мера реализуется использованием протокола BOOTP вместо DHCP, при этом каждому IP адресу сопоставляется MAC адрес, зарегистрированный на АРМ.
Мера реализуется использованием Service Radius. Указывается, что запрос на выделение IP адреса обрабатывается только от известных Service Radius MAC адресов.
Для доступа по беспроводному соединению используются алгоритмы авторизации, заложенные в используемом протоколе шифрования.
РД.7 (Н-Н-Т)
Аутентификация АРМ пользователей, используемых для осуществления логического доступа.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Реализация - Т
Мера реализуется использованием на специальном управляемом коммутаторе (L2 Managed) технологии Port Security.
Мера реализуется использованием протокола BOOTP вместо DHCP, при этом каждому IP адресу сопоставляется MAC адрес, зарегистрированный на АРМ.
Мера реализуется использованием Service Radius. Указывается, что запрос на выделение IP адреса обрабатывается только от известных Service Radius MAC адресов.
Для доступа по беспроводному соединению используются алгоритмы авторизации, заложенные в используемом протоколе шифрования.
Проверочные процедуры (свидетельства)
Фрагмент сетевой конфигурации с демонстрацией ограничения MAC адресов состава подключаемых АРМ.
Скриншот использования Service Radius с демонстрацией ограничения состава MAC адресов для выдачи IP адреса.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.8 (Т-Т-Т)
Сокрытие (неотображение) паролей при их вводе субъектами доступа.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Реализация - Т
Мера реализуется средствами аутентификации ресурсов доступа и операционных систем.
Проверочные процедуры (свидетельства)
Скриншот из ОС, АС, иных ресурсов доступа с демонстрацией маскированных символов в поле ввода пароля.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.9 (О-О-О)
Запрет использования учетных записей субъектов логического доступа с незаданными аутентификационными данными или заданными по умолчанию разработчиком ресурса доступа, в том числе разработчиком АС.
Уровень защиты информации 3-О, 2-О, 1-О.
Реализация - О
Мера реализуется при выполнении условий:
включение во внутренний документ запрета использования субъектами паролей, ПИН-кодов (иных аутентификационных данных), заданных по умолчанию, а также запрета использования пустых паролей;
выполнение, регистрация в актах и задачах и контроль процедуры смены пароля по умолчанию для ресурса доступа с момента регистрации учетной записи субъекта доступа в ресурсе доступа;
периодические выполнения проверок (путем сканирования или вручную) ресурсов доступа на предмет возможного использования пароля по умолчанию или использования пустого пароля.
Проверочные процедуры (свидетельства)
Для ресурса доступа скриншот неудачной попытки входа с пустым паролем, паролем по умолчанию для выборки учетных записей.
Акты или задачи, где зафиксирована процедура смены пароля по умолчанию и факта проверки такой смены.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.10 (О-О-О)
Запрет на использование групповых, общих и стандартных учетных записей и паролей, а также прочих подобных методов идентификации и аутентификации, не позволяющих определить конкретного субъекта доступа.
Уровень защиты информации 3-О, 2-О, 1-О.
Реализация - О
Мера реализуется при выполнении условий:
включение во внутренний документ запрета использования одной учетной записи, использование которой разрешено группе субъектов доступа;
включение во внутренний документ запрета использования общей учетной записи нескольким субъектам доступа;
включение во внутренний документ запрета использования стандартной учетной записи, не позволяющей определить конкретного субъекта доступа;
смена пароля встроенной учетной записи и его защищенное хранение для исключения его использования субъектами доступа для встроенной общей учетной записи, если такая учетная запись неперсонифицирована в системе;
блокирование гостевых учетных записей;
периодические выполнения проверок на отсутствие общих или групповых учетных записей;
проверки фактов систематического возможного использования стандартной учетной записи с нескольких рабочих мест.
Проверочные процедуры (свидетельства)
Внутренние документы, определяющие запрет на использование групповых, общих и стандартных учетных записей и паролей, а также прочих подобных методов идентификации и аутентификации, не позволяющих определить конкретного субъекта доступа.
Скриншот встроенной заблокированной неперсонифицированной учетной записи.
Опрос о порядке использования учетной записи работниками, если в ресурсе доступа обнаружена активная неперсонифицированная учетная запись, например, учетная запись администратора.
Типичные недостатки
Ситуация наличия в ресурсе доступа или объекте доступа (например, сетевом оборудовании) единственной встроенной учетной записи (как правило уровня администрирования) является типовой. Технологические процессы требуют систематического использования такой учетной записи, причем разными работниками из числа эксплуатационного персонала. При этом не всегда возможно реализовать компенсационные меры, позволяющие установить, кто из эксплуатационного персонала использовал учетную запись.
Сложившиеся практики разработанных систем до внедрения настоящего стандарта ГОСТ Р 57580.1 или решений с открытым кодом, где также реализованы учетные записи привилегированного уровня в единственном экземпляре.
Компенсационные меры
В качестве таких мер рекомендуется распорядительным документом определять состав работников, их очередность и ответственность если необходимо использовать неперсонифицированные групповые или общие учетные записи.
В качестве компенсационной меры может использоваться подход выделения специальной рабочей станции для ограничения доступа к ресурсу, имеющему недостаток.
Выявленные коллизии
Не выявлены.
РД.11 (Т-Т-Т)
Временная блокировка учетной записи пользователей после выполнения ряда неуспешных последовательных попыток аутентификации на период времени не менее 30 мин.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Реализация - Т
Нужно отметить, что требование также распространяется на клиентов - пользователей АС.
Для контроллера домена WIndows
Настройка параметра в разделе GPO: Политика блокировки учетной записи (Account Lockout Password):
Пороговое значение блокировки (Account Lockout Threshold) – как много попыток набрать неверный пароль может сделать пользователь перед тем, как его учетная запись будет заблокирована;
Продолжительность блокировки учетной записи (Account Lockout Duration) – на какое время нужно заблокировать учетную запись (запретить вход), если пользователь ввел несколько раз неверный пароль;
Время до сброса счетчика блокировки (Reset account lockout counter after) – через сколько минут после последнего ввода неверного пароля счетчик неверных паролей (Account Lockout Threshold) будет сброшен.
Количество неправильных попыток ввода пароля устанавливается в файле /etc/pam.d/password-auth
auth required pam_tally2.so deny=3
account required pam_tally2.so
Установка параметров FAILED_LOGIN_ATTEMPTS и PASSWORD_LOCK_TIME профиля, зарегистрированного для использования пользователями.
SQL Server поддерживается использование механизмов политики паролей Windows.
В связи с этим в отношении MS SQL Server для систем, использующих СУБД MS SQL, и включающихся в оценку ГОСТ Р 57580.1-2017, рекомендуется использовать windows-authentication.
Для АС.
Реализация функций парольной политики, позволяющая выполнить автоматическую блокировку учетной записи при достижении определенного числа попыток неверного ввода пароля. Зависит от архитектурной реализации АС.
Проверочные процедуры (свидетельства)
Для контроллера домена Windows
скриншот настроек Политики блокировки учетной записи политик по умолчанию или групповых политик, настроенных для использования пользователями;
наблюдение за попытками много кратного ввода паролей до появления сообщения о блокировки учетной записи и проверка, что учетная запись заблокирована через 29 минут с момента появления сообщения о блокировке.
Для Linux
Для СУБД Oracle:
скриншот профиля пользователя из системной таблицы базы данных Oracle. Проверка настройки параметров AILED_LOGIN_ATTEMPTS и PASSWORD_LOCK_TIME.
Для АС:
скриншоты парольных политик учетных записей АС;
конфигурационные файлы настройки парольных политик АС;
наблюдение за процедурой многократного ввода неверного пароля и проверка, что доступ заблокирован через 29 минут после уведомления о блокировке.
Типичные недостатки
Мера не определяет состав ресурсов доступа, в отношении которых должна быть реализована мера, что позволяет требовать реализацию для всего состава ресурсов доступа, включая почтовые сервера, СУБД, сетевые приложения, виртуальные машины. Не для всего состава ресурсов доступа имеется техническая возможность настройки параметров блокирования доступа в границах значений, определённых ГОСТ Р 57580.1-2017.
Для ряда АС архитектурно не предусматривалось наличие параметров в границах значений, требуемых ГОСТ Р 57580.1-2017, либо действие таких параметров распространяется не на весь состав пользователей (например, не распространяется на клиентов).
На примере параметров СУБД Oracle видна проблема недостаточной точности параметра. При этом формально требование реализуемо, но в усиленном варианте (блокировка на день, а не на 30 мин), что может нарушать нормальное функционирование бизнес-процессов. Проверяющие должны в этой ситуации анализировать возможные негативные последствия своих рекомендаций, если реализация рекомендации возможна только в более строгом варианте.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.12 (Н-Т-Т)
Запрет множественной аутентификации субъектов логического доступа с использованием одной учетной записи путем открытия параллельных сессий логического доступа с использованием разных АРМ, в том числе виртуальных.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Реализация - Т
Настройка ограничений числа одновременной возможных сессий для одного субъекта доступа Remote Desktop Services для Windows-based систем (для удаленного подключения).
Мера реализуется путем соблюдения двух условий:
использования единого способа идентификации, аутентификации для всех ресурсов (например, путем использования single sign-on (технология единого входа));
принудительного ограничения числа single sign-on сессии в единственном числе для каждого субъекта доступа.
Мера реализуется путем принудительного наложения ограничения единственной сессии в СУБД, АС, сетевом приложении, виртуальном АРМ для каждого субъекта доступа. Должно быть обеспечено принудительное прерывание имеющейся на АРМ активной сессии при успешном создании на АРМ второй сессии либо запрет создания на АРМ второй сессии при наличии на АРМ активной первой сессии.
Данная мера должна быть реализована и в отношении клиентов как пользователей АС.
Проверочные процедуры (свидетельства)
Скриншоты и конфигурационные файлы, свидетельствующие об использование технологии single sign-on, проверка наличия ограничение единственной сессии для каждого субъекта доступа.
Наблюдение за процедурой создания первой сессии субъектом доступа и попыткой создания второй сессии тем же субъектом доступа при наличии активной первой сессии.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Мера не определяет, для какого состава субъектов доступа и ресурсов доступа должно быть наложено ограничение, таким образом ограничение должно быть наложено для всех субъектов доступа (пользователей (включая клиентов) и эксплуатационный персонал) и всех ресурсов доступа, что технически невозможно реализовать в полном объеме. В состав ресурсов доступа включены АС, в том числе системы ДБО, а значит должна быть запрещена возможность подключения клиента системы ДБО к двум разным компонентам одной АС одновременно, поскольку вне зависимости от SID сессии фактически идентификация и аутентификация выполняется от имени одной зарегистрированной учетной записи. Коллизия формулировки меры, формулировку меры следует понимать как запрет одновременного подключения с ресурсу доступа с разных АРМ.
Формулировка меры создает формально допустимую ситуацию, когда одновременные и параллельные сессии от имени одного субъекта доступа регистрируются на серверном оборудовании.
РД.13 (Т-Т-Т)
Обеспечение возможности выполнения субъектом логического доступа - работниками финансовой организации процедуры принудительного прерывания сессии логического доступа и (или) приостановки осуществления логического доступа (с прекращением отображения на мониторе АРМ информации, доступ к которой получен в рамках сессии осуществления логического доступа).
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Реализация - Т
Для ресурса доступа, имеющего интерфейс для логического доступа субъекта, должно быть предусмотрено наличие и доступность субъекту функции прекращения (прерывания) сессии логического доступа (меню Выход). При использовании функции прекращения логического доступа (например, нажатии на пункт Выход) должно происходить явное видимое субъектом прерывании сессии логического доступа, отображение конфиденциальной информации должно блокироваться заставкой или стартовой страницей.
Требование должно выполняться и для клиентов - пользователей систем дистанционного банковского обслуживания. Вне зависимости от способа реализации клиентского приложения.
Разрыв сессии логического доступа также может быть реализован посредством изъятия средства для аутентификации (токена) их устройства.
Проверочные процедуры (свидетельства)
Скриншот активного и доступного субъекту пункта меню Выход для каждого из типов ресурса доступа (АС, веб-сервера, виртуальной машины, сетевого приложения и пр.) совместно со скриншотом появления заставки или стартовой страницы после нажатия на пункт Выход.
Наблюдение за процессом прерывания субъектом сессии логического доступа для ресурса доступа, контроль появления заставки или стартовой страницы.
Типичные недостатки
Для ряда реализаций, например АС в реализации "толстый клиент" нет технической возможности обеспечить принудительное прекращение отображения информации.
В ряде случаев проверяющие организации считают прекращением отображения информации запуск заставки ОС и не требуют появления стартовой страницы АС после разрыва сессии в АС или в ОС, если для доступа к АС необходим обязательный предварительный логический доступ в ОС. Например, такой способ свидетельства может использоваться для АРМ, где активная сессия в ОС возможна только при установленном средстве для аутентификации (токене). Однако в этой ситуации надо понимать, что непосредственно сама сессия в АС может сохраняться активной, в связи с чем сохраняется риск несанкционированного доступа к конфиденциальной информации в отсутствие субъекта доступа.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.14 (Т-Т-Т)
Автоматическое прерывание сессии логического доступа (приостановка осуществления логического доступа) по истечении установленного времени бездействия (неактивности) субъекта логического доступа, не превышающего 15 мин., с прекращением отображения на мониторе АРМ информации, доступ к которой получен в рамках сессии осуществления логического доступа.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Реализация - Т
Должна быть реализована функция в составе ресурса доступа, выполняющая автоматическое прерывание сессии логического доступа по истечении 15 минут бездействия субъекта доступа, при этом после прерывания сессии должна быть активирована стартовая страница/заставка, блокирующая отображение конфиденциальной информации.
Необходимо помнить, что в составе ресурсов доступа ГОСТ 57580.1-2017 рекомендует рассматривать не только АС, но и сетевые ресурсы, веб-сервисы, сетевые приложения и пр.
Мера должна быть реализована и для компоненты АС, используемой клиентами, вне зависимости от типа технической реализации клиентского приложения
Проверочные процедуры (свидетельства)
Скриншот политик автоматического управления логическим доступом в ОС и АС.
Фрагмент конфигурации ресурса доступа, содержащей настройки прерывания сессии логического доступа и настройки переадресации на стартовую страницу.
Наблюдение за поведением ресурса доступа при наличии активной сессии логического доступа при бездействии свыше 15 минут субъекта, выполнившего логический доступ.
Типичные недостатки
В ряде случаев проверяющими принимается в качестве свидетельства автоматического прерывания сессии логического доступа и прекращения отображения информации в АС факт наличия настройки автоматической блокировки сессии логического доступа в ОС и запуска заставки в ОС, если доступ в АС возможен только при наличии активной сессии в ОС, при бездействии субъекта доступа свыше ненужного времени. При этом разрыв сессии логического доступа в АС не гарантируется, что создает риск несанкционированного доступа при отсутствии субъекта.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.15 (Т-Т-Т)
Выполнение процедуры повторной аутентификации для продолжения осуществления логического доступа после его принудительного или автоматического прерывания (приостановки осуществления логического доступа), предусмотренного мерами РД.13 и РД.14 настоящей таблицы.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Реализация - Т
Для каждого ресурса доступа, для которого осуществляется субъектами логический доступ, должна быть реализована функция автоматического принудительного возврата к функции аутентификации после прерывания логического доступа (возврат на страницу ввода пароля или предъявления иного фактора аутентификации).
Проверочные процедуры (свидетельства)
Последовательность скриншотов из ресурса доступа, демонстрирующая прерывание сессии логического доступа и переход к странице, требующей выполнения аутентификации следующим шагом.
Наблюдение за процедурой прекращения сессии логического доступа и перехода к пункту, требующему аутентификации в следующем шаге для восстановления логического доступа.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.16 (Т-Т-Т)
Использование на АРМ субъектов логического доступа встроенных механизмов контроля изменения базовой конфигурации оборудования (пароль на изменение параметров конфигурации системы, хранящихся в энергонезависимой памяти).
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Реализация - Т
Установка пароля на BIOS для физических АРМ пользователей и эксплуатационного персонала.
При реализации меры следует учесть, что если организация использует АРМ, являющиеся публично доступными для клиентов устройствами, то такие АРМ также требуют установки пароля на BIOS.
Проверочные процедуры (свидетельства)
Снимок страницы попытки доступа в базовую конфигурацию оборудования с демонстрацией запроса на ввод пароля.
Наблюдение за процедурой попытки доступа в базовую конфигурацию оборудования.
Типичные недостатки
Мера не определяет требований к сложности пароля, таким образом не обеспечивая защиту параметров конфигурации системы, поскольку формально выполнением можно считать даже установление пароля в один символ или легко определяемого пароля.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Недостаточная мера. ГОСТ 57580.1 - 2017 не требует аналогичной установки пароля для BIOS для физических серверов или средств вычислительной техники в составе публично доступных устройств.
Last updated
