GCP - Logging Enum

Підтримайте HackTricks

Основна інформація

Цей сервіс дозволяє користувачам зберігати, шукати, аналізувати, контролювати та сповіщати про дані журналу та події з GCP.

Cloud Logging повністю інтегрований з іншими службами GCP, надаючи централізований сховище для журналів з усіх ваших ресурсів GCP. Він автоматично збирає журнали з різних служб GCP, таких як App Engine, Compute Engine та Cloud Functions. Ви також можете використовувати Cloud Logging для додатків, що працюють в офісі або в інших хмарах, використовуючи агент або API Cloud Logging.

Основні функції:

  • Централізація даних журналу: Агрегуйте дані журналу з різних джерел, пропонуючи всебічний погляд на ваші додатки та інфраструктуру.

  • Управління журналами в реальному часі: Потік журналів в реальному часі для негайного аналізу та реагування.

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

  • Інтеграція з BigQuery: Експортуйте журнали в BigQuery для детального аналізу та запитування.

  • Метрики на основі журналів: Створюйте власні метрики на основі даних журналу для моніторингу та сповіщення.

Потік журналів

По суті, стоки та метрики на основі журналів визначають, де слід зберігати журнал.

Конфігурації, підтримувані GCP Logging

Cloud Logging має високу налаштовуваність для відповідності різноманітним операційним потребам:

  1. Бакети журналів (Зберігання журналів в мережі): Визначте бакети в Cloud Logging для управління збереженням журналів, надаючи контроль над тим, як довго зберігаються ваші записи журналу.

  • За замовчуванням створюються бакети _Default та _Required (один реєструє те, що інший - ні).

  • _Required є:

LOG_ID("cloudaudit.googleapis.com/activity") OR LOG_ID("externalaudit.googleapis.com/activity") OR LOG_ID("cloudaudit.googleapis.com/system_event") OR LOG_ID("externalaudit.googleapis.com/system_event") OR LOG_ID("cloudaudit.googleapis.com/access_transparency") OR LOG_ID("externalaudit.googleapis.com/access_transparency")
  • Період збереження даних налаштовується для кожного бакета і повинен бути принаймні 1 день. Однак період збереження _Required становить 400 днів і не може бути змінений.

  • Зверніть увагу, що бакети журналів не видимі в Cloud Storage.

  1. Стоки журналів (Маршрутизатор журналів в мережі): Створюйте стоки для експорту записів журналу до різних місць призначення, таких як Pub/Sub, BigQuery або Cloud Storage на основі фільтра.

  • За замовчуванням створюються стоки для бакетів _Default та _Required:

_Required logging.googleapis.com/projects//locations/global/buckets/_Required LOG_ID("cloudaudit.googleapis.com/activity") OR LOG_ID("externalaudit.googleapis.com/activity") OR LOG_ID("cloudaudit.googleapis.com/system_event") OR LOG_ID("externalaudit.googleapis.com/system_event") OR LOG_ID("cloudaudit.googleapis.com/access_transparency") OR LOG_ID("externalaudit.googleapis.com/access_transparency") _Default logging.googleapis.com/projects//locations/global/buckets/_Default NOT LOG_ID("cloudaudit.googleapis.com/activity") AND NOT LOG_ID("externalaudit.googleapis.com/activity") AND NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND NOT LOG_ID("externalaudit.googleapis.com/system_event") AND NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

* **Фільтри виключень:** Можливо налаштувати **виключення для запобігання відправлення певних записів журналу**, що входять, що дозволяє економити кошти та зменшувати непотрібний шум.
3. **Метрики на основі журналів:** Налаштуйте **власні метрики** на основі вмісту журналів, що дозволяє сповіщати та моніторити на основі даних журналу.
4. **Перегляди журналів:** Перегляди журналів надають розширене та **деталізоване керування тим, хто має доступ** до журналів у вашому бакеті журналів. 
* Cloud Logging **автоматично створює перегляд `_AllLogs` для кожного бакета**, який показує всі журнали. Cloud Logging також створює перегляд для бакета `_Default` під назвою `_Default`. Перегляд `_Default` для бакета `_Default` показує всі журнали, за винятком журналів аудиту доступу до даних. Перегляди `_AllLogs` та `_Default` не можна редагувати.

Можливо дозволити принципалу **використовувати лише певний перегляд журналу** за допомогою політики IAM, подібно до:

<div data-gb-custom-block data-tag="code" data-overflow='wrap'>

```json
{
"bindings": [
{
"members": [
"user:username@gmail.com"
],
"role": "roles/logging.viewAccessor",
"condition": {
"title": "Bucket reader condition example",
"description": "Grants logging.viewAccessor role to user username@gmail.com for the VIEW_ID log view.",
"expression":
"resource.name == \"projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_NAME/views/VIEW_ID\""
}
}
],
"etag": "BwWd_6eERR4=",
"version": 3
}

Стандартні журнали

За замовчуванням операції Admin Write (також називаються журнали аудиту дій адміністратора) логуються (записують метадані або інформацію конфігурації) і не можуть бути вимкнені.

Після цього користувач може увімкнути журнали аудиту доступу до даних, це Admin Read, Data Write та Data Write.

Більше інформації про кожен тип журналу можна знайти в документації: https://cloud.google.com/iam/docs/audit-logging

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

Щоб увімкнути більше журналів у консолі, системному адміністратору потрібно перейти за посиланням https://console.cloud.google.com/iam-admin/audit та увімкнути їх. Є 2 різні варіанти:

  • Стандартна конфігурація: Можливо створити стандартну конфігурацію та логувати всі журнали Admin Read та/або Data Read та/або Data Write та навіть додати виняткові принципали:

  • Вибір сервісів: Або просто виберіть сервіси, для яких ви хочете генерувати журнали, тип журналів та винятковий принципал для цього конкретного сервісу.

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

Перерахунок

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

# List buckets
gcloud logging buckets list
gcloud logging buckets describe <bucket-name> --location <location>

# List log entries: only logs that contain log entries are listed.
gcloud logging logs list

# Get log metrics
gcloud logging metrics list
gcloud logging metrics describe <metric-name>

# Get log sinks
gcloud logging sinks list
gcloud logging sinks describe <sink-name>

# Get log views
gcloud logging views list --bucket <bucket> --location global
gcloud logging views describe --bucket <bucket> --location global <view-id> # view-id is usually the same as the bucket name

# Get log links
gcloud logging links list --bucket _Default --location global
gcloud logging links describe <link-id> --bucket _Default --location global

Приклад перевірки журналів cloudresourcemanager (використовується для BF дозволів): https://console.cloud.google.com/logs/query;query=protoPayload.serviceName%3D%22cloudresourcemanager.googleapis.com%22;summaryFields=:false:32:beginning;cursorTimestamp=2024-01-20T00:07:14.482809Z;startTime=2024-01-01T11:12:26.062Z;endTime=2024-02-02T17:12:26.062Z?authuser=2&project=digital-bonfire-410512

Немає журналів testIamPermissions:

Післяексплуатаційний етап

GCP - Logging Post Exploitation

Наполегливість

GCP - Logging Persistence

Посилання

Підтримайте HackTricks

Last updated