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
:
Післяексплуатаційний етап
pageGCP - Logging Post ExploitationНаполегливість
pageGCP - Logging PersistenceПосилання
Last updated