Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Prepare and test your skills
Prepare and test your skills
Security log analytics is a process that helps teams prevent, detect, and respond to threats like malware or unauthorized access. The workflow starts by enabling specific logs, routing them to a central destination, and then analyzing the data for risks. Visibility into administrative actions and data access is essential for maintaining a secure cloud environment. This structured approach helps organizations answer the critical questions of "who did what, where, and when."
Google Cloud provides tools like Logs Explorer and Log Analytics to investigate security incidents. Logs Explorer allows users to search and filter through massive amounts of data to find specific events, such as a deleted resource or a suspicious login. For more complex investigations, Log Analytics uses SQL queries to aggregate data and identify patterns of misuse. These tools are vital for performing root cause analysis after a potential breach occurs.
Establishing log-based metrics and alerts is necessary for real-time response to anomalous behavior. By setting up specific triggers, security teams can be notified immediately when a policy is violated or when API usage spikes unexpectedly. This proactive monitoring ensures that potential threats are addressed before they cause significant damage. Automated alerts help maintain a continuous state of compliance across all cloud resources.
A hierarchy diagram showing the four main categories of Google Cloud Audit Logs: Admin Activity, Data Access, System Event, and Policy Denied, along with their sub-types and configuration rules.
Google Cloud services use Cloud Audit Logs to help security teams answer "who did what, where, and when" within a project. Admin Activity logs are a primary category that records "admin write" operations, such as creating or modifying resources. These logs are always enabled and cannot be turned off, ensuring that there is always a record of configuration changes. Because they are vital for security, Google provides these logs at no additional cost.
Data Access logs track "admin read" operations and "data read/write" actions that involve user-provided information. Unlike activity logs, these are disabled by default because they can generate a high volume of data and result in extra costs. To use them, administrators must explicitly enable the specific log types for each service, including Admin Read (records metadata or configuration information), Data Write (records entries that create or modify user-provided data), and Data Read (records entries that read user-provided data). Choosing the right logs to enable is a balance between visibility and storage costs.
Other important categories include System Event logs, which record administrative actions taken by Google systems, and Policy Denied logs, which trigger when a user is blocked by a security policy. For specialized services like Google Kubernetes Engine, users can also enable logs for the API server, Scheduler, and Controller Manager. These additional logs provide deeper visibility into the control plane, which is essential for troubleshooting and compliance.
To manage the large amount of data generated, teams use log sinks to route information to destinations like Cloud Storage or BigQuery. Administrators can also set up exclusion filters to prevent specific, less important logs from being stored in Cloud Logging. This strategy is critical for optimizing costs while still ensuring that the most important security data is available for forensic analysis.
Managing audit logs requires specific IAM roles to ensure that only authorized personnel can view or change logging settings. For example, the Logs View Accessor role allows a user to see logs, while the Project Owner role is often needed to configure Data Access logs. Segmenting access through different log buckets can further protect sensitive information from being seen by unauthorized users within the same organization.
To manage logs effectively, you use log sinks to route data to different destinations based on your organizational needs. These destinations include Cloud Storage for long-term, low-cost storage and forensic analysis, BigQuery for performing complex analysis using SQL queries, and Pub/Sub for streaming logs to third-party security tools or external applications. Aggregated sinks are particularly useful because they allow you to collect logs from all projects within a folder or an entire organization into one central location.
Retention compliance ensures that your organization keeps logs for the required amount of time to meet legal or regulatory rules. You can set specific retention periods in log buckets, such as 365 days, to satisfy these mandates and ensure data residency requirements are met. Configuring sinks before logs are actually generated is a critical best practice to ensure no data is lost for future forensic investigations.
Maintaining security requires strict access control and active monitoring of your log data. Using Identity and Access Management, you can assign specific roles like the Private Logs Viewer to restrict who can see sensitive information in Data Access logs. Additionally, you can create log-based alerts in Cloud Monitoring to notify security teams immediately when suspicious events or specific patterns appear in the logs.
Admin Activity logs record admin write operations like creating or modifying resources, are always enabled at no cost, and cannot be turned off. Data Access logs record admin read and data read/write operations involving user data, are disabled by default, and can generate high volume and extra costs if enabled.
The primary tools are Logs Explorer, which allows searching and filtering through massive log data to find specific events, and Log Analytics, which uses SQL queries to aggregate data and identify patterns for complex investigations and root cause analysis.
Data Access logs are disabled by default because they can generate a high volume of data and result in extra costs. To use them, administrators must explicitly enable specific log types (Admin Read, Data Write, Data Read) for each service.
Common destinations include Cloud Storage for long-term, low-cost storage and forensic analysis, BigQuery for performing complex analysis using SQL queries, and Pub/Sub for streaming logs to third-party security tools or external applications.
An enterprise is designing a compliance and auditing architecture across its Google Cloud organization while optimizing Cloud Logging storage and ingestion costs. The security operations team has established the following requirements:
StudyCerts
StudyCerts_Default log bucket.Which combination of audit log configurations and IAM roles should you implement?
Enable Data Access audit logs across all services by default, create exclusion filters on Admin Activity logs to reduce costs, and grant auditors the Logs Viewer (roles/logging.viewer) role.
Rely on default configuration for Data Access logs, explicitly enable Policy Denied logs, and grant auditors the Private Logs Viewer (roles/logging.privateLogViewer) role.
Rely on the default configuration for Admin Activity and System Event logs, explicitly enable Data Access audit logs for the relevant services, and grant auditors the Private Logs Viewer (roles/logging.privateLogViewer) role.
Explicitly enable Admin Activity and System Event audit logs in the audit configuration, disable Data Access logs, and grant auditors the Logs Viewer (roles/logging.viewer) role.