Більшість порад на цю тему зводяться до запуску однієї команди. Це небезпечно. Успішний імпорт доводить лише те, що байти потрапили до сховища ключів, але не підтверджує, що ключ належить зазначеній особі, не прострочений і має використовуватися для підписання робочих артефактів. Команди, які розглядають операції GPG add key як рішення про довіру, уникають поширеної та дорогої помилки: побудови випусків, процесів доступу або підписаних комітів на неперевіреній ідентичності.
Зміст
- Чому «gpg add key» — це рішення про довіру, а не просто команда
- Імпорт ключів у Linux, macOS і Windows
- Перевірка відбитків, ідентифікаторів користувача та довіри
- Додавання підключів без ризику для основного ключа
- Публікація на серверах ключів, у WKD та Git-хостингу
- Підключення gpg add key до Git для підписаних комітів
- Автоматизація, CI-конвеєри та ізольовані сховища ключів
Чому «gpg add key» — це рішення про довіру, а не просто команда
Проблема не в GnuPG. Проблема — неперевірена довіра за замовчуванням: звичка копіювати команду з інструкції та сприймати нульовий код завершення як підтвердження ідентичності. Перед дією розділіть три запитання. Чи потрапив ключовий матеріал до потрібного сховища? Чи належить він заявленій особі або сервісу? Чи він досі дійсний, не відкликаний і обмежений відповідним завданням?
Операційна модель із семи кроків
Щоразу дотримуйтеся тієї самої послідовності — незалежно від того, чи підключаєте інженера, чи готуєте підписувача випусків.
- Імпорт: додайте публічний або секретний матеріал до відомого сховища ключів.
- Перелік: точно перевірте, що саме було додано.
- Перевірка: порівняйте повний відбиток через незалежний канал.
- Рішення про довіру: зафіксуйте, чому цей ключ прийнято та для якої сфери використання.
- Додавання підключів: за потреби створіть вузько призначені ключі для підписання або шифрування.
- Публікація: поширте публічний ключ через контрольований канал.
- Повторний експорт: оновлюйте копії після кожної зміни, щоб одержувачі не використовували застарілий матеріал.
Практичний висновок: вважайте кожен імпортований ключ недовіреним вхідним матеріалом, доки не перевірите його походження. Зберігання не є автентифікацією.
Ця дисципліна стосується й інших засобів контролю доступу. Так само як посібник із безпечного доступу для розробників відокремлює створення ключа від авторизації, процеси GPG мають відокремлювати імпорт від довіри. Такий самий підхід до зберігання активів застосовують у належно організованих практиках зберігання цифрових активів, де походження, закріплення відбитка та аудиторський журнал визначають, хто може діяти. Якщо ключ захищає рух коштів, випуски пакетів або частки відновлення, задокументуйте відбиток, власника, призначення, строк дії та особу, яка виконала перевірку, у своєму операційному посібнику. Не залишайте цей контекст в історії командної оболонки.
Імпорт ключів у Linux, macOS і Windows
Спочатку встановіть GnuPG через менеджер пакетів своєї платформи. У Debian або Ubuntu використайте sudo apt install gnupg. У macOS — brew install gnupg. У Windows установіть Gpg4win або пакет winget, а команди запускайте з PowerShell чи Git Bash.
Основні команди імпорту
Базова операція — gpg --import, яка додає або об’єднує публічні чи секретні ключі OpenPGP у локальному сховищі. Приклад імпорту в GNU Privacy Handbook використовує gpg --import blake.gpg, повідомляє ідентифікатор ключа, зазначає обробку 1 публічного ключа, підтверджує імпорт 1 ключа, а потім перевіряє його командою gpg --list-keys. Матеріал також можна передати через стандартний ввід, що корисно в скриптах, або отримати із сервера ключів за допомогою gpg --receive-keys.
Імпортовані ключі зберігаються в GNUPGHOME, зазвичай у ~/.gnupg. Публічний матеріал міститься у pubring.kbx, а приватний — у каталозі private-keys-v1.d. Якщо два термінали вказують на різні домашні каталоги, вони читатимуть різні сховища ключів. Тому ключ може здаватися відсутнім, хоча імпорт пройшов успішно.
Публічні та секретні ключі виконують різні завдання
Імпортуйте публічний ключ колеги, якщо потрібно лише шифрувати дані для нього або перевіряти його підписи. Секретний ключовий матеріал імпортуйте тільки на комп’ютері, який має підписувати або розшифровувати дані, і захищайте його обмежувальними дозволами, зашифрованим сховищем та окремим домашнім каталогом. Ніколи не розміщуйте секретний матеріал у спільному каталозі лише заради успішного виконання команди.
- Підтвердьте розташування: виконайте
echo $GNUPGHOMEтаgpg --list-keysдо і після імпорту. - Імпортуйте свідомо: використовуйте
gpg --import key.ascдля файлів або перевірений конвеєр для стандартного вводу. - Перевірте наявність секретної частини: запускайте
gpg --list-secret-keysлише там, де очікується секретний матеріал. - Тестуйте безпечно: для репетицій і відновлення спрямовуйте GNUPGHOME у тимчасовий каталог.
Перевірка відбитків, ідентифікаторів користувача та довіри
Імпорт може бути успішним навіть для шахрайського, простроченого або нерелевантного ключа. Під час перевірки ви вирішуєте, чи заслуговує цей матеріал на довіру. Почніть із gpg --fingerprint для перевірки людиною та gpg --list-keys --with-colons для записів, які ваша команда може перевірити.
Імпорт лише розміщує сертифікат у локальному сховищі ключів. Рекомендації GnuPG щодо перевірки відбитків радять порівнювати повний відбиток із власником ключа через незалежний канал і переконуватися у відповідності ідентичності та електронної адреси, перш ніж вважати ключ дійсним. Повідомлення про успішний імпорт не є підтвердженням безпеки, а завантаження із сервера ключів саме по собі не встановлює власника.
Оберіть канал перевірки, який зможете обґрунтувати
Використовуйте канал, який зловмиснику також довелося б скомпрометувати. Підписаний лист із уже відомої адреси, відбиток на контрольованому сайті, перевірена друга платформа або особиста звірка надійніші за повідомлення в тій самій гілці, де надіслали ключ. Зафіксуйте використаний канал. Для розповсюдження застосунків логіка подібна до захисту оновлень застосунків перевіркою підпису, де прийняття оновлення потребує більшого, ніж просто отримання підписаного файла.
Не плутайте дійсність із довірою до власника. Дійсність відповідає на запитання, чи прив’язаний ключ до заявленої ідентичності. Довіра до власника — чи компетентна ця особа засвідчувати ключі інших людей. Використовуйте gpg --edit-key і команду trust лише для другого рішення. Підписання ключа є сильнішою публічною заявою про те, що ви перевірили прив’язку ідентичності, тому не робіть цього легковажно. Ці відмінності також лежать в основі правильної моделі пари публічного та приватного ключів, де публікація ніколи не замінює перевірку.
Додавання підключів без ризику для основного ключа
Зберігайте основний ключ для сертифікації, а підключі використовуйте для щоденного підписання та шифрування. Таке розділення дає змогу замінити скомпрометований або прострочений підключ без заміни всієї ідентичності. Компонентів стає більше, але потенційна шкода зменшується.
Використовуйте повний відбиток
Спочатку перевірте ідентичність командою gpg --list-keys --with-subkey-fingerprint. Потім додайте один ключ із чітким призначенням, наприклад gpg --quick-add-key FINGERPRINT rsa4096 encr 1y або gpg --quick-add-key FINGERPRINT ed25519 sign 1y. Документація GnuPG з керування ключами OpenPGP використовує відбиток основного ключа, а не короткий ідентифікатор, а потім підтверджує результат командою gpg --list-keys --with-colons перед експортом і резервним копіюванням секретної частини.
Короткі ідентифікатори та електронні адреси зручні як селектори, але можуть вибрати неправильну ідентичність або не вибрати нічого. Скопіюйте повний відбиток із локального переліку, порівняйте його з перевіреним записом і лише тоді змінюйте ключ. Якщо не вказати алгоритм, призначення та строк дії, GnuPG створить стандартний підключ для шифрування, який може не відповідати вашій політиці.
- Одна можливість на підключ: використовуйте
signдля підписання, аencr— для шифрування замість поєднання ролей. - Явний строк дії: задайте відносне значення, наприклад
1y, або схвалену абсолютну дату й заплануйте заміну в календарі. - Опублікуйте зміну: одержувачі не зможуть використати новий підключ для шифрування, доки не отримають оновлений публічний ключ.
- Створіть резервну копію після зміни: негайно експортуйте оновлений секретний матеріал до захищеного офлайн-сховища.
Інтерактивний шлях через --edit-key і addkey досі працює, але в діалоговому режимі легше втратити контроль над вибором. Для повторюваної роботи швидкий інтерфейс зрозуміліший і простіший для перевірки.
Публікація на серверах ключів, у WKD та Git-хостингу
Розповсюдження робить ключ доступним для пошуку, але не підтверджує, що він належить вам. Обирайте канал з огляду на те, хто має знайти ключ, хто контролює основу довіри та як швидко повинні поширюватися відкликання або заміни.
| Канал | Команда розповсюдження | Основа довіри | Затримка відкликання |
|---|---|---|---|
| Публічний сервер ключів | gpg --keyserver keys.openpgp.org --send-keys FINGERPRINT | Незалежна перевірка відбитка | Може бути довгою, бо старі копії іноді зберігаються |
| Web Key Directory | gpg --export у контрольоване доменом розташування WKD | Контроль домену | Швидша, якщо оперативно замінити опублікований матеріал |
| Профіль Git-хостингу | gpg --armor --export FINGERPRINT, потім вставити в налаштування облікового запису | Контроль облікового запису хостингу | Залежить від оновлення облікового запису та відображення на платформі |
Публічні сервери ключів забезпечують широку доступність і просте отримання через gpg --receive-keys. Вони не перевіряють вашу юридичну особу, а застарілий чи відкликаний матеріал може залишатися доступним. Одержувачам однаково потрібна перевірка відбитка через інший канал.
Web Key Directory, або WKD, прив’язує пошук до домену, яким ви вже керуєте. Для корпоративних ключів електронної пошти це сильніший організаційний сигнал, але потрібно підтримувати опублікований пакет і оновлювати його після змін підключів. Git-хостинг має вужче призначення та зручний для перевірки комітів. GitHub, GitLab і подібні сервіси можуть пов’язати публічний ключ з обліковим записом, але захоплення цього запису послабить сигнал.
Для інституційних ключів надавайте перевагу контрольованому домену або внутрішньому сховищу артефактів, а потім закріплюйте відбиток у політиці. Використовуйте публічні сервери для зручного розповсюдження, а не як корінь довіри.
Підключення gpg add key до Git для підписаних комітів
Git дає змогу будь-кому локально встановити знайомі ім’я та електронну адресу. Підпис надає рецензентам криптографічне підтвердження, пов’язане з ключем, який вони можуть перевірити через платформу хостингу. Він не доводить якість коду й не замінює рев’ю.
Налаштуйте Git явно
Установіть ключ підписання на потрібний відбиток або ідентифікатор із перевіреного переліку. Потім задайте commit.gpgsign як true, gpg.format як openpgp, а gpg.program — якщо Git не знаходить потрібний виконуваний файл GnuPG. Типові команди: git config --global user.signingkey FINGERPRINT та git config --global commit.gpgsign true.
- Зіставте ідентичності: ваша електронна адреса Git має відповідати одному з ідентифікаторів користувача в ключі.
- Завантажте публічний ключ: додайте експорт у форматі ASCII armor до GitHub, GitLab або Bitbucket, перш ніж очікувати позначку перевірки.
- Перевірте локально: створіть підписаний коміт і перегляньте його через
git log --show-signature. - Підписуйте випуски окремо: використовуйте
git tag -sдля підписаних тегів, оскільки підписання комітів і тегів відповідає на різні запитання про випуск.
Більшість збоїв буденні. Не встановлено GPG_TTY, агент не може показати запит, строк дії підключа для підписання минув або Git використовує інше сховище. Перевірте gpg --list-secret-keys, дати завершення дії та середовище термінала, перш ніж щось генерувати заново. Підключі на апаратних пристроях можуть зменшити ризик, але додають вимоги до PIN-коду, фізичного дотику та доступності пристрою в щоденній розробці.
Автоматизація, CI-конвеєри та ізольовані сховища ключів
Автоматизація перетворює помилку з ключем на повторювану помилку ланцюга постачання. Конвеєр має питати не лише, чи успішно завершився імпорт, а й чи точні очікувані відбиток, можливість, ідентифікатор користувача та строк дії потрапили саме до того сховища ключів, яке використовує завдання.
Перетворіть підготовку середовища на контрольовану транзакцію
Для роботи без участі людини віддавайте перевагу швидкому інтерфейсу замість інтерактивних запитів. Рекомендації GnuPG щодо автоматичного створення ключів описують створення або імпорт основного ключа, отримання його повного відбитка, запуск gpg --batch --yes --quick-add-key FINGERPRINT ALGORITHM USAGE EXPIRY, перевірку результату в машинозчитуваному переліку, а потім експорт публічного ключа та резервне копіювання секретного матеріалу. Старіший шлях gpg --generate-key --batch для цього завдання вважається застарілим.
Використовуйте окремий GNUPGHOME для кожного завдання, клієнта або призначення підписання. Створюйте його з обмежувальними дозволами, імпортуйте лише потрібний завданню матеріал і видаляйте тимчасові секретні каталоги, якщо це дозволяє політика. У контейнерах не вбудовуйте секретні ключі в образи та не копіюйте весь каталог ~/.gnupg розробника до спільного середовища виконання. Обмежуйте облікові дані сервісів так само, як ключі API, а повноваження підписання — так само, як контрольований клієнтом Co-Signer або політика MPC обмежує, хто може схвалити дію.
| Завдання | Рекомендована команда | Обов’язкова перевірка |
|---|---|---|
| Перевірити артефакт постачальника | gpg --import публічного ключа до ізольованого каталогу | Закріплений відбиток, ідентифікатор користувача, строк дії, стан відкликання |
| Створити сервісний підключ | gpg --batch --yes --quick-add-key | Відбиток підключа, можливість і строк дії у переліку з двокрапками |
| Відновити підписувача | gpg --import секретного матеріалу до окремого каталогу | Перелік секретних ключів, дозволи, власник, запис про резервну копію |
Закріплюйте очікуваний відбиток у версіонованій політиці, а не в неперевіреній змінній збірки. Аналізуйте gpg --list-keys --with-colons, порівнюйте відбиток і строк дії та відмовляйте за замовчуванням у разі невідповідності. Перевіряйте коди завершення, але не робіть їх єдиним засобом контролю. Для паралельних процесів gpg-agent ізолюйте домашні каталоги та сокети, а парольні фрази не допускайте до історії оболонки й журналів. Якщо браузерний AI-агент або інший автоматизований учасник може запускати процеси, він однаково не повинен розширювати повноваження підписання без схвалення політикою.
Ризики та контроль до запуску
Основні ризики — підміна ключа, непомітний імпорт до неправильного сховища, випадковий імпорт секретного ключа, прострочені підключі та застарілі публічні копії. Контролюйте їх за допомогою закріплення відбитків, ізольованих домашніх каталогів, підключів із мінімальними можливостями, сповіщень про завершення строку, відпрацьованого оновлення, незмінних журналів і звірки схвалених відбитків із ключами, виявленими під час виконання. Цей операційний підхід подібний до правильної моделі контролю MPC-гаманця, де жодна успішна команда не надає необмежених повноважень. WebSocket-події, записи операційного журналу й ключі ідемпотентності розв’язують аналогічні аудиторські завдання в транзакційних системах, роблячи зміни стану видимими та безпечними для повторення.
У конвеєрі, який спочатку імпортує, а потім перевіряє, порядок дій неправильний.
Поширені запитання
Як безпечно додати ключ зовнішнього колеги? Імпортуйте його до відомого сховища, покажіть відбиток, порівняйте через незалежний канал, перевірте ідентифікатори користувача та строк дії й зафіксуйте рішення. Не надавайте довіру власнику лише тому, що збираєтеся шифрувати дані для цієї людини.
Чи можна розміщувати секретні ключі в спільних контейнерах? Ні. Для завдань перевірки віддавайте перевагу публічним ключам. Для підписання використовуйте окреме середовище виконання або контрольований шлях внесення секрету, вузько призначений підключ, суворі дозволи та короткий контрольований строк життя.
Що станеться, якщо імпортований ключ згодом відкличуть? Оновіть публічну копію, перевіряйте стан перед використанням і блокуйте процеси перевірки чи шифрування, доки не схвалите новий відбиток. Відкликання не допоможе, якщо системи нижче за потоком зберігають застарілі ключі в кеші.
Як перейти від сховища ключів на одному ноутбуці до керованого командного ключа? Заморозьте зміни, експортуйте та перевірте резервні копії, створіть підключі для сервісів із чітким призначенням, закріпіть відбитки в політиці, перевірте все в одноразових каталогах і поширте оновлені публічні ключі, перш ніж відмовлятися від старого шляху.
Bro has your back! Дотримуйтеся правильної послідовності довіри: імпорт не дорівнює довірі, довіра до власника не дорівнює дійсності, а підпис не означає схвалення підписаного вмісту.
BroLabel надає модульну криптоінфраструктуру, зокрема BroSettlement, BroWallet, гаманці для AI-агентів, MPC-підписання з контрольованим клієнтом Co-Signer, обмежені ключі API, WebSocket-події та звірку операційного журналу для команд, яким потрібен контроль ключів і транзакцій із можливістю аудиту. Якщо сьогодні GPG захищає ваші випуски, але робоче підписання, схвалення й відновлення потребують інституційного контролю, відвідайте BroLabel, щоб спроєктувати операційну модель до того, як обсяг змусить ухвалити рішення.
