Fascinated by the world of cloud databases? Explore the methods for structuring, scaling, and securing database solutions on Google Cloud as you gear up for the Professional Cloud Database Engineer exam!
Google Cloud Audit Logs track "who did what, where, and when" across your services. There are three main types, each serving a different purpose. Admin Activity logs record actions that change a resource's configuration, like creating or deleting a database instance, and are enabled by default for all Google Cloud services. Data Access logs track when someone reads or writes the actual data stored in a service, but these logs are not on by default and must be manually configured. System Event logs are generated automatically by Google's own systems, not by user actions, and record events like automated system maintenance.
Data Access logs are further broken down into specific categories to provide detailed visibility. The ADMIN_READ category logs viewing of configuration or metadata. The DATA_READ category logs access to user-provided data. The DATA_WRITE category logs any creation or modification of data. For managed database services like Cloud SQL, Spanner, and Bigtable, you must explicitly turn on these logs to capture this level of detail, which is done through the Google Cloud Console or command-line tools.
Enabling detailed auditing for a database engine often requires extra configuration. For example, a Cloud SQL for PostgreSQL instance needs the pgAudit extension enabled via a database flag. Similarly, SQL Server uses its own built-in audit features. Turning on these features usually requires restarting the database instance, so it should be planned for a maintenance window. Once active, they can log specific SQL commands to help meet security and compliance needs.
Logs need a place to go. Audit data is typically sent to Cloud Logging for immediate analysis or to a Cloud Storage bucket for long-term, low-cost archiving. It's important to monitor the disk space on your database instance, as logs are stored there temporarily before being exported. Using Cloud Monitoring helps track log file sizes and set alerts to prevent disk space issues.
Access to audit logs is controlled by Identity and Access Management (IAM) roles. The Logs Viewer role allows someone to see standard Admin Activity and System Event logs. To view the more sensitive Data Access logs, a user needs the Private Logs Viewer role. Correctly assigning these roles based on the principle of least privilege ensures that only authorized personnel can see records of who accessed sensitive data.
Creating organization-wide auditing policies sets a standard for what events to log and review across all your managed databases. These policies define which actions, like successful logins or data deletions, are captured to meet both internal security goals and external legal compliance requirements. Having a clear, consistent policy ensures operational transparency and simplifies managing audits at scale.
The Google Cloud Observability suite provides tools to manage the full lifecycle of audit data. You can use Cloud Monitoring to create custom metrics from your logs and set up alerts. Pub/Sub can be used to stream logs in real-time to third-party security tools for immediate analysis. Setting up these alerts and streams ensures your team is quickly notified of unusual activity or failures in the audit logging process itself.
For long-term storage, you use log sinks to export audit logs to specific destinations based on their use case. Cloud Storage is ideal for low-cost archiving to meet multi-year legal retention requirements. BigQuery is used for advanced analysis, like identifying patterns in user behavior over long periods. Pub/Sub enables real-time streaming of logs to external security information and event management (SIEM) systems. Choosing the right destination balances cost, accessibility, and analysis needs.
IAM roles are critical for securing the audit data itself. While the Logs Viewer role provides read-only access to basic logs, viewing the contents of Data Access audit logs requires the more privileged Private Logs Viewer role. Applying the principle of least privilege when assigning these roles prevents unauthorized users from seeing records of sensitive data interactions.
VPC Service Controls add a powerful security layer by creating a virtual perimeter around your resources, including managed databases and their audit logs. This helps prevent data exfiltration, meaning it stops sensitive audit telemetry (or the data it describes) from being moved outside authorized network boundaries. Implementing VPC Service Controls is especially important for protecting high-value data in services like BigQuery and Cloud SQL.
Data Access audit logs are the detailed records of user interactions with your database's data and configuration. They are categorized as ADMIN_READ for viewing settings, DATA_READ for reading user data, and DATA_WRITE for creating or modifying data. Enabling these logs is a foundational step for security monitoring and proving compliance, as they provide a clear trail of who accessed what and when.
For a service like Cloud SQL, achieving this level of detail requires enabling database-specific audit tools. For PostgreSQL, you set the cloudsql.enable_pgaudit flag to "on". For SQL Server, you configure its native SQL Server Audit. It is a best practice to also enable automatic storage increases for the database instance, because the audit files generated can consume disk space quickly before they are exported to Cloud Logging or Cloud Storage.
The granularity of auditing refers to how much detail is captured in each log entry. You can configure tools like pgAudit to log every single statement or only specific types of operations. Increasing granularity provides deeper visibility into user queries and actions but comes with a significant trade-off: it dramatically increases log volume, which directly raises storage costs and can impact system performance. Organizations must balance the need for detailed visibility against the financial and operational impact.
Analyzing these logs requires both the right permissions and the right tools. Users need the Private Logs Viewer IAM role to access Data Access logs. Tools like Logs Explorer in Cloud Logging and BigQuery are then used to query, analyze, and identify patterns or anomalies in the data. Regularly reviewing your audit configuration and the logs themselves ensures your policies remain effective and storage costs are managed. Setting up log-based metrics and alerts can also automatically notify you of critical events or configuration changes.
Prepare and test your skills
Prepare and test your skills
Admin Activity logs record actions that change a resource configuration, such as creating or deleting a database instance, and are enabled by default for all Google Cloud services. In contrast, Data Access logs track when someone reads or writes the actual data stored in a service, and they are not enabled by default.
The Logs Viewer role allows users to view standard Admin Activity and System Event logs. Viewing the more sensitive Data Access audit logs requires the Private Logs Viewer role to ensure access is restricted according to the principle of least privilege.
Audit logs can be exported using log sinks to Cloud Storage, BigQuery, or Pub/Sub depending on the use case. Cloud Storage serves as low-cost archiving for multi-year legal retention, BigQuery enables advanced analysis of user behavior patterns over long periods, and Pub/Sub streams logs in real time to external security information and event management systems.
Increasing audit granularity provides deeper visibility into user queries and specific operations, but it dramatically increases log volume. This higher volume directly raises storage costs, can impact database performance, and rapidly consumes local disk space before logs are exported to Cloud Logging or Cloud Storage.