Contractors, Shared VPN, and Stale Service Account Keys
An organization has 420 employees and 60 external contractors. A security review found that 38 service accounts have editor-level roles on the production project, 22 of those use downloaded JSON keys, and 9 keys are older than 365 days. Contractors currently use a shared VPN account and a single IAM group with broad access to storage and compute. The audit team requires least privilege, keyless authentication where possible, and evidence that access is reviewed quarterly. Application teams say strict roles will break batch jobs that need to read from three storage buckets, write to one queue, and invoke two internal APIs. The organization uses a single cloud project for production and a separate project for shared services. There is no central identity provider for contractors, but the company has an existing SAML identity provider for employees.
1. Redesign human access for employees and contractors. Explain how you would remove the shared VPN and still give contractors the access they need.
Read the worked answer
Employees: federate the existing SAML identity provider to the cloud identity system, require MFA, and map IdP groups to cloud groups. Do not create local user accounts. Production access goes through a just-in-time elevation group with a time-bound membership and an approval record.
Contractors: the lack of a central contractor IdP is the main gap. Prefer federating each contractor employer or using a sponsored account with MFA, not a shared VPN account. Put contractors in a separate group with access limited to the shared-services project and specific production read roles. Make group membership expire automatically, for example after 12 hours for production elevation and 90 days for standing access.
Remove the shared VPN. Shared credentials destroy attribution and violate least privilege. Replace with per-user access and device posture checks where possible.
Why not just tighten the existing group: a single broad group cannot express the batch job's storage, queue, and API needs or contractor separation. Group design should mirror job functions, not org charts.
Evidence: IdP assertion logs, group membership expiry records, elevation approvals, and quarterly access review sign-off.
2. Remediate the 38 over-privileged service accounts, including the 22 with JSON keys. Show how the batch job can get exactly the access it needs without editor.
Read the worked answer
Inventory and classify. Split the 38 service accounts by workload: batch jobs, CI/CD, and application runtime. Editor on production is the finding to remove first.
Replace keys. For workloads running on cloud infrastructure, attach a dedicated service account or use workload identity federation so no JSON key exists. For external batch jobs, use federation if supported; if not, use a short-lived token exchange rather than a long-lived key. Where a key is unavoidable, store it in a secret manager, restrict read access, rotate at most every 90 days, and alert on use outside expected networks.
Least privilege for the batch job. Create a custom role granting read on the three named buckets, publish on the one queue, and invoke on the two named APIs. Bind it to a dedicated service account. Test with a dry run or staging execution before production. Do not grant project-level editor.
Rollback safety. Apply in staging first, then production with a canary batch. If the job fails, the error should identify the missing permission; add only that permission, not editor.
Evidence: IAM policy diff, key inventory with creation dates, rotation tickets, and successful job runs under the new role.
3. Design a break-glass process and a quarterly access review that produces usable audit evidence. What tradeoff does break-glass introduce?
Read the worked answer
Break-glass design. Create one emergency role with broad production access, assumable only through a documented incident process. Require MFA, a ticket or incident ID, and an approval; the assumption generates a high-severity alert to security. Grant it for a short session, not standing access. Test it quarterly and review every use.
Quarterly review. Export effective IAM bindings, group memberships, service-account keys, and elevation logs. Reviewers must confirm each principal still needs each role, with special attention to contractors and production editor. Automate the export and comparison so the review is evidence, not a spreadsheet exercise.
Evidence for auditors: signed review records, removal tickets for access that was revoked, key-age report, and break-glass usage log.
Tradeoff. Just-in-time elevation adds friction and depends on the approval path working during an incident. Mitigate by keeping a documented fallback and by testing the break-glass flow, not by leaving standing editor access in place.