Вы просматриваете документацию Apigee Edge .
Перейти к документации Apigee X. info
Протокол Transport Layer Security (TLS), предшественником которого является протокол Secure Sockets Layer (SSL), — это стандартная технология безопасности для установления зашифрованного соединения между веб-сервером и веб-клиентом, таким как браузер или приложение. Зашифрованное соединение гарантирует конфиденциальность всех данных, передаваемых между сервером и клиентом. Для использования TLS клиент отправляет защищённый запрос серверу по зашифрованному протоколу HTTPS вместо незашифрованного протокола HTTP .
Edge поддерживает односторонний и двусторонний TLS как в облаке, так и в локальном развертывании (поддерживаемые версии TLS см. в разделе «Поддерживаемое программное обеспечение и поддерживаемые версии »). Односторонний TLS позволяет клиенту TLS проверять подлинность сервера TLS. Например, приложение, работающее на телефоне Android (клиент), может проверять подлинность API Edge (сервер).
Apigee также поддерживает более надёжную форму аутентификации с использованием двустороннего (клиентского) TLS. Двусторонний TLS обычно используется для повышения сквозной безопасности и защиты данных от клиентских атак, таких как подмена клиента или атаки типа «человек посередине». При двустороннем TLS клиент проверяет подлинность сервера, а затем сервер проверяет подлинность клиента.
Терминология TLS
Перед настройкой TLS вам следует ознакомиться со следующими важными терминами и понятиями:
Срок | Определение |
|---|---|
Калифорния | Центр сертификации. Доверенная организация, например, Symantec или VeriSign, используемая для выдачи сертификатов и подтверждения их подлинности. Один тип сертификатов, называемый самоподписанным сертификатом, не требует центра сертификации. |
Цепочка сертификатов | Зачастую у вас нет сертификата, подписанного корневым закрытым ключом вашего центра сертификации. Вместо этого у вас есть ваш сертификат и один или несколько промежуточных сертификатов, образующих цепочку. Последний промежуточный сертификат в цепочке обычно подписан корневым закрытым ключом центра сертификации. |
КСО | Запрос на подпись сертификата. CSR — это файл, создаваемый на TLS-сервере на основе закрытого ключа. CSR содержит открытый ключ и другую информацию, такую как название организации, местоположение и доменное имя. Центр сертификации подписывает CSR для создания TLS-сертификата. Обычно CSR генерируется, когда у вас истёк срок действия сертификата и вы хотите его продлить. |
| ДЕР | Отличительные правила кодирования. Формат DER представляет собой двоичную форму сертификата, а не формат ASCII PEM. Иногда он имеет расширение .der, но чаще всего — .cer. Единственный способ отличить файл DER .cer от файла PEM .cer — открыть файл в текстовом редакторе и найти операторы |
| Ключевой псевдоним | Псевдоним ключа однозначно идентифицирует запись хранилища ключей (сертификат TLS и соответствующий закрытый ключ) в хранилище ключей. В Apigee Edge |
Хранилище ключей | Хранилище ключей — это репозиторий, содержащий один или несколько сертификатов TLS и соответствующий закрытый ключ, который используется для идентификации объекта во время установления соединения TLS между клиентом и сервером. При северном соединении маршрутизатор выступает в роли сервера, а его сертификат хранится в хранилище ключей в Apigee Edge. В южном соединении обработчик сообщений выступает в роли клиента, а внутренний сервер — в роли сервера. Сертификат клиента и его закрытый ключ хранятся в хранилище ключей в Apigee Edge. |
| П7Б | Формат PKCS #7 или P7B обычно хранится в формате Base64 ASCII и имеет расширение .p7b или .p7c. Сертификаты P7B содержат операторы |
ПЭМ | Формат Privacy Enhanced Mail (PEM) — это текстовый формат ASCII, представляющий собой двоичный формат Distinguished Encoding Rules (DER) в кодировке Base64. Сертификаты PEM можно открыть в любом текстовом редакторе, а фактическое содержимое сертификата заключено между операторами Он соответствует формату X.509 для хранения сертификатов, цепочек сертификатов и закрытых ключей. Если ваш сертификат или закрытый ключ не определён в PEM-файле, вы можете преобразовать его в PEM-файл с помощью таких утилит, как OpenSSL. |
| PKCS #12/PFX | Формат PKCS #12 или PFX — это двоичный формат для хранения сертификата сервера, любых промежуточных сертификатов и закрытого ключа в одном зашифрованном файле. Файлы PFX обычно имеют расширения .pfx и .p12. Файлы PFX обычно используются на компьютерах Windows для импорта и экспорта сертификатов и закрытых ключей. |
Закрытый ключ | Используется на TLS-сервере для расшифровки данных. Закрытый ключ есть только на TLS-сервере и не передается TLS-клиентам. |
Открытый ключ | Используется для шифрования данных, передаваемых от TLS-клиента к TLS-серверу. Открытый ключ включен в сертификат. У всех TLS-клиентов есть копия открытого ключа сервера. |
| Ссылки | Ссылки обеспечивают определённый уровень косвенности для хранилищ ключей; поэтому изменения в хранилищах ключей не требуют обновления виртуального хоста, пока сохраняются те же ссылка и псевдоним ключа. Это позволяет вам самостоятельно вносить эти изменения и снизить зависимость от службы поддержки Apigee. |
Самоподписанный сертификат | Сертификат, не подписанный доверенным центром сертификации. Эмитент и субъект идентичны; они подписаны закрытым ключом, совпадающим с содержащимся в них открытым ключом. |
СНИ | Указание имени сервера. Позволяет обслуживать несколько HTTPS-целей с одного IP-адреса и порта, не требуя от этих целей использования одного и того же сертификата. |
TLS-сертификат | Цифровой файл, идентифицирующий объект в транзакции TLS. Сертификат (или cert ) может использоваться для идентификации сервера TLS и клиента TLS в зависимости от конфигурации TLS. |
Truststore | Содержит доверенные сертификаты на TLS-клиенте, используемые для проверки сертификата TLS-сервера, предоставленного клиенту. Эти сертификаты обычно являются самоподписанными или не подписаны доверенным центром сертификации. При северном подключении сертификаты клиентского приложения хранятся в хранилище доверенных сертификатов в Apigee Edge. Это требуется только в том случае, если вы настроили двусторонний TLS-протокол между клиентом и Apigee. При южном подключении сертификаты бэкенд-сервера хранятся в хранилище доверенных сертификатов в Apigee Edge. Это необходимо, если вы хотите проверить сертификат бэкенд-сервера в Apigee Edge при одностороннем или двустороннем соединении TLS между Apigee Edge и бэкенд-сервером. В Apigee Edge нет отдельного объекта хранилища доверенных сертификатов. Поэтому хранилища доверенных сертификатов создаются как объекты хранилища ключей, но везде, где они используются (например, на виртуальном хосте, целевых конечных точках, целевых серверах и т. д.), упоминаются как хранилища доверенных сертификатов. |
| Виртуальный хост | Виртуальный хост представляет собой конечную точку API Apigee для клиентских приложений. Это сущность, которая позволяет размещать несколько доменных имён (с отдельной обработкой каждого имени) на одном сервере (или пуле серверов). Это позволяет одному серверу совместно использовать свои ресурсы, такие как память и процессорные циклы, без необходимости использования одного и того же имени хоста всеми предоставляемыми службами. Виртуальный хост может обслуживать трафик HTTP или HTTPS (с поддержкой SSL). Виртуальный хост с поддержкой SSL может быть настроен в одностороннем или двустороннем режиме TLS. Для этого используются следующие параметры:
|
Односторонний TLS/SSL
На следующем рисунке показано согласование TLS/SSL для односторонней аутентификации между клиентом TLS и сервером TLS:
В односторонней конфигурации TLS рукопожатие выглядит следующим образом:
- Клиент отправляет серверу запрос на сеанс.
- Сервер отвечает сертификатом, содержащим его открытый ключ. Этот сертификат поступает из хранилища ключей сервера, где также содержится его закрытый ключ. Закрытый ключ никогда не отправляется клиенту.
- Для подписанного сертификата клиент использует доверенное хранилище, содержащее сертификаты сервера и открытые ключи, для проверки того, что цепочка сертификатов подписана доверенным центром сертификации (CA).
- Клиент и сервер обмениваются еще несколькими сообщениями для проверки ключей.
- Клиент начинает передачу данных по протоколу TLS с сервером.
На следующем рисунке показано подтверждение связи TLS/SSL с использованием дополнительного хранилища доверенных сертификатов на стороне клиента:
Если TLS-сервер использует самоподписанный сертификат или сертификат, не подписанный доверенным центром сертификации, на клиенте создается хранилище доверенных сертификатов. Клиент заполняет свое хранилище доверенными сертификатами сервера и открытыми ключами, которым он доверяет. Когда клиент получает сертификат, входящий сертификат проверяется на соответствие сертификатам в его хранилище доверенных сертификатов.
В одностороннем TLS Edge может быть либо сервером, либо клиентом следующим образом:
Edge как сервер TLS
Edge — это сервер, на котором размещена конечная точка TLS, которая соответствует API-прокси, развёрнутому на виртуальном хосте. Клиент — это приложение, пытающееся получить доступ к API-прокси. В этом сценарии Edge располагает хранилищем ключей, содержащим сертификат и закрытый ключ.
Edge как клиент TLS
Edge выступает в роли клиента, обращающегося к бэкенд-сервису. В данном случае бэкенд-сервис соответствует серверу, на котором размещена конечная точка TLS. Следовательно, на бэкенд-сервере есть хранилище ключей, содержащее сертификат и закрытый ключ.
Двусторонний TLS
На следующем рисунке показано согласование TLS/SSL для двусторонней аутентификации TLS между клиентом и сервером:
В двустороннем TLS рукопожатие происходит следующим образом:
- У клиента и сервера есть собственные хранилища ключей. Хранилище ключей клиента содержит его сертификат и закрытый ключ, а хранилище ключей сервера — его сертификат и закрытый ключ.
- TLS-сервер предоставляет свой сертификат TLS-клиенту для аутентификации. Затем клиент проверяет подлинность сервера, прежде чем отправить свой сертификат серверу.
- Клиент TLS предоставляет свой сертификат серверу TLS для аутентификации на сервере.
На следующем рисунке показано подтверждение связи TLS с использованием дополнительного хранилища доверенных лиц:
В этом сценарии рукопожатие выглядит следующим образом:
- Если TLS- сервер использует самоподписанный сертификат или сертификат, не подписанный доверенным центром сертификации, на клиенте создается хранилище доверенных сертификатов. В хранилище доверенных сертификатов клиента хранится копия сертификата сервера . Во время установления связи TLS клиент сравнивает сертификат в своем хранилище доверенных сертификатов с сертификатом, отправленным сервером , для проверки подлинности сервера .
- Если TLS- клиент использует самоподписанный сертификат или сертификат, не подписанный доверенным центром сертификации, на сервере создается хранилище доверенных сертификатов. В этом хранилище хранится копия клиентского сертификата. Во время TLS-рукопожатия сервер сравнивает сертификат в своем хранилище доверенных сертификатов с сертификатом, отправленным клиентом , для проверки подлинности клиента .
Клиент или сервер, или оба могут использовать хранилище доверенных сертификатов.
В двустороннем TLS Edge может быть либо сервером, либо клиентом следующим образом:
Edge как сервер
Edge — это сервер, на котором размещается конечная точка TLS, соответствующая прокси-серверу API. Клиент — это приложение, пытающееся получить доступ к прокси-серверу API. В этом сценарии Edge имеет хранилище ключей, содержащее сертификат и закрытый ключ, и требует хранилища доверенных сертификатов, содержащего сертификат клиента и цепочку центров сертификации.
Эдж как клиент
Edge выступает в роли клиента, обращающегося к бэкенд-сервису. В данном случае бэкенд-сервис соответствует серверу, на котором размещена конечная точка TLS. Таким образом, бэкенд-сервер имеет хранилище ключей, содержащее его сертификат и закрытый ключ.
Edge также должен определить хранилище ключей, содержащее сертификат, необходимый для проверки себя на внутреннем сервере, и, при необходимости, доверенное хранилище, содержащее сертификат с внутреннего сервера, если сервер использует самоподписанный сертификат или сертификат, не подписанный доверенным центром сертификации.
Важно помнить, что Edge достаточно гибок для поддержки двустороннего TLS независимо от того, как вы решите его настроить.
Поддержка SNI
Edge поддерживает использование указания имени сервера (SNI) от прокси-серверов API к Edge, где Edge выступает в качестве сервера TLS, и от Edge к целевым конечным точкам, где Edge выступает в качестве клиента TLS, как в облачных, так и в частных облачных установках.
С помощью SNI, который является расширением TLS/SSL, несколько целей HTTPS могут обслуживаться с одного и того же IP-адреса и порта, при этом не требуется, чтобы эти цели использовали один и тот же сертификат.
Информацию о включении SNI для локальной установки см. в разделе Использование SNI с Edge .
На север и на юг
В Apigee термин «северный» относится к конечной точке API, используемой клиентскими приложениями для вызова API-прокси. Обычно маршрутизатор (Router) является точкой входа в Apigee Edge и обрабатывает входящие запросы к Apigee Edge. Поэтому в Apigee конечная точка, используемая для взаимодействия клиентского приложения и Apigee Edge (маршрутизатор), называется «северным» .
В Apigee термин «южный» относится к целевой конечной точке, которую Apigee использует для взаимодействия с бэкенд-сервером. Поэтому в Apigee конечная точка, используемая для взаимодействия между Apigee Edge (процессором сообщений) и бэкенд-сервером, называется «южным» . Процессор сообщений — это компонент Apigee Edge, который перенаправляет запросы API на целевые бэкенд-серверы.
На следующем рисунке показаны северные и южные соединения для Apigee Edge:
