Содержание
Безопасность любой компьютерной системы — комплексное понятие, включающее как технические, так и организационные меры по её обеспечению. Информационная система Arta Synergy, будучи компонентом общей компьютерной сети предприятия, может предложить технические средства для усиления безопасности тех или иных своих частей, которые потенциально могут быть атакованы злоумышленниками, но итоговая безопасность системы всё также будет зависеть от самого слабого её звена; задача данного раздела — показать, как исключить Arta Synergy из числа таких звеньев.
Со стороны Платформы дожно обеспечиваться выполнение следующих требований.
Безопасность:
вход в систему должен осуществляться только при успешной авторизации пользователя с доступом к разделам системы на основе предоставленных ролей;
при использовании сессионной авторизации или авторизации по ключам срок действия ключа или длительность сессии должны быть регулируемыми;
права каждого пользователя на доступ к отдельным разделам Платформы можно настроить индивидуально;
все действия пользователей должны журналироваться;
должна обеспечиваться возможность блокировки и разблокировки пользователей для входа в Платформу; возможность доступа пользователя к Платформе регулируется администратором Synergy;
должна обеспечиваться гибкая настройка сложности пароля пользователя;
должна быть возможность настройки таймаута для предотвращения подбора пароля.
Надежность:
Платформа должна позволять резервное копирование данных.
Управление пользователями, парольная политика мониторинг действий пользователей и управление резервным копированием описаны в главе «Подсистема администрирования», а также в документе «Руководство администратора». Далее будут рассмотрены:
авторизация пользователей при использовании интеграционных модулей в ARTA Synergy;
рекомендации по настройке Платформы и ее окружения для защиты от некоторых типов атак.
API ARTA Synergy доступны только авторизованным пользователям.
Тип авторизации — BASIC HTTP. Методы API
выполняются от имени того пользователя, который авторизован.
Имеются следующие типы авторизации:
Авторизация пользователя по его логину и паролю приемлема в тех случаях, когда приложение может знать текущий логин и пароль пользователя, например:
Приложение предоставляет альтернативный интерфейс к некоторым модулям Synergy (мобильное приложение, десктопный клиент для хранилища)
Приложение представляет собой
server-side утилиту для синхронизации,
для которого создан выделенный пользователь, и его логин и
пароль хранятся в конфигурационном файле на сервере.
Для реализации данного типа авторизации надо передать в
запросе заголовок Authorization со
значением
Basic + Base64(login +
: + password)
Например:
|
Логин |
|
|
Пароль |
|
|
Значение заголовка |
|
Сессионная авторизации используется для встроенных
WEB-модулей. При cессионной авторизации также используется тип
— BASIC HTTP, но в качестве логина
пользователя необходимо использовать значение
$session и в качестве пароля — полученное
значение sso_hash.
Таким образом заголовок Authorization
должен иметь значение:
Basic + Base64($session:
+ sso_hash)
Например:
|
Значение |
|
|
Значение заголовка |
|
Кроме того, получить параметры авторизации можно с помощью переменной окружения основного WEB-приложения Synergy:
$CURRENT_USER - представляет собой
JSON-объект следующего вида:
{
"id": "Идентификатор текущего пользователя",
"sso_hash": "hash-сумма для идентификации пользователя",
"surname": "Фамилия текущего пользователя",
"name": "Имя текущего пользователя",
"patronymic": "Отчество текущего пользователя"
}
Модуль, который хочет авторизоваться от имени какого-либо
пользователя таким способом, должен сгенерировать для него
ключевую пару, обеспечив сохранность закрытого ключа. Затем
модуль сохраняет получивший открытый ключ для пользователя в
Synergy, используя API
rest/api/person/generate_auth_key.
Этот метод назначает ключ тому пользователю, от имени которого выполняется.
Параметр user_token_expire_interval
регулирует интервал устаревания ключей авторизации. Пример
настройки интервала:
insert into options (id, value) values ('user_token_expire_interval', '30'); -- 30 минут
Интервал устаревания ключа указывается в минутах. Значение по умолчанию
0, то есть если ранее для данного пользователя был сгенерирован другой ключ, то предыдущий автоматически становится недействительным. Создать ключ можно только для существующего WEB-модуля, так как для этого требуется идентификатор приложения. Если у вас нет необходимости разрабатывать WEB модуль, но есть необходимость в использовании авторизации по ключам, можно создать такой модуль на уровне БД и отключить его использование в административном приложении SynergyAdmin для всех элементов оргструктуры.
Использование этого ключа для авторизации аналогично
использованию сессионного ключа. Тип авторизации
Basic HTTP, в качестве логина пользователя
надо использовать строку «$key», в качестве
пароля — полученный с помощью API ключ.
Таким образом заголовок Authorization
должен иметь значение:
Basic + Base64($key: +
значение_ключа)
Например:
|
Значение ключа |
|
|
Значение заголовка |
|
Средства обеспечения безопасности информационной системы можно разделить на два условных класса:
архитектурные
специализированные
К архитектурным средствам (security-in-mind) можно отнести такие вещи, как используемый язык и платформа программирования, используемая операционная система общий подход к проектированию разработке ИС, размещению данных, журналирование действий и тому подобное.
Специализированные средства обеспечения безопасности — это конкретные возможности (features), направленные на добавление либо усиление безопасности какой-либо части системы. К ним можно отнести шифрование передаваемых данных, требования к сложности паролей и защита от их подбора, антивирусная проверка загружаемых в систему данных и тому подобное. Также, если рассматривать безопасность в широком смысле, сюда можно отнести средства защиты от таких вещей, как атака, направленная на отказ в обслуживании (DoS, DDoS).
Используемый для разработки Arta Synergy язык и платформа
программирования Java разрабатывалась с
учётом требований к безопасности. Вот несколько примеров этого:
В Java используется автоматическое управление памятью, исключающее появление «висячих» указателей и выход за границы массива, что нейтрализует атаки вида «переполнение буфера»
Контроль при получении и загрузке программ носит в Java многоступенчатый характер: программные компоненты могут снабжаться электронной подписью, что позволяет контролировать их целостность и аутентичность, а верификатор байткодов, кроме общей проверки формата поступившей информации, пытается убедиться в отсутствии следующих некорректных действий:
подделка указателей (например, получение указателя как результат выполнения арифметической операции);
нарушение прав доступа к компонентам классов (например, присваивание переменной, снабженной описателем final);
использование объектов в каком-либо другом качестве (например, применение к объекту метода другого класса);
вызов методов объектов с недопустимым набором параметров;
недопустимое преобразование типов;
вызов операции Java-машины с недопустимым набором параметров;
некорректная операция с регистрами Java-машины (например, запись регистра с неопределенным содержимым);
переполнение или исчерпание стека. Выполняются также некоторые другие, более тонкие проверки, связанные, в частности, с корректностью обработки исключительных ситуаций.
Выполнение Java-кода внутри виртуальной машины Java (JVM) обеспечивает защиту Java-окружения времени выполнения и ресурсов аппаратно-программной платформы от вредоносного программного обеспечения и разграничивает доступ субъектов к ресурсам прикладного уровня.
Несомненно, никакая другая технология программирования на сегодняшний день не обеспечивает аналогичной степени информационной безопасности[2]
Платформа Arta Synergy реализована с использованием подхода к
проектированию ИС, называемого «трехслойная архитектура» (3 tier
architechture) согласно спецификации Java Enterprise
Edition[3] версии 6 (JEE6). В такой
архитектуре клиентское приложение (в нашем случае, основное
веб-приложение Arta Synergy, мобильные клиенты и Arta Synergy
Desktop Client) не имеет прямого доступа к хранилищу данных
(СУБД либо другому хранилищу), а взаимодействует со слоем
бизнес-логики, который и определяет, какие данные передавать и
получать. Это исключает, например, возможность атаки типа
«инъекция SQL» и ей подобных. В стандартной поставке Arta
Synergy SQL-сервер (MySQL) разрешены только локальные
подключения от сервера приложений (JBoss), что ликвидирует ещё
один источник потенциальных проблем с безопасностью.
Основной способ взаимодействия пользователей с платформой Arta
Synergy — использование главного веб-приложения Synergy, а её
настройка осуществляется через Конфигуратор и Административное
приложение, также работающие через Web. Эти веб-приложения
реализованы с использованием технологии Google Web Toolkit
(GWT) — технологии написания Rich Internet
Applications, преобразовывающей некоторое подмножество языка
Java в клиентский JavaScript-код. Для обмена данными с сервером
этот код использует генерируемые при компиляции методы RPC
(GWT-RPC). Технология GWT позволяет
контролировать и защищаться от таких проблем веб-приложений,
как:
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (XSRF) с
помощью GWT-RPC tokens[4]
Контроль за выполнением произвольного (не сгенерированного
GWT) JavaScript-кода
Кроме этого, при проектировании платформы в разрезе доступа пользователей к данным был применён подход «всё, что явно не разрешено, то запрещено». В общем случае, доступ пользователя к данным экземпляра системы определяется совокупностью следующих вещей:
Положение пользователя в организационной структуре предприятия
Членство пользователя в группах доступа
Это, а также наборы разрешений, называемые «ролями» и место их применения (например, каталог хранилища файлов) определяют конкретные наборы данных системы, которые доступны пользователю.
Немаловажным свойством платформы Arta Synergy, применяющимся при её проектировании, является журналирование всех действий пользователей и взаимодействующих с платформой внешних систем, что позволяет проводить аудиты безопасности и, кроме того, разрешать проблемы вида «кто, когда и каким образом просмотрел/добавил/изменил/удалил какие-либо данные».
Все клиентские приложения платформы Arta Synergy поддерживают работу по протоколу HTTPS, который позволяет:
Осуществлять проверку подлинности сервера (если для сервера используется ключ и сертификат, подписанный доверенным удостоверяющим центром)
Шифровать передаваемые данные
На стороне сервера включить работу клиентов по протоколу HTTPS можно двумя способами:
Используя поставляемый вместе с сервером Arta Synergy легкий
проксирующий веб-сервер nginx, можно очень гибко настроить
работу по https (например, вовсе запретить подключение по
нешифрованному каналу и перенаправлять все клиентские
запросы на адреса вида https:// либо
разрешить нешифрованные соединения только внутри доверенной
сети, и так далее).
Настроив поддержку протокола HTTPS напрямую во встроенном в
сервер приложений JBoss web-сервер: это
может быть использовано в том случае, если по каким-либо
причинам использование nginx невозможно либо нежелательно
Учётные данные пользователя для входа в систему Arta Synergy — это логин и пароль. Arta Synergy позволяет реализовать парольную политику — набор требований к сложности, устареваемости логинов и паролей и т. п. - настолько «параноидально», насколько это необходимо. Среди поддерживаемых возможностей задания требований к учётным данным:
Минимальная длина пароля
Минимальное количество цифровых символов в пароле
Минимальное количество букв верхнего, нижнего регистра в пароле
Минимальное количество специальных символов в пароле
Количество хранимых старых паролей, при совпадении с которыми нового пароля отказывать в его использовании
Максимальное количество последовательных одинаковых символов, символов одного класса
Запрет совпадения пароля с логином
Запрет совпадения пароля с фамилией, именем, отчеством пользователя (включая транслитерацию)
Кроме этого, для противодействия попыток подбора учётных данных пользователя возможно установить ограничение количества неудачных попыток входа под каким-либо пользователем с одного ip-адреса. По достижении этого количества неудачных входов будет активирован тайм-аут — следующую попытку ввода логина и пароля можно будет произвести только через определённое в настройках время — например, 15 минут.
Этот тайм-аут может быть также прогрессивным — следующее значение времени задержки получается по настраиваемой формуле, в которой задействуется предыдущее время задержки и различные математические действия — можно, например, настроить систему так, что при достижении 15 неудачных попыток входа каждая следующая (неудачная) попытка будет доступна через 5, 10, 15, … минут.
Все эти возможности в совокупности позволяют настроить парольную политику Arta Synergy в соответствии со стандартом PCI DSS 2.0.
Тема защиты от от атак вида «Отказ в обслуживании» (DoS) и «Распределённая атака на отказ в обслуживании» (DDoS) очень обширная, сложная и не относится напрямую к информационной безопасности программного обеспечения — с проблемами такого рода сталкиваются популярные публичные веб-порталы и интернет-бизнес, что несколько не совпадает с целями применения платформы Arta Synergy.
Описание способов защиты от подобного рода атак выходит за рамки
этого документа, однако поставляемый вместе с Arta Synergy
веб-сервер nginx разработан как
«отказоустойчивый сервер для ресурсов с высоким
трафиком»[5]. Nginx имеет высокую производительность
(используется на 34,9% из top 1000 высоконагруженных сайтов, что
больше, чем все остальные)[6], а также широкие и гибкие возможности по
перенаправлению и блокированию клиентских (в нашем случае,
злонамеренных) запросов на основе очень многих признаков,
включая географическое положение клиента.
Также существуют специализированные модули nginx для защиты от ddos, например testcookie-nginx-module[7].
Для защиты данных от фальсификации, а также для подтверждения личности осуществляющего действия человека в Arta Synergy реализован механизм создания и проверки цифровой подписи данных (документов).
Алгоритмы реализации цифровой подписи включают в себя как
сертифицированные алгоритмы семейств
ГОСТ Р 34.10 и
ГОСТ Р 34.310, так и связку
Sha256+RSA, что позволяет использовать ключи
и сертификаты, подписанные авторизационными центрами как
госудаственного уровня, так и собственными удостоверяющими
центрами организаций.
Поддержка локальных и сетевых CRL-листов может быть использована для гарантии того, что используемый для подписи сертификат не просрочен и не отозван, а также отбрасывать «плохие» сертификаты непосредственно на этапе подписывания.