Чому розробникам потрібні реальні політики контролю доступу (а не лише теорія)
Якщо ви надсилаєте код, підтримуючи pipelineабо керування реєстрами артефактів, вам потрібно більше, ніж теорія. Слабкі або невизначені політики контролю доступу призводять до втручання в репозиторії, CI/CD зловживання, та витоки облікових данихDevSecOps вимагає реального забезпечення дотримання правил, а не просто прихованих налаштувань дозволів.
Для ефективного керування політиками контролю доступу в різних репозиторіях коду, CI/CD pipelines, та реєстри артефактів, багато команд покладаються на автоматизовані інструменти забезпечення дотримання правил, такі як Xygeni. Завдяки постійному моніторингу ролей, дозволів та дотримання політик, Xygeni допомагає запобігти зміщенню дозволів, несанкціонованому доступу та ручному зміненню, перетворюючи теорію обов'язкового контролю доступу на практиці.
Контроль доступу безпосередньо блокує ваш вихідний код, захищає ваші збірки та захищає вашу продакшн-продукцію. pipelineЯкщо розробники обходять елементи керування або облікові записи служб мають широкі дозволи, ви відкриваєте двері для порушень безпеки. Ось чому розуміння обов’язкового контролю доступу, контролю доступу за MAC-адресами та інших моделей є критично важливим.
Типи політик контролю доступу, які повинні знати розробники
Політики контролю доступу поділяються на три основні категорії, кожна з яких по-різному відповідає CI/CD робочі процеси. Ось короткий побічний розбив для ясності:
| Модель | Хто контролює доступ? | Типове використання в CI/CD | Рівень ризику |
|---|---|---|---|
| DAC (Дискреційний контроль доступу) | Власник ресурсу (розробник, адміністратор) | Ручний обмін доступом до репозиторію або реєстру | Високий (людська помилка) |
| RBAC (керування доступом на основі ролей) | Система призначає дозволи за ролями | Захист гілок GitHub, доступ до завдань CI на основі ролей користувачів | Середній (неправильно налаштовані ролі) |
| MAC (обов'язковий контроль доступу) | Застосовується системною політикою | Визначає, хто може публікувати артефакти або розгортати код | Низький (політика має перевагу над наміром користувача) |
Уточнення MAC проти RBAC у CI/CD Контекст
Легко сплутати керування доступом на основі ролей (RBAC) з обов'язковим контролем доступу (контроль доступу MAC), особливо в CI/CD середовища. Хоча CI/CD Такі платформи, як GitHub та GitLab, використовують RBAC для керування ролями та дозволами (наприклад, хто може об'єднувати або розгортати), але це все ще фундаментально засноване на ролях, а не справжнє керування доступом за MAC-адресою.
RBAC дозволяє призначати дозволи на основі ролей (розробник, супроводжуючий тощо), але ці дозволи все ще контролюються користувачем і можуть бути змінені. Неправильні конфігурації або розповсюдження дозволів є поширеними ризиками.
Обов’язковий контроль доступу (контроль доступу за MAC-адресою), навпаки, застосовується на рівні системи або інфраструктури. Користувачі, включаючи адміністраторів, не можуть його змінити. Уявіть собі контроль доступу за Mac як політики, вбудовані в платформу: політики IAM у хмарних постачальниках (наприклад, AWS IAM, GCP IAM) або інструменти забезпечення дотримання правил на рівні ОС, такі як SELinux або AppArmor. У цих випадках доступ надається лише за умови дотримання попередньо визначених правил, які неможливо обійти.
In CI/CDБагато інструментів імітують поведінку контролю доступу за MAC-адресами за допомогою вузько обмежених ролей IAM або дозволів для окремих ресурсів, але це не повний обов'язковий контроль доступу. Справжнє забезпечення обов'язкового контролю доступу вимагає контролю нижче рівня програми, на рівні ОС, мережі або хмарної інфраструктури, де доступ регулюється незмінними політиками контролю доступу, а не конфігурацією, яку встановлює людина.
Контроль доступу на основі ролей (RBAC)
RBAC зіставляє дозволи з визначеними ролями, такими як «розробник», «супроводжуючий» або «менеджер релізів». Це спрощує управління в таких інструментах, як GitHub та GitLabЗамість налаштування кожного користувача окремо, призначте йому роль і дозвольте системі застосовувати правила.
приклад: Файл CODEOWNERS на GitHub
Це гарантує, що лише призначені ролі можуть затверджувати зміни в критично важливих каталогах.
Налаштування ролі GitLab: налаштуйте доступ до проекту в розділі Налаштування > Учасники:
- Розробник: Можна надсилати до гілок features.
- Обслуговувач: Може об'єднуватися в захищені гілки.
- Гість: Доступ лише для читання.
Приклад робочого процесу дій GitHub RBAC:
Обов'язковий контроль доступу (MAC)
Обов’язковий контроль доступу (контроль доступу за MAC-адресою) застосовує суворі правила на рівні системи, які користувачі та адміністратори не можуть змінити. Використовуйте контроль доступу за Mac-адресою. жорстко контролювати, хто може читати, записувати або виконувати критично важливі ресурси.
приклад: Політика реєстру артефактів Google (спрощений YAML)
приклад: Політика Amazon ECR (спрощена YAML)
Ризики ручного керування та як MAC їм запобігає
Один з найбільших ризиків, пов'язаних з RBAC, та Моделі ЦАП існує потенціал для навмисного або випадкового ручного перевизначення. Наприклад, адміністратор або розробник може безпосередньо завантажувати артефакти до захищеного реєстру або надавати надмірні дозволи поза визначеними політиками контролю доступу. Ці дії можуть створювати вразливості або спричиняти прогалини у відповідності.
Обов'язковий контроль доступу (контроль доступу за MAC-адресою) запобігає таким змінам, застосовуючи політики на рівні системи, які жоден користувач, навіть адміністратори, не може обійти.cisІони регулюються незмінними правилами, вбудованими в інфраструктуру (наприклад, політиками хмарної IAM або модулями безпеки на рівні ОС). Це означає:
- Адміністратор не може вручну завантажувати артефакти до реєстру, якщо політика контролю доступу Mac забороняє їх.
- Користувачі не можуть підвищувати привілеї або змінювати дозволи поза межами визначених політик контролю доступу.
- Автоматизований CI/CD pipelineвиконуються суворо в межах призначених їм дозволів, запобігаючи розширенню області доступу.
Завдяки усуненню ручного керування, обов'язковий контроль доступу забезпечує сильнішу та надійнішу систему безпеки, ніж лише RBAC або DAC.
2.4 Дискреційний контроль доступу (DAC)
DAC дозволяє власникам ресурсів вручну призначати дозволи. Це гнучко, але ризиковано. Один неправильний спільний доступ може поставити під загрозу репозиторій. DAC працює за принципом: «Ви володієте ним, ви вирішуєте, хто входить».
Приклад: розробник запрошує зовнішнього співавтора та надає йому доступ для запису в репозиторій. Співавтор надсилає незахищений код безпосередньо до DEV філія
In CI/CDDAC може виглядати так, ніби розробник вручну надає тимчасовому члену команди доступ до розгортання в робочому середовищі через консоль, поза межами будь-якої визначеної політики контролю доступу.
Як вибрати політику контролю доступу, яка працює в реальних умовах Pipelines
Контроль доступу в Git
Використовуйте RBAC для керування ролями учасників, розробників та випускників. Заблокуйте права злиття для захищених гілок. Вимагайте підписаних елементів. commitта обмежити, хто може обходити захист.
Приклад: Правила захисту гілок GitHub
- Вимагати pull request огляди перед об'єднанням.
- Відхилити застаріле pull request схвалення, коли нові commits штовхаються.
- Вимагати підпису commits.
- Пропускайте DAC для критично важливих для виробництва репозиторіїв. Не роздавайте права на запис без розбору.
Pipeline правозастосування
Встановити обов'язковий контроль доступу для pipelines. Надійна модель контролю доступу Mac обмежує завдання неперервної інтеграції лише тими дозволами, які їм потрібні.
- Розділіть секрети за середовищем.
- Використовуйте унікальні токени для кожного середовища.
- Запобігайте впливу ручних виконань на виробництво.
приклад: Завдання CI повторно використовує токен розгортання в проміжній та пробній версіях, випадково публікуючи тестовий код.
Додайте правила контролю доступу Mac для керування областю дії токенів:
Приклад визначення області видимості секретів: використання токена, специфічного для середовища
Правильне визначення області охоплення секретів за середовищем є критично важливим для запобігання випадковому або зловмисному доступу з різних середовищ. Наприклад, токен розгортання для середовища розробки ніколи не повинен бути придатним для розгортання у продакшені.
Ось як елементи керування на основі політик доступу ізолюють використання секретних даних у діях GitHub:
Це забезпечує виконання наступного:
- Тільки ті розробник роль може запускати розгортання, використовуючи токен розробника на DEV філія
- Тільки ті менеджер релізів роль може розгортатися у продакшені, використовуючи токен prod на основний філія
Таке обмежене використання секрету зменшує ризик поширення витоків токенів у різних середовищах та забезпечує найменші привілеї в CI/CD pipelines дотримуючись суворих політик контролю доступу.
Контроль доступу до артефактів
Блокуйте реєстри артефактів за допомогою обов'язкового контролю доступу. CI/CD системи повинні займатися публікацією, а не окремі розробники.
Використовуйте RBAC, щоб визначити, які команди отримують дані з певних реєстрів. Розробникам може знадобитися доступ лише для читання до виробничих пакетів.
Поширені збої контролю доступу в робочих процесах розробки
Надмірно дозвільний доступ до репозиторію
Проблема: Надання занадто великої кількості користувачів доступу для запису/адміністратора до репозиторіїв.
Як це відбувається: Членів команди підвищують або додають без перевірки дозволів. Ролі стають перевантаженими.
Експлойт зловмисника: Зловмисники атакують ці облікові записи, використовуючи викрадені облікові дані або соціальну інженерію. Потрапивши всередину, вони можуть впроваджувати шкідливий код, створювати бекдори або видаляти історію, щоб приховати сліди.
Спільні дозволи між розробником та продакшеном
Проблема: Здається розробник та продакшн pipelineдозволи на спільний доступ.
Як це відбувається: Команди повторно використовують той самий токен розгортання або обліковий запис служби CI в різних середовищах.
Експлойт зловмисника: Порушення середовища розробки надає зловмисникам доступ до виробничого середовища. Обов'язковий контроль доступу можна запобігти цьому, прив'язавши дозволи до певних середовищ.
Ручне завантаження артефактів
Проблема: Дозвіл на ручне завантаження артефактів до виробничих реєстрів.
Як це відбувається: Обхід розробників pipelineдля швидких виправлень або гарячих патчів.
Експлойт зловмисника: Скомпрометовані машини розробників можуть завантажувати шкідливе програмне забезпечення безпосередньо до сховища артефактів, минаючи всі CI/CD перевірки безпеки.
Ризик зловживання політикою реєстру: Ручна публікація артефактів створює критичну поверхню для атаки в ланцюжку постачання програмного забезпечення. Зловмисники використовують слабкі політики контролю доступу може вставляти шкідливий код у довірені пакети або образи контейнерів, що призводить до широкомасштабного компрометування даних. Нещодавні інциденти в ланцюжку постачання програмного забезпечення показали, як нерегульоване завантаження артефактів може швидко перерости у серйозні порушення безпеки, впливаючи на незліченну кількість користувачів і систем.
Приклад: аСтажер з повним доступом до реєстру npm помилково публікує нестабільну версію. Якби зловмисник скомпрометував машину цього стажера, він міг би замість цього опублікувати шкідливе програмне забезпечення.
Практичні кроки для забезпечення жорсткого контролю доступу
- Зіставте ролі з точними дозволами, відмовтеся від налаштувань "одна роль підходить усім"
- Автоматизуйте перевірки політик контролю доступу у вашому CI/CD pipelines
- Блокування реєстрів з обов'язковим контролем доступу
- Безперервно реєструвати та контролювати доступ до критично важливих систем
- Ставтеся до політик контролю доступу як до коду. Кожну помилку можна використати.
Роль Xygeni: Забезпечення та моніторинг політик доступу в робочих процесах DevOps
Ксігені допомагає вам перетворити обов'язковий контроль доступу з теорії на дію, вирішуючи реальні, щоденні проблеми забезпечення дотримання політик контролю доступу в DevSecOps pipelines.
- Вирішення проблеми з надмірним доступом до Git: Xygeni постійно відстежує репозиторії Git на наявність порушень RBAC, таких як неперевірені призначення ролей або відсутні захисти гілок. Він попереджає, коли політики контролю доступу відхиляються від визначених правил, і застосовує коригувальні дії, щоб уникнути випадкових злиттів або зловмисних запитів на доступ (PR).
- Блокування CI/CD Pipelines: Завдання CI іноді виконуються з ширшими обсягами, ніж передбачалося. Xygeni виявляє, коли CI/CD завдання запитують або виконують дії поза межами призначених їм ролей, виявляючи розширення області застосування та зловживання привілеями в режимі реального часу. Це допомагає забезпечити дотримання принципів контролю доступу за MAC-адресами всередині pipelineшляхом суворого прив'язування доступу до ідентичності та мети роботи.
- Забезпечення контролю над публікацією артефактів: Якщо розробники все ще вручну завантажують артефакти чи зображення, Xygeni цьому покладає край. Він застосовує обов'язковий контроль доступу на рівні реєстру, щоб реєструвалися лише перевірені pipeline ідентифікатори можуть публікувати артефакти. Більше жодного завантаження людьми до виробничих реєстрів.
- Моніторинг доступу та позначення аномалій: За допомогою Xygeni ви отримуєте уявлення про те, хто, коли та як отримував доступ до чого. Xygeni постійно відстежує використання секретів, доступ до репозиторію та взаємодію з реєстром, щоб виявляти незвичайну поведінку, позначати неправильні конфігурації та допомагати з аналізом після інцидентів.
Підсумок: Xygeni забезпечує автоматизацію та забезпечення дотримання правил контролю доступу, щоб ваше середовище DevOps залишалося безпечним, не уповільнюючи вашу роботу.
Отже, ставтеся до контролю доступу як до Code Security
Будь-хто з правами на розгортання або доступом до інфраструктури може випадково чи ні зламати ваш застосунок. Саме тому надійна політика контролю доступу не є необов'язковою. Використовуйте RBAC для належного делегування ролей. Застосовуйте обов'язковий контроль доступу до критично важливих систем. Повністю пропустіть DAC для виробничих шляхів. Вбудуйте політики контролю доступу у свій Найкращі практики DevSecOps. Автоматизуйте їх. Контролюйте їх. Забезпечте їх виконання.
TL, д-рДобре впроваджена політика контролю доступу автоматично робить вашу кодову базу, артефакти та інфраструктуру безпечнішими.
