Вы просматриваете документацию по Apigee Edge.
Перейдите к документации по Apigee X. Информация
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
Прежде чем настраивать TLS, ознакомьтесь со следующими важными терминами и понятиями:
|
Термин |
Определение |
|---|---|
|
CA |
Центр сертификации. Надежная организация, например Symantec или VeriSign, которая выдает сертификаты и проверяет их подлинность. Один из типов сертификатов – самозаверяющий – не требует участия центра сертификации. |
|
Цепочка сертификатов |
Часто у вас не будет сертификата, подписанного закрытым корневым ключом ЦС. Вместо этого у вас есть сертификат и один или несколько промежуточных сертификатов, которые образуют цепочку. Последний промежуточный сертификат в цепочке обычно подписывается корневым закрытым ключом ЦС. |
|
CSR |
Запрос на подпись сертификата. CSR – это файл, созданный на сервере TLS на основе закрытого ключа. Запрос CSR содержит открытый ключ и другую информацию, например название организации, ее местоположение и доменное имя. Центр сертификации подписывает CSR, чтобы создать сертификат TLS. Обычно запрос CSR создается, когда срок действия сертификата истек и его нужно продлить. |
| DER |
Правила кодирования Distinguished Encoding Rules. Формат DER – это двоичный формат сертификата, а не формат ASCII PEM. Иногда у него расширение DER, но чаще – CER. Единственный способ отличить DER-файл с расширением CER от PEM-файла с расширением CER – открыть файл в текстовом редакторе и найти операторы |
| Псевдоним ключа |
Псевдоним ключа однозначно идентифицирует запись в хранилище ключей (сертификат TLS и соответствующий закрытый ключ).
В Apigee Edge |
|
Хранилище ключей |
Хранилище ключей – это репозиторий, в котором содержится один или несколько сертификатов TLS и соответствующий закрытый ключ, используемый для идентификации объекта во время подтверждения TLS между клиентом и сервером. При исходящем подключении маршрутизатор выступает в качестве сервера, а его сертификат хранится в хранилище ключей в Apigee Edge. В нисходящем соединении Message Processor выступает в роли клиента, а бэкенд-сервер – в роли сервера. Сертификат клиента и его закрытый ключ хранятся в хранилище ключей в Apigee Edge. |
| P7B |
Формат PKCS #7 или P7B обычно хранится в формате Base64 ASCII и имеет расширение файла .p7b или .p7c. Сертификаты P7B содержат операторы |
|
PEM |
Формат 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. |
|
Сертификат с собственной подписью |
Сертификат, не подписанный доверенным центром сертификации. Издатель и субъект идентичны. Они подписаны закрытым ключом, соответствующим открытому ключу, который они содержат. |
|
SNI |
Указание имени сервера. Позволяет обслуживать несколько целевых страниц HTTPS с одного IP-адреса и порта, не требуя, чтобы эти целевые страницы использовали один и тот же сертификат. |
|
Сертификат TLS |
Цифровой файл, который идентифицирует объект в транзакции TLS. Сертификат или cert можно использовать для идентификации сервера TLS и клиента TLS в зависимости от конфигурации TLS. |
|
Хранилище доверенных сертификатов |
Содержит доверенные сертификаты на клиенте 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 как сервер 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 поддерживает использование функции SNI (указание имени сервера) из прокси API в Edge, где Edge выступает в качестве TLS-сервера, и из Edge в целевые конечные точки, где Edge выступает в качестве TLS-клиента, как в облачной, так и в частной облачной установке.
SNI – это расширение TLS/SSL, которое позволяет обслуживать несколько HTTPS-целей с одного IP-адреса и порта, не требуя, чтобы эти цели использовали один и тот же сертификат.
Информацию о том, как включить SNI для локальной установки, можно найти в статье Использование SNI с Edge.
На север и на юг
В Apigee термин "северное направление" относится к конечной точке API, которую клиентские приложения используют для вызова прокси API. Обычно маршрутизатор является точкой входа в Apigee Edge и обрабатывает входящие запросы к Apigee Edge. Поэтому в Apigee конечная точка, используемая для связи между клиентским приложением и Apigee Edge (маршрутизатором), называется северной.
В Apigee термин "южное направление" относится к целевой конечной точке, которую Apigee использует для связи с внутренним сервером. Поэтому в Apigee конечная точка, используемая для связи между Apigee Edge (Message Processor) и бэкенд-сервером, называется southbound. Message Processor – это компонент Apigee Edge, который проксирует запросы API к целевым серверам.
На рисунке ниже показаны входящие и исходящие подключения для Apigee Edge:
