Tiered access model documented and approved

Severity: Critical

Check automatically:

1. Cloud IAM - GCP:

   # List IAM bindings for production project
   gcloud projects get-iam-policy PROJECT_ID --format=json
   
   # Compare with staging
   gcloud projects get-iam-policy STAGING_PROJECT_ID --format=json
   
   # Count members with elevated roles
   gcloud projects get-iam-policy PROJECT_ID --format=json | jq '[.bindings[] | select(.role | test("owner|admin|editor"; "i")) | .members[]] | unique | length'
   

2. Cloud IAM - AWS:

   # List IAM users/roles with production access
   aws iam list-users --query 'Users[].UserName'
   
   # Check who can access production resources
   aws iam get-account-authorization-details --filter LocalManagedPolicy
   

3. GitHub repository access:

   # List collaborators with their permission level
   gh api repos/{owner}/{repo}/collaborators --jq '.[] | {login, role_name}'
   
   # List teams with access
   gh api repos/{owner}/{repo}/teams --jq '.[] | {name, permission}'
   

4. Check for documented & approved access lists:

   # Look for access policy docs
   find . -type f -name "*.md" | xargs grep -liE "access.*(control|policy|tier)|who.*access|permissions" 2>/dev/null
   

For database access verification:

If direct CLI access available:

# PostgreSQL - list users
psql -h $PROD_DB_HOST -U admin -c "\du"

# MySQL - list users
mysql -h $PROD_DB_HOST -u admin -e "SELECT user, host FROM mysql.user;"

If direct DB access not available, ask user: "Please run the following queries and provide the output as evidence:

• PostgreSQL: \du or SELECT usename, usesuper, usecreatedb FROM pg_user;
• MySQL: SELECT user, host FROM mysql.user;
• Cloud SQL/RDS: Provide screenshot or export of database users from console

Provide results for: (1) Production DB (2) Staging DB (3) Dev DB"

Cross-reference with:

• DB-004 (Database users & permissions)
• ADMIN-002 (Admin user audits)

Pass criteria:

• Access lists are documented (who has access to what)
• Access lists are approved (sign-off from appropriate person)
• Prod has fewer users than staging
• Staging has fewer users than dev
• Principle of least privilege visible

Fail criteria:

• No documented access list
• Access exists but not approved/reviewed
• Same users everywhere (flat access)
• Prod has more users than staging (inverted)

If cloud CLI not available, ask user: "Unable to query IAM directly. Please provide:

1. Who has production access? (list names/emails)
2. Who has staging access?
3. Who has dev access?
4. Where is this access documented?
5. Who approved the current access list?"

Evidence to capture:

• IAM binding counts per environment
• Database user counts per environment
• Access documentation location
• Last access review/approval date
• Approver name

---