Стежити Використовуйте gcloud logging read з фільтром на cloudaudit.googleapis.com, або виконайте той самий запит у Logs Explorer та завантажте результати у форматі JSON:
gcloud logging read 'logName:"cloudaudit.googleapis.com" AND timestamp>="2026-10-19T00:00:00Z" AND timestamp<"2026-10-20T00:00:00Z"'
--project=my-project --format=json > gcp_audit_1019.json
Журнали перевірки адміністративної діяльності завжди ввімкнені і зберігаються протягом 400 днів. Журнали доступу до даних вимкнені за замовчуванням, за винятком BigQuery, і зберігаються протягом 30 днів після увімкнення.
Cloud Audit Logs записують, хто які зміни вніс у ваші проекти Google Cloud: надання прав IAM, нові ключі облікових записів служби, змінення брандмауера, запуск віртуальних машин у незвичайних регіонах. Prime Core має 140 правил виявлення для журналів аудиту Google Cloud, які мапуються на 74 техніки MITRE ATT&CK. Серед них: зловживання обліковими записами в хмарі (T1078.004), додаткові облікові дані, такі як нові ключі облікових записів служби (T1098.001) та втручання в логування (T1562.008).
Перш ніж почати
Знати, який журнал перевірки вам потрібен.
| Тип | Включено за замовчуванням? | Утримання | Що в ньому є |
|---|---|---|---|
| Адміністративна діяльність | Завжди, не може бути вимкнено | 400 днів | Зміни конфігурації та IAM |
| Системна подія | Завжди | 400 днів | Дії, які системи Google здійснили над вашими ресурсами |
| Доступ до даних | Ні (за винятком BigQuery) | 30 днів | Читання даних і метаданих |
| Відмова в політиці | Yes | 30 днів | Запити, заблоковані політиками безпеки |
Якщо питання “хто прочитав цей бакет?” і журнали доступу до даних ніколи не були увімкнені, відповіді немає в Cloud Logging.
Дозволи. Logs Viewer (roles/logging.viewer) покриває адміністрування діяльності, системні події та відмови в політиках. Журнали доступу до даних потребують Private Logs Viewer (roles/logging.privateLogViewer).
Сфера. Журнали перевірки живуть по проекту. Активність на рівні організації та папки має окремі журнали. Запити до них виконуйте з –organization=<ORG_ID> або –folder=<FOLDER_ID> замість –project.
Варіант 1: Logs Explorer
У консолі, відкрийте Logging → Logs Explorer, введіть logName:”cloudaudit.googleapis.com”, встановіть діапазон часу, виконайте запит, а потім завантажте результати у форматі JSON. Завантаження обмежене. Для більших діапазонів використовуйте gcloud.
Варіант 2: gcloud logging read
Команда на початку є базовою формою. Три деталі економлять час.
Завжди вказуйте часовий проміжок у фільтрі. Без умови за часовою міткою gcloud logging read тишком обмежує себе останнім днем (–freshness за замовчуванням дорівнює 1d). Це дивує майже всіх один раз.
Підвищте ліміт, коли це потрібно. Додайте –limit=100000 (або що там підходить) для великих вікон.
Зробіть плоским для завантаження. Вихід – це один JSON масив. Перетворіть його в один запис на рядок:
jq -c '.[]' gcp_audit_1019.json > gcp_audit_1019.jsonl
Корисні вужчі фільтри:
# лише адміністрування діяльності
logName="projects/my-project/logs/cloudaudit.googleapis.com/activity"
# нові ключі облікових записів служби
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"
# все, що зробила одна ідентичність
protoPayload.authenticationInfo.principalEmail="suspicious-sa@my-project.iam.gserviceaccount.com"
Варіант 3: Масова історія з переборів
Якщо ваша організація направляє журнали перевірки через перебір до Cloud Storage або BigQuery, ця копія може йти далі, ніж вказані вище бакети. Витягуйте файли з gcloud storage cp, або запитуйте BigQuery і експортуйте результат у форматі JSON.
На що звертати увагу
| Метод або поле | Чому це важливо |
|---|---|
| CreateServiceAccountKey | Довгострокові облікові дані, які може вкрасти зловмисник |
| SetIamPolicy | Надання ролей; спостерігайте за roles/owner, roles/editor і allUsers |
| UpdateSink, DeleteSink, нові виключення | Хтось перенаправляє або знешкоджує журнали |
| v1.compute.instances.insert в незвичайних регіонах | Класичний слід криптомайнінгу |
| Сплески зі статусом.code: 7 (PERMISSION_DENIED) | Вкрадені облікові дані, які пробують, що вони можуть зробити |
Завантажте, очистіть і перегляньте в LogTotal
- Завантажити. Відкрити logtotal.com і перетягніть файл .jsonl.
- Очистити. [what gets masked: principal emails, project IDs, IPs, resource names]. Look it over before you continue.
- Переглянути.
Коли це йде не так
| Симптом | Ймовірна причина | Fix |
|---|---|---|
| Повертаються лише останні 24 години | У фільтрі не було часової мітки, тому застосовується –freshness=1d | Вкажіть вікно в фільтрі |
| Відсутні записи доступу до даних | Журнали доступу до даних ніколи не були увімкнені | Очікувано; увімкніть їх на майбутнє |
| PERMISSION_DENIED при читанні журналів | Відсутній Private Logs Viewer для доступу до даних | Запитуйте roles/logging.privateLogViewer |
| Результати обриваються раніше | Досягнуто за замовчуванням або явно встановленого –limit | Збільшіть –limit або розбийте вікно |
| Відсутні зміни на рівні організації | Ви запитували проект | Використовуйте –organization |
FAQ
Чи є тут журнали Google Workspace?
Тільки якщо ваша організація ділиться даними Workspace з Google Cloud, і потім на рівні організації.
А як щодо GKE?
GKE записує свої журнали аудитів Kubernetes у Cloud Audit Logs також.
