Azure RBAC & ServiceNow Access Automation – Working-Session Notes

Context & Meeting Purpose

  • Participants: Steve, Jason, Adam, Dennis, (mentions of Frank & Justine)
  • Primary goal:
    • Review current Azure RBAC (Role-Based Access Control) practices.
    • Discuss how to automate access requests through ServiceNow.
    • Align with security, CMDB, & JML (Joiner-Mover-Leaver) processes.
  • Secondary goals:
    • Compare Azure approach with existing Merkle model (AWS / GCP patterns).
    • Identify gaps (e.g.
      Linux server domain joins, owner tracking when staff leave).

Current Azure Workflow ("How we do it today")

  • Resource creation
    • User requests (e.g., Cosmos DB, Storage Account, VM).
    • TCS spins up resource inside a Resource Group (RG).
  • Naming conventions
    • RG name → descriptive; security group name → sg-<resource_group> pattern.
  • Security Groups (SG) per RG
    • SG-Reader → default, view-only.
    • SG-Elevated → bundled higher privileges (multiple roles).
    • Reader assigned ≈\approx (90%)(90\%) of the time first; elevated added on demand.
  • Role assignments to SG-Elevated (example set)
    • Storage Account Contributor
    • Storage Data Blob Contributor
    • Cosmos DB Owner
    • Up to 2020 built-in roles can be attached.
  • Granularity
    • Avoid granting Contributor or Owner unless absolutely necessary; prefer fine-grained data-plane roles.
  • Handling mixed needs
    • If Tech Lead needs elevated to ALL items but colleague needs only Blob write, team may create an additional SG; rare in practice.

Azure Hierarchy Refresher

  • Layers (top → bottom)
    • Management Group → Subscription → Resource Group → Resource.
  • Multiple Subscriptions per department; e.g.
    • BDC-7 = prod subscription.
    • BDC-6 = non-prod subscription.
  • Tagging strategy
    • Tags set at RG level (owner, finance owner, TCS managed flag, working hours, BBC code, etc.).
    • Azure Policy auto-propagates tags to every nested resource.

VM / Server Access Mechanics

  • Windows
    • TCS automation joins every VM to on-prem AD domain.
    • GPO auto-creates two AD groups on the server:
    • Local-Admins-<hostname>
    • Local-Users-<hostname>
    • Adding user to AD group grants local rights; ServiceNow form exists for requests.
  • Linux
    • Unclear; action item to confirm whether Linux hosts join domain & leverage AD credentials.

Pain-Points Identified

  • Manual creation of SG-Elevated + multi-role mapping is error-prone.
  • Users usually do not understand Azure role catalog ("I just need to see data").
  • Security cannot easily find true owners when employees leave.
  • Current flow does not create custom least-privilege roles per solution.

Proposal – Standard Custom Role ("v1, v2, …")

  • Design: pre-approved list of actions a "standard user" needs across common resources.
  • Benefits
    • Simplifies ServiceNow form → pick Reader or Standard-Elevated (custom).
    • ≈\approx (90%)(90\%) of requests closed automatically.
    • Versioning (v1 → v2) allows incremental expansion as new Azure resource types appear.
  • Governance
    • Security signs off once; owners can self-grant.
    • Deny-actions baked in (e.g., no Microsoft.Compute/virtualMachines/delete).

ServiceNow Automation Blueprint

  • Forms required
    • Request Access → captures user, target subscription/RG, desired role.
  • Owner resolution
    • Pull from CMDB OR Azure tag (owner = email).
    • Auto-approver group fallback for unmanaged subs.
  • Scripted operations (easy part)
    1. Verify SG exists; create if missing.
    2. Add role(s) to SG (if new).
    3. Add requester to SG upon approval.
  • Edge cases
    • When owner departed, workflow must escalate to security / secondary approvers.

Comparison – Merkle Model (Reference)

  • Pre-defined role catalog (Tier-1, Tier-2, SSO-Admin, etc.).
  • AD groups
    • Synced to Google & Azure; AWS via nested Okta mapping (no Identity Center yet).
  • ServiceNow CMDB integration
    • Service Offering ≈ project/RG.
    • Approvers & members recorded in CMDB.
    • Request → Auto-approve if requester is already an approver.
    • Otherwise email approver with single-click approve/deny.
  • Client-facing dimension (distinct "client" flair in roles) to allow external user access.
  • Lesson: identical structure is feasible for Dentsu; leverages standard ServiceNow connectors to AD.

Ownership, CMDB & JML Considerations

  • ServiceNow JML events already feed CMDB for hardware reclaim (laptops).
  • Need to extend same hooks to cloud ownership records.
    • When owner leaves → trigger "find new owner" task.
  • GoTo (internal security portal) to surface owner data so Security can self-serve when Wiz finds vulnerabilities.

Numbers & Percentages Mentioned

  • Reader role granted ≈\approx (90%)(90\%) of cases.
  • Windows domain join covers 95%95\% of managed servers.
  • SG-Elevated could hold up to 2020 Azure built-in roles.
  • Custom role expected to satisfy ≈\approx (90%)(90\%) of future access tickets.

Open Questions & Action Items

  • [ ] Confirm Linux domain-join pattern & AD integration (Steve to investigate).
  • [ ] Justine to demo CMDB service-offering structure & AD sync flow.
  • [ ] Define authoritative source for owner (Azure tag vs. CMDB record).
  • [ ] Draft Standard-Custom-Role v1 permission JSON; circulate for security sign-off.
  • [ ] Build ServiceNow form + PowerShell/Azure CLI script to manage SG & role assignment.
  • [ ] Map escalation path when owner not found or left company.

Key Takeaways

  • Present flow already uses SG-Reader & SG-Elevated, but maintenance is manual.
  • Automating via ServiceNow + a single custom elevated role will dramatically cut effort & confusion.
  • Proper CMDB integration is critical for both approvals and security ownership.
  • Merkle’s mature implementation proves concept; Dentsu/TCS can replicate with minor tailoring.
  • Next sync will focus on Linux server access gaps & a live CMDB demo.