BarsUP.AM: как мы разрабатывали средство защиты информации web-приложений

BarsUp.Access Manager (BarsUp.AM) — наш программный комплекс по защите конфиденциальной информации. При проектировании и разработке этой системы в соответствии с требованиями нормативных документов ФСТЭК России мы столкнулись со сложностями по управлению доступом к web-приложениям с использованием сертифицированных средств защиты информации.

Приказ ФСТЭК России № 17 говорит, что должен осуществляться выбор средств защиты информации, сертифицированных на соответствие требованиям по безопасности информации, с учетом их стоимости, совместимости с информационными технологиями и техническими средствами. Мы посмотрели, что было на тот момент на рынке и поняли: стоимость решений, совместимых с нашими информационными системами, зачастую превышала стоимость самих систем, либо они были несовместимы.

В этом случае регулятор сообщает, что при отсутствии подходящих средств защиты информации, организуется их разработка (доработка) и сертификация в соответствии с законодательством РФ или корректировка проектных решений. Мы приняли решение разработать и сертифицировать во ФСТЭК России ПО, реализующее функции идентификации и аутентификации пользователей, управления доступом и регистрации событий безопасности для возможности его использования:

• В автоматизированных системах до класса защищенности 1Г включительно согласно требованиям руководящего документа «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации» (Гостехкомиссия России, 1992);
• В государственных информационных системах до первого класса защищенности включительно согласно приказу ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» и методическому документу от 11 февраля 2014 г. «Меры защиты информации в государственных информационных системах»;
• В информационных системах персональных данных до 1 уровня защищенности включительно согласно приказу ФСТЭК России от 18 февраля 2013 г. № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».

Продукт получил название BarsUP.Access Manager или BarsUP.AM. Вопросы, связанные с получением решения ФСТЭК и заключением договоров с испытательной лабораторией и органом по сертификации я вынесу за границы данного материала, а опишу то, как мы разрабатывали программное обеспечение для защиты web-приложений.

Старт

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



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

На выходе мы получили продукт, который решает следующие задачи:

• обеспечение единой точки доступа (SSO) к информационным системам;
• идентификация и аутентификация пользователей и устройств;
• многофакторная аутентификация;
• управление идентификаторами;
• управление доступом субъектов доступа к информационным системам;
• регистрация событий безопасности.
• гибкая система паролей, при управлении аутентификационной информацией пользователей и устройств в ПО;
• возможность входа с использованием ЭП;
• возможность многофакторной (двухфакторной) аутентификации, с использованием TOTP алгоритма;
• ограничение неуспешных попыток входа в ПО;
• ограничение числа параллельных сеансов доступа для каждой учетной записи пользователя ПО;
• блокирование сеанса доступа в ПО после установленного времени бездействия (неактивности) пользователя или по его запросу;
• возможность создания справочников;
• взаимодействия с внешними каталогами;
• горизонтальная масштабируемость системы, за счет кластеризации.

ПО поддерживает два стандарта реализации единого входа:

• security assertion markup language (SAML);
• OpenID Connect 1.0.

Реализация единого входа на основе SAML

В соответствии с терминами стандарта SAML, ПО выступает в роли поставщика идентификации (identity provider, IdP). Подсистемы ИС выступают в роли поставщиков услуг (service provider, SP).

Общий порядок работы при едином входе посредством SAML представлен ниже:

1. Пользователь пытается осуществить web-доступ к приложению (SP);
2. Приложение проверяет наличие контекста безопасности и, при его отсутствии, формирует сообщение AuthnRequest и перенаправляет браузер пользователя на сервер авторизации BarsUP.AM (IdP);
3. Пользователь подключается к серверу авторизации и вводит свои учетные данные;
4. Сервер авторизации идентифицирует, аутентифицирует и авторизует пользователя;
5. Сервер авторизации перенаправляет браузер пользователя обратно к приложению с сообщением Response;
6. Пользователь снова пытается получить доступ к приложению, с параметром Response. Приложение проверяет Response и предоставляет пользователю доступ.

Обмен сообщениями между сторонами производится в виде утверждений SAML (assertions). Утверждения SAML передаются при помощи защищенного протокола HTTPS.

Между поставщиком идентификации IdP и поставщиками услуг SP устанавливаются доверительные отношения. Передаваемые сообщения SAML, в том числе AuthRequest и AuthResponse, подписываются при помощи цифровых сертификатов SP и IdP, соответственно.

Сообщение AuthRequest подписывается закрытым ключом приложения и доставляется на сервер авторизации посредством сообщений HTTP Redirect, HTTP POST или HTTP Artifact. В сообщении AuthRequest, в частности, содержится следующая информация:

• URL приложения;
• URL поставщика идентификации IdP (сервера авторизации BarsUP.AM);
• идентификатор и время создания запроса.

Ответное сообщение AuthnResponse подписывается закрытым ключом сервера авторизации. В сообщении AuthnResponse, в частности, содержится следующая информация:

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

Реализация единого входа на основе OpenID Connect

OpenID Connect является расширением, предназначенным для обеспечения идентификации и аутентификации пользователя посредством протокола OAuth 2.0.

В процессе реализации единого входа по технологии OpenID Connect, BarsUP.AM выполняет роль поставщика OpenID (OpenID Provider, OP). Информационные системы (т.е. целевые веб-приложения, к которым получает доступ пользователь) выполняют роль доверяющей стороны (Relying Party, RP), которая использует OP для аутентификации пользователя.

Реализация единого входа посредством OpenID Connect описана на рисунке ниже:

1. Пользователь пытается осуществить Web-доступ к приложению (SP);
2. Приложение формирует Authorization Code Request (протокол OAuth2.0) и перенаправляет браузер пользователя на сервер авторизации BarsUP.AM (OP);
3. Пользователь вводит свои учетные данные на OP;
4. OP аутентифицирует пользователя одним из установленных способов;
5. В случае успеха, OP запрашивает у пользователя разрешение на передачу RP информации о нем. В случае положительного решения, возвращает сообщение Authorization Response, которое содержит код авторизации;
6. RP проверяет ответ OP, после чего отправляет запрос на токен (Token Request). При этом взаимодействие осуществляется при помощи защищенного протокола TLS;
7. В случае успешной проверки запроса на токен, OP отправляет RP токены идентификации и авторизации (ID Token, Access Token);
8. RP проверяет токен и в случае успеха предоставляет доступ пользователю.

Аутентификация между BarsUP.AM и web-приложениями

Чтобы избежать атак, направленных на подмену OP или RP, они должны взаимно аутентифицировать друг друга.

BarsUP.AM поддерживает методы аутентификации, определенные в спецификации на OpenID Connect. Принцип работы OpenID Connect и OAuth 2.0 основан на использовании токенов идентификации (ID token) и авторизации (access token).

Приведу реализацию основных функций безопасности в ПО:

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

Идентификация и аутентификация пользователей

Идентификация и аутентификация реализуется в BarsUP.AM на основе имени пользователя и пароля. Пользователь вводит свои учетные данные на web-странице аутентификации BarsUP.AM. При этом учетные данные передаются в защищенном виде по протоколу HTTPS. Доступ к целевому приложению разрешается только в случае успешной аутентификации. Таким образом, реализуются идентификация и аутентификация пользователей при удаленном web-доступе к ИС.

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

Политика пароля BarsUP.AM предусматривает настройку следующих параметров:

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

BarsUP.AM поддерживает также многофакторную (двухфакторную) аутентификацию пользователей.

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

BarsUP.AM реализует автоматизированную поддержку управления учетными записями пользователей и автоматическое блокирование учетных записей.

Администратор может создавать, изменять, удалять, блокировать и разблокировать учетные записи пользователей по своему усмотрению. Учетные записи пользователей создаются администратором при помощи web-консоли сервера управления BarsUP.AM. При создании учетной записи указывается ФИО, адрес электронной почты, срок действия учетной записи и, при необходимости, другие атрибуты пользователя. Пароль меняется пользователем при первом входе в систему в соответствии с парольной политикой. Учетные записи пользователей могут объединяться в группы с определенными групповыми атрибутами и полномочиями.

Предусмотрены следующие механизмы блокировки учетных записей пользователей:

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

Разблокировка учетной записи производится администратором или после истечения таймаута блокировки (например, при блокировке вследствие превышения числа неудачных попыток входа).

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

Регистрация событий безопасности

BarsUP.AM реализует сбор, запись и хранение информации о событиях безопасности при удаленном web-доступе к ИС. В том числе, производится регистрация событий, связанных со сменой паролей пользователей, заведением и удалением учетных записей пользователей, изменением правил разграничения доступа и полномочий пользователей.

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

События разделены на категории, включая события безопасности и системные события. Права на просмотр журнала событий предоставляются администратору.

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

Итог

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