Инфраструктуры открытых ключей

6.1.12 Конфиденциальность с шифрованием

Другой рассмотренной нами службой обеспечения безопасности, которую необходимо предусмотреть, является конфиденциальность (confidentiality). Она и будет темой этого раздела.

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

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

Недостаток секретности является серьезной проблемой. Несмотря на то что основной объем трафика электронной почты не содержит чувствительных данных, он содержит небольшое, но важное подмножество сообщений. Для этой проблемы существует только два решения: либо убедить пользователей серьезно относиться к безопасности, либо трактовать всю электронную почту как содержащую чувствительную информацию и шифровать все. Опыт показывает, что внесение эффективных изменений в ИT-архитектуру обычно проще, чем изменение сознания людей, поэтому зачастую применяется последний подход. (Однако пользователи должны продолжать серьезно относиться к безопасности, а также должны применяться политики безопасности, чтобы гарантировать, что минимум в обеспечении безопасности соблюдается в организации всеми.)

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

Электронная почта зашифровывается автоматически клиентом Notes и отправляется далее. После того как зашифрованная электронная почта достигнет места назначения, клиент Notes расшифровывает ее, чтобы дать получателю возможность ее прочитать. Этот метод защищает данные от неавторизованного доступа. Для шифрования и расшифровки данных Notes использует механизм группового шифрования, в основе которого лежит секретный ключ. Это также подтверждает, что полученные данные не были прочитаны другими. Принимая во внимание тот факт, что клиенты Notes и серверы Domino обрабатывают огромное множество электронной почты, важно, чтобы используемый алгоритм был эффективным. Для группового шифрования данных Notes использует алгоритмы RC2 или RC4.

Криптостойкость

Единственный вариант относительно изменения криптостойкости представлен типом имеющейся у пользователя лицензии Notes.

Все Notes ID содержат две пары открытого/секретного ключей. До версии 5.0.4 длины ключей были ограничены в целях шифрования данных, но не в интересах аутентификации и осуществления электронной подписи. Все, что было свыше 512-битового RSA-ключа и 56-битового симметричного ключа, рассматривалось как сильное шифрование, и правительство США запретило это экспортировать. Заказчики были вынуждены соблюдать эти правила и осуществлять выбор среди комплектов программного обеспечения с различными силами криптографии.

По мере смягчения постановлений правительства США относительно экспорта криптографии, программные продукты сервера Domino, Domino Administrator, Domino Designer®, клиента Lotus Notes объединили все предыдущие разновидности криптостойкости – североамериканскую (North American), интернациональную (International) и французскую (France) – в один уровень криптостойкого шифрования в отдельном выпуске "Global (Глобальный)" этих продуктов. Глобальный выпуск принял характеристики шифрования, ранее известные как североамериканские. Криптостойкое шифрование программных продуктов глобальной версии может использоваться по всему миру, за исключением тех стран, в которых это запрещают законы об импорте либо в которые экспорт товаров и услуг запрещен правительством США. Покупателям больше не требуется заказывать программное обеспечение Notes в соответствии с силой криптографии.

Когда организация обновляет программное обеспечение до глобальной версии Domino и Notes, более сильная криптография будет использоваться без требования повторного выпуска существующих ID. Эти изменения безболезненны как для пользователей, так и для администраторов. При взаимодействии двух различных версий программного обеспечения переговоры по шифрованию закончатся переходом к более слабому его уровню. Поэтому все преимущества криптостойкого шифрования будут реализованы только в том случае, когда все программное обеспечение обновлено до глобального уровня (dерсия 5.0.4 и выше). Однако любые смешанные версии программного обеспечения все же будут взаимодействовать друг с другом.

Диалоговое окно Register New User (Регистрация нового пользователя) все еще будет предлагать осуществить выбор между североамериканскими и интернациональными ID. Это было оставлено, потому что администраторы часто используют их различие в административных целях и потому что в некоторых компаниях все еще используются более старые версии программного обеспечения. В дополнение к этому различные страны имеют свои собственные правила импорта. Сохранение этого различия позволит Lotus реагировать на изменения для определенных стран, если это потребуется.

Примечание. Эти предписания касаются только экспорта из США. Для других стран с собственными предписаниями относительно импорта заказчикам необходимо осуществить проверку на предмет соответствия требованиям для определенной страны. Несмотря на то что Lotus предпринимает все шаги для обеспечения согласования правительственных предписаний относительно шифрования по всему миру, компания все же рекомендует, чтобы заказчики ознакомились с местными предписаниями относительно шифрования, чтобы обеспечить соответствие им.

Проблемы совместимости

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

• Поддержка типов ID. В глобальном выпуске продолжают поддерживаться как североамериканский, так и интернациональный тип ID. Это выполнено для осуществления обратной совместимости с клиентами, имеющими более раннюю версию, чем 5.0.4. Если установлена глобальная версия программного обеспечения, пользователи Lotus Notes могут сохранять свои существующие интернациональные ID. Глобальная версия автоматически разрешит применять более сильное шифрование. Пользователи браузеров могут сохранять свои существующие наборы ключей, но они должны следовать рекомендациям производителя по обновлению браузера в целях обеспечения криптостойкости.
• Совместимость с версиями после 5.0.4. Если все клиенты и серверы организации работают с версиями 5.0.4 и выше, то нет разницы в том, североамериканские или интернациональные ID были созданы. Оба типа ID будут работать одинаковым способом.
• Совместимость с версиями до 5.0.4. Пользователи Lotus Notes, а также серверы Domino, которые были обновлены до версии 5.0.4 и выше, могут проводить аутентификацию и продолжать повседневные операции безопасным образом с клиентами и серверами, работающими на более ранних версиях программного обеспечения. Однако если в организации есть клиенты или серверы, работающие на более ранних версиях, чем Notes и Domino 5.0.4, организация должна продолжить создание таких же типов ID; которые были созданы в более ранних версиях. Интернациональные варианты версий до 5.0.4 не дают возможность пользователям переключаться к североамериканским ID, соответственно при регистрации новых интернациональных пользователей не должны создаваться только североамериканские ID. Подобным образом североамериканские варианты ранних версий используют более слабую криптографию при работе с интернациональными ID, поэтому не должны создаваться только интернациональные ID.

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

Важные соображения относительно Notes ID

Очень важно беречь Notes ID. Соответственно приведем два особых момента, которые достойны запоминания.

1. Если пользователь более не способен применять свой файл Notes ID (либо по причине того, что забыл требуемый для расшифровки Notes ID пользователя пароль, либо по причине физической потери файла), то любая зашифрованная почта, использующая секретный ключ этого человека, является навсегда утерянной (предполагая невозможность восстановления упомянутого ID, как это обсуждалось ранее).
2. Важно бережно обращаться с Notes ID пользователя, так как внутри файла Notes ID пользователя содержится секретный ключ. Если Notes ID пользователя скомпрометирован, любой, имеющий копию этого Notes ID пользователя, может выдавать себя за этого пользователя (предполагая, что не применяется никакого механизма смягчения этого обстоятельства).

Шифрование сообщений электронной почты

Одним из способов, который Lotus Notes предлагает для обеспечения конфиденциальности, является предоставление служб, с помощью которых электронная почта может быть легко и эффективно зашифрована. Метод, с использованием которого это выполняет клиент Lotus Notes, проиллюстрирован на рис. 6.16.

Рис. 6.16. Шифрование сообщений электронной почты в Lotus Notes

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

1. Алиса решает отправить зашифрованное сообщение электронной почты Notes Бобу. Клиент Notes, видя, что установлен флажок Encrypt (Шифровать), генерирует случайный ключ шифрования (секретный ключ, который обычно упоминается как сеансовый ключ, впоследствии новый случайный ключ генерируется каждый раз, когда отправляется зашифрованное сообщение Notes), и шифрует с его помощью сообщение.
2. Ключ шифрования сеанса шифруется Notes (с применением RC2) с помощью открытого ключа получателя и прикрепляется к сообщению, а это означает, что расшифровать его будет способен только открытый RSA-ключ Боба.
3. Зашифрованный текст и зашифрованный ключ отправляются Бобу по почте Notes.
4. Клиент Notes Боба использует секретный RSA-ключ Боба для расшифровки зашифрованного ключа (снова с применением RC2) и получает расшифрованный ключ сеанса. Здесь гарантируется секретность, потому что для расшифровки ключа сеанса, необходимого для расшифровки сообщения, может быть использован только секретный ключ Боба.
5. Клиент Notes Боба использует расшифрованный ключ сеанса для расшифровки почтового сообщения (с применением RC2), результатом чего является расшифрованное исходное сообщение, которое было отправлено Алисой.

Важно указать на пару следующих моментов:

• Если клиент Notes Боба не способен расшифровать отправленное Алисой сообщение электронной почты (обычно благодаря тому факту, что Боб может уже иметь новый Notes ID пользователя, а открытый ключ в каталоге, к которому имеет доступ Алиса, является всего лишь старым ключом), то в поле тела сообщения ничего не будет отображено.
• Пример подобен, по сути, способу работы S/MIME, стандарта безопасного обмена сообщениями для Интернета. Мы рассмотрим S/MIME в разделе об инфраструктуре открытых ключей в Интернете далее в этой лекции.

Другие возможности шифрования в Notes

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

• Базы данных могут быть зашифрованы с ID сервера или пользователя путем применения опции безопасности, касающейся шифрования локальной базы данных. Это защитит базы данных, которые используют это свойство безопасности, от доступа со стороны неавторизованного пользователя, получившего доступ к файловой системе рабочей станции, на которой хранится база данных, и сделавшего копию базы данных в файловой системе посредством операционной системы.
• Для ограничения доступа к полям со стороны авторизованных пользователей может применяться шифрование полей с применением специальных ключей шифрования, созданных и распространенных разработчиком базы данных.
• Документы могут быть зашифрованы с использованием секретных или открытых ключей. Ключи могут добавляться к форме либо на основании того, что каждый документ создан с формой для шифрования, либо путем предоставления пользователям возможности шифровать документы с помощью своих собственных ключей шифрования.
• Шифрование сетевого порта позволяет шифровать незашифрованные данные на уровне порта для безопасной транспортировки по сети. Шифрование сетевого порта может быть разрешено для рабочей станции пользователя или на сервере путем выбора пунктов меню File (Файл) – Preferences (Настройки) – Ports (Порты) для внесения поправок в определение порта в целях выполнения шифрования сетевых данных.

6.1.13 Краткие выводы по Notes PKI

Мы рассмотрели все важнейшие аспекты инфраструктуры открытых ключей Notes (Notes PKI) и показали, каким образом безопасность Notes и Domino строится на надежной инфраструктуре открытых ключей, которая делает возможным обеспечение аутентификации, целостности данных и конфиденциальности для всех пользователей Notes, воспользовавшихся этими встроенными функциями. Принимая во внимание прозрачность PKI в Lotus Notes, инфраструктуру открытых ключей Notes удобно применять, обеспечивая безопасность без наличия всяких трудностей, свойственны стандартным реализациям инфраструктур открытых ключей, что сделало ее наиболее распространенной PKI в корпоративном мире.

Так как Notes и Domino взаимодействуют также и с людьми, их не использующими, то в оставшихся разделах этой лекции мы обсудим, как Notes и Domino расширили свои возможности в целях представления поддержки интернет-стандартов в вопросах инфраструктуры открытых ключей и служб, которые становятся доступными при ее употреблении.

6.2 Инфраструктура открытых ключей в Интернете

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

Как и в случае с безопасностью в Notes, эти стандарты, технологии и инструменты по большей части основаны на технологии сертификатов открытых ключей. Двумя наиболее распространенными форматами сертификатов являются PGP и X.509. Принимая во внимание широкую поддержку со стороны Domino сертификатов X.509, мы сфокусируем ваше внимание на этом формате.

Поддержка подобных встроенных в сервер интернет-стандартов осуществлялась с момента представления в 1996 г. сервера Domino 4.5. Целью этого являлась все большая интеграция данных стандартов в ядро сервера Domino, и результат таких усилий хорошо виден в Domino 6. На протяжении оставшейся части этой лекции мы обсудим необходимые вам основы технологий обеспечения безопасности в Интернете, а более подробное разъяснение новых сервисов и услуг представлено в "Функции безопасности Domino/Notes 6" .

6.2.1 Интернет-стандарты

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

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

Интернет-стандарты определяются целевой группой инженерной поддержки Интернета IETF (Internet Engineering Task Force). Это документы, которые создаются как интернет-черновики (Internet Drafts), потом становятся "запросами на комментарии" [Requests for Comments (RFC)], которые в некоторых случаях после длительного консультативного процесса утверждаются как стандарты [standards (STD)] группой по стандартизации инженерных решений в Интернете IESG (Internet Engineering Steering Group).

Стандарты (STD)

Спецификации, которые планируется сделать интернет-стандартами, проходят в своем развитии последовательность уровней зрелости, известных как путь стандартов (standards track). Эти уровни зрелости включают предложенный стандарт (Proposed Standard), черновой стандарт (Draft Standard) и стандарт (Standard).

Спецификация предложенного стандарта (Proposed Standard), как правило, устойчива, имеет решенные варианты проектирования, предполагается, что она хорошо понятна, подверглась серьезному рассмотрению со стороны сообщества и вызвала достаточный интерес с его стороны, чтобы быть довольно ценной для рассмотрения. Однако результат дальнейшего опыта использования может заключаться в изменении или даже отмене спецификации перед ее дальнейшим продвижением. Обычно для такой спецификации не требуются ни реализация, ни опыт работы с ней.

Спецификация, на основе которой были разработаны как минимум две независимые и взаимодействующие реализации на базе различного кода и для которой был получен достаточно удачный опыт использования, может подняться до уровня чернового стандарта (Draft Standard).

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

Спецификация, для которой получены достоверная реализация и успешный опыт работы с ней, может подняться до уровня интернет-стандарта (Internet Standard). Интернет-стандарт [который может упоминаться просто как стандарт (Standard)] характеризуется высокой степенью технической зрелости и в целом предполагает, что указанный протокол или служба предоставляют значительную пользу интернет-сообществу.

Как правило, интернет-стандарты определяют способность к взаимодействию систем путем задания протоколов, форматов сообщений, схем и языков. Наиболее фундаментальные стандарты определяют интернет-протокол IP (Internet Protocol).

Все интернет-стандарты задаются в последовательности STD числом. Первый документ в этой последовательности, STD1, описывает оставшиеся в последовательности документы и содержит список предложенных стандартов. Зачастую документы в последовательности STD являются копиями RFC либо несколькими собранными вместе RFC. Номера STD не имеют номеров версий, так как все обновления выполняются через RFC, а номера RFC являются уникальными. Для четкого указания того, какая версия стандарта упоминается, должны быть точно определены номер стандарта и все RFC, которые он включает.

Запрос на комментарии (RFC)

Запросы на комментарии [requests for comments (RFC)] являются начатой в 1969 г. последовательностью пронумерованных информационных документов и стандартов Интернета, которым в значительной степени следуют разработчики коммерческого и свободно распространяемого программного обеспечения в интернет- и UNIX-сообществах. Лишь некоторые из RFC являются стандартами, но все интернет-стандарты записаны в RFC. Наверное, самым важным отдельным RFC стал RFC 822, стандарт формата электронной почты (e-mail) Интернета.

RFC, выпущенные организацией IFTF и ее предшественниками, являются наиболее известной последовательностью с названием RFC; эта последовательность почти всегда является тем, что означает RFC без последующего уточнения. Однако в прошлом последовательности с названием RFC выпускались также и другими организациями.

RFC необычны тем, что они запускаются в ход техническими экспертами, действующими по своей собственной инициативе, и детально оцениваются в Интернете, причем даже лучше, чем если бы они были официально опубликованы таким институтом, как Национальный институт стандартизации США (ANSI). По этой причине они остаются известными как RFC даже после принятия в качестве стандартов. Эта традиция получения не допускающего возражений, подтвержденного опытом, становящегося таковым после завершения процесса стандарта, написанного отдельными людьми или небольшими рабочими группами, имеет важные преимущества по сравнению с более официальным, проводимым комиссиями процессом. Символичным для этих преимуществ является наличие процветающей традиции выпуска "шуточных" RFC. Обычно такой RFC выпускается как минимум один раз в году, как правило 1 апреля.

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

Получение доступа к STD и RFC

STD и RFC являются свободно доступными, в том числе и в режиме онлайн. Наиболее легким способом получить их является посещение Web-сайта организации IETF, находящегося по следующему URL-адресу:

http://www.ietf.org

Полный каталог RFC в текстовом формате доступен на сайте организации по адресу:

http://www.ietf.org/iesg/1rfc_index.txt

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

http://www.ietf.org/rfc.html

За более подробным описанием RFC и процесса создания RFC обратитесь к RFC 2026 The Internet Standards Process, Revision 3 (Процесс создания интернет-стандартов, редакция 3).

Некоторые мысли по поводу STD и RFC

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

Это важно понимать, поскольку недобросовестные специалисты по маркетингу и невнимательная профессиональная пресса иногда ошибочно внушают нам, что каждый RFC представляет собой стандарт или что все стандарты имеют одинаковый вес. Взаимоотношения между техническими спецификациями Интернета зачастую очень сложны. На самом деле существует даже RFC, который разъясняет это, – RFC 1796, называемый Not All RFCs are Standards (Не все RFC являются стандартами), доступ к которому можно получить по адресу:

http://www.faqs.org/rfcs/rfc1796.html

Когда вы будете читать о технологиях, инструментах и службах Интернета, которые поддерживаются и предлагаются сервером Domino для интернет-клиентов, помните об этих отличиях между STD и RFC.