The two-minute scorecard is a good way to open this. Most small business owners will answer "not sure" to at least three of those five questions, and "not sure" is the honest answer when the AWS account was set up by a contractor who has since left.
Point 2 is the one I see most often in handovers. The key belongs to a deployment script or a person who is gone, it still works, and nobody can say what would break if it were deleted. A credential report plus a short owner column for every key fixes most of that.
I would add one item for teams that buy infrastructure work as projects: write these five checks into the definition of done for any cloud engagement. Root MFA on, no root keys, no SSH or database ports open to the internet, account-wide S3 block, CloudTrail and GuardDuty in every region. Security then becomes part of what was delivered rather than a later audit. How often do you find GuardDuty enabled in only one region?
You're right about handovers. The contractor-built account is exactly where "not sure" comes from. For the orphaned keys, one thing that helps before deleting anything is to deactivate the key first rather than delete it. The credential report and "last used" data show when it was last active. If nothing breaks after a week or two, it's safe to delete. If something does break, you can switch it back on in seconds, and you've found its owner.
I really like the "definition of done" idea. It turns security from a later audit into an acceptance criterion, and it's easy to check at handover with a handful of read-only CLI commands. I might borrow that for a follow-up post.
On GuardDuty: when I find it enabled, it's often only in the main region the team works in. It has to be turned on per region (or auto-enabled across accounts through a delegated administrator in AWS Organizations), so the regions nobody uses are usually left uncovered. Those are the ones attackers like, because nobody is looking there. That's why the bonus loop in the article checks every region.
The two-minute scorecard is a good way to open this. Most small business owners will answer "not sure" to at least three of those five questions, and "not sure" is the honest answer when the AWS account was set up by a contractor who has since left.
Point 2 is the one I see most often in handovers. The key belongs to a deployment script or a person who is gone, it still works, and nobody can say what would break if it were deleted. A credential report plus a short owner column for every key fixes most of that.
I would add one item for teams that buy infrastructure work as projects: write these five checks into the definition of done for any cloud engagement. Root MFA on, no root keys, no SSH or database ports open to the internet, account-wide S3 block, CloudTrail and GuardDuty in every region. Security then becomes part of what was delivered rather than a later audit. How often do you find GuardDuty enabled in only one region?