SOPS and Secret Management: English for GitOps Security Workflows (англійською)

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

Ключовий словник

** SOPS (Secrets OPerationS) ** — інструмент, який шифрує секретні файли (YAML, JSON, ENV тощо), щоб їх можна було безпечно перенести до сховища Git. Інженери називають його просто «SOPS» (вимовляється як слово «sops») і кажуть «ми шифруємо з SOPS» або «файл зашифрований SOPS»

«Ми зберігаємо всі наші секрети Kubernetes в SOPS-зашифрованих YAML-файлах в репозиторії. Будь-хто з правим ключем KMS може розшифрувати локально, але GitHub бачить тільки шифрований текст»

** Шифрування конвертів ** — двошаровий шаблон шифрування, за якого ваш справжній секрет зашифровано за допомогою ключа шифрування даних (DEK), а цей DEK зашифровано за допомогою ключа керування ключами (KEK). SOPS використовує цей підхід. Інженери кажуть: «SOPS використовує шифрування конвертів» або «ключ даних обгортається головним ключем»

«Шифрування конвертів означає, що ви ніколи не відкриваєте головний ключ для програми — ви використовуєте його для розгортання ключа даних, а ключ даних робить фактичне розшифрування. Це чисте розділення турбот»

** Служба керування ключами (KMS) ** — керована служба (AWS KMS, GCP KMS, Azure Key Vault), яка зберігає і контролює криптографічні ключі. Інженери кажуть: « ми використовуємо KMS для підтримки SOPS » або « головний ключ знаходиться у KMS ». Часто використовується як прикметник: « шифрування за допомогою KMS »

«Ми налаштували SOPS для використання AWS KMS як кореня довіри — ключ шифрування ніколи не залишає KMS, тому навіть якщо репозиторій витікає, нападник все ще потребує доступу до AWS для розшифровки»

** age encryption ** — сучасний, простий засіб шифрування (вимовляється як англійське слово « age »), який часто використовується у SOPS як альтернатива PGP. Інженери кажуть « ми використовуємо старі ключі » або « команда перейшла з PGP на старі ключі ». Зауважте, що малі літери — це справжня назва інструменту.

«Ми перейшли від PGP до вікових для локальних ключів розробників, тому що управління ключами набагато простіше — немає ключового ланцюжка, немає проблем з gpg-агентом, просто файл пари ключів»

** Ключ PGP ** — ключі Pretty Good Privacy, це старий стандарт шифрування, який досі використовується у SOPS. Ви почуєте « Зашифровано за допомогою PGP », « Підписати за допомогою вашого ключа PGP » або « У налаштуваннях SOPS наведено список одержувачів PGP ». Вимовляється за допомогою букв: « P- G- P. »

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

** Ротація секретів ** — практика регулярної заміни секретів (паролів, ключів API, токенів) новими значеннями, щоб обмежити вплив потенційного витоку інформації. Інженери кажуть «ми змінюємо секрети», «примушуємо змінювати», або «секрет застарів для зміни»

«Після порушення, ми негайно поміняли всі секрети, які були в обсязі — паролі бази даних, API-ключі, роботи. Налаштування SOPS зробило це простим, тому що ми просто перешифровуємо з новими значеннями»

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

Однією з переваг SOPS, що підтримується KMS, є те, що кожен виклик розшифровки з’являється в CloudTrail — у вас є повний слід аудиту того, хто розшифрував який секрет і коли

** Зашифровані секрети у сховищі ** — шаблон GitOps зберігання зашифрованих секретів безпосередньо у сховищі Git. Інженери описують це як «секрети в репо» або «управління секретами в репо», контрастуючи його з зовнішніми секретними магазинами.

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

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

«Кожне середовище має свій власний ключ KMS, а ролі CI/CD мають тільки доступ до розшифрування ключа для їхнього середовища — це підхід з найменшими привілеями»

** Розповсюдження секретів ** — проблема розкидання секретів у багатьох місцях (локальні файли, параметри CI/ CD, повідомлення Slack, твердо закодовані у коді), що ускладнює їх відстеження і обертання. Інженери кажуть «ми маємо таємне розширення» або «SOPS допомагає нам вирішити розширення»

«До того, як ми прийняли SOPS, у нас було жахливе секретне розширення — деякі речі були в Vault, деякі в секретах GitHub Actions, деякі в спільній папці LastPass. Неможливо було провести аудит»

** Контекст розшифрування ** — додаткові метадані, передані до KMS під час шифрування і розшифрування, які мають збігатися, додаючи додатковий шар захисту від неправильного використання ключа. Інженери кажуть «ми включаємо контекст розшифровки» або «контекст повинен збігатися»

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

Фрази в контексті

** Пояснення налаштування SOPS у процесі впровадження або перегляду: **

«Спосіб, в який ми працюємо з секретами: все живе в репозиторії як SOPS-зашифровані файли. Вам потрібно, щоб ваш ключ віку був доданий до конфігурації .sops.yaml іншим інженером, а потім sops -d розшифрує його локально для вас. У CI, роль KMS обробляє розшифрування автоматично.”

** Позначення проблеми безпеки в обзоре PR: **

“Я бачу, що цей PR додає ключ API безпосередньо в ConfigMap. Можемо пересунути це в файл секретів, зашифрований SOPS? Прості текстові реквізити в репозиторії є важким блокатором для нас — навіть у внутрішніх репозиторіях»

** Обговорення секретної ротації в ретроспективі:**

“Як наслідок цього інциденту, я пропоную нам задокументувати графік роботи для таємного обертання і встановити календарні нагадування для будь-яких даних, які не автоматично обертаються. Шлях аудиту в CloudTrail розповість нам, коли кожен ключ був останній раз повернутий

** Підвищення найменших привілеїв у обговоренні архітектури: **

« Обліковий запис служби має адміністративний доступ до всього ланцюжка ключів KMS, що є більшим, ніж потрібно. Можемо ми обмежити його лише двома ключами, які використовує ця служба? Ми хочемо застосовувати найменші привілеї послідовно по всіх наших облікових записах сервісу»

Ключові слова

• ** передавати зашифровані секрети ** до сховища (не « відсилати секрети »)
• ** обертати таємницю ** / ** викликати обертання ** (не « змінювати таємницю »)
• ** audit trail ** (майже завжди ці два слова разом, а не « журнал аудиту » у контексті відповідності — хоча існують обидва)
• ** кореневий ключ довіри ** — останній авторитет у ієрархії ключів: « KMS є кореневим ключем довіри »
• ** secret plaintext ** — незашифровані уповноваження: « no plaintext secrets in the repository »
• ** розширити / зменшити обсяг** прав — надає більше або менше прав: « зменшити обсяг ролі IAM »
• ** у сфері дії ** — стосується інциденту з безпекою: « всі дані реєстрації у сфері дії було змінено »
• ** жорсткий блокувальник ** — щось, що слід виправити перед об’ єднанням/ надсиланням: « звичайні текстові дані реєстрації є жорстким блокувальником »

Practice

Знайдіть публічне сховище, яке використовує SOPS — пошук GitHub для .sops.yaml, щоб знайти приклади. Прочитайте README і будь- яку пов’ язану з ним документацію щодо налаштування командою секретів. Потім напишіть коротке (від п’ яти до восьми речень) пояснення щодо вступу, так само, як ви пояснювали б роботу з секретами новому члену команди у повідомленні Slack. Використовуйте принаймні п’ ять слів з цього матеріалу. Зверніть увагу на те, чи пишете ви « ми змінюємо секрети » або « ми змінюємо секрети » — ці маленькі слова сигналізують вільність рідним носієм і повідомляють їм, чи ви справді знаєте домен.