Системы и методы аутентификации пользователей

Введение

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

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

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

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

Обратимся к существующим методам аутентификации и освежим в памяти то, насколько они соответствуют требованиям времени – в том числе применительно к отечественной специфике.

Аппаратные токены

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

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

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

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

Рисунок 2. Аппаратный токен с генерацией одноразовых ключей RSA SecurID

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

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

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

Ауд.1 инвентаризация информационных ресурсов

Тип требования: Смешанное

Способы реализации:

• рекомендуемые: Организационные меры, реализуемые путем выполнения положений внутренних руководящих документов.
• возможные: Средства мониторинга показателей функционирования компонентов информационных систем.
  Средства управления активами и объектами защиты.

Возможности некоторых продуктов:

• CL DATAPK – Анализ сетевого трафика. Сбор конфигураций. Реализация указанной меры включает в себя:
  • Автоматическое назначение уникальных идентификаторов объектам защиты, определение сетевых параметров, полученных в режиме пассивного мониторинга – MAC-адреса и IP-адреса (при наличии).
  • Автоматическое назначение принадлежности объекта защиты к указанной в CL DATAPK домашней подсети.
  • Указание дополнительных идентификаторов для объектов защиты пользователем: наименования, типа объекта защиты. Возможность указания принадлежности к группам и присвоение меток.
  • Периодическое получение с объекта защиты конфигураций с использованием активного сбора данных и контроль за изменением получаемых конфигураций. Описание механизма активного сбора данных и контроль за изменением конфигурации ОЗ приведено в приложении А
• Secret Net Studio 8.5 – Снимок состава программного обеспечения (Паспорт ПО)

• Secret Net Studio – C 8.5 – Снимок состава программного обеспечения (Паспорт ПО)

• InfoWatch Endpoint Security – Инвентаризация используемого ПО, оборудования, внешних носителей

• InfoWatch ARMA (Firewall, Endpoint, Management) –

Аналоги в других приказах ФСТЭК России:

• Приказ 31 — АУД.1 Инвентаризация информационных ресурсов

Наверх

Обратно к V. Аудит безопасности (АУД)

Ауд.2 анализ уязвимостей и их устранение

Тип требования: Смешанное

Способы реализации:

• рекомендуемые: Организационные меры, реализуемые путем выполнения положений внутренних руководящих документов.
• возможные: Средства анализа защищенности.

Возможности некоторых продуктов:

• CL DATAPK – Анализ уязвимостей. Контроль соответствия требованиям ИБ. С целью осуществления оценки состояния объектов защиты в CL DATAPK реализована поддержка языка OVAL (Open Vulnerability and Assessment Language). Это основанный на XML формат, предназначенный для автоматизированной оценки безопасности систем и предоставляющий средства для описания исследуемой системы, анализа ее состояния и формирования отчетов о результатах проверки. Реализация указанной меры включает в себя:
  • Выполнение сканирования защищенности объектов защиты – активное взаимодействие с объектами защиты с целью выявления уязвимостей и способов их эксплуатации. Данный режим работы целесообразно применять только в режиме технического обслуживания АСУ ТП.
  • Формирование отчетов по результатам сканирования ОЗ на уязвимости, включающие список выявленных уязвимостей и рекомендации по устранению выявленных уязвимостей.
  • Формирование отчетов по результатам проверки конфигураций ОЗ на соответствие требованиям ИБ, включающий список выявленных несоответствий.
• АПКШ Континент 3.7 – Внутренняя синхронизация времени с ЦУС. ЦУС – синхронизация с сервером во внешней сети по NTP.
• Континент-АП Сервер доступа 3.7 – Внутренняя синхронизация времени СД с ЦУС.

• vGate 4.0 – Политика синхронизации временив ВИ

• Astra Linux Special Edition РУСБ.10015-01 – Выявление и оперативное устранение уязвимостей Astra Linux Special Edition производится разработчиком в соответствии с «Требованиями к уровням доверия», утвержденным приказом ФСТЭК России №131, и ГОСТ Р 56939

Аналоги в других приказах ФСТЭК России:

• Приказ 31 — АУД.2 Анализ уязвимостей и их устранение

Наверх

Обратно к V. Аудит безопасности (АУД)

Ауд.8 реагирование на сбои при регистрации событий безопасности

Тип требования: Смешанное

Способы реализации:

• рекомендуемые: Организационные меры, реализуемые в рамках реализации процедур выявления инцидентов и реагирования на них.
• возможные: Средства оперативной организации и автоматизации деятельности по мониторингу, регистрации и реагированию на инциденты информационной безопасности – IRP (Incident Response Platform).

Возможности некоторых продуктов:

• Secret Net Studio 8.5 – Есть реакция на переполнение журнала.
• Secret Net Studio – C 8.5 – Есть реакция на переполнение журнала.
• Secret Net LSP 1.9 – компоненты подсистемы контроля работоспособности, реализующие про-
  верку запуска и работоспособности подсистемы ведения журналов.
• ПАК “Соболь” 3.0.9 (M2) – В случае если при регистрации события произойдет сбой – при записи будет выдана ошибка, компьютер будет заблокирован из-за нарушения целостности внутренних структур
• Соболь 4.2 – В случае если при регистрации события произойдет сбой – при записи будет выдана ошибка, компьютер будет заблокирован из-за нарушения целостности внутренних структур
• АПКШ Континент 3.7 – Фильтрация при просмотре событий
• Континент-АП Сервер доступа 3.7 – Фильтрация при просмотре событий

• vGate 4.0 – Отправка уведомлений о событиях безопасности

• Astra Linux Special Edition РУСБ.10015-01 – Реагирование на сбои регистрации и предупреждения администратора при заполнении объема памяти для хранения информации о событиях безопасности осуществляются с помощью средств централизованного протоколирования и аудита событий безопасности

Аналоги в других приказах ФСТЭК России:

• Приказ 31 — АУД.8 Реагирование на сбои при регистрации событий безопасности

Наверх

Обратно к V. Аудит безопасности (АУД)

Биометрия

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

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

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

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

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

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

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

Защита конфиденциальных данных

10 ЗАКОНОВ БЕЗОПАСНОСТИ (от Microsoft) 

Закон №1. Если вы запустили на своем компьютере приложение злоумышленника, это больше не ваш компьютер.  

Закон №2. Еслизлоумышленник внес измененияв операционную систему вашего компьютера, это больше не ваш компьютер. 

Закон №3. Если у злоумышленника есть неограниченный физический доступ к вашему компьютеру, это больше не ваш компьютер.

Закон №4. Если злоумышленник смог загрузить приложения на ваш сайт, это больше не ваш сайт.

Закон №5. Ненадежные пароли делают бесполезной любую систему безопасности.

Закон №6. Безопасность компьютера напрямую зависит от надежности администратора.

Закон №7. Безопасность зашифрованных данных напрямую зависит от того, насколько защищен ключ расшифровки.

Закон №8. Устаревшее антивирусное приложение лишь немногим лучше, чем его отсутствие.

Закон №9. Абсолютная анонимность недостижима ни в жизни, ни в Интернете.

Закон №10. Технология не является панацеей. 

Зни.7 контроль подключения съемных машинных носителей информации

Тип требования: Смешанное

Способы реализации:

• рекомендуемые: Требование реализуется встроенными механизмами обеспечения информационной безопасности операционных систем, прикладного программного обеспечения, программируемых логических контроллеров, активного сетевого оборудования и т.п.
• возможные: Средства контроля съемных носителей информации.
  Физическое ограничение доступа к портам ввода-вывода.

Возможности некоторых продуктов:

• CL DATAPK – Периодический контроль подключенных устройств. Периодическое получение с объекта защиты информации о подключенных к нему устройствах с использованием активного сбора данных.
• Secret Net Studio 8.5 – Контроль устройств
• Secret Net Studio – C 8.5 – Контроль устройств

• Secret Net LSP 1.9 – Контроль устройств

• vGate 4.0 – Контроль устройств на ВМ, запрет подключения съемных носителей к серверам виртуализации

• InfoWatch Endpoint Security – Контроль использования внешних устройств и съёмных носителей

• InfoWatch ARMA (Firewall, Endpoint, Management) – Контроль использования внешних устройств и съёмных носителей
• Astra Linux Special Edition РУСБ.10015-01 – Реализуется средствами Astra Linux Special Edition, обеспечивающими контроль использования интерфейсов ввода (вывода) средств вычислительной техники, типов подключаемых внешних программно-аппаратных устройств и конкретных съемных машинных носителей информации на основе установленных администратором правил разграничения доступа

Аналоги в других приказах ФСТЭК России:

• Приказ 31 — ЗНИ.7 Контроль подключения машинных носителей информации

Наверх

Обратно к IV. Защита машинных носителей информации (ЗНИ)

Многофакторная (двухфакторная) аутентификация

Идеология многофакторной аутентификации (multi-factor authentication, MFA) заключается в том, чтобы взаимно компенсировать недостатки нескольких отдельных факторов, как минимум двух, у которых различаются ключевые риски. Чаще всего на практике используется двухфакторная аутентификация.

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

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

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

Например, Symantec предлагает сервис VIP – Validation and Identity Protection (бывший VeriSign Identity Protection), который не бесплатен, но предлагает довольно разнообразные функции вроде бесконтактной разблокировки, когда сотруднику не нужно ничего вставлять в считыватель или подносить к нему – достаточно находиться рядом.

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

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

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

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

Опс.1 управление запуском (обращениями) компонентов программного обеспечения

Тип требования: Функциональное

Способ реализации: Требование реализуется встроенными механизмами обеспечения информационной безопасности операционных систем, прикладного программного обеспечения, программируемых логических контроллеров, активного сетевого оборудования и т.п.

Возможности некоторых продуктов:

• CL DATAPK – Управление реализуется путем:
  • Идентификации запущенных компонентов программного обеспечения по имени, пути исполняемого файла, пользователю, запустившему процесс и другим атрибутам.
  • Периодического контроля перечня запущенных компонентов программного обеспечения с выявлением фактов их запуска и останова.
  • Определения легитимности факта запуска компонентов программного обеспечения путем сравнения перечня запущенных процессов с перечнем разрешенных процессов (эталонная конфигурация) и выявления отклонения от разрешенных значений.
  • Реагирования силами оператора / ответственного лица на факт выявления инцидента ИБ
• Secret Net Studio 8.5 – Замкнутая программная среда.
  Дополнительный режим контроля запуска скриптов.
• Secret Net Studio – C 8.5 – Замкнутая программная среда.
  Дополнительный режим контроля запуска скриптов.

• Secret Net LSP 1.9 – Замкнутая программная среда, включая контроль запуска скриптов.

• vGate 4.0 – Whitelist на серверах виртуализации

• InfoWatch Endpoint Security – Контроль целостности и запуска ПО

• InfoWatch Traffic Monitor – Контроль целостности и запуска ПО
• InfoWatch ARMA (Firewall, Endpoint, Management) – Контроль целостности и запуска ПО
• Astra Linux Special Edition РУСБ.10015-01 – Задача запуска в информационной системе разрешенного программного обеспечения реализуется средствами ограничения программной среды

Аналоги в других приказах ФСТЭК России:

• Приказ 31 — ОПС.1 Управление запуском (обращениями) компонентов программного обеспечения

Наверх

Обратно к III. Ограничение программной среды (ОПС)

Оцл.1 контроль целостности программного обеспечения

Тип требования: Функциональное

Способы реализации:

• рекомендуемые: Требование реализуется встроенными механизмами обеспечения информационной безопасности операционных систем, прикладного программного обеспечения, программируемых логических контроллеров, активного сетевого оборудования и т.п.
• возможные: СЗИ от НСД.
  Сканеры анализа защищенности,

Возможности некоторых продуктов:

• CL DATAPK – Контроль целостности файлов, реестра, БД, результатов вывода команд. Включает в себя активный сбор данных с ОЗ (из файлов, реестра, баз данных, выводов команд) и контроль за изменениями собираемых данных.
• Secret Net Studio 8.5 – Контроль целостности (файлы, папки, реестр)
  Замкнутая программная среда с возможностью контроля целостности модулей
• Secret Net Studio – C 8.5 – Контроль целостности (файлы, папки, реестр)
  Замкнутая программная среда с возможностью контроля целостности модулей
• Secret Net LSP 1.9 – Контроль целостности (файлы, папки)
  Замкнутая программная среда с возможностью контроля целостности модулей
• ПАК “Соболь” 3.0.9 (M2) – По контрольным суммам.
  При этом целостность средств защиты проверяется при загрузке системы по наличию имен (идентификаторов) компонент СЗПДн.
  Целостность программной среды обеспечивается отсутствием в ИСПДн средств разработки и отладки программ.
• Соболь 4.2 – По контрольным суммам.
  При этом целостность средств защиты проверяется при загрузке системы по наличию имен (идентификаторов) компонент СЗПДн.
  Целостность программной среды обеспечивается отсутствием в ИСПДн средств разработки и отладки программ.
• АПКШ Континент 3.7 – Средствами входящего в конструкцию ПАК “Соболь”
• Континент-АП Сервер доступа 3.7 – Программный КЦ

• vGate 4.0 – Контроль целостности файлов внутри ВМ, кончтроль целостности собственных компонентов vGate

• InfoWatch ARMA (Firewall, Endpoint, Management) –
• Astra Linux Special Edition РУСБ.10015-01 – Для обеспечения контроля целостности программного обеспечения и средств защиты информации используются средства динамического и регламентного контроля целостности

Аналоги в других приказах ФСТЭК России:

• Приказ 31 — ОЦЛ.1 Контроль целостности программного обеспечения

Наверх

Обратно к VIII. Обеспечение целостности (ОЦЛ)

Пароли

Классика удостоверения личности в информационных системах – пароль. Он так прочно ассоциируется с аутентификацией, что иногда считается ее сущностью. Например, в ГОСТе по судебно-технической экспертизе (Р 57429-2022) значится, что аутентификация пользователя – это «процедура проверки подлинности пользователя путём сравнения введенного им пароля с паролем, сохраненным в базе данных пользователей».

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

Помимо этого, средний пользователь современного Интернета зарегистрирован на десятках (если не на сотне-другой) разных ресурсов и сервисов, и каждый из них требует от него пароль. Один пароль на все сайты удобен, но небезопасен. Отдельный пароль для каждого сайта безопасен, но неудобен, поскольку пользователь нуждается либо в великолепной памяти, либо в хранилище для кодовых слов (которое опять же можно взломать).

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

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

Впрочем, обработку одноразовых паролей можно переложить на «подрядчика»: скажем, Google предлагает всем желающим воспользоваться приложением Authenticator, которое берет работу с одноразовыми паролями на себя. В этом случае можно не разрабатывать свою систему, а воспользоваться уже существующей – что и делает, например, популярное геймерское приложение Discord. Впрочем, это – уже тема для разговора о двухфакторной аутентификации.

Рисунок 1. Одноразовый пароль по SMS

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

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

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

Упд.12 управление атрибутами безопасности

Тип требования: Функциональное

Способы реализации:

• рекомендуемые: Требование реализуется встроенными механизмами обеспечения информационной безопасности операционных систем, прикладного программного обеспечения, программируемых логических контроллеров, активного сетевого оборудования и т.п.
• возможные: Требование может быть реализованы с помощью Служба каталогов (LDAP, Microsoft AD).

Возможности некоторых продуктов:

• Secret Net Studio 8.5 – Управление атрибутами в рамках настройки дискреционного и мандатного доступа. Атрибуты сохраняются в процессе обработки информации
• Secret Net Studio – C 8.5 – Управление атрибутами в рамках настройки дискреционного и мандатного доступа. Атрибуты сохраняются в процессе обработки информации

• Secret Net LSP 1.9 – Управление атрибутами в рамках настройки дискреционного доступа. Атрибуты сохраняются в процессе обработки информации

• vGate 4.0 – Назначение меток на объекты ВИ и контроль операций с ними

• InfoWatch Endpoint Security – Шифрование

• Astra Linux Special Edition РУСБ.10015-01 – В Astra Linux Special Edition реализовано мандатное управление доступом к информации в процессе ее хранения и обработки с учетом атрибутов безопасности (классификационных меток в формате, установленном ГОСТ Р 58256)

Аналоги в других приказах ФСТЭК России:

• Приказ 17 — УПД.12 Поддержка и сохранение атрибутов безопасности (меток безопасности), связанных с информацией в процессе ее хранения и обработки

• Приказ 21 — УПД.12 Поддержка и сохранение атрибутов безопасности (меток безопасности),  связанных  с информацией в процессе ее хранения и обработки

• Приказ 31 — УПД.12 Управление атрибутами безопасности

Наверх

Обратно к II. Управление доступом (УПД)

Упд.8 оповещение пользователя при успешном входе о предыдущем доступе к информационной (автоматизированной) системе

Тип требования: Функциональное

Способ реализации: Требование реализуется встроенными механизмами обеспечения информационной безопасности операционных систем, прикладного программного обеспечения, программируемых логических контроллеров, активного сетевого оборудования и т.п.

Возможности некоторых продуктов:

• Secret Net Studio 8.5 – Политика “Оповещение пользователя о последнем успешном входе в систему”

• Secret Net Studio – C 8.5 – Политика “Оповещение пользователя о последнем успешном входе в систему”

• ПАК “Соболь” 3.0.9 (M2) – Время(часы:минуты) и дата(день/месяц/год) тех моментов времени, когда был выполнен ваш вход в систему в текущеми в предыдущем сеансе работы на компьютере соответственно. Время и дата фиксируются в моментнажатия при вводе пароля

• Соболь 4.2 – Время(часы:минуты) и дата(день/месяц/год) тех моментов времени, когда был выполнен ваш вход в систему в текущеми в предыдущем сеансе работы на компьютере соответственно. Время и дата фиксируются в моментнажатия при вводе пароля

• Astra Linux Special Edition РУСБ.10015-01 – Сведения о предыдущей аутентификации, количестве успешных и неуспешных попыток входа предоставляются пользователю (в соответствии с его правилами разграничения доступа) и администратору с использованием средств протоколирования

Аналоги в других приказах ФСТЭК России:

• Приказ 17 — УПД.8 Оповещение пользователя после успешного входа в информационную систему о его предыдущем входе в информационную систему

• Приказ 21 — УПД.8 Оповещение пользователя после успешного входа в информационную систему о его предыдущем входе в информационную систему

• Приказ 31 — УПД.8 Оповещение пользователя при успешном входе предыдущем доступе к информационной (автоматизированной) системе

Наверх

Обратно к II. Управление доступом (УПД)

Централизованная модель со встроенной точкой принятия решения

В этой модели правила контроля доступа определяются централизованно, но хранятся и оцениваются на уровне микросервисов (рисунок 5). Правила контроля доступа определяются с помощью PAP (шаг 1) и доставляются во встроенную PDP вместе с атрибутами субъектов и объектов доступа, которые необходимы для использования этих правил (шаг 2). Когда субъект вызывает микросервиса (шаг 3), код микросервиса вызывает PDP, а PDP генерирует решение политики контроля доступа, оценивая входной запрос по правилам и атрибутам контроля доступа (шаг 4). На основе решения PDP микросервис применяет авторизацию (шаг 5).

Рисунок 5 Высокоуровневая архитектура централизованной модели со встроенной PDP

PDP код в этом случае может быть реализован как встроенная библиотека микросервиса или «sidecar-прокси». Sidecar обрабатывают коммуникации между сервисами, производят мониторинг и устраняют проблемы безопасности, то есть все, что может быть абстрагировано от отдельных сервисов, подробнее можно почитать тут.

В связи с возможными отказами сети или хоста и задержками в сети рекомендуется реализовать встроенную PDP в виде микросервисной встроенной библиотеки или sidecar на одном хосте с микросервисом. Встроенная PDP обычно хранит политику авторизации и связанные с политикой данные в памяти, чтобы уменьшить количество внешних зависимостей во время авторизации и для получения низкой задержки.

Основное отличие от “централизованного шаблона с единой точкой принятия решения” с подходом к кэшированию заключается в том, что решения по авторизации не хранятся на стороне микросервиса, вместо этого на стороне микросервиса хранится актуальная политика авторизации.

В выступлении “How Netflix Is Solving Authorization Across Their Cloud” представлен практический пример применения шаблона “Централизованную модель со встроенной PDP” для реализации авторизации на уровне микросервисов (рисунок 6):

Преимущества этих шаблонов такие же, как и для “Централизованных шаблонов с одним PDP”. Кроме того, шаблон не сильно влияет на задержки в обслуживании сетевых запросов из-за встраивания PDP на уровне микросервисов.

Существует несколько проблем, которые необходимо учитывать при применении этой модели:

• этот шаблон опирается на ручные или полуручные правила политики доступа, разработанные командой безопасности, которые могут быть подвержены ошибкам — во избежание уязвимостей конфигурации необходимо применять методы тестирования и верификации безопасности;
• архитекторы безопасности приложений должны комбинировать его с другими шаблонами (например, авторизация на пограничном уровне), чтобы избежать наличия единой точки принятия решений и обеспечить соблюдение принципа “эшелонированной обороны”;
• может случиться так, что некоторые специфические для бизнеса правила контроля доступа не могут быть реализованы таким образом — архитекторы безопасности приложений должны комбинировать этот шаблон с “Децентрализованным шаблоном”;
• архитекторы безопасности приложений должны выбрать подход, как получать обновления политик авторизации из централизованных PAP (например, опрос PAP или механизм публикации-подписки);
• команда разработчиков должна безопасно использовать сторонние компоненты авторизации и описывать политику контроля доступа, используя некий формальный язык, который в некоторых случаях может быть накладным — “Децентрализованный шаблон” может быть достаточным для реализации некоторой простой политики контроля доступа.

Централизованный шаблон с единой точкой принятия решения

В этой модели правила контроля доступа определяются, хранятся и оцениваются централизованно (рисунок 4). Правила контроля доступа определяются с помощью PAP (шаг 1) и доставляются в централизованную PDP вместе с атрибутами субъектов и объектов доступа, которые необходимы для использования этих правил (шаг 2).

Когда субъект вызывает микросервис (шаг 3), код микросервиса вызывает централизованный PDP через сетевой вызов, а PDP генерирует решение политики контроля доступа, оценивая входной запрос по правилам и атрибутам контроля доступа (шаг 4). На основе решения PDP микросервис реализует авторизацию (шаг 5).

Рисунок 4. Высокоуровневая архитектура централизованного шаблона с единой PDP

Некоторыми преимуществами этой схемы являются:

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

Для определения правил контроля доступа команда разработчиков и DevOps-инженеров должна использовать язык или нотацию. Примером может служить язык разметки Extensible Access Control Markup Language (XACML) и Next Generation Access Control (NGAC), который является стандартом для реализации описания правил политики.

Этот шаблон плохо влияет на время обслуживания запросов из-за дополнительных сетевых вызовов PDP; использование кэширования решений политики авторизации на стороне микросервиса позволяет уменьшить сетевые задержки.

Следует отметить, что PDP должен работать в режиме высокой доступности из-за возможных проблем с отказоустойчивостью. Архитекторы безопасности приложений должны комбинировать его с другими шаблонами (например, авторизация на уровне шлюза API), чтобы избежать наличия единой точки принятия решений и обеспечить соблюдение принципа “эшелонированной обороны”.

Заключение первой части

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

Stay tuned.

public void Configuration(IAppBuilder app)
{
    var factory = new IdentityServerServiceFactory();
    factory.UseInMemoryClients(Clients.Get())
           .UseInMemoryScopes(Scopes.Get())
           .UseInMemoryUsers(Users.Get());

    var options = new IdentityServerOptions
    {
        SiteName = Constants.IdentityServerName,
        SigningCertificate = Certificate.Get(),
        Factory = factory,
    };

    app.UseIdentityServer(options);
}

public void Configuration(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = "Cookies"
    });

    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
    {
        ClientId = Constants.ClientName,
        Authority = Constants.IdentityServerAddress,
        RedirectUri = Constants.ClientReturnUrl,
        ResponseType = "id_token",
        Scope = "openid email",
        SignInAsAuthenticationType = "Cookies",
    });
}

public void Configuration(IAppBuilder app)
{
    app.UseIdentityServerBearerTokenAuthentication(
        new IdentityServerBearerTokenAuthenticationOptions
        {
            Authority = Constants.IdentityServerAddress,
            RequiredScopes = new[] { "write" },
            ValidationMode = ValidationMode.Local,

            // credentials for the introspection endpoint
            ClientId = "write",
            ClientSecret = "secret"
        });

    app.UseWebApi(WebApiConfig.Register());
}