Ravindra BagaleCourses & study guides मराठी Track your progress

30. Cloud and AWS Security

30.2 IAM Done Right

By Last updated:

In short: IAM (Identity and Access Management) is the front door of your account.

Quick answer: the short, self-contained version of this lesson is the guide Cloud IAM Least Privilege.

IAM (Identity and Access Management) is the front door of your account. Get this right and most attacks fail.

1. Lock the root user. The root user (your sign-up email) can do everything, including closing the account.

  • Enable MFA on root (IAM console, Security credentials, Assign MFA device).
  • Delete any root access keys. Root should never have keys.
  • Use root only for billing and account-level tasks; do daily work as an IAM user or through IAM Identity Center.

2. MFA for every human. A stolen password alone should never be enough.

3. Least privilege. Give only the permissions a job needs. Compare:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::reels-media-pune/*"
  }]
}

This policy lets the app read and write objects in one bucket. Attaching AdministratorAccess to the app instead would let one bug in your PHP code hand an attacker your whole account.

4. Roles, not access keys. An EC2 instance should get permissions from an IAM role (you did this in Chapter 16), which gives short-lived credentials that rotate automatically. Long-lived access keys in code or ~/.aws/credentials on a server are the most common way cloud accounts get stolen.

5. Review regularly. IAM, Credential report (download CSV) shows who has MFA, old passwords and unused keys. IAM Access Analyzer flags resources shared outside your account.

aws sts get-caller-identity                     # who am I right now?
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > cred-report.csv
aws iam list-access-keys --user-name dev-sanket  # any old keys?

Ravindra Bagale's Tip

The biggest mistake: writing an access key into your code and pushing it to GitHub. Bots scan public repos within minutes and use the key to start crypto-mining servers – and the bill comes to you. A key should never be in code. Use a role on EC2, aws configure on your laptop, and .gitignore. If it does get pushed, deactivate the key immediately (30.6).

Lab

In your own account: (1) enable MFA on root and on your IAM user, (2) download the credential report and find any user without MFA, (3) create a policy that allows only s3:GetObject on one test bucket, attach it to a test user, and prove with the CLI that s3:PutObject is denied (AccessDenied). Delete the test user afterwards.

Real incident: Ginkgo Bioworks – data taken from old, forgotten cloud environments (Oct 2026)

1. What happened

On 8 October 2026, US biotech company Ginkgo Bioworks said it had recently discovered that an unauthorised third party accessed data from cloud environments mainly linked to its former biosecurity business. The company believes the data came primarily from legacy cloud environments – older cloud setups left over from a business it no longer runs the same way. Ginkgo said it cut off the intruder's access, rotated credentials, took some legacy systems offline as a precaution, and found no evidence the intruder still had access or reached other environments. Its core systems, including financial systems, were not interrupted. The company was clear: this was not a ransomware or encryption event. It informed the FBI and notified customers whose data was involved. Ginkgo has not said how many people were affected, what kind of data was taken, or when the access happened.

2. How the hack happened (public reporting only – high-level)

  1. A company keeps old cloud environments running from a past business line – fewer people watch them, and their access rules may be years old.
  2. An outsider gets access to those legacy environments (Ginkgo has not published the exact entry path).
  3. The outsider reads and takes data stored there – no encryption, no ransom note, so nothing "breaks" that would alert staff quickly.
  4. The company discovers the access, cuts it off and rotates credentials – which tells us access credentials were a key part of the clean-up.
  5. Legacy systems are taken offline and checks confirm the main environments were not reached.

3. How to stop it / defend (this lesson: IAM Done Right)

  • Every cloud account needs an owner. When a business unit closes or is sold, someone must either shut down its cloud accounts or hand them over formally – never just leave them running.
  • Rotate and remove old credentials. Use the IAM credential report from this lesson to find access keys and users nobody has used for 90+ days, and disable them.
  • Least privilege on legacy data too. Old buckets and databases should be locked to a small read-only group, or moved to archive with strict access.
  • Same logging everywhere. Turn on CloudTrail (Chapter 30.5) in old accounts as well as new ones, so access to forgotten data still raises an alert.
  • Delete data you no longer need. Data that does not exist cannot be stolen.

4. How to take care so it won't happen again (checklist)

  • [ ] Make a list of every cloud account and project you have, with an owner name next to each.
  • [ ] Mark which ones belong to old projects, closed teams or past clients.
  • [ ] For each old one: delete it, or archive the data and lock access down.
  • [ ] Download the credential report every month and disable unused keys and users.
  • [ ] Check that CloudTrail and alerts are on in every account, not just the main one.
  • [ ] India students: the same applies to old client projects at IT companies – when a project ends, remove access and clean up its cloud accounts. Report major incidents to CERT-In within the required time (see Ch.34).

Source: Ginkgo Bioworks press release "Ginkgo Bioworks Cybersecurity and Incident Response", 8 October 2026, as reported by TSN Media, "Cyber Breaches, 9 October 2026", 9 October 2026.

Check if you're safe: Website Security Checklist

Real incident: ConnectWise Cloud Backup (SkyKick) – one stolen vendor app secret used to sign in to hundreds of Microsoft 365 tenants (Oct 2026)

1. What happened

ConnectWise Cloud Backup (earlier called SkyKick) is a backup service that managed service providers (MSPs) use to back up their clients' Microsoft 365 mail, OneDrive, SharePoint and Teams data. To do that job, every client gives the backup app broad read and write permission in its Microsoft 365 tenant.

  • On 15 October 2026, someone signed in to customer tenants as the backup app itself, using the app's own secret credential, and received Microsoft Graph access tokens.
  • Huntress confirmed unauthorised sign-ins in 173 tenants it protects. Its later update said almost 1,000 Microsoft tenants saw sign-in activity from the attacker's server, and more than 300 of those sign-ins succeeded.
  • Microsoft Threat Intelligence called it an active supply-chain attack. It said the attacker likely abused permissions customers had already given the app, including the very powerful Directory.ReadWrite.All.
  • ConnectWise published an advisory on 16 October, disabled seven of its app identities on 17 October and suspended the backup service. It said it has no evidence the stored backup archives were accessed.
  • The reports do not yet say how the attacker got the vendor's credential, and how much data was read is still unclear. Educational framing only.

2. How the hack happened (public reporting only – high-level)

  1. When a company connects the backup app, Microsoft Entra ID creates an app identity (service principal) for it inside that company's tenant, with the permissions the admin approved once.
  2. The app proves who it is with a secret or certificate kept in the vendor's own environment. The same credential works in every tenant where the app is installed, so one stolen credential opens many companies at once.
  3. A script signed in as the app to tenant after tenant, a few seconds apart. This is an app-only sign-in: no user and no phone, so MFA never comes into the picture.
  4. The tokens carried the app's existing rights – read and write mail, files, Teams chats and directory data. Microsoft also saw Graph reconnaissance and attempts to add extra credentials as a backdoor.
  5. In about 50 tenants, ConnectWise Cloud Management apps gave themselves admin roles, mostly Exchange Administrator. In one tenant, a Cloud Management app made itself Global Administrator and added new secrets to two other trusted apps – an MSP management tool and Huntress's own security app. A secret added like this keeps working even after the vendor app is switched off. Huntress has not yet confirmed whether this earlier activity was the same operator.
  6. It was hard to see: these sign-ins show only on the separate Service principal sign-ins tab, not the default user sign-ins tab, and directory reads through Microsoft Graph leave no audit trail.

3. How to stop it / defend (this lesson: IAM done right)

  • Least privilege applies to apps and vendors too. Before you approve a third-party app, read the permissions it asks for. Ask the vendor why it needs directory write rights or admin roles.
  • Remove apps you no longer use. ConnectWise asked partners to check even tenants with dormant SkyKick connections. An old, forgotten app with big permissions is an open door.
  • MFA does not protect app identities. Protect them with the controls built for them: Conditional Access for workload identities (allow sign-in only from the vendor's expected locations), app management policies that block or shorten client secrets, and very few people holding the Application Administrator roles.
  • The same idea in AWS: give a vendor an IAM role with an External ID and a narrow policy, never long-lived access keys. Watch CloudTrail for a vendor role that creates access keys or attaches policies to itself, and use IAM Access Analyzer to list everything shared outside your account.
  • Alert on these events: an app adding itself to a directory role, an app changing other apps, or new credentials appearing on an app (SOC and SIEM, Chapter 31).
  • During an incident: disable the vendor app (don't delete it), save the sign-in and audit logs early because they are kept only for a limited time, and remember that tokens already issued stay valid until they expire. Revoking user sessions does not stop app access.

4. How to take care so it won't happen again (checklist)

  • [ ] If you use ConnectWise Cloud Backup or Cloud Management (or older SkyKick apps), follow the ConnectWise advisory: keep the listed apps disabled until ConnectWise gives restore steps, and check service principal sign-ins from 13 October 2026 onwards.
  • [ ] Review the secrets and certificates on all your apps and remove any you did not create.
  • [ ] Remove any directory role you never meant to give an app.
  • [ ] Keep a list of every third-party app in your tenant or AWS account, its owner, its permissions and when it was last used.
  • [ ] Turn on alerts for app role changes and new app credentials.
  • [ ] Plan for a backup vendor outage: know how you would restore if the backup service is suddenly suspended.

Source: Huntress, Jonathan Semon, "ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks", 16 October 2026 (updated 17 October 2026); BleepingComputer, Ionut Ilascu, "Hackers breach Microsoft 365 tenants via ConnectWise supply-chain attack", 17 October 2026; The Hacker News, Ravie Lakshmanan, "Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants", 17 October 2026 (quoting Microsoft Threat Intelligence and Todyl); ConnectWise Trust Center advisory "Cloud Backup (formerly known as SkyKick) Service Interruption", first published 16 October 2026, updated 18 October 2026.