Topic guide · 2 min read
Cloud security through identity
Short answer
In the cloud, identity is the main security boundary: protect it by federating every SaaS app with your identity provider, provisioning and deprovisioning with SCIM, granting least-privilege roles in infrastructure accounts, replacing static keys with workload identities, and logging every sign-in and permission change.
Key takeaways
- Most cloud incidents involve identity: stolen credentials, over-privileged roles, leaked access keys or misconfigured access.
- Replace long-lived access keys with federation for people and workload identity for services.
- Treat cloud admin roles as privileged access: MFA, just-in-time elevation and separate accounts.
Moving to the cloud did not remove security work; it moved it. The provider runs the data centers and the hypervisors. You decide who can sign in, what they can change and which services can talk to which. That is identity work.
What is your side of the shared responsibility model?
Identities, access configuration and data, in every service model.
| Service model | Provider secures | You secure |
|---|---|---|
| SaaS | Application, platform, infrastructure | Users, SSO, roles, sharing settings, data |
| PaaS | Runtime, platform, infrastructure | Code, app identities, data, access policies |
| IaaS | Physical, network fabric, hypervisor | OS, network rules, IAM roles, keys, data |
How do I secure SaaS applications?
Federate them, provision them with SCIM, restrict OAuth consents and review sharing settings.
- SSO through your IdP for every app, with local passwords disabled.
- SCIM for account lifecycle; see the provisioning guide.
- Restrict which third-party OAuth apps users may connect to email and files.
- Use vendor or government baselines, such as CISA's SCuBA configuration baselines for major productivity suites, to review settings.
- Export audit logs centrally.
The article on extending IAM to cloud apps walks through a full rollout.
How do I secure infrastructure accounts?
Federate human access, grant least privilege, and replace stored keys with workload identities.
- People sign in through SSO with phishing-resistant MFA and assume roles; no individual long-lived access keys.
- Separate accounts or projects per environment, with guardrails at the organization level.
- Roles scoped to tasks; review unused permissions regularly.
- Break-glass accounts locked away and monitored.
- Services use platform-issued workload identities; CI/CD pipelines use OpenID Connect federation to obtain short-lived cloud credentials instead of stored secrets.
How do cloud services reach on-premises systems?
Through gateways or private connections, with every call authenticated and tokens limited to one audience.
The pattern is covered in calling on-premises services from the cloud: mTLS or signed assertions for the workload, token exchange for the user, and an API gateway at the boundary.
Which web protections still matter?
TLS 1.2 or 1.3 only, HSTS, a content security policy and the usual security headers on every web interface you publish.
Generate a header set with the Security Header Builder and test it in report-only mode first.
What should be monitored?
Sign-ins, role assignments, key creation, policy changes, public exposure of storage, and unusual API use.
Cloud providers emit control-plane logs. Keep them in a separate, write-protected account, and alert on new admin grants, new access keys, disabled logging and storage made public. For frameworks auditors use, see cloud security standards.
Questions
What is a workload identity?
An identity issued by the platform to a running service, such as a role assumed by a container or function, with short-lived credentials obtained automatically. It removes the need to store access keys in code or configuration.
What is CIEM?
Cloud infrastructure entitlement management: tools that analyze the permissions granted across cloud accounts, find unused and excessive privileges and help right-size them.