Обеспечение безопасности распределенных систем в .NET Framework
9.1. Введение в обеспечение безопасности
Распределенная система представляет набор программных компонент, использующих те или иные промежуточные среды для своего взаимодействия (рис. 9.1). Каждая промежуточная среда использует так называемый транспортный протокол, в роли которого может выступать:
- промежуточная среда (например, Remoting или COM+ поверх MSMQ);
- протокол верхнего уровня модели OSI (например, HTTP или HTTPS);
- протокол транспортного уровня модели OSI (например, TCP).
Транспортный протокол промежуточной среды, в свою очередь, использует протоколы нижних уровней.
Напомним, что обеспечение безопасного взаимодействия программных компонент включает в себя:
- идентификацию пользователя сервисов компоненты (аутентификацию);
- защиту передаваемой информации от просмотра и изменения (шифрование и цифровая подпись);
- ограничение доступа пользователей к сервисам компоненты в соответствии с результатом их идентификации (авторизацию).
Указанные функции могут выполняться промежуточной средой, ее транспортным протоколом или протоколами нижних уровней. Сами программные компонента не должна участвовать в выполнении функций безопасности каким-либо образом. В качестве примера рассмотрим веб службы ASP.NET. Безопасность в них может обеспечиваться:
- самой промежуточной средой (при использовании WSE);
- транспортным протоколом HTTPS;
- или даже безопасным IP соединением (IPSec), как при использовании веб служб поверх TCP, так и при использовании HTTP.
Другим примером является среда .NET Remoting. Ее безопасность может обеспечиваться только на транспортом уровне, например при использовании HTTP или HTTPS с IIS, MSMQ в качестве транспорта, а так протокола IPSec. При этом функция авторизации в среде Remoting отсутствует, невозможно разграничить доступ пользователей для методов удаленного класса.
Обеспечение функций безопасности на уровне промежуточной среды имеет определенные преимущества.
- Большая гибкость. Например, возможно шифровать только отдельные части сообщения, а цифровая подпись применять к целому сообщению.
- Переносимость. Промежуточная среда с собственной поддержкой безопасности может работать с различными транспортами и не выдвигает каких либо требований к безопасности транспортного уровня.
- Возможность аудита. При использовании систем с маршрутизацией сообщений (например, веб служб) промежуточные маршрутизаторы сообщений могут добавлять в него дополнительную служебную информацию.
- Большое время защиты сообщения. Сообщение остается зашифрованным максимально возможное время, в то время как при обеспечении безопасности транспортом оно поступает в промежуточную среду уже в расшифрованном виде.
Однако реализация безопасности транспортом также имеет ряд достоинств.
- Меньшие затраты времени. При идентификации на уровня транспортного протокола решение об идентичности пользователя принимается без участия промежуточной среды. Шифрование на уровне транспорта обычно также работает быстрее.
- Универсальность. Безопасность транспортного протокола позволяет защитить любые промежуточные среды, его использующие. Не возникает проблем с реализацией функций безопасности промежуточных сред разных производителей.
- Можно сделать вывод, что обычно безопасность на уровне сообщений более предпочтительна. Если промежуточная среда не поддерживает необходимую функцию безопасности, и ее реализация на транспортом уровне невозможна, то не следует реализовывать данную функцию на уровне компоненты. Вместо этого следует сменить промежуточную среду или используемый ею транспорт на другие, удовлетворяющие требованиям к безопасности распределенной системы.
9.2. Механизмы обеспечения безопасности
Электронные сертификаты
В настоящее время наиболее распространенным базовым механизмом обеспечения безопасности являются цифровые сертификаты, используемые для организации инфраструктуры открытых ключей ( public key infrastructure, PKI). Наиболее распространенным стандартом сертификата является стандарт X.509. Инфраструктура PKI основана на использовании доверенных систем. Целью организации инфраструктуры открытых ключей является привязка сторон обмена к сертификатам, содержащих их открытые ключи. Это позволяет как идентифицировать пользователя по сертификату, так и использовать асимметричное шифрование с открытым и закрытым ключами при передаче информации (рис. 9.2).
Открытые ключи содержаться в сертификатах X.509, которые представляют собой текстовый цифровой документы, связывающий набор реквизитов стороны (адрес, название) с ее открытым ключом. Сертификат подписывается закрытым ключом некоторой доверенной третьей стороной ( certificate authority, CA). Цифровая подпись заключается в вычислении образа сертификата, вычисленного криптографической хеш функцией MD5, и последующего шифрования образа закрытым ключом CA. Результат шифрования образа сертификата называется цифровой подписью (рис. 9.3). Таким образом, сертификат содержит:
- реквизиты предъявляющей его организации или подразделения организации;
- реквизиты подписавшей его доверенной третьей стороны;
- сроки действия сертификата;
- открытый ключ;
- цифровую подпись.
После получения сертификата другая сторона обмена информацией проверяет его, используя открытый ключ подписавшей его организации. Если результат дешифровки подписи сертификата совпадает с образом остальной части сертификата, то сертификат верен. Сертификат доверенной стороны подписывается им самим.
В роли доверенной стороны могут выступать коммерческие фирмы, занимающиеся выдачей сертификатов или созданный внутри организации сервер PKI (например, Windows Certificate Services). В простейших случаях доверенная сторона может быть представлена самоподписанным сертификатом, который выдается заранее всем участникам обмена информацией после подписи их сертификатов соответствующим закрытым ключом. Иногда используется и вариант с предъявлением серверу клиенту самоподписанного сертификата. Такой сертификат не может быть проверен клиентом на подлинность и предполагает доверие серверу, но может быть использован для защиты передаваемой информации.