Token-based авторизация для сессий прямого соединения в облачной системе (Андрей Романюк, LVEE-2014) — различия между версиями

== Аннотация ==
;Докладчик: {{Speaker|Андрей Романюк}}
<blockquote>
Performance and security is the cornerstone of the Cloud based applications.

Under this thesis we are going to discuss solution which was proposed by ITS Partner team of developers to optimize and improve access to the Cloud data without loosing security level.
</blockquote>

== Видео ==

{{vimeoembed|106429992|800|450}}

{{youtubelink|DLx7w9D9nJE}}{{letscomment}}


<!-- pollholder -->

== Слайды ==

== Доработка модуля авторизации ==

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

 AuthTokenSecret “secret string”

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

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

В настоящий момент авторы пробуют осуществить включение своих доработок в основной код проекта mod_auth_token.


== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->
* [http://lvee.org/en/abstracts/132 Страница доклада на сайте конференции]

<references/>





<!-- topub -->
{{stats|disqus_comments=1|refresh_time=2020-07-18T22:09:152021-08-31T16:39:50.908298131609|vimeo_comments=0|vimeo_plays=562|youtube_comments=0|youtube_plays=261273}}

[[Категория:LVEE-2014]]
[[Категория:Open-source projects]]
[[Категория:Аутентификация и авторизация]]
[[Категория:Хранение данных]]

Текущая версия на 12:20, 4 сентября 2021

Аннотация

Докладчик

Андрей Романюк

Performance and security is the cornerstone of the Cloud based applications.

Under this thesis we are going to discuss solution which was proposed by ITS Partner team of developers to optimize and improve access to the Cloud data without loosing security level.

Видео

Слайды

Тезисы

Введение

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

Данное приложение позволяет пользователям получать доступ к данным своих устройств NAS (Network Attached Storage) независимо от их физического местоположения. Облачный сервис, таким образом, имеет свою специфику: каждый пользователь облака непосредственно владеет и управляет собственным хранилищем данных. Кроме того, сервис позволяет обмениваться данными с другими пользователями, за счет предоставления доступа к отдельным ресурсам на своих NAS.

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

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

• оптимизация сетевого доступа клиента к NAS при появлении возможности их прямого соединения,
• а также обеспечение безопасности обмена данными.

Ниже рассмотрена проблематика и особенности решений, примененных в обоих случаях.

Оптимизация доступа

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

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

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

Для определения возможности соединения между клиентом и NAS в локальной сети используется следующая стратегия:

• Клиент запрашивает через сервер локальный IP-адрес NAS-устройства и его идентификатор.
• После этого отправляется запрос напрямую на устройство по полученному внутреннему IP-адресу.
• Очевидно, что если клиент и устройство находятся в одной сети, то запрос от клиента будет обработан успешно.
• NAS возвращает клиенту свой идентификатор (серийный номер), по которому определяется, что это именно то устройство, которое требуется пользователю.
• Если клиент не получил ответа по локальному адресу, или ответ был неверный, то предполагается, что прямого соединения с устройством хранения данных нет и поэтому коммуникация продолжается через сервер.

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

Обеспечение безопасности

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

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

Токен представляет собой закодированный в шестнадцатеричном формате MD5-хэш секретного ключа и значение текущего времени в миллисекундах в формате Linux time. Он вставляется в URI следующим образом:

uri-prefix/token/timestamp-in-hex/rel-path

например:

/fsbroker/dee0ed6174a894113d5e8f6c98f0e92b/43eaf9c5/file_to_protect.txt

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

Особенности реализации

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

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

cd ~ 
wget "http://mod-auth-token.googlecode.com/files/mod_auth_token-1.0.6-beta.tar.gz" 
tar xvzf mod_auth_token-1.0.6-beta.tar.gz 
cd mod_auth_token-1.0.6-beta / 
sudo ./configure 
sudo make 
sudo make check 
sudo make install 
sudo service apache2 restart

Также для использования модуля авторизации mod_auth_token в конфигурации веб-ресурса под управлением apache прописываются необходимые настройки (обычно эта конфигурация находится в файлах /etc/apache2/sites-enabled/*). Token-авторизация применяется только для директивы Location:

<Location /downloads/>      
AuthTokenSecret       "secret string"      
AuthTokenPrefix       /downloads/      
AuthTokenTimeout      60      
AuthTokenLimitByIp    off
</Location>

Доработка модуля авторизации

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

AuthTokenSecret “secret string”

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

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

В настоящий момент авторы пробуют осуществить включение своих доработок в основной код проекта mod_auth_token.

Примечания и отзывы

• Страница доклада на сайте конференции

Plays:335   Comments:1