Когда мы разрабатывали Connekt — наш HTTP Client — один из вопросов, который встал перед нами: как правильно работать с секретами? API-ключи, токены, пароли — разработчики постоянно используют их при тестировании API, и важно делать это безопасно.

Мы изучили существующие подходы в индустрии и обнаружили интересные паттерны — как удачные, так и проблемные.

Анатомия утечки: как секрет попадает в публичный доступ?

Большинство утечек секретов следует одному и тому же сценарию. Представьте типичный день разработчика:

Шаг 1: Создание
Понедельник, 10:00. Разработчик добавляет API-ключ в Postman environment для тестирования нового эндпоинта. Файл сохраняется на диске в plain text — это как хранить ключи от квартиры под ковриком. Но ведь это локально, так можно, всё под контролем, что может пойти не так?

{
  "production": {
    "API_KEY": "sk_live_51H...",
    "DB_PASSWORD": "super_secret_pass"
  }
}

Шаг 2: Синхронизация
Инструмент автоматически синхронизирует коллекцию в облако для удобства работы с других устройств. Теперь секрет существует в двух местах: на локальном диске и на сервере в облаке.

Шаг 3: Шеринг
Вторник, 14:30. Коллега просит поделиться коллекцией для воспроизведения бага. Разработчик экспортирует JSON-файл и отправляет через Teams/Slack/Mattermost или что там у вас используют. Секрет теперь в третьем месте.

Шаг 4: Version Control
Среда, 16:00. Коллега добавляет полученную коллекцию в проект и коммитит в Git для удобства команды. Git сохраняет файл в истории навсегда. Удалить секрет из истории Git — нетривиальная задача, которую мало кто делает правильно.

Шаг 5: Случайный коммит
Пятница, 18:45. Разработчик спешит закоммитить фичу перед выходными. В IDE открыто много файлов, он быстро кликает "Commit All" и не замечает, что в список попал .postman_environment.json. Или забыл снять галочку с этого файла при коммите или не добавил в .gitignore. В конечном итоге, файл уходит в публичный репозиторий. Игра окончена — секрет в публичном доступе.

Реальный пример: инцидент Uber (2022)

Хакер получил доступ к корпоративному Slack, где в одном из каналов нашёл Postman-коллекцию с AWS credentials. Используя эти credentials, злоумышленник украл 77GB данных, включая информацию о 57 миллионах пользователей и водителей.

Последствия:

• Штраф от регуляторов — $148 миллионов

• Ущерб репутации компании

• Массовые увольнения в security-команде

• Обязательный пересмотр всех security практик

Что пошло не так:

1. Секреты хранились в plain text в Postman-коллекции

2. Коллекция была расшарена в Slack канале (доступ у сотен сотрудников)

3. Никто не ротировал credentials после утечки

4. Отсутствовал мониторинг использования критических API-ключей

Это не единичный случай:

• 2024, RedHunt Labs Project Resonance (Wave 14): Годовое исследование публичных Postman-коллекций выявило массовые утечки секретов из 200,000+ окружений. Обнаружено 70,000 JWT-токенов, 5,500 Bearer-токенов, 2,000+ Postman API ключей, а также credentials для AWS, GitHub, Azure, OpenAI и других сервисов. В одном из кейсов утечка AWS-ключей дала доступ к CloudWatch логам и инфраструктуре UK-стартапа. (RedHunt Labs Research)

• 2023, CircleCI incident: Компрометация привела к утечке environment variables и secrets клиентов. Пострадало более 4,500 организаций, потенциальный ущерб превысил $100 миллионов (CircleCI Security Alert)

• 2022, Heroku & Travis CI OAuth Token Theft: Компрометация OAuth tokens через GitHub привела к доступу к credentials и secrets в CI/CD системах. Атакующие получили доступ к приватным репозиториям и environment variables множества разработчиков (GitHub Security Alert)

• 2021, Codecov Supply Chain Attack: Взлом CI/CD привел к краже environment переменных, включая Postman API ключи у сотен компаний. Ущерб для одной только Twilio составил несколько миллионов долларов (Codecov Incident Report)

• 2020, SolarWinds: Частью масштабной атаки стала компрометация Postman-коллекций, отправленных подрядчикам через email. Доступ к системам 18,000+ организаций, включая правительственные агентства США (CISA Alert)

Почему так происходит: системные проблемы инструментов

Postman: удобство против безопасности

Postman — самый популярный HTTP-клиент, но его подход к безопасности создаёт риски.

Проблема 1: Экспорт коллекций — секреты попадают в Git в plaintext

В некоторых случаях Postman collections и environment файлы синхронизируются или экспортируются и хранятся в публичных репозиториях вроде GitHub. Если чувствительные данные не замаскированы или не очищены перед загрузкой, они становятся доступны любому с доступом к репозиторию.

При экспорте из Postman:

• Collection — экспортируются Shared collection variables как plain text

• Environment — Shared variables экспортируются в plaintext, Mark as sensitive экспортирует пустое значение.

Проблемы:

• Чтобы использовать переменные в CI/CD через Newman, разработчики часто делают их Shared — и они экспортируются в plaintext

• Postman не предупреждает при экспорте что файл содержит секреты. Предупреждает только когда делаешь переменную Mark as sensitive + Shared

• Секреты остаются в истории Git даже после удаления файла

Проблема 2: Форки коллекций

Механизм форков позволяет копировать популярные коллекции и подставлять свои ключи для тестирования. Если workspace публичный — ключи видны всем.

Сканирование 40,000 workspace показало следующую статистику:

• 16% публичных форков коллекции OpenAI содержали живые credentials

• 20% форков Pynt (инструмент безопасности API) содержали активные API-ключи

Проблема 3: Vault строго локальный — нельзя шарить с командой

Postman Local Vault — храните чувствительные данные как vault secrets в вашем локальном экземпляре Postman. Только вы можете получить доступ к vault secrets в вашем Postman Local Vault, и они не синхронизируются в облако Postman.

Проблемы:

• Если у команды 10 человек, каждый должен вручную добавить секреты в свой локальный vault.

• В CI/CD (Newman, Postman CLI) vault secrets просто не существуют — pipeline их не видит.

IntelliJ IDEA HTTP Client: локальность — не панацея

IDEA HTTP Client, который встроен во все IDE от JetBrains, избегает облачной синхронизации, но имеет свои проблемы:

Проблема 1: Plain text без защиты

// http-client.env.json
{
  "production": {
    "API_KEY": "sk_live_actual_secret_key",
    "DB_PASSWORD": "super_secret_password"
  }
}

http-client.env.json файл лежит в проекте рядом с .http файлами и легко попадает в Git при невнимательности.

Проблема 2: Нет автоматического .gitignore

IDEA не создаёт .gitignore для environment файлов автоматически. Не предупреждает при попытке закоммитить файл с потенциальными секретами. Нет защиты от дурака — легко случайно забыть снять галочку при коммите.

Проблема 3: Private environment требует знания о фиче

IDEA предлагает http-client.private.env.json, который IDE не индексирует. Звучит хорошо, но на практике:

• Нет автоматического .gitignore — ничто не мешает добавить файл в Git вручную, например, случайно

• Нет проверки при коммите — можно случайно запушить

Как эти проблемы решает Connekt

В Connekt мы реализовали Private Environment (PR #12) с тремя ключевыми особенностями:

1. Автоматический .gitignore при создании

Когда вы создаёте private environment, Connekt:

• Проверяет наличие .gitignore в корне проекта

• Если файла нет — создаёт его

• Добавляет connekt.private.env.json в ignore-лист

Результат: закоммитить секреты становиться значительно сложнее.

2. Разделение публичной конфигурации и секретов

Примечание: IDEA HTTP Client также поддерживает разделение через http-client.private.env.json, но требует знания о фиче. В Postman такого разделения нет — все переменные в одном файле.

// connekt.env.json (публичная конфигурация, можно коммитить в Git)
{
  "production": {
    "apiUrl": "https://api.example.com",
    "timeout": "5000",
    "debugMode": "false"
  }
}


// connekt.private.env.json (секреты, автоматически в .gitignore)
{
  "production": {
    "apiKey": "sk_live_actual_secret_key",
    "dbPassword": "super_secret_password"
  }
}

Connekt автоматически мержит переменные из обоих файлов. Если переменная присутствует в обоих файлах, приоритет у private environment.

Так же есть предупреждение о том что файл connekt.private.env.json не зарегестрирован в gitignore и предложение его туда добавить.

3. Работает из коробки

Не нужно вручную добавлять записи в .gitignore

Просто создаёте private environment через UI — остальное Connekt делает сам.

Сравнение решений

Что дальше?

Private Environment решает большинство проблем для индивидуальных разработчиков и небольших команд. Для enterprise-сценариев мы рассматриваем возможность интеграции с:

1. SOPS (Secrets OPerationS) — индустриальный стандарт для шифрования секретов с поддержкой корпоративных KMS.

   Преимущества:

   1. Шифрование с использованием AWS KMS, GCP Cloud KMS, Azure Key Vault, PGP

   2. Git-friendly: можно безопасно коммитить зашифрованные секреты

   3. Централизованное управление доступом через IAM policies

   # connekt.private.env.sops.yaml (можно коммитить!)
   production:
     apiKey: ENC[AES256_GCM,data:8fH7gK...,iv:...,tag:...]
   dbPassword: ENC[AES256_GCM,data:mN9pQ...,iv:...,tag:...]
   

2. Возможно интеграция с HashiCorp Vault – для команд, использующих Vault:

   {
     "production": {
       "apiKey": "vault://secret/data/api#key",
       "dbPassword": "vault://secret/data/db#password"
     }
   }
   

   Connekt будет автоматически получать секреты из Vault при выполнении запросов.

Есть что добавить? Сталкивались с утечками секретов? Есть идеи по улучшению безопасности HTTP-клиентов? Интересует ли вас SOPS или HashiCorp Vault в контексте Connekt? Поделитесь этим в комментариях или в нашем Телеграм-чате.

Попробуйте Connekt, если для вас важна безопасность API-ключей. Проект доступен на GitHub, там же можно оставлять issues и предложения. Также прочитайте обзор Connekt на Хабр от Домклик: https://habr.com/ru/companies/domclick/articles/965116/.