Национальный стандарт республики казахстан



страница33/33
Дата20.11.2016
Размер4.62 Mb.
Просмотров6793
Скачиваний0
1   ...   25   26   27   28   29   30   31   32   33

А.4 HTTP по TLS (HTTPS) ППГ над БТУ (TransportLayerSecurity- Безопасность Транспортного Уровня (БТУ)
CDMI также включает механизм обеспечения коммуникации ППГ между пользователями и серверами и зашифрован по сети. Важно отметить, общение пользователя CDMI с сервером CDMI через HTTPS на порту TCP 443 (порт TCP 80 используется для HTTP). 5 предоставление важной подробной информации о БТУ.

При использовании БТУ обеспечивается ППГ, где пользователь-сервер, выполняет некоторую форму идентификации. Однако характер данной идентификации зависит от номера шифра; номер шифра определяет алгоритм шифрования и алгоритм обзора для использования на связи БТУ. Общая операция включает использование свидетельств стороны сервера. Возможно, не произойдет никакая идентификация (например, анонимная идентификация).


А.5 Транспортная безопасность (TБ)
Серверы CDMI осуществляют протокол БТУ; однако, его использование пользователями дополнительное. БТУ 1.0 определяется согласно ссылке 2246, и БТУ 1.1 и БТУ 1.2 и соответственно ссылке 4346 и RFC 5246.

Основная цель протокола БТУ состоит в обеспечении целостности данных. БТУ позволяет общение пользователь-сервер в сети. БТУ имеет пункты транспортного протокола (например, TCP) и используется для заключения различных высокоуровневых протоколов (например, ППГ).

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

БТУ включает три основных фазы:

- переговоры пэра относительно поддержки алгоритма;

- ключевой обмен и идентификация;

- и симметричное шифрование шифра и идентификация сообщения.

Во время первой фазы клиент-сервер договаривается о номерах люкс шифра (см. 5.1), которые определяют шифры, которые будут использоваться, ключевой обмен, алгоритмы идентификации и коды аутентификации сообщения (MACs). Ключевые алгоритмы обмена и идентификации - типично алгоритмы с открытым ключом. MACs составлены из Кода аутентификации сообщения включенной HMAC.


5.1 Блоки шифра
TLS это одно ключевое учреждение, конфиденциальность, подпись и алгоритм хеширования в блоке шифра. Зарегистрированные 16 битов (4 шестнадцатеричных цифры) число, названное индексом блоке шифра, назначены для каждого определенного блоке шифра.

ПРИМЕР соглашение о ключе RSA, подпись RSA, AdvancedEncryptionStandard (AES), используя Блок Шифра

Формированию цепочки (Си-би-си) конфиденциальность и Безопасный Алгоритм хеширования (SHA-1) мешанина назначают шестнадцатеричная стоимость {OxOOOF} для БТУ.

Клиент всегда начинает сессию БТУ и начинает переговоры по блоку шифра, передавая сообщение рукопожатия, которое перечисляет блок шифра (стоимостью индекса), что это примет. Сервер отвечает сообщением рукопожатия, указывающим, какой номер люкс шифра он выбрал из списка или "аварийного прекращения работы", как описано ниже. Хотя клиент обязан заказывать его список, увеличивая "силу" блока шифра, сервер может выбрать ЛЮБОЙ из блока шифра, предложенных клиентом. Поэтому, нет НИКАКОЙ гарантии, что переговоры выберут самый сильный блок шифра. Если никакие блок шифра взаимно не поддержаны, то связь будет прервана. Когда договорные варианты, включая дополнительные свидетельства открытого ключа и случайные данные для развития вводящего материала, который будет использоваться шифровальными алгоритмами, сообщения будут обменены, чтобы поместить коммуникационный канал в безопасный способ.

Чтобы гарантировать минимальный уровень безопасности и совместимости между внедрениями, все клиент-серверы CDMI должны поддержать:

Номер блок шифра TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (шестнадцатеричная стоимость {0x0013}), который также обязательный номер блока шифра для БТУ 1.0 (см. раздел 9 ссылка 2246, Обязательный Шифр Номера люкс).

Номер люкс шифра TLS_RSA_WITH_AES_128_CBC_SHA (шестнадцатеричная стоимость {0x002F}) должен быть осуществлен, который является обязательным номером блок шифра для TLS 1.2.

Номер люкс шифра TLS_RSA_WITH_NULL_SHA (шестнадцатеричная стоимость {0x0002}) должен быть поддержан обоими клиент-серверы CDMI, чтобы осуществить заверенные, незашифрованные коммуникации. Когда этот номер блок шифра будет использоваться, базовая аутентификация HTTP не должна использоваться.

• Номер люкс шифра TLS_RSA_WITH_AES_128_CBC_SHA256 (шестнадцатеричная стоимость {0x003C}) должен быть включенный со всеми рекомендуемыми внедрениями TLS 1.2, чтобы встретить переход к безопасности сила 112 битов.

Конструкторы свободнj включают дополнительные номера блок шифра.


А.5.2 Цифровые сертификаты
Клиент-серверы CDMI могут подвергнуться нападению, настроив ложный сервер CDMI, чтобы захватить userids и пароли или вставить себя как необнаруженное полномочие между клиентом и сервером CDMI. Самая эффективная контрмера для этого нападения - использование, которым управляют, свидетельств сервера с БТУ, подобранным клиентом контроль над принятием свидетельства при условии, что ложный сервер будет неспособен получить приемлемое свидетельство. Определенно, это может быть достигнуто, формируя клиентов, чтобы всегда использовать БТУ внизу идентификация ППГ, и только принять свидетельства из определенного местного центра сертификации.

Когда используется CDMI, БТУ должен использовать свидетельства открытого ключа вариантов 3 X.509, которые соответствуют Профилю Расширения Свидетельства и Свидетельства, определенному в Разделе 4, RFC 3280 (Свидетельство X.509v3 и CRL). Этот профиль свидетельства и списка аннулирования свидетельства (CRL) определяет обязательные поля, которые должны быть включены в свидетельство, а также дополнительные области и расширения, которые могут быть включены в свидетельство.

Сертификаты сервера должны быть поддержаны всеми серверами CDMI, и свидетельства клиента могут быть поддержаны клиентами CDMI. Сервер представляет свидетельство сервера, чтобы подтвердить подлинность сервера клиенту; аналогично, клиент представляет свидетельство клиента, чтобы подтвердить подлинность себя к серверу. Для мест государственной сети, предлагающих безопасные коммуникации через БТУ, использование свидетельства сервера довольно распространено, но свидетельства клиента редко используются, потому что клиент, как правило, заверяется другими средствами.

ПРИМЕР место электронной коммерции подтвердит подлинность клиента номером кредитной карточки, имя пользователя / пароль, и т.д., когда покупка сделана. Это - намного больше трастовой проблемы, что клиент (покупатель) быть уверенными в идентичности места электронной коммерции и причине forthis, со свидетельствами сервера намного более обычно сталкиваются на практике.

Эти сертификаты X.509 используют цифровую подпись, чтобы связать открытый ключ с идентичностью. Эти подписи будут часто выпускаться органом сертификации (CA), который связан с внутренней или внешней инфраструктурой открытых ключей (PKI); однако, дополнительный подход использует самоподписанные свидетельства (свидетельство в цифровой форме подписано той же самой парой ключей, общественная часть которой появляется в данных о свидетельстве). Трастовые модели, связанные с этими двумя подходами, очень отличаются. В случае свидетельств PKI с иерархией доверия и доверенной третьей стороны можно консультироваться в процессе проверки свидетельства, который увеличивает безопасность за счет увеличенной сложности. Самоподписанные свидетельства могут использоваться, чтобы сформировать паутину доверия (трастовые решения находятся в руках отдельных пользователей/администраторов), но считается менее безопасным, поскольку нет никакой центральной власти для доверия (например, никакая гарантия идентичности или аннулирование). Это сокращение полной безопасности, которая может все еще предложить надлежащую защиту для некоторой окружающей среды, сопровождается освобождением полной сложности внедрения.

Со свидетельствами PKI часто необходимо пересечь иерархию или цепь доверия в поисках корня трастового или трастового якоря (CA, которому доверяют). Этот трастовый якорь может быть внутренним CA, которому подписал свидетельство более высокопоставленный CA, или это может быть конец цепи свидетельства как самое высокопоставленное Приблизительно, Этот самый высокопоставленный CA - окончательная власть аттестации в особой схеме PKI, и ее свидетельство, известное как свидетельство корня, может только быть самоподписано. У установления трастового якоря на уровне свидетельства корня, специально для коммерческой АВАРИИ, могут быть нежелательные побочные эффекты, следующие из полного доверия, предоставленного все свидетельства, выпущенные той рекламой Приблизительно Идеально, трастовый якорь должен быть установлен с самым низким ранжированием CA, который практичен.


5.2.1 Проверка сертификата
Клиент-серверы CDMI должны выполнить основную проверку пути, дополнительную проверку пути и проверку CertificateRevocationList (CRL), как определено в Разделе 6,ссылка 3280 для всех представленных свидетельств. Эти проверки включают, но не ограничены, следующее:

Свидетельство - законно построенное свидетельство.

Подпись правильна для свидетельства.

Дата его использования в пределах срока действия (т.е., это не истекло).

Свидетельство не было отменено (применяется только к свидетельствам PKI).

Цепь сертификата законно построена (рассмотрение свидетельства плюс действительные свидетельства выпускающего до максимальной позволенной глубины цепи (применяется только к свидетельствам PKI).

Когда клиент-серверы CDMI будут использовать CRLs, они должны использовать версию 2 X.509 CRLs, которые соответствуют CRL и Дополнительному Профилю CRL, определенному в Разделе 5,RFC 3280. (Это требование также только относится к свидетельствам PKI.)

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


5.2.2 Форматы сертификатов
Все интерфейсы для конфигурации свидетельства (импорт в особенности) должны поддержать следующие форматы свидетельства:

DER-закодированный X.509. См. ISO/IEC 9594-8:2008 для спецификации и технических исправлений. Базируйте 64 закодированный X.509 (часто называемый PEM). Посмотрите Раздел 6.8,ссылка 2045. PKCS#12. См. PKS12 для спецификации и технических исправлений.

Все программное обеспечение проверки свидетельства должно поддержать местные списки аннулирования свидетельства и по крайней мере один список за свидетельство корня CA. Поддержка требуется и для DER-закодированного X.509 и для основы 64 закодированные форматы X.509, но эта поддержка может быть оказана при помощи одного формата в программном обеспечении и обеспечении инструмента, чтобы преобразовать списки из другого формата. OCSP и другие средства непосредственной проверки онлайн законности свидетельства дополнительные, поскольку возможность соединения в Центр сертификации издания нельзя гарантировать.
5.2.3 Управление свидетельствами
Все свидетельства и их связанные частные ключи должны быть заменимыми. У клиент-серверов CDMI должна или быть способность к

импортируйте внешне произведенное свидетельство и соответствующий частный ключ, или

произведите и установите новое самоподписанное свидетельство наряду с его соответствующим частным ключом.

Когда клиент-серверы CDMI будут использовать свидетельства PKI, внедрения должны включать способность импортировать, устанавливать/хранить, и удалить свидетельства корня CA; поддержка кратного числа положила, что АВАРИЯ издания должна быть включена. Свидетельства CA используются, чтобы проверить, что свидетельство было подписано ключом от приемлемого органа сертификации.

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

Поддержка формата свидетельства PKCS#7 была сознательно опущена от требований. Этот формат прежде всего используется для взаимодействия онлайн с центрами сертификации; такая функциональность не соответствующая, чтобы потребовать всего программного обеспечения CDMI, и инструменты легко доступны, чтобы преобразовать свидетельства PKCS#7 или от других форматов свидетельства.


5.2.4 Цифровое руководство свидетельства для БТУ
Использование свидетельств, внедрения CDMI должны включать конфигурируемые механизмы, которые допускают один из следующих взаимоисключающих рабочих режимов, чтобы быть в силе в любое время для свидетельств предприятия (т.е., не свидетельств CA):

Предприятие неподдающееся проверке (самоподписалось), свидетельства автоматически установлены как основные, когда они представлены; такие свидетельства должны быть полны решимости не быть свидетельствами CA прежде чем быть установленным как основным, чтобы проверить любые другие свидетельства. Если свидетельство CA будет представлено как свидетельство предприятия, то оно должно быть отклонено. Для клиентов CDMI вариант этого выбора, который консультируется с пользователем перед принятием мер, должен осуществляться и использоваться, если это возможно.

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

Предприятие неподдающееся проверке (самоподписалось), свидетельства могут быть вручную импортированы и установлены как основные (способом, подобным ручному импортированию и установке свидетельства корня CA), но они автоматически не добавлены, когда существуютпервоначальные. Административная привилегия может потребоваться, чтобы импортировать и устанавливать свидетельство предприятия как основной.

Этот рабочий режим считают нормальным. Вся политика свидетельства для клиент-серверов CDMI должна быть конфигурируемой. Конфигурируемые механизмы определяют, как внедрение CDMI обращается с представленными свидетельствами. Под нормальным рабочим режимом серверы CDMI не должны принимать свидетельства от неизвестных (т.е., свидетельство CA не было установлено).

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

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

(информативное)
Библиография

CRC, Уильямс, Росс, "Безболезненный справочник по алгоритмам обнаружения ошибки CRC", глава 16, август 1993, http://www .repairfaq.org/filipg/LINK/F_crc_v3.html

OCCI, "Открытый Интерфейс Облачных вычислений", Версия 1.1, июнь 2011. Спецификация - http://occi-wg .org/about/спецификация /

PKS12, лаборатории RSA, PKCS № 12: синтаксис обмена личной информации, версия 1.0, июнь 1999. Спецификация и техническое исправление - http://www .rsa.com/rsalabs/node.asp? id=2138

"Представительная государственная Передача" - http://www .ics.uci.edu / ~ fielding/pubs/dissertation/rest_arch_style.htm

Сеть RESTfui, Ричардсон, Леонард и Сэм Руби, веб-сервисы RESTfui, О'Райли, 2007.



INCITS 464-2010, информационные технологии - управление информацией - расширяемый метод доступа (XAM™)
Каталог: sites -> default -> files
files -> Методические рекомендации по проведению Дня Знаний, посвященного Году кино в РФ
files -> Блестящие будущие возможности в сфере икт для нового поколения женщин
files -> Ларцева А. 1 Перевод имен собственных на примере книги ховарда рейнголда
files -> Занятие №18 Здравствуйте, участники программ личностного развития для детей!
files -> Программа кружка «Юный журналист»
files -> Шелакина А. А. Студентка 2 курса атп 921 ппк сгту имени Гагарина Ю. А
files -> Культурного и природного наследия имени д. С. Лихачева
files -> Участники регионального отборочного Чемпионата профессионального мастерства по методике WorldSkills «WorldSkills Russia Иркутск 2016» по компетенции: 21 PlasteringandDrywallSystems – Сухое строительство и штукатурные работы 25 27
files -> Семинар «использование квест- технологии в обучении английскому языку»


Поделитесь с Вашими друзьями:
1   ...   25   26   27   28   29   30   31   32   33


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал