Secure your Amazon Web Services surface
Your largest attack surface, watched continuously — public exposure, privilege escalation paths, and CloudTrail gaps. We don’t connect to Amazon Web Services 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 Amazon Web Services goes wrong
AWS goes wrong through accumulation: an account that was tight at launch drifts as teams add roles, buckets and security groups nobody revisits.
- S3 buckets and object ACLs exposed to the public internet or to any authenticated AWS principal
- IAM policies with wildcard actions, cross-account trust relationships, and access keys that have never been rotated
- Security groups permitting 0.0.0.0/0 on management ports, and NACLs that quietly undo them
- Unencrypted EBS volumes, RDS instances, and snapshots holding regulated data
- CloudTrail disabled in a region, or writing to a bucket nobody monitors
[02] What We Secure
What we watch, catch and fix on Amazon Web Services
What we watch on Amazon Web Services is what an attacker could actually reach, rather than every finding the API will return.
- Privilege escalation paths traced across roles — not just 'this policy is broad', but the specific chain from a low-privilege principal to admin
- Access key age and last-used data, so dormant credentials get revoked before they are found by someone else
- Public exposure detected at the moment it changes, with the responsible principal and the API call that caused it
- CloudTrail continuity monitored as a control in its own right, because a gap in the log is a gap in every other control
- Drift between the account as designed and the account as running, surfaced with the diff
[03] Where It Lands
Where Amazon Web Services 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 Amazon Web Services specifically
On Amazon Web Services, we revoke stale access keys, tighten security groups, and remediate public exposure directly where you have granted us that authority. Changes with blast radius — IAM role restructuring, encryption rollouts requiring downtime — we scope, sequence, and project-manage with your engineers.
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] Amazon Web Services FAQs
What AWS permissions does Konfirmity need?
Konfirmity uses a cross-account IAM role with SecurityAudit and ViewOnlyAccess as the baseline. Some controls need more than read-only — CloudTrail history and Config recorder state, for example — and we tell you which control requires each permission before you grant it. Remediation permissions are separate, opt-in, and scoped per action.
Does connecting AWS affect our bill or performance?
Connecting AWS adds no agents and no load to your workloads. API calls are read operations against control-plane endpoints, which are not billed. The one exception is CloudTrail data-event history, which you may already be paying for; we read what exists rather than enabling new logging without telling you.
Google Cloud Platform
Microsoft Azure
Kubernetes
Terraform
Docker