О TLS/SSL

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X.
информация

Transport Layer Security (TLS), предшественником которого является Secure Sockets Layer (SSL), является стандартной технологией безопасности для установления зашифрованного соединения между веб-сервером и веб-клиентом, например браузером или приложением. Зашифрованная ссылка гарантирует, что все данные, передаваемые между сервером и клиентом, остаются конфиденциальными. Чтобы использовать TLS, клиент отправляет безопасный запрос серверу, используя зашифрованный протокол HTTPS вместо незашифрованного протокола HTTP .

Edge поддерживает односторонний TLS и двусторонний TLS как в облаке, так и при локальном развертывании (поддерживаемые версии TLS см. в разделе Поддерживаемое программное обеспечение и поддерживаемые версии ). Односторонний TLS позволяет клиенту TLS проверять подлинность сервера TLS. Например, приложение, работающее на телефоне Android (клиент), может проверять подлинность Edge API (сервер).

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

Терминология TLS

Перед настройкой TLS вы должны быть знакомы со следующими важными терминами и понятиями:

Срок

Определение

Калифорния

Центр сертификации. Доверенная организация, например Symantec или VeriSign, используемая для выдачи сертификатов и проверки подлинности сертификата. Один тип сертификата, называемый самозаверяющим сертификатом, не требует центра сертификации.

Цепочка сертификатов

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

КСО

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

РЭД

Отличительные правила кодирования. Формат DER — это двоичная форма сертификата вместо формата ASCII PEM. Иногда он имеет расширение файла .der, но часто имеет расширение файла .cer. Единственный способ отличить файл DER .cer от файла PEM .cer — открыть файл в текстовом редакторе и найти инструкции BEGIN и END . Все типы сертификатов и закрытых ключей могут быть закодированы в формате DER. DER обычно используется с платформами Java.

Ключевой псевдоним

Псевдоним ключа однозначно идентифицирует запись хранилища ключей (сертификат TLS и соответствующий закрытый ключ) в хранилище ключей.

В Apigee Edge KeyAlias ​​называется alias , когда вы загружаете сертификат/ключ в хранилища ключей с помощью пользовательского интерфейса или API.

хранилище ключей

Хранилище ключей — это репозиторий, который содержит один или несколько сертификатов TLS и соответствующий закрытый ключ, который используется для идентификации объекта во время установления связи TLS между клиентом и сервером.

При северном соединении маршрутизатор действует как сервер, а его сертификат хранится в хранилище ключей Apigee Edge.

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

P7B

Формат PKCS #7 или P7B обычно хранится в формате Base64 ASCII и имеет расширение файла .p7b или .p7c. Сертификаты P7B содержат операторы -----BEGIN PKCS7----- и -----END PKCS7----- . Файл P7B содержит только сертификаты и сертификаты цепочки, а не закрытый ключ.

ПЕМ

Формат Privacy Enhanced Mail (PEM) — это текстовый формат ASCII, который представляет собой кодировку Base64 двоичного формата Distinguished Encoding Rules (DER). Сертификаты PEM можно открыть в любом текстовом редакторе, а фактическое содержимое сертификата ограничивается операторами -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- .

Он соответствует формату X.509 для хранения сертификата, цепочки сертификатов или закрытого ключа. Если ваш сертификат или закрытый ключ не определен в файле PEM, вы можете преобразовать его в файл PEM с помощью таких утилит, как OpenSSL.

ПККС № 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.

хранилище доверенных сертификатов

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

При северном соединении сертификаты клиентского приложения хранятся в хранилище доверенных сертификатов Apigee Edge. Это требуется только в том случае, если вы настроили двусторонний TLS между клиентом и Apigee.

При южном соединении сертификаты внутреннего сервера хранятся в хранилище доверенных сертификатов в Apigee Edge. Это необходимо, если вы хотите проверить сертификат серверной части в Apigee Edge при односторонней или двусторонней связи TLS между Apigee Edge и внутренним сервером.

Apigee Edge не имеет отдельного объекта хранилища доверенных сертификатов. Таким образом, хранилища доверенных сертификатов создаются как объект хранилища ключей, но упоминаются как хранилище доверенных сертификатов везде, где оно используется (например, на виртуальном хосте, целевых конечных точках, целевых серверах и т. д.).

Виртуальный хост

Виртуальный хост представляет собой конечную точку API Apigee для клиентских приложений. Это объект, который помогает размещать несколько доменных имен (с отдельной обработкой каждого имени) на одном сервере (или пуле серверов). Это позволяет одному серверу совместно использовать свои ресурсы, такие как память и циклы процессора, не требуя, чтобы все предоставляемые службы использовали одно и то же имя хоста.

Виртуальный хост может обслуживать трафик HTTP или HTTPS (с поддержкой SSL).

Виртуальный хост с поддержкой SSL можно настроить в одностороннем или двустороннем режиме TLS. Он настроен следующим образом:

  • Один или несколько хосталиев (DNS-имя конечной точки API).
  • Порт
  • хранилище ключей
  • Псевдоним ключа для уникальной идентификации одного из сертификатов сервера в хранилище ключей.
  • Необязательно, хранилище доверенных сертификатов (в двустороннем TLS, где включена аутентификация клиента).

Односторонний TLS/SSL

На следующем рисунке показано подтверждение связи TLS/SSL для односторонней аутентификации между клиентом TLS и сервером TLS:

В односторонней конфигурации TLS рукопожатие выглядит следующим образом:

  • Клиент отправляет серверу запрос сеанса.
  • Сервер отвечает сертификатом, который содержит его открытый ключ. Этот сертификат поступает из хранилища ключей сервера, которое также содержит закрытый ключ сервера. Закрытый ключ никогда не отправляется клиенту.
  • Для подписанного сертификата клиент использует хранилище доверенных сертификатов, содержащее сертификаты сервера и открытые ключи, для проверки того, что цепочка сертификатов подписана доверенным центром сертификации (CA).
  • Клиент и сервер обмениваются еще несколькими сообщениями для проверки ключей.
  • Клиент начинает передачу данных TLS с сервера.

На следующем рисунке показано подтверждение связи TLS/SSL с использованием дополнительного хранилища доверенных сертификатов на клиенте:

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

В одностороннем TLS Edge может быть либо сервером, либо клиентом следующим образом:

  • Edge в качестве TLS-сервера

    Edge — это сервер, на котором размещена конечная точка TLS, где конечная точка 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, где конечная точка 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 (маршрутизатором), называется Northbound .

В Apigee южное направление относится к целевой конечной точке, которую Apigee использует для связи с внутренним сервером. Поэтому в Apigee конечная точка, используемая для связи между Apigee Edge (процессором сообщений) и внутренним сервером, называется южной . Процессор сообщений — это компонент Apigee Edge, который передает запросы API на внутренние целевые серверы.

На следующем рисунке показаны соединения Apigee Edge в северном и южном направлении:

Northbound and southbound flow. Client application to Router is northbound. Then to Message Processor. Message Processor to Backend Server is southbound.