IBM Cloud Security Engineer cheat sheet

Shared responsibility split in IBM Cloud: IBM secures the physical facilities, hypervisor, and managed-service infrastructure; the customer secures workloads, identities, data, and configuration of IaaS/PaaS resources they deploy.

The IBM Cloud Framework for Financial Services is the control set that underlies most IBM Cloud compliance postings; it is expressed as control families mapped to NIST CSF and is enforced through the IBM Cloud Catalog and account controls.

Account hierarchy: an IBM Cloud account belongs to exactly one enterprise (or stands alone); resource groups partition services inside an account; Cloud Foundry orgs/spaces are a separate legacy hierarchy and do not equal resource groups.

Governance guardrails available natively: IAM policies (allow), access groups, trusted profiles, context-based restrictions, and account settings such as 'public access' toggles for specific services; there is no native deny-policy engine, so deny is achieved by absence of allow plus CBR.

Tagging and policy: IBM Cloud Tagging attaches key:value metadata; account-level 'tag policies' can require tags before a resource is created, which is the primary mechanism for enforcing cost and ownership metadata.

A security architecture baseline on IBM Cloud typically layers: account isolation per environment, resource groups per workload, least-privilege access groups, CBR network zones, KMS-encrypted storage, and centralized logging to IBM Log Analysis or an external SIEM.

Risk register inputs specific to cloud: misconfigured public endpoints (COS buckets, VPC security groups), orphaned API keys and service IDs, unrotated HMAC keys, and unmonitored Activity Tracker routes.

Resource reclamation: IBM Cloud deletes or suspends resources for accounts in arrears; governance designs must not assume indefinite resource persistence and should export configuration state externally.

IAM policy tuple: subject (user, service ID, access group, or trusted profile) + role + resource (account, resource group, or specific CRN) + optional context (CBR rule). A policy with no resource attribute applies at account scope.

Platform roles are Reader, Writer, Editor, Administrator, Operator, Viewer; service roles are service-defined (e.g., Manager, Writer, Reader for many services). Platform roles govern resource lifecycle; service roles govern data-plane actions.

Access groups hold users, service IDs, and trusted profiles; policies attached to the group grant access to all members. Group membership is the recommended unit of audit, not individual user policy.

Trusted profiles allow federated identities (IBM Cloud Identity, external IdPs via compute resource tokens) to assume an identity without storing long-lived API keys; a profile has a trust relationship, conditions, and a linked access group.

API keys: IBM Cloud API keys are per-user or per-service-ID; they are shown once, cannot be retrieved later, and can be scoped to a single service ID. Classic infrastructure API keys are separate and must be managed independently.

Context-based restrictions (CBR) define network zones (IP/CIDR, VPC, service refs) and rules that allow or deny access to resources by zone; CBR is evaluated in addition to IAM policy and cannot grant access that IAM does not already allow.

Federation: IBM Cloud Identity supports SAML and OIDC enterprise IdPs; SCIM provisioning syncs users and groups. Identity provider metadata and signing certificates must be rotated before expiry or logins fail.

Authorization decision order: authenticate (token/API key) -> IAM policy evaluation (allow) -> CBR zone evaluation -> service-level authorization (service role). Any stage failing returns 403.

IBM Key Protect and Hyper Protect Crypto Services (HPCS) both provide key management; HPCS offers FIPS 140-2 Level 4 validated hardware with keep-your-own-key (KYOK) capability, while Key Protect is a multi-tenant FIPS 140-2 Level 3 service.

Key hierarchy: root key (created in KMS, never leaves the HSM boundary in plaintext) wraps a data encryption key (DEK); the service stores the wrapped DEK alongside the data and calls KMS to unwrap on access. Deleting the root key renders the data unrecoverable.

Envelope encryption integration: IBM Cloud Object Storage, Block/File Storage, Databases for *, and VPC block volumes support customer-managed keys via Key Protect or HPCS; each integration uses a specific 'key protect instance + root key' binding set at resource creation or via API.

Key states: Active, Suspended, Deactivated, Destroyed. Suspending a root key blocks unwrap operations, making dependent data unreadable without destroying the key; deactivation is a soft step before destruction and is reversible within a retention window.

Rotation: Key Protect supports automatic rotation policies with a configurable interval; rotation creates a new key version, and old versions remain available for unwrap of data encrypted under them, so rotation does not re-encrypt existing data.

COS data protection features: versioning, object lock (retention and legal hold), lifecycle rules, and immutability via bucket-level retention. Cross-region and cross-account replication support DR and separation of duties.

Data classification on IBM Cloud should drive key scoping: separate KMS instances (or at least separate root keys) per environment and per data class so that a compromised key does not span production and non-production.

Deletion safety: Key Protect requires a 'force delete' flag after a waiting period for root keys; enable this only with a documented break-glass process, because destruction is irreversible.

VPC constructs: a VPC spans a region and contains subnets bound to a single zone; a subnet has an associated ACL (stateless, per-subnet) and instances have security groups (stateful, per-instance). Default security group denies all inbound and allows all outbound.

Security groups are allow-only and stateful; there is no explicit deny rule. To block traffic you remove the allow. ACLs are stateless and support allow and deny rules, evaluated in order by rule number.

Public gateways provide egress/ingress to the internet for a subnet; a floating IP attaches public reachability to a single instance. Private-only subnets have no public gateway and no floating IPs.

VPC routing: custom routes in a routing table direct traffic to next hops such as a VPN gateway, transit gateway, or a virtual network interface of a firewall appliance. Default routes are per-subnet routing table association.

IBM Cloud Transit Gateway connects VPCs, classic infrastructure, and Direct Link across accounts and regions; it is the standard hub for multi-VPC segmentation and centralized inspection.

IBM Cloud Internet Services (CIS) provides edge protection: DDoS mitigation, WAF, TLS termination, and global load balancing. CIS sits in front of public endpoints; it does not protect private VPC traffic.

Private service endpoints: IBM Cloud services (COS, Key Protect, IAM) expose private endpoints resolvable via the 'private.' DNS suffix inside VPC; using them keeps service traffic off the public internet.

DNS Services in VPC allows custom resolver rules and forwarding to on-premises DNS over Direct Link or VPN; without it, VPC instances use the IBM-provided resolver at 161.26.0.10/161.26.0.11.

IBM Cloud Activity Tracker records account-level API events (who did what, when, from where) for control-plane actions; it does not capture data-plane object reads in COS unless the service emits them. Routes deliver events to IBM Log Analysis, COS, or Event Streams.

Activity Tracker event fields: action, outcome (success/failure), initiator (id, type, IP), target (CRN), requestId, and timestamp. Detection rules typically key on outcome=failure bursts and on sensitive actions such as IAM policy creation or key deletion.

IBM Cloud Log Analysis (IBM Log Analysis with LogDNA) ingests platform and application logs; VPC flow logs are delivered to COS or Log Analysis and capture 5-tuple, bytes, and accept/reject per flow for network forensics.

IBM Cloud Monitoring (Sysdig) captures metrics and can raise alerts on infrastructure signals; it is complementary to log-based detection and does not replace Activity Tracker for audit.

IBM Cloud Security and Compliance Center (SCC) evaluates resources against profiles built from the IBM Cloud Framework for Financial Services or custom controls, producing findings that can be routed to tickets or SIEM.

Incident response sequence on IBM Cloud: contain (revoke API keys, suspend service IDs, apply CBR deny, disable public endpoints) -> preserve evidence (export Activity Tracker to COS with object lock) -> eradicate -> recover -> post-incident control updates.

Break-glass: keep a documented emergency identity (e.g., a service ID with Administrator in a dedicated access group) whose use triggers an alert; its API key should be stored in a vault and rotated after each use.

Log retention: Activity Tracker routes have configurable retention in the target service; compliance regimes often require 90 days hot and one year cold, so plan COS archival with lifecycle and object lock.

IBM Cloud compliance posture is documented per service in the IBM Cloud Catalog 'Compliance' tab and in the IBM Cloud compliance page; a service's certification scope (e.g., PCI DSS, HIPAA, SOC 2, ISO 27001) is service-specific, not account-wide.

The IBM Cloud Framework for Financial Services maps controls to NIST CSF functions (Identify, Protect, Detect, Respond, Recover) and is the basis for SCC profiles; it is available to all customers, not only financial institutions.

Customer compliance responsibility: IBM attests to the infrastructure controls; the customer must evidence controls over identity, data, configuration, and monitoring. Audit artifacts such as SOC 2 reports are requested through the IBM Trust Center under NDA.

Data residency: IBM Cloud regions determine where data at rest resides; some services offer cross-region resiliency that replicates outside the primary region, which must be evaluated against residency requirements.

Architecture review checklist: account and resource-group isolation, IAM least privilege with access groups, CBR zones, KMS with customer-managed keys, private endpoints, flow logging, Activity Tracker routing, and SCC profile assignment.

Risk treatment on IBM Cloud follows the standard accept/mitigate/transfer/avoid model; compensating controls for a missing native feature are typically CBR, external inspection appliances in a transit gateway, or SCC custom controls.

Third-party and supply chain: catalog services may be IBM-built or third-party; the provider is identified on the service page, and the shared responsibility boundary shifts for third-party services.