What's changed: Created Professional Security Operations Engineer Chapter 1 (Domain 1 "Platform operations": Google SecOps (SIEM/SOAR)/Security Command Center/GTI/Cloud IDS telemetry prioritization/tool integration/justifying overlaps/coverage gaps/automation; user-service account authentication/IAM feature-data authorization/Cloud Audit Logs (Data Access)/API access for automation (service accounts-API keys)/Workforce Identity Federation).
1.2Configuring access and auditing
Understand user/service account authentication to security tools (SCC, Google SecOps), authorizing feature access and data access via IAM roles/permissions, configuring/analyzing audit logs (Cloud Audit Logs, data access logs), configuring API access for automation (service accounts, API keys, SCC/SecOps/GTI), and provisioning identities with Workforce Identity Federation.
Operating the security tools themselves securely is the prerequisite. Control who can access what with least privilege, and audit operations.
1.2.1Authentication, authorization, and identity provisioning
For authentication to SCC or Google SecOps, use user accounts for people and service accounts for automation. For authorization, use IAM roles/permissions, separating feature access (which operations) from data access (which data) and granting least privilege—e.g., view-only for analysts, detection-rule editing for detection engineers. To use external-IdP people without creating Google accounts, provision identities with Workforce Identity Federation. Map "separate feature and data authorization = IAM least-privilege roles" and "federate external-IdP people = Workforce Identity Federation."
1.2.2Audit logs and API access for automation
Keep trails for security-ops actions too: configure/analyze Cloud Audit Logs Admin Activity logs and sensitive Data Access logs (explicitly enabled), so you can trace "who changed which detection rule / viewed which data." For automation (SOAR playbooks, external integrations), use API access via service accounts or API keys to securely connect to SCC/SecOps/GTI endpoints, handling keys with least privilege, short-lived, and rotation. Map "trail of security-tool actions = Cloud Audit Logs (enable Data Access)" and "automation connectivity = service accounts/API keys."
Common: requirement → means. E.g., "view-only for analysts, rule editing for detection engineers" = separate feature/data authorization via IAM roles; "audit security-tool actions" = Cloud Audit Logs (enable Data Access); "connect SOAR playbooks to external APIs" = service accounts/API keys; "federate external-IdP SOC analysts" = Workforce Identity Federation.
Watch the mix-ups: (1) Feature access (operations) vs data access (visibility) are different authorizations—least-privilege both. (2) Data Access logs are off by default—enable for sensitive-operation trails. (3) Automation API keys/SA keys are leak sources—least privilege/rotation, prefer Workload Identity Federation where possible.
1.2.3Section summary
- Auth = user/service accounts; authorization = IAM separating feature/data with least privilege
- Action trail = Cloud Audit Logs (enable Data Access); external-IdP people = Workforce Identity Federation
- Automation API access = service accounts/API keys with least privilege/rotation
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To allow SOC analysts to only view detections while detection engineers can edit detection rules, which is best?
Q2. To let SOC analysts managed in an external IdP (e.g., Okta) access security tools without creating Google accounts, which is best?
Q3. To keep a trail of who changed which detection rule and accessed which sensitive data, what is the prerequisite?
Q4. To call SCC/GTI APIs from a SOAR playbook for automation, which is the best authentication means?
Q5. Which correctly distinguishes feature access from data access?