Professional Cloud Security Engineer

Configure Custom Log Buckets, Log Views, and Field-Level Access Controls

Log Segregation Architecture

Custom log buckets are storage containers for logs in a specific Google Cloud region. You can create different buckets to separate logs by type, such as keeping all audit logs in one bucket and operational logs in another. This allows you to apply different security settings and retention periods to each category of log data. A log view is a filtered window into a bucket. It lets you show only certain logs based on criteria like the source project or resource type, which helps you give users access to only the logs they need without exposing everything in the bucket.

Field-Level Access Controls for Sensitive Data

Field-level access controls protect specific sensitive information inside individual log entries. While a log view can hide an entire log, field-level controls let you redact or restrict access to just certain fields, like personally identifiable information (PII) or passwords in authentication payloads. You configure these by listing the specific field paths (e.g., jsonPayload.user.email) when you create or update a log bucket. By default, Cloud Logging hides these restricted fields from all users except those who have been granted a special IAM role called logging.fieldAccessor.

Implementation and Operational Tradeoffs

Setting up these controls requires planning. You define the list of restricted fields using the gcloud command-line tool, and if you update an existing bucket, you must provide the complete new list—the update replaces the old one entirely. There are important tradeoffs to consider: log buckets with field-level access controls enabled cannot be used with Log Analytics or live tailing features. You must use Logs Explorer or export the logs to BigQuery for analysis instead. This is part of a broader strategy that also includes setting data retention periods and using customer-managed encryption keys (CMEK) for advanced data protection.

Enforce IAM Permissions, Privileged Roles, and Perimeter Boundaries

Applying Least Privilege with IAM Roles

You control who can see and manage logs by assigning Identity and Access Management (IAM) roles. Predefined roles like Logs View Accessor allow users to read logs, while more powerful roles like Logging Admin are needed to change configurations. Following the principle of least privilege means giving users only the permissions they absolutely need for their job. It is best practice to assign these roles to groups, not individual users, to make permission management easier and more consistent across your organization.

Protecting Sensitive Audit Logs

Data Access audit logs record who accessed or changed your cloud data and are highly sensitive. You must enable these logs at the organization or folder level to ensure coverage across all projects. There are three main types: ADMIN_READ (viewing configuration), DATA_READ (reading data), and DATA_WRITE (changing data). Because these logs can contain PII, access to them must be strictly limited to a small set of privileged, trusted roles and accounts.

Controlling Access with Network and Context Boundaries

VPC Service Controls create a service perimeter, which is a network-based security fence around your logging resources like APIs and storage. This control blocks any attempt to access or export logs from outside the approved network, helping prevent data exfiltration. You can layer on context-aware access controls, which check additional factors like the user’s geographic location or device security before granting access. Combining strong network boundaries with strict identity checks ensures that only authorized users on secure devices within the right network can query critical logs.

Secure Aggregated Log Routing, Export Destinations, and Storage Immutability

Centralizing Logs with Aggregated Sinks

To get a unified security view, you create aggregated sinks at the organization or folder level. These sinks automatically collect logs from all projects within that scope and route them to a central, dedicated logging project. The key security step is to tightly restrict who has permission to create or modify these sinks. This prevents unauthorized changes that could stop log collection or send logs to an insecure location, ensuring your security team has a reliable, complete stream of telemetry.

Securing Export Destinations

Logs are often exported to Cloud Storage, BigQuery, or Pub/Sub for long-term storage, analysis, or real-time processing. Each destination must be secured. You should use the principle of least privilege for access and enable Customer-Managed Encryption Keys (CMEK). With CMEK, you control the encryption keys in Cloud Key Management Service (Cloud KMS), instead of using Google’s default encryption. This gives you greater control over who can decrypt the data and is required for many advanced compliance standards.

Ensuring Log Integrity with Immutable Storage

For audit and compliance, you must ensure logs cannot be tampered with or deleted before their retention period ends. In Cloud Storage, you can use Bucket Lock to make a retention policy immutable. Once locked, no one—not even project administrators—can delete or change the stored logs until the retention period expires. This guarantees the integrity of your historical log data. You should plan retention periods (which in Cloud Logging can range from 1 to 3650 days) based on your specific regulatory requirements and business needs.