Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info
Протокол TLS (Transport Layer Security), предшественником которого является протокол SSL (Secure Sockets Layer), является стандартной технологией безопасности для установления зашифрованного соединения между веб-сервером и веб-клиентом, например, браузером или приложением. Зашифрованное соединение гарантирует конфиденциальность всех данных, передаваемых между сервером и клиентом. Для использования TLS клиент отправляет защищенный запрос к серверу, используя зашифрованный протокол HTTPS , а не незашифрованный протокол HTTP .
Edge поддерживает односторонний и двусторонний TLS как в облачной, так и в локальной среде (информацию о поддерживаемых версиях TLS см. в разделах «Поддерживаемое программное обеспечение» и «Поддерживаемые версии »). Односторонний TLS позволяет TLS-клиенту проверять подлинность TLS-сервера. Например, приложение, работающее на телефоне Android (клиент), может проверять подлинность API Edge (сервер).
Apigee также поддерживает более надежную форму аутентификации с использованием двустороннего, или клиентского, TLS. Двусторонний TLS обычно используется для повышения сквозной безопасности и защиты данных от атак со стороны клиента, таких как подмена клиента или атаки типа «человек посередине». В двустороннем TLS клиент проверяет подлинность сервера, а затем сервер проверяет подлинность клиента.
Терминология TLS
Перед настройкой TLS необходимо ознакомиться со следующими важными терминами и понятиями:
Срок | Определение |
|---|---|
Калифорния | Центр сертификации. Доверенная организация, такая как Symantec или VeriSign, используется для выдачи сертификатов и проверки их подлинности. Один из типов сертификатов, называемый самоподписанным сертификатом, не требует наличия центра сертификации. |
Цепочка сертификатов | Часто у вас нет сертификата, подписанного закрытым ключом корневого центра сертификации. Вместо этого у вас есть ваш сертификат вместе с одним или несколькими промежуточными сертификатами, образующими цепочку. Последний промежуточный сертификат в цепочке обычно подписан закрытым ключом корневого центра сертификации. |
КСО | Запрос на подписание сертификата (CSR). CSR — это файл, генерируемый на TLS-сервере на основе закрытого ключа. CSR содержит открытый ключ и другую информацию, такую как название организации, местоположение и доменное имя. Центр сертификации (CA) подписывает 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, представляющий собой кодировку Base64 двоичного формата Distinguished Encoding Rules (DER). Сертификаты 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 рукопожатие происходит следующим образом:
- Клиент отправляет серверу запрос на создание сессии.
- Сервер отправляет в ответ сертификат, содержащий его открытый ключ. Этот сертификат поступает из хранилища ключей сервера, которое также содержит закрытый ключ сервера. Закрытый ключ никогда не отправляется клиенту.
- Для подписанного сертификата клиент использует хранилище доверенных сертификатов, содержащее сертификаты сервера и открытые ключи, чтобы проверить, что цепочка сертификатов подписана доверенным центром сертификации (ЦС).
- Клиент и сервер обмениваются еще несколькими сообщениями для проверки ключей.
- Клиент начинает передачу данных по протоколу 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 как клиент
Edge выступает в роли клиента, обращающегося к серверной службе. В данном случае серверная служба соответствует серверу, на котором размещена конечная точка TLS. Следовательно, серверная часть имеет хранилище ключей, содержащее ее сертификат и закрытый ключ.
Edge также должен определить хранилище ключей, содержащее сертификат, необходимый для проверки подлинности перед серверной службой, и, при необходимости, хранилище доверенных сертификатов, содержащее сертификат от серверной части, если сервер использует самоподписанный сертификат или сертификат, не подписанный доверенным центром сертификации.
Важно помнить, что Edge достаточно гибок, чтобы поддерживать двусторонний TLS независимо от того, как вы решите его настроить.
Поддержка SNI
Edge поддерживает использование Server Name Indication (SNI) от API-прокси к Edge, где Edge выступает в качестве TLS-сервера, и от Edge к целевым конечным точкам, где Edge выступает в качестве TLS-клиента, как в облачных, так и в частных облачных установках.
Благодаря SNI, расширению TLS/SSL, несколько HTTPS-серверов могут обслуживаться с одного и того же IP-адреса и порта без необходимости использования одного и того же сертификата.
Для получения информации о включении SNI для локальной установки см. раздел «Использование SNI с Edge» .
в северном и южном направлениях
В Apigee термин «northbound» относится к конечной точке API, используемой клиентскими приложениями для вызова прокси-сервера API. Обычно маршрутизатор является точкой входа в Apigee Edge и обрабатывает входящие запросы к Apigee Edge. Поэтому в Apigee конечная точка, используемая для связи между клиентским приложением и Apigee Edge (маршрутизатором), называется northbound .
В Apigee термин «southbound» обозначает целевую конечную точку, которую Apigee использует для связи с бэкэнд-сервером. Поэтому в Apigee конечная точка, используемая для связи между Apigee Edge (процессором сообщений) и бэкэнд-сервером, называется «southbound» . Процессор сообщений — это компонент Apigee Edge, который перенаправляет API-запросы на целевые бэкэнд-серверы.
На следующем рисунке показаны варианты пересадок в направлении севера и юга для маршрута Apigee Edge:
