Secure your IBM Cloud surface
Account-scope IAM policies, public COS buckets, and service IDs holding stale API keys. We don’t connect to IBM Cloud to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where IBM Cloud goes wrong
IBM Cloud goes wrong through scope drift: policies assigned at account level rather than resource group grow reach nobody re-examines.
- IAM policies assigned at account scope rather than to a resource group
- Cloud Object Storage buckets with public access enabled
- Service IDs accumulating API keys that outlive the systems using them
- Resource groups created without access control, becoming a shared free-for-all
- Activity Tracker absent or not retaining events long enough to investigate
[02] What We Secure
What we watch, catch and fix on IBM Cloud
On IBM Cloud we resolve effective access per identity across account, resource group and resource scope in one view.
- Effective access resolved per identity across account, resource group, and resource scope
- Service ID key inventory with age and last use
- Public bucket exposure detected against classification
- Resource group boundaries reviewed as isolation, since that is the role they play
- Event retention monitored against your investigation window
[03] Where It Lands
Where IBM Cloud lands in your registers
Every cloud resource we discover becomes an entry in your asset register with an owner, a criticality rating, and its data classification. Access reviews cover the IAM principals attached to it, and the risk register carries the mapping between the asset and the risks it actually carries — so a public bucket is a named risk against a named asset, not a line item in a scan report.
[04] How We Engage
On IBM Cloud specifically
On IBM Cloud, we revoke unused service ID keys and close public buckets. Resource group restructuring and IAM policy redesign we plan with your team.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] IBM Cloud FAQs
What IBM Cloud access does Konfirmity need?
Konfirmity needs we use a service ID with Viewer and Reader access at account scope, plus the ability to read IAM policy definitions. That covers inventory, access analysis and Activity Tracker review. The service ID's own API key is tracked and rotated like any other credential we hold.
Do you monitor service ID API keys?
Yes, including ours. Service IDs accumulate keys that outlive the systems using them, and an orphaned key with account-scope access is a standing risk. Konfirmity inventories every key with its age and last use so dormant ones can be revoked with confidence.
Amazon Web Services
Google Cloud Platform
Microsoft Azure
Kubernetes
Terraform