GCP - Logging Enum
Основна інформація
Цей сервіс дозволяє користувачам зберігати, шукати, аналізувати, контролювати та сповіщати про дані журналу та події з GCP.
Cloud Logging повністю інтегрований з іншими службами GCP, надаючи централізований сховище для журналів з усіх ваших ресурсів GCP. Він автоматично збирає журнали з різних служб GCP, таких як App Engine, Compute Engine та Cloud Functions. Ви також можете використовувати Cloud Logging для додатків, що працюють в офісі або в інших хмарах, використовуючи агент або API Cloud Logging.
Основні функції:
Централізація даних журналу: Агрегуйте дані журналу з різних джерел, пропонуючи всебічний погляд на ваші додатки та інфраструктуру.
Управління журналами в реальному часі: Потік журналів в реальному часі для негайного аналізу та реагування.
Потужний аналіз даних: Використовуйте розширені можливості фільтрації та пошуку для швидкого просіювання великих обсягів даних журналу.
Інтеграція з BigQuery: Експортуйте журнали в BigQuery для детального аналізу та запитування.
Метрики на основі журналів: Створюйте власні метрики на основі даних журналу для моніторингу та сповіщення.
Потік журналів
По суті, стоки та метрики на основі журналів визначають, де слід зберігати журнал.
Конфігурації, підтримувані GCP Logging
Cloud Logging має високу налаштовуваність для відповідності різноманітним операційним потребам:
Бакети журналів (Зберігання журналів в мережі): Визначте бакети в Cloud Logging для управління збереженням журналів, надаючи контроль над тим, як довго зберігаються ваші записи журналу.
За замовчуванням створюються бакети
_Default
та_Required
(один реєструє те, що інший - ні)._Required є:
Період збереження даних налаштовується для кожного бакета і повинен бути принаймні 1 день. Однак період збереження _Required становить 400 днів і не може бути змінений.
Зверніть увагу, що бакети журналів не видимі в Cloud Storage.
Стоки журналів (Маршрутизатор журналів в мережі): Створюйте стоки для експорту записів журналу до різних місць призначення, таких як 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")
Стандартні журнали
За замовчуванням операції 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
для керування конфігураціями журналів та доступом до журналів.
Приклад перевірки журналів 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Посилання
Last updated