India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Cloud Identity & Access Management: Least Privilege by Design
Cloud identity and access management is the design of who and what can act in your cloud accounts: workforce sign-in, admin elevation, service identities and the permissions each holds. NTSPL builds federated single sign-on, just-in-time privileged access and least-privilege role catalogues across AWS, Azure and Google Cloud for Indian banks, brokers, insurers and digital platforms.
Delivered on
In scope
Why Standing Admin Rights and Static Keys Are the Real Exposure
Identity is where most cloud breaches start, and the pattern in Indian estates is consistent: IAM users created per engineer and never deleted, a dozen permanent Global Administrators, vendor staff signing in with shared accounts, and applications authenticating with client secrets that have not rotated since go-live. Each engineer who leaves or each vendor contract that ends leaves credentials behind. When an auditor asks who could have changed a production firewall rule last March, the honest answer is often 'about 140 people'.
NTSPL rebuilds access around three ideas. Humans sign in only through your corporate identity provider with phishing-resistant MFA, and receive permissions through a small catalogue of job-based roles. Administrative rights are eligible, not standing: elevation is time-boxed, approved and logged. Workloads use platform-issued identities instead of keys. We implement this as code, migrate teams in waves so nobody is locked out, and leave behind access reviews that run without us.
When Your Cloud Access Model Needs Rebuilding
Signals you need Identity & Access Management
- More than 30 local IAM users, or any human user with an access key, still exist in production accounts
- Five or more permanent Global Administrator, Owner or org-level Owner assignments are held by named individuals
- Leavers retain cloud access for days because offboarding is a manual ticket across several consoles
- Applications authenticate with client secrets or service account keys older than 180 days
- An RBI, SEBI CSCRF or IRDAI audit has raised an observation on privileged access management
When to choose something else
- Your problem is secrets stored in code and config, not human or role access: start with Secrets & Key Management.
- You need customer-facing login for an app (CIAM) such as OTP sign-in for millions of users; that is an application build, not cloud IAM.
Workforce, Privileged and Workload Identities We Redesign
Workforce federation
Connect AWS IAM Identity Center, Microsoft Entra ID and Google Cloud to one identity provider with SCIM provisioning, so joiners, movers and leavers flow from HR records.
Role catalogue
Define 8-15 job-based roles (platform admin, network engineer, developer, read-only auditor, vendor support) with permissions generated from observed activity, not copied from managed admin policies.
Privileged access
Convert standing admin rights to eligible, time-boxed elevation with approval, justification and ticket reference, and configure two monitored break-glass accounts.
Workload identities
Replace static keys and client secrets with instance roles, managed identities, Workload Identity Federation for CI/CD and pod-level identities on Kubernetes.
Guardrails and reviews
Organisation-level policies that deny local user creation and key issuance, plus quarterly access reviews with automatic removal on no response.
Identity Provider to Resource: The Federated Access Architecture
Federated Workforce and Workload Identity Architecture
The corporate identity provider authenticates every human with phishing-resistant MFA and provisions group membership into each cloud's access layer. Privileged roles are granted only through time-boxed elevation, while workloads obtain short-lived tokens from the platform instead of stored keys.
Select any component
Federated Workforce and Workload Identity Architecture: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Identity Center, Entra ID and Cloud IAM Patterns Compared
Permission sets are generated from Access Analyzer policy generation on CloudTrail activity; Roles Anywhere covers on-prem servers that previously held IAM user keys.
PIM requires Entra ID P2 or ID Governance licences for eligible users; we license only the elevating population, typically 5-10% of staff.
Workforce Identity Federation lets Entra or Okta users reach Google Cloud without duplicating accounts in Cloud Identity.
Role Catalogue, Elevation and Break-Glass Choices
How many roles in the catalogue
Aim for 8-15 roles per cloud. Fewer than 6 forces over-permissioned 'developer' roles; more than 25 means reviewers rubber-stamp because nobody understands the difference. Use ABAC session tags or conditions to scope a single developer role to a team's resources instead of creating one role per team. Review the catalogue every six months as services are adopted.
Elevation window and approval
Set 2 hours for production admin, 4 hours for change-window work and 8 hours maximum for incidents. Require approval for Global Administrator, Owner at management-group or org level and anything touching IAM itself; self-approval with justification is acceptable for lower roles. Approvals slower than 15 minutes push teams back to standing access.
Break-glass design
Keep exactly two cloud-only emergency accounts per tenant or organisation, excluded from Conditional Access but protected with FIDO2 hardware keys held in separate locations. Alert the SOC on any sign-in, test them every quarter, and never use them for routine work. More than two becomes a hidden standing admin population.
Vendor and partner access
Vendors should sign in as B2B guests or through their own federated IdP, never through shared local accounts. Give them eligible roles scoped to their accounts with a contract end date as expiry. If a vendor has 20 or more staff on your estate, require them to federate so their leavers are removed at source.
Migrating Teams to Federated, Just-in-Time Access in Waves
Access discovery and activity baseline
Export every user, role assignment and key with 90 days of activity to see who actually uses what.
Role catalogue and elevation design
Define job roles, eligible privileged roles, approval chains and break-glass procedure with the CISO.
Federation and pilot wave
Connect the IdP with SCIM and move one platform team, verifying no lock-out before widening.
Team migration waves
Move remaining teams and vendors in waves of 50-80 users, deleting local users and keys after each.
Workload key replacement and guardrails
Swap application keys for platform identities, then enforce deny policies for new users and keys.
What you receive
Privilege and Credential Measures We Report Monthly
| KPI | Typical target |
|---|---|
| Standing privileged role assignments | Two break-glass accounts per tenant only |
| Human IAM users or local accounts with keys | Zero |
| Time to remove a leaver's cloud access | Under 1 hour from HR exit |
| Median elevation approval time | Under 10 minutes |
Lock-Outs, Role Explosion and Other IAM Rollout Traps
| Risk | How NTSPL prevents it |
|---|---|
| Federation cutover locks the operations team out during an incident | Break-glass is tested before the first wave, and local admin users are deleted only after two weeks of clean federated use. |
| Generated least-privilege roles break batch jobs that run monthly | Activity baselines cover at least 90 days, and month-end jobs are tested in a shadow role before cutover. |
| Teams return to standing access because elevation is slow | Approval groups have three or more approvers across shifts and an SLA tracked on the monthly report. |
Native cloud IAM tools or a third-party PAM vault for cloud admins?
For cloud control-plane access, native tools win in most Indian estates. Entra PIM, Google Cloud Privileged Access Manager and Identity Center permission sets give just-in-time elevation with approvals and logs, at a fraction of the cost of a PAM suite, and they cannot be bypassed by signing in directly. A PAM vault such as CyberArk or a similar product still earns its place for session recording on servers, network devices and databases, and for shared OS root credentials. The usual answer is both: native elevation for the cloud consoles and APIs, the vault for host and database sessions.
Key facts: Identity & Access Management
Identity & Access Management in Practice
2 Identity & Access Management scenarios, from Capital markets (discount stock broker) and Urban mobility (ride-hailing and auto-rickshaw aggregation), plus related platform case studies.
Stock broker cuts permanent Azure admins from 11 to 2 with PIM and FIDO2 sign-in
Ride-hailing platform retires 324 IAM users and offboards leavers in under an hour
Health-tech SaaS moves patient data behind KMS and Identity Center ahead of DPDP
Three directories become one: identity consolidation after two acquisitions
Identity & Access Management: Frequently Asked Questions
How long does a cloud IAM redesign take and what does it cost?
For 200-600 cloud users across one or two clouds, expect 10-12 weeks. NTSPL fees are typically INR 12-25 lakh depending on vendor count and workload key replacement. Licensing is extra: Entra ID P2 or ID Governance for users who elevate, while AWS IAM Identity Center carries no separate charge.
Will engineers lose access during the migration?
No. Each team moves in a wave after a pilot, with federated and old access running side by side for up to two weeks. Local users and keys are deleted only after the team confirms clean federated use, and tested break-glass accounts cover any identity provider outage.
Does this help meet SEBI CSCRF or RBI requirements on privileged access?
Yes. SEBI's Cybersecurity and Cyber Resilience Framework of August 2024 and RBI's IT governance master direction both expect controlled, logged and reviewed privileged access. Time-boxed elevation with approvals, quarterly access reviews and 180-day sign-in logs give auditors direct evidence for those control areas.
What is phishing-resistant MFA and do we need it for every user?
Phishing-resistant MFA uses FIDO2 security keys, passkeys or certificate-based authentication, which cannot be relayed by a fake login page the way OTPs and push prompts can. We require it for anyone who can elevate to admin; standard users can stay on authenticator app MFA initially.
How do you handle service accounts used by on-premises systems?
On AWS we use IAM Roles Anywhere with certificates from your private CA. On Google Cloud, Workload Identity Federation can trust an on-prem OIDC or SAML issuer. On Azure, Arc-enabled servers receive a managed identity. Any system that cannot use these gets a key in a vault with 90-day rotation.
Can vendors keep their own logins?
Vendors with many staff on your estate should federate their own identity provider so their leavers are removed automatically. Smaller vendors sign in as guests with your MFA policy. Either way, they receive eligible roles scoped to their accounts that expire with the contract.