GuidesAct on an identity risk in your cloud account
On this page0

Guide

Act on an identity risk in your cloud account

Read the list of risky cloud users and access keys on a resource map, rehearse the fix Zonitix offers for an AWS access key, and make the real fix in your cloud account.

For: IT administratorPlan: Advanced

Before you start

  • This is an IT task. It assumes you can sign in to your cloud console and know what an access key is used for. If you do not look after your company’s cloud accounts yourself, do this together with the person who does.
  • A cloud account is connected and has been scanned. See Connect AWS, Azure or GCP.
  • A role that can view cloud infrastructure, to open the map. In the built-in set, administrators have that permission, and so do members of the “Security & Compliance” group. The “security_analyst” and “cloud_architect” roles have it too; no group carries them, so an administrator gives one to a person by hand, as Roles, groups and permissions shows.
  • For the “Remediate” button: a role that lets you manage compliance or manage security settings. In the built-in set, administrators can, and so can anyone an administrator has given the “security_analyst” role; Roles, groups and permissions shows how a role is given to a person.
  • Someone who may change users and access keys in the cloud account itself. Unless the server has been set otherwise, the “Remediate” button in steps 4 and 5 is a rehearsal: it records what it would do and changes nothing in AWS. The real fix is made in the cloud account, in step 6.

Read the risks

  1. Step 1: Open the list

    Go to Cloud InfrastructureAWS Resource Map (or the Azure or GCP map) and click “Identity Risks” at the top of the page. A panel opens on the right, titled for example “AWS Identity Risks”.

    Zonitix compares the users and keys in the cloud account with your employee list. The panel shows how many it looked at and how many of each risk it found.

  2. Step 2: Know the four risks on the AWS map

    The Azure and GCP maps list their own risks in the same panel, read the same way.

    • “Departed-employee key” (critical): The cloud user matches an employee who is no longer active, yet the user is still enabled or still holds a working access key.
    • “Orphaned access key” (high): A working access key belongs to a cloud user that matches nobody in your employee list.
    • “No MFA” (medium): The cloud user has no second factor registered.
    • “Stale access key” (medium): An access key is more than 90 days old.
  3. Step 3: Read a row

    Each row has “Severity”, “Risk”, “Principal” (the cloud user’s name), “Owner” (the matching employee’s email, or “unmatched”), “Detail” and “Action”.

    Under “Action” a row shows either a “Remediate” button or the word “manual”. “Export CSV” downloads the whole list.

Try the fix Zonitix offers (AWS access keys)

  1. Step 4: Click Remediate

    On a row with the button, click “Remediate”. A window asks “Deactivate 1 access key(s)?” (with the real number), names the cloud user, and says the action is audited. Click “Deactivate”.

    Zonitix may ask you to prove it is you again first. This is called step-up.

  2. Step 5: Read the message that comes back

    • A message starting “Dry run: would deactivate” means nothing was changed in your AWS account. Zonitix recorded what it would have done. Go to step 6.
    • A message starting “Deactivated” means the key was switched off in AWS, and the list refreshes.
    Out of the box this button only makes a dry run. Making real changes is a setting on the server, not a switch on any screen in the app, so nothing you click here turns it on. The connection the cloud guide sets up is read-only as well.

Make the fix in your cloud account

  1. Step 6: Fix it at the source

    For a dry run, for a row marked “manual”, and for every row on the Azure and GCP maps, the change is made in the cloud account itself, by someone who may change users and keys there:

    • A key of someone who has left, or a key nobody owns: switch the key off, or remove the user.
    • No MFA: have the user register a second factor.
    • An old key: replace it with a new one and switch the old one off.
  2. Step 7: Check again

    Back in the panel, click the refresh button at the top (its tooltip reads “Re-scan”). The row is gone once the cloud account no longer shows the problem.

What you should see

When nothing is left, the panel reads “No identity risks found — every principal maps to an active employee with MFA and fresh keys.”

Every use of “Remediate”, dry run or real, is in the audit log.

If something goes wrong

Every row says "manual" and none has a Remediate button
The button appears only on the AWS map, only for a risk that involves an access key (No MFA never has one), and only if your role lets you manage compliance or security settings.
"No principals were returned for this account, so nothing was assessed."
This is not a clean result. The connection could not list the users in the cloud account. Check the read permissions you gave it in Connect AWS, Azure or GCP, then click the refresh button.
A real person shows as "unmatched"
The cloud user’s name does not match anyone in your employee list, so Zonitix cannot tell who owns it. Check the row by hand before you switch anything off: it may be a service account that an application depends on.
The panel shows an error with a Retry button
The list could not be loaded. Click Retry. If it keeps failing, check the cloud connection is still verified in Identity Hooks.

Still stuck? See When something goes wrong, or Contact Zonitix support.

Where next