Вступ
Управління привілейованим доступом до хмарних середовищ є основою безпеки та відповідності вимогам для сучасних організацій. Як тільки організації починають масштабуватись і досягати сертифікацій, таких як SOC2, стає необхідним посилення контролю доступу до виробничих і клієнтських ресурсів. Це часто призводить до напруження між командами SRE та розробниками, оскільки обмеження привілейованих дозволів порушує встановлені правила доступу для розробників. Я бачив, як команди використовують власні інструменти для надання тимчасового доступу, дозволяючи розробникам та інженерам тимчасово отримувати підвищені дозволи. Хоча ці інструменти можуть бути ефективними, вони часто не мають структурованих процесів схвалення та залежать від ручного нагляду, що призводить до потенційних проблем з безпекою. Centrify стверджує, що 74% витоків даних пов'язані з неналежним використанням привілейованих облікових даних (https://www.helpnetsecurity.com/2019/02/28/privileged-credential-abuse/?utm_source=chatgpt.com).
У цьому пості ми розглянемо, як Just-In-Time (JIT) привілейований доступ у GCP пропонує більш безпечний, масштабований та аудиторний підхід до керування доступом до виробничих ресурсів.
Старий підхід: Використання облікових записів служб
Як це працювало:
- Користувачі активували привілейовані ролі за допомогою інструменту, часто вказуючи причину доступу (наприклад, налагодження або розгортання коду).
- Сповіщення надсилались до каналів Slack для інформування команд про запити на доступ за допомогою інструменту, такого як Chirp.
- Доступ був тимчасовим і автоматично закривався після певного періоду.
Обмеження:
- Відсутність схвалень: Доступ міг надаватися без схвалення колег, що робило його вразливим до зловживань.
- Втома від сповіщень: Сповіщення було легко пропустити, особливо в каналах Slack з високим трафіком.
- Прогалини в аудиті: Хоча журнали фіксувались, відслідкувати дії до конкретних інцидентів часто вимагало ручної роботи.
- Глобальні дозволи: Доступ не можна було обмежити до конкретних ресурсів, що призводило до занадто широких дозволів.
Модель Just-In-Time (JIT)
JIT привілейований доступ пропонує сучасну альтернативу, засновану на політиках. Відповідно до принципів найменших привілеїв та нульового довіри, JIT забезпечує тимчасовий доступ з чіткими аудитами та процесами схвалення. Користувачам надається лише той доступ, який необхідний для виконання конкретних завдань.
Переваги:
- запобігання випадковому зміненню або видаленню ресурсів
- створення аудиторського сліду
- закриття доступу після виконання завдання
- вимога схвалення перед виконанням завдань… це може бути налаштовано на попередньо визначений список схвалювачів, в нашому випадку — схвалення від керівника інженерії та члена команди SRE/Staff.
- гранульовані дозволи
Як працює JIT:
- Допустимі прив'язки ролей: Користувачам надаються ролі з особливими умовами, такими як
has({}.jitAccessConstraint)
, що робить їх придатними для активації. - Самостійне схвалення: Користувачі можуть активувати попередньо визначені ролі для нижчих середовищ без необхідності зовнішнього схвалення.
- Мультипартійне схвалення: Для вищих середовищ потрібне схвалення колег перед наданням доступу.
- Тимчасовий доступ: Доступ автоматично деактивується після вказаного часу, зменшуючи поверхню для атак.
Реалізація в GCP
JIT реалізується як додаток на основі Java, що працює на Google App Engine з використанням Identity-Aware Proxy (IAP) для аутентифікації.
Вступ
Управління привілейованим доступом до хмарних середовищ є основою безпеки та відповідності вимогам для сучасних організацій. Як тільки організації починають масштабуватись і досягати сертифікацій, таких як SOC2, стає необхідним посилення контролю доступу до виробничих і клієнтських ресурсів. Це часто призводить до напруження між командами SRE та розробниками, оскільки обмеження привілейованих дозволів порушує встановлені правила доступу для розробників. Я бачив, як команди використовують власні інструменти для надання тимчасового доступу, дозволяючи розробникам та інженерам тимчасово отримувати підвищені дозволи. Хоча ці інструменти можуть бути ефективними, вони часто не мають структурованих процесів схвалення та залежать від ручного нагляду, що призводить до потенційних проблем з безпекою. Centrify стверджує, що 74% витоків даних пов'язані з неналежним використанням привілейованих облікових даних (https://www.helpnetsecurity.com/2019/02/28/privileged-credential-abuse/?utm_source=chatgpt.com).
У цьому пості ми розглянемо, як Just-In-Time (JIT) привілейований доступ у GCP пропонує більш безпечний, масштабований та аудиторний підхід до керування доступом до виробничих ресурсів.
Старий підхід: Використання облікових записів служб
Як це працювало:
- Користувачі активували привілейовані ролі за допомогою інструменту, часто вказуючи причину доступу (наприклад, налагодження або розгортання коду).
- Сповіщення надсилались до каналів Slack для інформування команд про запити на доступ за допомогою інструменту, такого як Chirp.
- Доступ був тимчасовим і автоматично закривався після певного періоду.
Обмеження:
- Відсутність схвалень: Доступ міг надаватися без схвалення колег, що робило його вразливим до зловживань.
- Втома від сповіщень: Сповіщення було легко пропустити, особливо в каналах Slack з високим трафіком.
- Прогалини в аудиті: Хоча журнали фіксувались, відслідкувати дії до конкретних інцидентів часто вимагало ручної роботи.
- Глобальні дозволи: Доступ не можна було обмежити до конкретних ресурсів, що призводило до занадто широких дозволів.
Модель Just-In-Time (JIT)
JIT привілейований доступ пропонує сучасну альтернативу, засновану на політиках. Відповідно до принципів найменших привілеїв та нульового довіри, JIT забезпечує тимчасовий доступ з чіткими аудитами та процесами схвалення. Користувачам надається лише той доступ, який необхідний для виконання конкретних завдань.
Переваги:
- запобігання випадковому зміненню або видаленню ресурсів
- створення аудиторського сліду
- закриття доступу після виконання завдання
- вимога схвалення перед виконанням завдань… це може бути налаштовано на попередньо визначений список схвалювачів, в нашому випадку — схвалення від керівника інженерії та члена команди SRE/Staff.
- гранульовані дозволи
Як працює JIT:
- Допустимі прив'язки ролей: Користувачам надаються ролі з особливими умовами, такими як
has({}.jitAccessConstraint)
, що робить їх придатними для активації. - Самостійне схвалення: Користувачі можуть активувати попередньо визначені ролі для нижчих середовищ без необхідності зовнішнього схвалення.
- Мультипартійне схвалення: Для вищих середовищ потрібне схвалення колег перед наданням доступу.
- Тимчасовий доступ: Доступ автоматично деактивується після вказаного часу, зменшуючи поверхню для атак.
Реалізація в GCP
JIT реалізується як додаток на основі Java, що працює на Google App Engine з використанням Identity-Aware Proxy (IAP) для аутентифікації.
Для детальнішої інформації з установкою зверніться до цього простого посібника, зверніть увагу, що JIT розділено на JIT Groups, що є платною преміум-версією, або JIT Access, підхід, який ми розглядаємо:
[
Огляд - JIT Groups
JIT Access - це додаток з відкритим вихідним кодом, який дозволяє впровадити привілейований доступ за принципом Just-In-Time до Google Cloud…
googlecloudplatform.github.io
](https://googlecloudplatform.github.io/jit-groups/jitaccess-overview/?source=post_page-----1c8a42fe0526--------------------------------)
Процес роботи JIT Groups
Для процесу роботи користувачі обирають роль, список заздалегідь призначених схвалювачів та необхідний квиток JIRA/причину запиту. Можливість вибору схвалювачів дозволяє європейським розробникам обирати лише співробітників/керівників відділів та членів SRE з європейського боку для швидшого схвалення.
Кроки:
- Після того як ви слідуєте вказівкам вище та встановлюєте JIT Access на додаток на Google App Engine з підключенням IAP, потрібно призначити правильні дозволи JIT для всіх бажаних проектів.
resource "google_project_iam_member" "jit_project_iam" {
project = google_project.project.project_id
role = "roles/resourcemanager.projectIamAdmin"
member = "serviceAccount:"
}
- Створіть нові групи, ми створили одну для розробників і одну для списку схвалювачів. У групі розробників ми призначили дозволи на ролі для нашої організації розробників і надали дозволи на наступні ролі (*зауважте умову hasconstraint, яка потрібна для JIT. Це надає тимчасовий доступ до ролі).
resource "google_folder_iam_binding" "jit_developers_roles" {
folder = "folders/xxxxxxxxxxxxx"
for_each = toset([
"organizations/xxxxxxxxxxx//roles/bucket_read_access",
"organizations/xxxxxxxxxxx//roles/bucket_write_access",
"organizations/xxxxxxxxxxx//roles/portforward_service",
"organizations/xxxxxxxxxxx//roles/database_access",
"organizations/xxxxxxxxxxx/cronjob_trigger",
"roles/secretmanager.secretVersionAdder",
"roles/secretmanager.secretAccessor",
"roles/cloudkms.cryptoKeyEncrypterDecrypter"
])
role = each.key
members = [
"group:",
]
condition {
title = "JIT"
description = "JIT Developer Roles"
expression = "has({}.jitAccessConstraint)"
}
}
Це повинно виглядати ось так:
Виклики та аспекти, які варто врахувати
Хоча JIT покращує безпеку, деякі виклики залишаються:
- Обмеження на рівні ресурсів: Поточні реалізації працюють на рівні ролей, що може надавати доступ до більш широких ресурсів, ніж це необхідно (наприклад, доступ до всіх кошиків замість одного конкретного).
- Гнучкість процесу схвалення: За замовчуванням схвалення здійснюються через електронну пошту, відсутні інтеграції з Slack або системами квитків.
- Надання дозволів через групи: Ролі IAM, призначені групам, застосовуються до всіх членів групи, що може не відповідати принципу найменших привілеїв.
Організації повинні доповнювати JIT іншими заходами, такими як:
- Визначення більш точних політик IAM там, де це можливо.
- Використання Cloud Audit Logs та BigQuery для розширеного моніторингу.
- Автоматизація процесів схвалення через API або спеціальні інтеграції.
Для детальнішої інформації з установкою зверніться до цього простого посібника, зверніть увагу, що JIT розділяється на JIT Groups, що є платною преміум-версією, або JIT Access, підхід, який ми розглядаємо:
[
Огляд - JIT Groups
JIT Access - це додаток з відкритим вихідним кодом, який дозволяє впровадити привілейований доступ за принципом Just-In-Time до Google Cloud…
googlecloudplatform.github.io
](https://googlecloudplatform.github.io/jit-groups/jitaccess-overview/?source=post_page-----1c8a42fe0526--------------------------------)
Процес роботи JIT Groups
У процесі роботи користувачі обирають роль, список заздалегідь призначених схвалювачів та необхідний квиток JIRA/причину запиту. Можливість вибору схвалювачів дозволяє європейським розробникам обирати лише співробітників/керівників відділів та членів SRE з європейського боку для швидшого схвалення.
Кроки:
- Після того як ви слідуєте вказівкам вище та встановлюєте JIT Access на додаток на Google App Engine з підключенням IAP, потрібно призначити правильні дозволи JIT для всіх бажаних проектів.
resource "google_project_iam_member" "jit_project_iam" {
project = google_project.project.project_id
role = "roles/resourcemanager.projectIamAdmin"
member = "serviceAccount:"
}
- Створіть нові групи, ми створили одну для розробників і одну для списку схвалювачів. У групі розробників ми призначили дозволи на ролі для нашої організації розробників і надали дозволи на наступні ролі (*зауважте умову hasconstraint, яка потрібна для JIT. Це надає тимчасовий доступ до ролі).
resource "google_folder_iam_binding" "jit_developers_roles" {
folder = "folders/xxxxxxxxxxxxx"
for_each = toset([
"organizations/xxxxxxxxxxx//roles/bucket_read_access",
"organizations/xxxxxxxxxxx//roles/bucket_write_access",
"organizations/xxxxxxxxxxx//roles/portforward_service",
"organizations/xxxxxxxxxxx//roles/database_access",
"organizations/xxxxxxxxxxx/cronjob_trigger",
"roles/secretmanager.secretVersionAdder",
"roles/secretmanager.secretAccessor",
"roles/cloudkms.cryptoKeyEncrypterDecrypter"
])
role = each.key
members = [
"group:",
]
condition {
title = "JIT"
description = "JIT Developer Roles"
expression = "has({}.jitAccessConstraint)"
}
}
Це повинно виглядати ось так:
Виклики та аспекти, які варто врахувати
Хоча JIT покращує безпеку, деякі виклики залишаються:
- Обмеження на рівні ресурсів: Поточні реалізації працюють на рівні ролей, що може надавати доступ до більш широких ресурсів, ніж це необхідно (наприклад, доступ до всіх кошиків замість одного конкретного).
- Гнучкість процесу схвалення: За замовчуванням схвалення здійснюються через електронну пошту, відсутні інтеграції з Slack або системами квитків.
- Надання дозволів через групи: Ролі IAM, призначені групам, застосовуються до всіх членів групи, що може не відповідати принципу найменших привілеїв.
Організації повинні доповнювати JIT іншими заходами, такими як:
- Визначення більш точних політик IAM там, де це можливо.
- Використання Cloud Audit Logs та BigQuery для розширеного моніторингу.
- Автоматизація процесів схвалення через API або спеціальні інтеграції.
Перекладено з: Goodbye Persistent IAM : Ephemeral Access control with GCP JIT Access