Як безпечно передати ключ API
Без розкриття ваших секретів
Ключам API не місце в Slack, Teams, електронній пошті, заявках чи історії Git. Дізнайтеся про безпечніший процес: обмежте права ключа, зашифруйте його локально, скористайтеся одноразовим посиланням і замініть його після передавання.
Головні висновки
- Ніколи не вставляйте ключі API в електронну пошту, чат, заявки, документи чи Git.
- Використовуйте найвужчий ключ: найменші права, короткий строк життя, заміна після завершення.
- Надсилайте секрети одноразовим посиланням із шифруванням у браузері.
- Для ключів високого ризику спочатку шифруйте локально; передавайте лише шифротекст.
- Після передавання стежте за незвичною активністю — PrivateNote призначений для передавання, а не для сховища.
На цій сторінці
Кожному розробнику рано чи пізно потрібно надіслати ключ API комусь іншому — для доступу до тестового середовища, підряднику, для інтеграції webhook або передавання клієнту. Найшвидший шлях зазвичай і залишає найдовший слід.
Ставтеся до ключів API як до робочих паролів
Ключ API — це фактично пароль для програмного забезпечення. Залежно від його прав витік ключа може розкрити дані клієнтів, витратити платні ресурси, розгорнути хмарну інфраструктуру, надіслати пошту з вашого підтвердженого домену або збільшити рахунок за ШІ.
На відміну від паролів людей, ключі API часто лишаються чинними місяцями, лежать у файлах конфігурації і повністю обходять багатофакторну автентифікацію. Якщо ключ витікає, зловмисник може діяти як ваш застосунок — і зловмисний трафік може злитися зі звичайним робочим навантаженням, доки витрати не зростуть або дані вже не буде розкрито.
Ніколи не вставляйте ключі API в постійні системи
Ці канали зручні саме тому, що зберігають історію. Саме тому вони є неправильним місцем для секретів.
- Slack, Microsoft Teams, Discord або інша історія чату
- Електронна пошта, SMS або переслані гілки листів
- Jira, Trello, Notion, Confluence або issues на GitHub
- Текстові документи, таблиці та спільні хмарні папки
- Коміти Git, pull request і коментарі в коді
Де ключі API насправді витікають
Більшість витоків — не витончені злами криптографії. Вони трапляються, коли хтось копіює секрет у систему, створену для збереження записів.
Електронна пошта
Електронна пошта створює довговічні копії. Ключ може лишатися у вхідних, архівах, резервних копіях, мобільній синхронізації, пересланих гілках і пошукових індексах ще довго після завершення завдання.
Командний чат
Slack і Teams зберігають контекст — саме тому вони ризиковані для секретів. Один вставлений ключ може стати доступним для пошуку майбутніми учасниками робочого простору або витекти через скомпрометований пристрій.
Інструменти проєктів
Jira, Notion, Confluence, Trello і GitHub Issues — не сховища облікових даних. Видалені заявки можуть усе ще існувати в експортах, резервних копіях, журналах аудиту й пошуку за допомогою ШІ.
Репозиторії Git
Історія Git липка. Видалення ключа в пізнішому коміті не стирає попередні коміти. Публічні репозиторії сканують постійно, і розкриті хмарні облікові дані можуть використати за лічені хвилини.
Ключі високого ризику: спочатку шифруйте локально
Більшість ключів API можна замінити: токени тестового середовища, короткочасні секрети інтеграцій і облікові дані з вузькими правами, які ви плануєте замінити. Для них одноразової доставки з шифруванням у браузері зазвичай достатньо.
Деякі ключі важать більше — адміністративний доступ до робочого середовища, ключі підпису, кореневі хмарні облікові дані або все довговічне, що болісно чи неможливо чисто відкликати. Ставтеся до них як до головних секретів: шифруйте локально перед будь-яким вивантаженням у мережу, а потім надсилайте шифротекст через 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 з підрядником або дати колезі разовий доступ до облікових даних тестового середовища.
Часті запитання
Чому б просто не використати змінну середовища?
Змінні середовища добре підходять для запуску локального програмного забезпечення. Вони не розв’язують проблему передавання, коли це значення потрібно передати колезі, підряднику, клієнту чи партнеру з інтеграції.
Чи мають ключі 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 ->
