Как безопасно передать ключ API
Не раскрывая ваши секреты
Ключам API не место в Slack, Teams, почте, заявках или истории Git. Более безопасный порядок: ограничьте права ключа, зашифруйте его локально, передайте одноразовой ссылкой и замените, когда передача завершена.
Ключевые выводы
- Никогда не вставляйте ключи API в почту, чат, заявки, документы или Git.
- Используйте самый узкий ключ: минимум прав, короткий срок, замена после задачи.
- Передавайте секреты одноразовой ссылкой с шифрованием в браузере.
- Для ключей с высоким риском сначала шифруйте локально и передавайте только шифротекст.
- Следите за необычным использованием после передачи: PrivateNote — это передача, а не хранилище.
На этой странице
Каждому разработчику рано или поздно нужно передать ключ API кому-то ещё — для доступа к staging, подрядчику, интеграции webhook или клиенту. Самый быстрый путь обычно оставляет и самый длинный след.
Относитесь к ключам API как к продакшен-паролям
Ключ API по сути является паролем для программного обеспечения. В зависимости от прав утёкший ключ может раскрыть данные клиентов, израсходовать платные ресурсы, развернуть облачную инфраструктуру, отправить почту с вашего подтверждённого домена или нарастить счёт за ИИ.
В отличие от паролей людей, ключи API часто остаются действительными месяцами, лежат в файлах конфигурации и полностью обходят многофакторную аутентификацию. Если ключ утечёт, атакующий может действовать как ваше приложение, а вредоносный трафик смешается с обычным продакшен-использованием, пока не вырастут расходы или данные уже не окажутся раскрыты.
Никогда не вставляйте ключи API в постоянные системы
Эти каналы удобны, потому что сохраняют историю. Именно поэтому им не место для секретов.
- История Slack, Microsoft Teams, Discord или другого чата
- Почта, SMS или пересланные цепочки писем
- Jira, Trello, Notion, Confluence или GitHub Issues
- Документы в обычном тексте, таблицы и общие облачные папки
- Коммиты Git, pull request и комментарии в коде
Где ключи API утекают на самом деле
Большинство утечек — не изощрённый взлом криптографии. Они случаются, когда кто-то копирует секрет в систему, созданную для хранения записей.
Почта
Почта создаёт долгоживущие копии. Ключ может остаться во входящих, архивах, резервных копиях, мобильной синхронизации, пересланных тредах и поисковых индексах ещё долго после того, как задача выполнена.
Командный чат
Slack и Teams сохраняют контекст — и поэтому опасны для секретов. Один вставленный ключ может стать доступным для поиска будущим участникам рабочего пространства или утечь через скомпрометированное устройство.
Инструменты проектов
Jira, Notion, Confluence, Trello и GitHub Issues — не хранилища учётных данных. Удалённые заявки могут остаться в экспортах, резервных копиях, журналах аудита и поиске с помощью ИИ.
Репозитории Git
История Git липкая. Удаление ключа в позднем коммите не стирает более ранние. Публичные репозитории сканируют постоянно, и раскрытые облачные учётные данные могут начать использовать в течение минут.
Ключи с высоким риском: сначала шифруйте локально
Большинство ключей API заменяемы: токены staging, короткоживущие секреты интеграций и узко ограниченные учётные данные, которые вы планируете заменить. Для них одноразовой доставки с шифрованием в браузере обычно достаточно.
Некоторые ключи весят больше — административный доступ к продакшену, ключи подписи, корневые облачные учётные данные или всё долгоживущее, что больно или невозможно чисто отозвать. Относитесь к ним как к мастер-секретам: шифруйте локально до любой загрузки в веб, затем отправляйте шифротекст через PrivateNote.
- age — самые простые значения по умолчанию для шифрования файла (
age -p -o key.txt.age key.txt) - OpenSSL — проверенный CLI, если вы уже знаете флаги
- Загрузите зашифрованный файл через PrivateNote; парольную фразу для расшифровки отправьте отдельным каналом (Signal, телефон, лично)
Тот же порядок подходит для сид-фраз криптокошелька и других незаменимых мастер-секретов. Полный разбор age и OpenSSL, советы по парольной фразе и случаи, когда одноразовые ссылки уместны и когда нет, — в материале сид-фразы и одноразовые ссылки.
Более безопасный порядок передачи
Когда ключ нужен человеку, а не когда приложение получает его во время работы, следуйте этой последовательности.
Ограничьте ключ
Только минимальные права
Зашифруйте локально
Ключ не покидает ваш браузер
Отправьте ссылку
Не сам секрет
Отзовите по завершении
Замените после передачи
Любой пароль заметки передавайте отдельным каналом — никогда в том же сообщении, что и ссылка.
Как PrivateNote встраивается в передачу
PrivateNote создан для момента «от человека к человеку»: ключи API, приватные ключи SSH, учётные данные базы данных, коды восстановления, секреты подписи webhook и временные пароли, которые должны дойти до одного человека и не стать постоянной записью.
Если секрет — ключ SSH, а не учётные данные API, см. как безопасно передавать ключи SSH: публичные и приватные ключи, ключи развёртывания и расширения редактора.
Секрет шифруется в вашем браузере до загрузки. PrivateNote хранит шифротекст, а не открытый текст. Ключ расшифровки живёт во фрагменте URL — части после #, — которую браузеры не отправляют на сервер при загрузке страницы. Это модель одноразовой секретной ссылки, применённая к учётным данным API.
https://privatenote.ai/note/abc123#kL8mN4...
- Сервер получает идентификатор заметки и зашифрованные данные.
- Сервер не получает ключ расшифровки.
- Удаление после прочтения и срок ограничивают, как долго существует зашифрованная заметка.
PrivateNote дополняет специализированные хранилища секретов: закрывает разрыв, когда нужно отправить ключ Stripe партнёру по интеграции, передать подрядчику временный ключ OpenAI или дать коллеге разовый доступ к учётным данным staging.
Частые вопросы
Почему не обойтись переменной окружения?
Переменные окружения хороши для запуска локального ПО. Они не решают задачу доставки, когда это значение нужно передать коллеге, подрядчику, клиенту или партнёру по интеграции.
Должны ли ключи API всегда истекать?
Если провайдер это поддерживает — да. Короткоживущие учётные данные сокращают окно злоупотребления после случайного раскрытия и делают замену частью обычного процесса.
Какой порядок самый безопасный?
Создайте узко ограниченный ключ, отправьте его одноразовой ссылкой с шифрованием в браузере, передайте необязательный пароль отдельным каналом, затем замените или отзовите ключ, когда задача выполнена. Для ключей с высоким риском или долгим сроком сначала зашифруйте локально с помощью age или OpenSSL и загружайте только шифротекст.
PrivateNote — это менеджер секретов?
Нет. PrivateNote решает безопасную передачу от человека к человеку. Для хранения секретов между машинами используйте HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager или Azure Key Vault.
Итог
Большинство утечек ключей API случаются не потому, что криптография отказала. Они случаются, потому что кто-то из удобства скопировал секрет в постоянную систему с поиском. Ограничивайте ключи жёстко, передавайте их только когда это необходимо и не оставляйте след в открытом тексте в чате, заявках, почте или Git. Сторона конвейера доставки — коммиты .env, журналы CI и история GitHub — разобрана в материале [секреты в CI/CD, файлах .env и GitHub](blog:secrets-in-cicd-env-github-leaks).
Передайте ключ API, не оставляя его в чате
Создайте ссылку PrivateNote с шифрованием в браузере и удалением после прочтения. Для одноразовых заметок аккаунт не нужен.
Создать PrivateNote ->
