IBM Cloud Security Checklist: Score Your Account

Resources are organized in resource groups per environment (for example Dev, Test, Prod), not left in the Default group.

Resource groups are planned before instances are created, since the assignment cannot be changed afterwards.

User tags or access management tags organize, search and allocate costs for resources.

Every resource group has a named owner who answers for what runs in it.

Access is granted through access groups, one per required level of access, mapped to resource groups, not per-user policies.

Policies follow least privilege: only the access that is necessary, using resource groups, tags or time-based conditions to reduce policy count.

Administrator access to everything is limited to a few people, because it includes the ability to revoke other administrators.

Inactive policies and per-user access are reviewed on a schedule, and unused access is removed.

Access for inactive identities and policies is removed.

Multifactor authentication is enabled at the account level for every user, and single sign-on users are covered by their identity provider.

Federated users reach the account through trusted profiles with SAML attribute conditions and a session duration.

Applications on IBM Cloud compute use trusted profiles with compute conditions instead of service ID API keys.

API keys have expiry dates, the leaked-action setting is configured, and keys are rotated regularly.

API key creation is restricted by default, with explicit grants for the identities that need keys.

Security groups per tier are attached to the interfaces that need them, and the default security group is not used as a general rule set.

Rules name a specific CIDR or another security group as remote source; no rule is left with an empty remote field.

You know that with several groups attached, the least restrictive rule governs, and review all groups on an interface.

If network ACLs are used at the subnet, they are written in both directions because they are stateless.

Customer data is protected by root keys in Key Protect (or Hyper Protect Crypto Services), using envelope encryption.

Dual authorization is set for key deletion and a rotation schedule is defined.

Workloads that need single-tenant key control (Keep Your Own Key) have been evaluated for Hyper Protect Crypto Services.

The account-level Public Access group is disabled unless needed, and any public bucket has an owner and a reason.

Nobody sets public-read on objects, and temporary sharing uses expiring pre-signed URLs.

Activity Tracker Event Routing has a target and a route so account auditing events reach a place you can search.

Audit events reach IBM Cloud Logs (or another searchable target), and an archive in Cloud Object Storage is considered.

Someone watches audit events for suspicious API key use.

Security and Compliance Center posture and workload protection capabilities are in use, with an owner for each failing control.