Безопасность данных в открытых информационных сетях, таких как Интернет, всегда будет источником серьезного беспокойства для разработчиков и клиентов. Поэтому для любого используемого продукта крайне важно создать безопасную среду исполнения.
Протокол SSL (Secure Socket Layers - протокол защищенных сокетов), совместно разработанный Netscape Communications и RSA Data Security, позволяет эффективно обеспечить такую безопасность. Протокол SSL обеспечивает безопасность, аутентификацию на базе сертификатов и согласование безопасности по установленному сетевому соединению, поэтому множество компаний и продуктов приняли SSL в качестве коммуникационного протокола.
В этой серии мы сконцентрируемся на двух главных аспектах:
- подробная информация о схеме работы SSL;
- детальная информация о поддержке SSL в версиях 5.1 и 6.0.1 среды ISC.
В данной статье исследуется SSL и объясняется, почему его рекомендуется реализовать в среде ISC. Во второй и третьей частях этой серии будет представлена подробная пошаговая инструкция по реализации и подключению SSL к ISC 5.1 и 6.0.1.
Во-первых, что такое SSL?
Знакомство с SSL
Протокол SSL обеспечивает целостность и конфиденциальность обмена данными между двумя общающимися приложениями, использующими TCP/IP. Данные, перемещающиеся между клиентом и сервером, шифруются симметричным алгоритмом.
Для цифровых подписей и обмена ключами шифрования используется алгоритм с открытым ключом (RSA). В шифровании с открытым ключом используется два ключа, каждый из которых может использоваться для шифрования сообщений. Если один ключ используется для шифрования сообщения, для его расшифровки необходимо использовать другой. Это позволяет получать защищенные сообщения, просто публикуя один (открытый) ключ и храня другой (секретный) ключ в тайне.
Цифровые сертификаты
Это подводит нас к обсуждению цифровых сертификатов, играющих важную роль в SSL. Цифровые сертификаты в основном служат двум целям:
- установить личность владельца;
- сделать доступным первичный ключ владельца.
Цифровой сертификат выпускается проверенной полномочной организацией - источником сертификатов (certificate authority - CA) и выдается только на ограниченное время. После истечения срока действия сертификата его необходимо заменить. Протокол SSL использует цифровые сертификаты для обмена ключами, аутентификации серверов и, при необходимости, аутентификации клиентов.
Цифровой сертификат содержит следующие фрагменты информации о личности владельца сертификата и источнике сертификатов:
- полное (уникальное) имя владельца сертификата;
- публичный ключ владельца;
- дата выдачи цифрового сертификата;
- дата окончания действия сертификата;
- полное (уникальное) имя издателя (источника сертификата);
- цифровая подпись издателя.
Подключение по SSL всегда инициируется клиентом вызовом URL-адреса, начинающегося с https:// вместо http:// .
Типы сертификатов
Протокол SSL использует сертификаты для проверки соединения. Эти SSL-сертификаты расположены на безопасном сервере и служат для шифрования данных и идентификации Web-сайта. Сертификат SSL помогает подтвердить, что сайт действительно принадлежит тому, кто это заявляет, и содержит информацию о держателе сертификата, домена, для которого был выдан сертификат, и название источника (CA), выдавшего сертификат.
Есть три способа получить SSL-сертификат:
- использовать сертификат от источника сертификатов;
- использовать самоподписанный сертификат;
- использовать "пустой" сертификат
Использование сертификата от источника сертификатов
Источники сертификатов (CA) - это организации, которым доверяет вся отрасль и которые занимаются выдачей Интернет-сертификатов. Например, такой сертификат можно получить от компании VeriSign. Чтобы получить сертификат, подписанный источником, необходимо предоставить достаточно информации источнику, чтобы он смог проверить вашу личность. Тогда источник создаст новый сертификат, подпишет его и доставит его вам. Популярные Web-браузеры заранее настроены доверять сертификатам, выданным определенными источниками, так что не нужно никакой дополнительной конфигурации для подключения клиента через SSL к серверу, для которого был выдан сертификат.
Использование самоподписанного сертификата
Самоподписанный сертификат - это сертификат, созданный самим пользователем. При использовании такого сертификата издатель совпадает с владельцем сертификата. Удобство такого решения в том, что для создания самоподписанного сертификата нужно меньше времени, чем для получения сертификата, подписанного источником сертификатов. Однако самоподписанный сертификат требует, чтобы любой клиент, подключающийся по SSL к серверу, установившему такой сертификат, был настроен доверять подписавшему сертификат. Так как сертификат был подписан самим пользователем, такая подпись скорее всего не окажется в файле списка доверенных источников клиента и поэтому должна быть туда добавлена. Если получить доступ к такому файлу любого клиента невозможно, то не стоит использовать такую конфигурацию, лучше получить сертификат от проверенного источника. Самоподписанные сертификаты полезны только тогда, когда каждый клиент, взаимодействующий с сервером, можно настроить так, чтобы он доверял данному сертификату.
Использование "пустого" сертификата
Это решение по функциональности ничем не отличается от предшествующих. В общих чертах, "пустые" сертификаты содержат фиктивную информацию, используемую в качестве временного решения для настройки SSL и проверки его функционирования в конкретной среде. Приложение ISC предоставляет "пустой" сертификат вместе с ключами и файлами доверенных источников для сервера и клиента.
Итак, что нужно делать после получения сертификата?
Аутентификация на стороне клиента или сервера
После того как сертификат был получен, необходимо установить его подлинность (аутентифицировать). В протоколе SSL есть два типа аутентификации:
- аутентификация на стороне клиента;
- аутентификация на стороне сервера.
SSL-аутентификация сервера позволяет клиенту проверить подлинность сервера. Клиентское ПО, поддерживающее SSL, может с помощью стандартных приемов криптографии с открытым ключом проверить, что сертификат сервера и открытый ключ действительны и были выданы источником, находящимся в списке доверенных источников сертификатов этого клиента. Это подтверждение может быть важным, если пользователь, например, отправляет номер кредитной карты по сети и хочет проверить подлинность сервера-получателя.
SSL-аутентификация клиента позволяет серверу проверить личность пользователя. Используя те же приемы, что и в случае с аутентификацией сервера, серверное ПО с поддержкой SSL может проверить, что сертификат клиента и открытый ключ действительны и были выданы источником сертификатов, имеющимся в списке доверенных источников сервера. Это подтверждение может быть важным, если, например, сервер - это банк, отправляющий конфиденциальную финансовую информацию заказчику, и он хочет проверить личность получателя.
На рисунке 1 приведена диаграмма, иллюстрирующая этот процесс.
Рисунок 1. Процесс аутентификации между клиентом и сервером
Файл ключей и файл со списком доверенных источников
Реализация протокола SSL, используемая в WebSphere® Application Server, хранит персональные сертификаты в файле ключей SSL и сертификаты издателя в файле со списком доверенных источников . Файл ключей содержит коллекцию сертификатов, каждый из которых может быть представлен во время установки SSL соединения для подтверждения подлинности. В файле со списком доверенных источников хранится коллекция сертификатов, которые считаются достоверными и с которыми будет сравниваться представленный сертификат во время установки SSL-соединения для проверки подлинности.
SSL и WebSphere Application Server
Хорошим примером реализации протокола SSL является его поддержка в IBM WebSphere Application Server. Система безопасности этого сервера имеет многоуровневую архитектуру, показанную на рисунке 2.
Рисунок 2. Многоуровневая безопасность WebSphere Application Server
Уровень сетевой безопасности обеспечивает аутентификацию на транспортном уровне, целостность и шифрование сообщений. Коммуникации между различными серверами WebSphere Application Server могут быть сконфигурированы на использование протоколов SSL и HTTPS. Для дополнительной защиты сообщений также можно использовать протоколы IP Security и VPN (Virtual Private Network - виртуальная частная сеть).
Протокол SSL обеспечивает безопасность на транспортном уровне: аутентификацию, целостность и конфиденциальность для безопасного соединения между клиентом и сервером в WebSphere Application Server. Этот протокол работает поверх TCP/IP и под прикладными протоколами, такими как HTTP, LDAP, IIOP, обеспечивая достоверность и секретность передаваемых данных. В зависимости от конфигурации SSL на клиенте и сервере могут быть установлены различные уровни достоверности, целостности данных и секретности. Понимание основ функционирования протокола SSL очень важно для правильной настройки и достижения требуемого уровня защиты для данных клиента и приложения.
Некоторые функции безопасности, предоставляемые протоколом SSL:
- Шифрование данных с целью предотвратить раскрытие конфиденциальных данных во время передачи.
- Подписывание данных с целью предотвратить несанкционированное изменение данных во время передачи.
- Аутентификация клиента и сервера , позволяющая убедиться, что общение ведется с соответствующим человеком или компьютером.
Протокол SSL может служить эффективным средством обеспечения безопасности информационной среды организации.
Протокол SSL используется различными компонентами внутри WebSphere Application Server для обеспечения достоверности и конфиденциальности. К этим компонентам относятся: встроенный HTTP-транспорт, ORB и безопасный LDAP-клиент.
Реализация SSL, используемая в WebSphere Application Server, - это либо расширение для Java - IBM Java™ Secure Sockets Extension (IBM JSSE), либо IBM System SSL. Провайдер IBM JSSE содержит эталонную реализацию, поддерживающую протоколы SSL и TLS (Transport Layer Security - безопасность транспортного уровня) и API для интеграции. С провайдером IBM JSSE также поставляется стандартный провайдер, предоставляющий поддержку RSA для функциональности цифровой подписи из библиотеки JCA (Java Cryptography Architecture - Архитектура Шифрования для Java) для платформы Java 2, стандартные наборы шифров для SSL и TLS, менеджеров доверенных источников сертификатов и ключей, использующих технологию X509, и реализацию технологии PKCS12 для хранилища цифровых сертификатов JCA.
Конфигурация провайдера JSSE очень похожа на конфигурацию большинства других реализаций SSL, например GSKit, однако пару отличий следует выделить:
- Провайдер JSSE поддерживает хранение собственного сертификата и сертификатов издателя в файле ключей SSL, но он также поддерживает и отдельный файл, т.н. файл источников сертификатов (trust file). Этот файл может содержать только сертификаты источников. Можно поместить свои собственные сертификаты в файл ключей SSL, а сертификаты издателей - в trust-файл. Это может потребоваться, например, при наличии недорогого аппаратного криптографического устройства, у которого памяти достаточно только для хранения персонального сертификата. В этом случае файл ключей указывает на аппаратное устройство, а trust-файл указывает на файл на диске, содержащий все сертификаты издателей.
- Провайдер JSSE не распознает специальный формат файла ключей SSL, используемый плагином - файлы с расширением .kdb. Провайдер JSSE распознает только стандартные форматы файлов, такие как Java Key Store (JKS - хранилище ключей Java). Совместное использование файлов ключей SSL плагином и сервером приложений невозможно. Более того, для управления ключами сервера приложений и trust-файлами необходимо использовать различные реализации утилиты управления ключами.
SSL и Integrated Solutions Console
Приложение ISC - это единая среда Web-консолей администрирования для развертывания и интеграции консольных модулей, позволяющая заказчикам управлять решениями, а не конкретными продуктами IBM. Эта среда включает в себя контейнер портлетов, Java-компоненты (JMX) для управления приложениями и модули справки Eclipse.
Для реализации конфиденциальности и шифрования можно использовать протокол SSL. С помощью SSL можно защитить взаимодействие между Web-браузером пользователя и сервером ISC. Шифрование важно потому, что в ISC используется аутентификация, основанная на формах; при этом идентификатор и пароль пользователя для входа в систему не шифруются при пересылке по сети. Если консольному модулю требуется доступ к внутренним ресурсам через безопасное соединение, его портлеты могут использовать SSL.
Какие преимущества дает использование SSL?
Почему это так важно? Безопасная и эффективная передача данных по открытым коммуникационным каналам - это критический компонент обеспечения функционирования современной ИТ-системы, и протокол SSL позволяет обеспечить эту безопасность. Однако подключение SSL к среде ISC может оказаться сложной и трудоемкой задачей. В чем сложность этой задачи? Вопрос безопасности данных в среде Web-приложений, подобных среде Integrated Solutions Console, может показаться немного размытым для новичков, потому что безопасность ИТ сама по себе - крайне широкая область, охватывающая много различных аспектов в открытых коммуникационных сетях.
В следующих двух статьях этой серии будет представлена организация безопасности данных на основе SSL в среде, основанной на Integrated Solutions Console. Сначала мы рассмотрим настройку и включение SSL для Integrated Solutions Console 5.1 с использованием пустого, собственного и выпущенного издателем сертификатов, а потом разберем, как выполнить те же действия для Integrated Solutions Console 6.0.1.