Зашифрованные KVM в Apigee X: полное руководство

Что такое зашифрованные KVM в Apigee X и зачем они нужны?

Если вы проходили собеседование на позицию разработчика Apigee, вы наверняка сталкивались с вопросом: «Что такое зашифрованный KVM и как получить доступ к его значениям?». Многие кандидаты отвечают: «Это для безопасного хранения паролей». Это верно, но интервьюеры ждут более глубокого объяснения. В этой статье мы разберем, что такое KVM, чем зашифрованный KVM отличается от обычного, как Apigee шифрует и расшифровывает значения, и как правильно использовать его в реальных проектах.

Зачем нужны зашифрованные KVM?

Представьте, что вы разрабатываете платежный API. Ваш прокси должен вызывать бэкенд-сервис, который требует базовую аутентификацию: имя пользователя и пароль. Где хранить эти учетные данные?

Плохой вариант: захардкодить пароль в коде прокси или JavaScript. Тогда любой, у кого есть доступ к прокси-бандлу, сможет его прочитать.

Хороший вариант: хранить пароль в зашифрованном KVM. Apigee расшифрует его только во время выполнения, и никто, кроме Apigee, не сможет получить доступ к исходному значению.

Что такое KVM?

KVM (Key Value Map) — это безопасное хранилище пар ключ-значение. Например:

databaseUrl → jdbc:mysql://server
timeout → 30
currency → INR
apiVersion → v1

Вместо того чтобы захардкоживать конфигурацию в прокси, вы храните ее в KVM. Это упрощает поддержку API.

Чем зашифрованный KVM отличается от обычного?

Обычный KVM хранит значения в открытом виде. Зашифрованный KVM хранит значения в зашифрованном виде. Например, вместо пароля welcome123 в зашифрованном KVM будет храниться что-то вроде A8FD92KSJH8237AJSHF....

Даже если кто-то получит доступ к хранилищу данных, он не сможет прочитать исходное значение.

Аналогия из жизни

Представьте два шкафчика. Обычный шкафчик открывается ключом, и вы видите пароль. Зашифрованный шкафчик — это сейф внутри шкафчика. Даже открыв шкафчик, вы не увидите пароль, потому что он в зашифрованном сейфе. Только Apigee знает, как его открыть.

Как работает шифрование в Apigee?

Процесс выглядит так:

1. Вы создаете зашифрованный KVM.
2. При добавлении значения Apigee шифрует его.
3. Зашифрованное значение хранится в базе данных.
4. Когда приходит запрос, Apigee автоматически расшифровывает значение и передает его в политику.

Важно: вы никогда не расшифровываете значение вручную. Apigee делает это автоматически.

Как создать зашифрованный KVM?

При создании KVM в Apigee X просто включите опцию Encrypted = true. Например, создайте KVM с именем backend-config и включите шифрование. Затем добавьте записи:

backendUser = payment-user
backendPassword = SuperSecretPassword

Apigee зашифрует значение backendPassword перед сохранением.

Как получить доступ к зашифрованному KVM?

Это любимый вопрос интервьюеров. Ответ — через политику KeyValueMapOperations. Пример:

<KeyValueMapOperations name="KVM-Read">
  <Get assignTo="private.backendPassword">
    <Key>
      <Parameter>backendPassword</Parameter>
    </Key>
  </Get>
  <Scope>environment</Scope>
  <MapName>backend-config</MapName>
</KeyValueMapOperations>

Что происходит? Apigee читает зашифрованное значение, расшифровывает его и сохраняет в переменную private.backendPassword. Теперь вы можете использовать {private.backendPassword} в прокси.

Использование значения

Допустим, бэкенд требует базовую аутентификацию. Вы можете создать заголовок Authorization с помощью политики AssignMessage:

<AssignMessage name="CreateAuthHeader">
  <AssignVariable>
    <Name>request.header.Authorization</Name>
    <Template>Basic {private.backendPassword}</Template>
  </AssignVariable>
</AssignMessage>

Обратите внимание: мы никогда не расшифровываем ничего вручную.

Может ли JavaScript прочитать зашифрованный KVM?

Да, но только после того, как политика KeyValueMapOperations выполнится и расшифрует значение. JavaScript может получить доступ к переменной потока:

var password = context.getVariable("private.backendPassword");
print(password);

JavaScript не выполняет расшифровку — Apigee уже сделал это.

Полный поток выполнения

Клиент → API Proxy → KeyValueMapOperations (чтение и расшифровка) → переменная private.backendPassword → AssignMessage/JavaScript → вызов бэкенда → ответ бэкенда.

Реальный пример из продакшена

Ваша организация интегрируется с платежным шлюзом. Шлюз предоставляет Client ID, Client Secret, Username и Password. Вместо хранения секретов в коде вы храните их в зашифрованном KVM, например, gateway-config с записями clientSecret, username, password.

При выполнении API: чтение KVM → расшифровка → вызов шлюза. Никакие секреты не раскрываются в коде прокси.

Почему не стоит хранить секреты в JavaScript?

Если кто-то скачает прокси-бандл, он сразу увидит пароль в коде JavaScript. Это огромный риск безопасности. С зашифрованным KVM в бандле будет только ссылка на KVM, а не само значение.

Частые вопросы на собеседовании

Вопрос 1: Каково назначение зашифрованного KVM?

Для безопасного хранения чувствительных данных: паролей, API-ключей, секретов клиентов, токенов — чтобы они не были захардкожены в прокси.

Вопрос 2: Можно ли прочитать зашифрованные значения напрямую?

Нет. Чтение происходит через политику KeyValueMapOperations, которая автоматически расшифровывает значение во время выполнения.

Вопрос 3: Может ли JavaScript расшифровать зашифрованный KVM?

Нет. JavaScript не может расшифровать значение. Он может получить доступ только к уже расшифрованной переменной потока после выполнения политики KVM.

Вопрос 4: Можно ли просмотреть зашифрованные значения через UI?

Нет. После сохранения зашифрованные значения нельзя просмотреть в открытом виде. Вы можете их обновить, но не посмотреть исходное значение.

Вопрос 5: Следует ли хранить сертификаты в KVM?

Нет. Сертификаты и приватные ключи следует хранить в Keystore и Truststore. KVM предназначен для конфигурационных значений и секретов, таких как пароли или учетные данные API.

Лучшие практики

• Храните в зашифрованных KVM только чувствительные значения.
• Используйте KVM с областью environment, чтобы в разных средах (dev, test, prod) были разные секреты.
• Никогда не хардкодьте пароли, API-ключи и секреты клиентов в JavaScript или XML прокси.
• Используйте осмысленные имена KVM: backend-config, payment-config, oauth-config.
• Ограничьте права доступа: только авторизованные администраторы могут обновлять записи в зашифрованном KVM.

Частые ошибки

• Хардкод учетных данных в JavaScript.
• Логирование расшифрованных секретов в MessageLogging или JavaScript.
• Использование обычного KVM для паролей и секретов.
• Хранение сертификатов в KVM вместо Keystore.
• Использование одного и того же секрета во всех средах.

Ответ на собеседовании (2-минутная версия)

«Зашифрованные KVM в Apigee X используются для безопасного хранения чувствительных конфигурационных данных, таких как пароли бэкенда, секреты клиентов, API-ключи и токены аутентификации. В отличие от обычного KVM, значения шифруются перед сохранением, что предотвращает их раскрытие администраторам или разработчикам. Во время выполнения API политика KeyValueMapOperations читает зашифрованное значение, и Apigee автоматически расшифровывает его и сохраняет в переменную потока. Прокси или JavaScript затем получает доступ к переменной без ручной расшифровки. Такой подход исключает захардкоженные секреты в прокси и соответствует лучшим практикам безопасности корпоративного управления API».

Ключевые выводы

• Зашифрованные KVM защищают чувствительные конфигурационные данные.
• Apigee выполняет шифрование и расшифровку автоматически.
• Доступ к значениям — через политику KeyValueMapOperations.
• JavaScript читает расшифрованную переменную, но не расшифровывает сам.
• Используйте зашифрованные KVM для секретов, а Keystore/Truststore — для сертификатов.

Практический вывод

Прямо сейчас пересмотрите свои прокси в Apigee: если вы храните пароли или секреты в JavaScript или XML, немедленно перенесите их в зашифрованный KVM. Создайте KVM с шифрованием, добавьте записи и замените хардкод на политику KeyValueMapOperations. Это займет не больше часа, но значительно повысит безопасность ваших API. Удачи на собеседованиях!