only care of active access key sets of users

[buzzdeee]

when gathering info of users, the number of access keys is added to a node. However, access keys might be Active or Inactive, so this might raise false positives when later on searching for risks in the analysis phase, or when querying.

Inactive access key sets can't be used, so consider them as if they were not there. The information whether a key is active or inactive is already fetched, so in the gathering phase, only take access key sets into account that have Status 'Active'.

When generating the analysis, and create the list of users that can potentially do harmful things without MFA, point out that this is the list of users that have active Keys.

This is the least invasive change I chose, otherwise there must be more info about keys stored into each user node.

[ncc-erik-steringer]

I agree that inactive keys will not be usable for API requests and can lead to false positives from this tool. I agree that we should track a separate active key count in order to correctly handle this scenario, which will also require doing a lot of work in the querying/local sim space.

However, I'm going to reject this for now for a couple reasons:

• This data is currently being used to identify if someone can access another IAM user by adding an access key for the user, in which case the status of the key does not matter. This change will break that edge check.
• The correct fix will be a breaking change, so I'm going to open a 1.1.0-dev branch to include these changes and put it in there.

I'll create the branch, milestone, and add issues when 1.1.0 work begins, probably by end-of-week.