Усиление аутентификации Google Apps при помощи Swivel PINpad

Усиление аутентификации Google Apps при помощи Swivel PINpad

В статье рассматривается интеграция предлагаемой компанией Swivel технологии аутентификации с сервисами Google Apps. В результате интеграции можно будет использовать различные методы аутентификации при доступе к таким ресурсам как Gmail, Google Docs, Google Drive и другим. Усиление процедуры аутентификации необходимо из-за участившихся случаев перехвата паролей, в том числе, и для сервисов Google Apps.

 

 

1. Введение

2. Общие сведения

3. Архитектура и системные требования Swivel PINpad

4. Интеграция

5. Результаты

6. Выводы

 

 

Введение

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

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

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

 

Общие сведения

В частности, компания Swivel предлагает двухфакторную аутентификацию с помощью изображений по технологии Swivel PINpad, которая не требует дополнительного независимого канала передачи данных от сервера к пользователю или специальных устройств для генерирования одноразовых паролей. В то же время технология Swivel построена по схеме «запрос-ответ»: сервер присылает пользователю изображение, по которому тот генерирует одноразовой пароль. Такой пароль создаётся пользователем по определённым правилами, подделку которых достаточно сложно автоматизировать, но при этом процедура аутентификации для пользователя оказывается достаточно простой. Картинка-запрос в PINpad сделана таким образом, чтобы автоматически распознать её было достаточно сложно - это своеобразный тест CAPTCHA, но для пользователя не составило бы труда распознать изображение и сгенерировать по ней одноразовый пароль. Фактически, такая проверка - это защита от автоматического перехвата пароля с помощью троянских программ, которые могут работать как на персональных компьютерах, так и на мобильных устройствах.

Следует отметить, что компания Swivel поддерживает в своих продуктах самые разнообразные способы аутентификации и доставки одноразовых паролей. Кроме метода аутентификации по специальной картинке для преобразования PIN-кода, предлагаются продукты для рассылки SMS. Также существует возможность проходить процедуру аутентификации с помощью виртуальной клавиатуры - это удобно для устройств с сенсорным экраном. Кроме того, есть и приложение для аутентификации с помощью мобильного устройства - в частности бесплатное приложение для аутентификации при помощи мобильного устройства есть в магазине Google Play и App Store.

 

Архитектура и системные требования Swivel PINpad

Компания Swivel разработала набор компонент, которые позволяют интегрировать PINpad, в том числе, и с сервисами Google Apps. В частности, сервисы эти поддерживают технологию федеративной аутентификации с помощью формата SAML. Это специальный формат обмена XML-сообщениями, который позволяет серверам Google доверять аутентификацию корпоративному серверу. На Рисунке 1 показана схема взаимодействия клиентского браузера, сервисов Google и корпоративной службы аутентификации.

 

Рисунок 1. Схема взаимодействия браузера клиента, сервисов Google и корпоративной службы аутентификации

Схема взаимодействия браузера клиента, сервисов Google и корпоративной службы аутентификации 

 

Последовательность действийпри работе с Swivel PINpad :

  1. Клиент посылает запрос серверу на доступ к используемым им ресурсам.
  2. Сервис Google генерирует SAML-запрос и передаёт его браузеру. Доступ к ресурсам при этом ещё не представляется.
  3. Браузер передаёт запрос в корпоративную службу аутентификации. При этом важно, чтобы между сервисом Google и службой аутентификации ранее уже были установлены доверительные отношения через сертификаты. Об этом чуть позже.
  4. Корпоративная служба получает от браузера SAML-запрос, предоставленный браузером пользователя, и проверяет, что он действительно сгенерирован сервисом Google.
  5. Если проверка SAML-запроса прошла успешно, то корпоративный сервер проводит процедуру двухфакторной аутентификации пользователей с помощью технологии Swivel и результаты в виде SAML-ответа со встроенной ссылкой на Google Apps ACS передаются браузеру.
  6. Браузер пересылает SAML-ответ сервису Google и, если всё правильно, получает доступ к сервису.

Из описанной процедуры видно, что для интеграции механизмов аутентификации Swivel с сервисами Google нужно установить в компании специальный сервер аутентификации. Компания подготовила специальное приложение для сервера приложений omcat, которое можно найти здесь. Настроить его так, что бы он мог обрабатывать SAML-запросы и выдавать корректные ответы, которые будут приниматься Google. После этого уже можно будет настроить доверительные отношения между Google и вашим корпоративным сервером аутентификации.

 

Интеграция

Общая схема интеграции следующая:

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

При интеграции процедуру аутентификации должен выполнять специально созданный сервер - шлюз аутентификации, который поддерживает веб-интерфейс для проведения аутентификации и проверки результатов. Этот сервер должен быть установлен в компании - лучше всего в демилитаризованной зоне, и настройкой его должен заниматься системный администратор или соответствующий сотрудник отдела ИБ. На нём должен быть развернут сервер приложений Tomcat, в который должно быть установлено специальное приложение Swivel. На сервере Swivel, развернутом внутри корпоративной сети, нужно указать этот шлюз аутентификации как XML-агента с настройками, которые показаны на Рисунке 2.

 

Рисунок 2. Настройки для взаимодействия сервера Swivel со шлюзом аутентификации

Настройки для взаимодействия сервера Swivel со шлюзом аутентификации 

 

Далее на шлюзе аутентификации нужно сгенерировать SSL-сертификаты, которые нужно будет загрузить на сервер конфигурации Google Apps. Для этого на шлюзе нужно выполнить следующие команды:

openssl dsaparam -out dsaparam.pem 2048 - определяет параметры для генерации секретного ключа с длиной 2048 бит, как этого требует Google;

openssl gendsa -out dsaprivkey.pem dsaparam.pem - генерация секретного ключа и запись его в файл dsaprivkey.pem;

openssl dsa -in dsaprivkey.pem -outform DER -pubout -out dsapubkey.der - генерации открытого ключа в формате DER (dsapubkey.der) , который поддерживается Google;

openssl pkcs8 -topk8 -inform PEM -outform DER -in dsaprivkey.pem -out dsaprivkey.der -nocrypt - экспорт секретного ключа в формат DER (dsaprivkey.der) для размещения его на шлюзе аутентификации;

openssl req -new -x509 -key dsaprivkey.pem -out dsacert.pem - создание сертификата в формате X.509, который также должен быть расположен на шлюзе.

Файлы dsapubkey.der, dsaprivkey.der и dsacert.pem нужно сохранить в каталоге /keys/pinsafe/robssl/ и указать путь к ним в соответствующих настройках файла AuthenticationPortal-google\WEB-INF\settings.xml на шлюзе. Остальные параметры этого файла настроек мы уже обсуждали в предыдущей статье серии.

Далее арендованные сервисы Google должны быть настроены так, чтобы перенаправлять пользователя, входящего в соответствующий домен, на этот сервер для прохождения процедуры усиленной аутентификации. Для этого в административном интерфейсе Google Apps нужно настроить процедуру однократной аутентификации SSO, как это показано на Рисунке 3, указав при этом в качестве домена свой адрес, по которому у вас расположен шлюз аутентификации, а директории указать во всех тех случаях как idp/pinsafeIdp.jsp как это показано на рисунке.

 

Рисунок 3. Интерфейс Google Apps для настройки интеграции с корпоративным шлюзом аутентификации

Интерфейс Google Apps для настройки интеграции с корпоративным шлюзом аутентификации 

 

В пункте "Проверочный сертификат" указать файл dsacert.pem с сертификатом и загрузить его на сервер. Далее нужно не забыть нажать на кнопочку "Сохранить".

 

Результаты

После настройки всех необходимых элементов процедура аутентификации в Google Apps немного поменялась - после прохождения основной аутентификации в сервисе Google Apps, которая показана на Рисунке 4, пользователь перенаправляется на специальный экран Swivel PNpad для прохождения дополнительной SAML-аутентификации.

 

Рисунок 4. Основной экран аутентификации в сервисе Google Apps

Основной экран аутентификации в сервисе Google Apps 

 

На Рисунке 5 показана уже аутентификация с помощью модуля Swivel PINpad с помощью специальной картинки для преобразования PIN-кода в одноразовый пароль.

 

Рисунок 5. Интерфейс для прохождения аутентификации с помощью одноразовых паролей

Интерфейс для прохождения аутентификации с помощью одноразовых паролей 

 

После верного прохождения процедуры аутентификации сервисы Google разрешают доступ к основному хранилище данных на Google Docs и других сервисах Google Apps.

 

Выводы

Добавление дополнительного фактора аутентификации, разработанного компанией Swivel, позволит клиентам, которые уже пользуются сервисами Google Apps, настроить дополнительный уровень защиты для доступа к своим данным. Злоумышленникам будет затруднительно получить к ним доступ, ― даже если они перехватят пароль, им ещё нужно понять, как устроена система генерации одноразовых паролей.

Плюсом системы аутентификации Swivel является достаточно удобный интерфейс, который не требует от пользователя сложных операций с дополнительными устройствами или ожидания одноразовых паролей по SMS. Кроме того, компания предоставляет все необходимые пользователю компоненты для интеграции своего инструмента с сервисами Google Apps, что сильно упрощает всю процедуру подключения облачных сервисов

Правда системным администраторам нужно разобраться с установкой и настройкой предоставленного установочного пакета для сервера приложений Tomcat и разобраться в механизмах SAML-аутентификации, который предлагает компания Google. Информации об интеграции сервисов и Swivel, и Google представляют в достаточном объёме, но только на английском языке. Тем не менее, процедура установки и настройки не является излишне сложной.

Подпишитесь
в Facebook

Я уже с вами
Telegram AMПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru