Секрети й облікові дані: надавайте доступ, який можна обмежити й відкликати

Пароль, ключ застосунку й тимчасовий токен — не просто рядки, які треба сховати. Вони є доказами, за якими система надає певну ідентичність і може дозволити конкретні дії. Безпечна робота з ними охоплює весь цикл: хто й навіщо отримав доступ, де дані проходять і зберігаються, як виявити їх витік, як замінити або відкликати та як перевірити, що старий доступ уже не використовується.

Після розділу читач може:

• розрізняти ідентичність, автентифікацію й авторизацію;
• пояснити різницю між конфігурацією та секретом і зрозуміти, чому файл .env сам по собі нічого не захищає;
• звузити права, строк дії й середовище облікових даних, особливо якщо доступу просить агент;
• описати межі захисту Git, журналів, маскування та секретів конвеєра;
• скласти окремі кроки зберігання, ротації, відкликання й реагування на витік;
• перевірити результат заміни, не розкриваючи значення ключа.

Тут секрет означає значення або матеріал, доступ до якого дає змогу пройти перевірку або отримати привілей: наприклад, пароль, ключ програмного інтерфейсу (Application Programming Interface, API), токен чи приватний ключ. Облікові дані (credentials) — докази, якими система підтверджує ідентичність або право доступу. Приклади й назви ключів у цьому розділі вигадані; жоден справжній секрет не потрібен для навчання. Точні можливості продуктів залежать від конкретного сервісу, типу облікового запису й конфігурації.

53.1. Хто звертається, чим доводить це і що може зробити

Ідентичність відповідає на запитання «хто або що звертається?»: людина, застосунок, сервісний обліковий запис чи робоче навантаження. Автентифікація — перевірка доказу цієї ідентичності. Авторизація — рішення, які дії й над якими ресурсами дозволені після перевірки. Наявність чинного токена не доводить, що його власникові потрібен доступ до кожної дії або кожного об’єкта.

Секрет може бути одним із таких доказів, але його властивості різняться. Пароль часто перевіряє людину й може мати супутні правила входу. Ключ API дає програмі спосіб звертатися до служби; він може бути прив’язаний до користувача, проєкту чи сервісної ідентичності. Токен доступу часто призначений для обмеженого строку або набору дій, а токен оновлення може отримати новий токен доступу. Приватний ключ підтверджує володіння криптографічною парою ключів. Жодна з цих назв сама собою не гарантує короткого строку, вузьких прав, безпечного зберігання чи автоматичного відкликання.

Під час оцінки облікових даних з’ясуйте окремо:

Питання	Що потрібно зафіксувати
Хто звертається?	Людина, сервіс, агент чи конкретне робоче навантаження; хто є власником і хто відповідає за заміну
Для чого?	Одна потрібна дія й ресурс, на якому її виконують
Який доказ?	Пароль, статичний ключ, тимчасовий токен, сертифікат чи федеративна ідентичність
Який обсяг доступу?	Дозволені дії, ресурси, середовище та можливість читати чутливі дані
Як довго?	Строк дії, умова завершення, спосіб продовження та дата перегляду
Де він проходить?	Місце створення, зберігання, передавання, використання, журналювання й відкликання
Як перевірити зміну?	Безпечний сигнал успішного доступу, журнал аудиту, метрика чи контрольний запит

Найменші необхідні повноваження (least privilege) означають надати лише дії й ресурси, потрібні для визначеного завдання, і переглянути доступ, коли завдання завершене або змінилося. Доступ лише для читання теж може розкрити приватний вихідний код, персональні дані, конфігурацію чи вразливість. Тому «тільки читання» — це обмеження типу зміни, а не твердження про нешкідливість.

Конфігурація описує, як запускається програма: наприклад, адресу служби або назву середовища. Секрет — це значення, компрометація якого може надати доступ. Одне налаштування не стає секретом лише через ім’я змінної, а секрет не перестає бути секретом, якщо його записали в файл налаштувань. Файл .env — поширений спосіб передати змінні процесу під час локальної розробки. Він не є сховищем секретів і не шифрує вміст автоматично. Змінні середовища можуть потрапити в дочірні процеси, налагоджувальний вивід, діагностичний знімок або журнал; межа їх видимості залежить від хоста, прав процесів і конфігурації. Не виводьте всі змінні середовища для діагностики. ([Розділ 3: локальне середовище й виконання програми](03-terminal-local-environment-and-program-execution.md))

У документації OpenAI окремо описано ключі саме OpenAI API Platform: ключ має залишатися на серверному боці, а API підтримує ключ або короткострокову федеративну автентифікацію там, де її налаштовано. У матеріалах Anthropic щодо Claude API описано статичні ключі, короткостроковий обмін через федерацію ідентичностей та інші способи для конкретних середовищ. Ці сторінки не визначають вхід до ChatGPT, Codex чи споживчого Claude; не переносіть властивості одного продукту на інший. Для ключів користувачів OpenAI API Platform документація пропонує режими All (усі), Restricted (обмежені) або Read Only (лише читання); керування ключами сервісних облікових записів відрізняється. Claude API розрізняє персональні ключі й ключі сервісного облікового запису та дозволяє за потреби обмежити ключ робочим простором. Це продуктоспецифічні засоби обмеження, а не універсальні властивості ключів. (OpenAI API: Authentication; OpenAI: Best Practices for API Key Safety; Anthropic: Claude API Authentication)

53.2. Місце зберігання не замінює обмеження доступу

Секрет треба зберігати в місці з контрольованим доступом, журналом його видачі й визначеним власником. Для локальної розробки це може бути сховище паролів розробника або контрольований секретний файл, виключений із коміту. Для сервера — менеджер секретів, сховище облікових даних платформи чи механізм видачі короткострокового доступу. Конкретний вибір залежить від середовища, моделі загроз і здатності команди обслуговувати його. «Менеджер секретів» теж потребує вузьких прав, аудиту й плану відновлення.

Змінна середовища може передати програмі значення з такого сховища, але вона не визначає, хто ще читає пам’ять процесу, чи успадкує її дочірня команда, чи потрапить вона в трасування помилки або чи збереже її образ контейнера. Обирайте механізм доставки разом із межами процесу, журналів і хоста. Не записуйте секрет в аргументи командного рядка, URL (Uniform Resource Locator — уніфікований локатор ресурсу), повідомлення помилки, записаний приклад або діагностичний дамп, якщо існує безпечніший спосіб передати його.

Короткострокове посвідчення або федерація робочої ідентичності можуть зменшити кількість довготривалих ключів: система обмінює довірене посвідчення робочого навантаження на токен із обмеженим строком. Це прибирає потребу зберігати окремий статичний ключ у цьому ланцюзі, але довіра до постачальника ідентичності, правила обміну та права виданого токена все одно критичні. Короткий строк не компенсує надмірних прав, а федерація не робить слабке вхідне посвідчення безпечним автоматично. Підтримка й назви таких механізмів різняться за продуктами. Open Worldwide Application Security Project (OWASP) описує керування секретами як повний життєвий цикл, а не лише вибір сховища. (OWASP Secrets Management Cheat Sheet; Anthropic: Workload Identity Federation)

Розділяйте облікові дані принаймні за середовищем і призначенням: локальна розробка, тестування та виробниче середовище не повинні непомітно користуватися одним довготривалим ключем. Визначайте власника, дозволені дії, дату перегляду або завершення, місце зберігання, споживачів і процедуру відкликання. Не створюйте копії «про запас» без обліку: невідомі копії важко знайти після витоку.

53.3. Git зберігає історію, а не намір

Файл .gitignore просить Git не додавати ще не відстежуваний файл до нових змін. Це правило не вилучає файл, який уже відстежується, і не стирає секрет із попереднього коміту. Перемикання репозиторію на приватний також не відкликає ключ і не забирає копії в тих, хто мав до нього доступ. Клони, форки, архіви, журнали CI/CD (Continuous Integration/Continuous Delivery — безперервна інтеграція й доставка), завантажені артефакти та кеші можуть зберігати окремі копії.

Знайшовши секрет у Git, не вставляйте його в коментар до запиту на злиття (pull request, PR), задачу трекера або повідомлення агенту для «підтвердження». Замість значення зафіксуйте тип і власника облікових даних, місце появи, приблизний час, діапазон доступу та кроки, які вже зроблено. Якщо потрібно ідентифікувати одну з кількох версій, використовуйте контрольований інвентар або відбиток, який не розкриває сам секрет.

Виправлення треба розділити на дві цілі: припинити доступ і прибрати копії. Видалення рядка з останньої версії чи переписування історії не скасовує вже скопійований секрет. Редагування історії може зменшити його видимість у контрольованому репозиторії, але форки, клони, кеші та зовнішні копії можуть залишитися. Якщо очищення історії потрібне, сплануйте його з власником репозиторію після відкликання або заміни активного ключа; перевірте наслідки переписування для співавторів. (GitHub: Remediating a leaked secret)

53.4. Конвеєр автоматизації має власні межі довіри

У CI/CD секрети можуть бути доступні завданню, яке їх не потребує, кроку стороннього розширення, журналу чи артефакту. Керування секретами в GitHub Actions дає різні рівні зберігання — репозиторій, середовище та організацію — і дозволяє обмежувати середовищні секрети правилами. За типовою поведінкою подія pull_request із форку не отримує звичайні секрети; це не універсальна гарантія для всіх типів подій і конфігурацій. Особливо небезпечно запускати неперевірений код із форку у привілейованому контексті подій на кшталт pull_request_target або workflow_run, де завдання може мати секрети чи право запису. Перевіряйте конкретний робочий процес і його ланцюг кроків. (GitHub: Using secrets in GitHub Actions; GitHub: Secure use reference; GitHub: Securely using pull_request_target)

Маскування у журналі — це зменшення випадкового показу, а не межа доступу. Система може приховувати відоме точне значення, але не гарантує виявлення кожного перетворення, розбиття на частини, кодування або витоку в сторонній канал. GitHub прямо застерігає, що автоматичне редагування журналу не є повним захистом; якщо створюється нове похідне представлення секрету, воно може потребувати окремого маскування, і навіть це не замінює ізоляцію кроку. Третя сторона, якій робочий процес передав секрет, може його вивести чи надіслати мережею. Обмежте секрети й право запису конкретними завданнями автоматизації, перевіряйте сторонні дії та не друкуйте значення. (GitHub: Secure use reference; GitHub: Workflow commands)

Повний випадок: декодоване значення з’явилося в журналі

У публічному повідомленні супроводжувачів Spotless у вересні 2026 року описано витік у журналах GitHub Actions. Під час зміни системи публікації робочий процес декодував збережене значення й записав його у змінну середовища GITHUB_ENV. У журналах наступних кроків GitHub Actions показав значення в заголовках блоків, зокрема пароль токена Sonatype/Maven Central; відоме маскувальнику закодоване значення не збіглося з декодованим. Супроводжувачі також повідомили, що під час налагодження тимчасово прибрали обмеження гілки для публікацій. Журнали були доступні приблизно 28 годин; після виявлення команда повідомила про локалізацію приблизно за 25 хвилин. Окремо згадано зашифрований підключ для підпису релізів, збережений засобами GNU Privacy Guard (GPG); за словами супроводжувачів, його пароль і головний ключ не витекли. Команда вважала токен скопійованим, відкликала й замінила його, прибрала закодовані значення, зупинила публікації й перевірила релізи. Це звіт власників проєкту, а не незалежне криміналістичне дослідження. (Spotless, повідомлення безпеки № 3089)

Рішення й дії: ставтеся до відкритого секрету як до скомпрометованого, зупиніть завдання, здатні повторно його надрукувати, відкличте або замініть активне посвідчення, перегляньте журнали й артефакти, перевірте використання та доступи, а потім змініть робочий процес так, щоб він передавав значення у формі, яку споживач очікує, без друку. Перевірте, що заміна працює, і лише тоді відновлюйте публікацію за погодженим порядком.

Спостережуваний результат: старий ключ більше не авторизує запити; новий ключ дає лише потрібну дію; журнали не показують значення; власник перевірив журнал доступу та статус публікацій. Випадок показує, чому захист треба прив’язувати до потоку даних, а не до рядка з налаштування маскування: перетворення створило інше значення. Він не доводить, що всі інструменти CI мають однакову помилку чи що маскування не має користі.

GitHub Push Protection може блокувати частину підтримуваних секретів перед потраплянням у репозиторій, але покриття й доступність функції залежать від типу секрету й конфігурації. Це додатковий бар’єр для Git, а не доказ, що журнал, артефакт, стороння дія або інше джерело не містить секрету. (GitHub: Push protection)

53.5. Агент отримує інструмент і межі, а не пароль «на пам’ять»

Агенту не потрібно передавати пароль у підказці, щоб «запам’ятав», і не слід вставляти ключ у приклад, повідомлення задачі чи журнал. Інструкція Markdown може попросити агента берегти секрет, але сама по собі не є технічним контролем доступу. Контроль задають дозволи середовища, інструментів, облікового запису й сховища. Якщо агент може викликати інструмент, який уже має доступ, його фактичні можливості визначаються цим інструментом і правами його ідентичності. Це продовжує різницю між інструкцією та технічним обмеженням, розглянуту в розділах про ієрархію інструкцій та Model Context Protocol (MCP — протокол контексту моделі). ([Розділ 28: ієрархія інструкцій](28-instruction-hierarchy.md); [Розділ 35: Model Context Protocol для Claude](35-mcp-for-claude.md))

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

Повний випадок: адміністраторський токен для читання одного репозиторію

Агент просить персональний токен із правами адміністратора організації, щоб прочитати один приватний репозиторій. Спершу уточніть, які саме файли й операцію він має виконати. Якщо достатньо перегляду коду, виділіть окрему сервісну ідентичність або інший доступний механізм, який дозволяє читати тільки цільовий репозиторій і не надає запису чи керування організацією. Якщо продукт не підтримує таке звуження, використайте контрольований експорт потрібних файлів або ручний огляд, якщо це відповідає політиці даних.

Спостережуваний результат: агент читає потрібні файли, а тестова спроба змінити репозиторій або прочитати інший цільовий ресурс відхиляється; журнал показує очікувану ідентичність. Якщо система дозволяє лише ширший доступ, власник документує залишковий обсяг і обирає інший маршрут або свідомо погоджує його за процесом організації. «Тільки читання» не означає «без ризику», адже код, секрети в репозиторії та внутрішня структура також можуть бути чутливими. Точні назви прав різняться між системами, тож не підставляйте неперевірений синтаксис дозволів.

53.6. Ротація, відкликання й відновлення — різні кроки

Ротація — керований перехід споживачів на нові облікові дані. Відкликання — припинення чинності старих. Відновлення після витоку — ширший процес, який також охоплює визначення доступу й копій, перевірку зловживання, усунення причини та спостереження після заміни. Створити новий ключ, переключити всі споживачі й відкликати старий — три різні події. У деяких системах відкликання поширюється не миттєво; звірте фактичну поведінку постачальника.

Для планової ротації складіть список споживачів і власників, перевірте строк та права, створіть нові облікові дані з потрібним обсягом, помістіть їх у контрольоване сховище, перевірте тестовий або контрольний запит, переключіть споживачів, перевірте метрики й журнали, а тоді відкличте старі. Спостерігайте за невикористаними старими ключами лише настільки довго, наскільки це дозволяє політика й ризик. Не залишайте перехідний доступ без кінцевої дати.

Для підозрюваного витоку припускайте, що секрет могли скопіювати. Визначте власника й можливості ключа, відкличте його або застосуйте термінову заміну за процедурою постачальника, зупиніть подальше друкування, перевірте журнали використання та діапазон доступу, знайдіть споживачів і копії, створіть нові облікові дані в безпечному місці, виправте джерело витоку й перевірте відновлення. Якщо одночасне існування ключів потрібне для безперервності, такий перекривний період прийнятний лише за оціненої загрози, жорсткого строку й контролю використання. Під час активної атаки швидке відкликання може мати пріоритет над безперервністю.

Не існує універсального строку ротації для кожного ключа. Ризик, строк життя, можливість спостереження та вартість помилкового відкликання різні; дотримуйтеся правил власника системи й постачальника. OWASP радить керувати повним життєвим циклом і доступом до секретів, а не покладатися на довільний календарний інтервал. (OWASP Secrets Management Cheat Sheet; OpenAI: Best Practices for API Key Safety)

Читайте журнали постачальника в межах їхнього призначення

Сигнали про використання й журнали адміністративних подій відповідають на різні запитання. Для OpenAI API Platform Usage Dashboard показує використання й витрати API, а Audit Logs API фіксує адміністративні та конфігураційні події, зокрема життєвий цикл ключів; журнал аудиту треба окремо ввімкнути. OpenAI окремо зазначає, що журнали аудиту не містять вміст запитів і відповідей API, а їхній строк зберігання не має фіксованої гарантії; якщо потрібна довготривала історія, експортуйте її до власного контрольованого сховища. (OpenAI: Reviewing API usage and costs; OpenAI: Admin and Audit Logs API)

Для Claude API матеріали Claude Platform описують керування ключами й організаційними звітами через Admin API. Для відповідних організацій Compliance API надає Activity Feed: ключ Claude Console Admin API може читати лише цей потік, а ширший доступ Compliance API використовує інші типи ключів і залежить від продукту та дозволів. Експорт журналу аудиту у CSV в налаштуваннях Claude Enterprise є окремою функцією. Не припускайте, що будь-який ключ API відкриває повний журнал запитів чи їхній текст. Поєднуйте доступні сигнали постачальника зі своїми знеособленими журналами застосунку, не записуючи заголовки автентифікації або тіло запиту без потреби. (Anthropic: Admin API; Anthropic: Compliance API)

Повний випадок: планова заміна ключа імпорту

Щоденний фоновий імпорт із постачальника використовує довготривалий ключ читання. Власник має список двох робочих процесів і одного резервного середовища, де цей ключ збережено. До заміни команда перевіряє, чи можна постачальнику видати окремий ключ лише для читання потрібного набору даних і чи журналюється його використання.

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

Спостережуваний результат: обидва робочі процеси завершують імпорт, нові дані відповідають очікуваній кількості, використання старого ключа зникло або його відхиляють, а старий ключ недійсний. Якщо постачальник дозволяє лише один ключ за раз, або імпорт не можна перевірити паралельно, команда обирає погоджене вікно обслуговування й план відновлення. Послідовність «створити — перевірити — переключити — відкликати» зменшує ризик помилки, але не гарантує нульового простою в кожному сервісі.

53.7. Повний план дій, якщо секрет опинився в PR

Припустімо, агент додав файл .env з ключем до гілки та відкрив PR. Не повторюйте значення в коментарі чи звіті, не просіть агента приховати його за іншим ім’ям і не обмежуйтеся видаленням файла з останнього коміту.

1. Зупиніть подальше поширення. Через затверджений приватний канал повідомте власника репозиторію та відповідального за секрет. Обмежте доступ до PR за процедурою реагування. Зупиніть завдання автоматизації або збірки, які можуть копіювати файл у журнали чи артефакти. Не підсумовуйте в публічному коментарі вміст файлу.
2. Визначте, що було розкрито. Перегляньте зміни контрольованим способом, встановіть власника, призначення, права, середовище, час, строк і всі можливі споживачі. Не перевіряйте чужий ключ викликом зовнішнього сервісу без дозволу власника.
3. Припиніть чинність або замініть доступ. Якщо ключ активний, повідомте власника й застосуйте процедуру відкликання чи термінової заміни. Першочерговість визначте за правами й можливістю зловживання; сам факт, що PR не злитий, не робить оприлюднений ключ безпечним.
4. Знайдіть копії й використання. Перевірте історію комітів, форки, клони, журнали, артефакти, кеші, сповіщення й локальні копії в межах доступної телеметрії. Перегляньте журнали використання від часу першого можливого розкриття, якщо сервіс їх надає. Відсутність запису аудиту не доводить відсутність доступу.
5. Змініть джерело. Вилучіть файл із поточної версії, додайте правильне правило ігнорування, перевірте, що він більше не відстежується, та перенесіть активний секрет до затвердженого сховища. Видаліть артефакти й журнали за правилами платформи, не обіцяючи стерти вже завантажені копії.
6. Очистіть історію, якщо це потрібно. Спершу припиніть чинність ключа. Узгодьте переписування історії з власником репозиторію, врахуйте форки й клони, попередьте співавторів і перевірте доступні копії. Очищення зменшує випадкове подальше відкриття, але не відновлює секретність.
7. Усуньте причину й перевірте результат. Обмежте доступ агента та кроків автоматизації, додайте підтримуваний сканер або захист від відправлення секретів, перегляньте шаблони й інструкції. Використовуйте фальшиве навчальне значення для перевірки, що файл і журнали не приймаються; не запускайте справжній ключ у тесті.

Очікуваний результат: старий ключ більше не працює; чинні споживачі використовують належну заміну або сервіс зупинено контрольовано; доступні журнали використання й копії перевірені; файл не додається повторно; власник знає, що лишається невідомим. Якщо секрет належить сторонній організації або постачальнику, залучіть його власника через узгоджений процес. Цей список — навчальний план реагування, а не заміна політики інцидентів організації.

Короткий підсумок

Захист секрету — це керування ідентичністю, правами, місцями проходження й строком доступу. .env, приватний репозиторій, маскування журналу чи очищена історія не відкликають ключ. Видавайте мінімально потрібні права на обмежений строк, зберігайте значення в контрольованому місці, не передавайте його агенту в підказці, а ротацію розділяйте на створення заміни, перевірку, перемикання та відкликання старого доступу. Після витоку припускайте, що секрет скопійовано, і перевіряйте як доступ, так і доступні копії.

Джерела та подальше читання

Матеріали перевірено 10 жовтня 2026 року. Документація хмарних і API-продуктів змінюється; перед налаштуванням звіряйте тип облікового запису, чинні права й документацію саме вашої системи.

• Open Worldwide Application Security Project (OWASP), Secrets Management Cheat Sheet — життєвий цикл, обмеження доступу, середовища, ротація й поводження з секретами в конвеєрах.
• GitHub, Using secrets in GitHub Actions — області секретів, посилання в робочий процес і межі подій із форків.
• GitHub, Secure use reference, Securely using pull_request_target, Compromised runners — права завдань автоматизації, неперевірений код, журнали й ризик скомпрометованого виконавця.
• GitHub, Remediating a leaked secret, Push protection, Workflow commands — відкликання, виявлення, маскування та обмеження очищення історії.
• OpenAI, API Authentication, Best Practices for API Key Safety, Assign API Key Permissions — вимоги лише до OpenAI API Platform, серверне зберігання та доступність обмеження ключа.
• Anthropic, Claude API Authentication, Workload Identity Federation — способи автентифікації саме Claude API, короткострокові посвідчення та їхні межі.
• OpenAI, Reviewing API usage and costs та Admin and Audit Logs API — відмінність між звітами про використання API та журналами адміністративних подій, зокрема життєвим циклом ключів; журнал аудиту треба ввімкнути окремо, а строк його зберігання не гарантований.
• Anthropic, Admin API та Compliance API — керування ключами й межі журналу активності залежно від типу організації та продукту.
• Spotless, Security notice #3089, вересень 2026 року — повідомлення супроводжувачів про розкриття токена в журналах через відмінність між закодованим і декодованим значенням; джерело є звітом власників проєкту.
• Updatecli, Security advisory GHSA-gc47-hwcc-8qp4, опубліковано 5 серпня 2026 року — приклад, коли конфіденційні дані автентифікації могли з’являтися у виводі окремих шляхів; опис уразливості не є доказом її експлуатації.
• [Розділ 3](03-terminal-local-environment-and-program-execution.md), [розділ 17](17-api-design.md), [розділ 28](28-instruction-hierarchy.md) і [розділ 35](35-mcp-for-claude.md) — середовище процесу, автентифікація API та відмінність між інструкціями й технічними правами.