Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ця служба дозволяє користувачам зберігати, шукати, аналізувати, моніторити та отримувати сповіщення про дані та події журналів з GCP.
Cloud Logging повністю інтегрований з іншими службами GCP, надаючи централізований репозиторій для журналів з усіх ваших ресурсів GCP. Він автоматично збирає журнали з різних служб GCP таких як App Engine, Compute Engine та Cloud Functions. Ви також можете використовувати Cloud Logging для додатків, що працюють на місці або в інших хмарах, використовуючи агент Cloud Logging або API.
Ключові особливості:
Централізація даних журналів: Агрегуйте дані журналів з різних джерел, пропонуючи цілісний погляд на ваші додатки та інфраструктуру.
Управління журналами в реальному часі: Потокове передавання журналів в реальному часі для негайного аналізу та реагування.
Потужний аналіз даних: Використовуйте розширені можливості фільтрації та пошуку, щоб швидко переглядати великі обсяги даних журналів.
Інтеграція з BigQuery: Експортуйте журнали в BigQuery для детального аналізу та запитів.
Метрики на основі журналів: Створюйте користувацькі метрики з ваших даних журналів для моніторингу та сповіщення.
В основному, зливи та метрики на основі журналів визначать, де журнал має бути збережений.
Cloud Logging має високу конфігурованість, щоб відповідати різноманітним операційним потребам:
Log Buckets (Зберігання журналів в мережі): Визначте кошики в 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 немає:
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
