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

30. Cloud and AWS Security

30.8 Zero Trust

By Last updated:

Example first. In 2009, Google was hit by a big attack later called Operation Aurora. After that, Google stopped trusting its own office network. It built a system called BeyondCorp. Staff open work apps the same way from the office or from a cafe. Every request checks the person and the device. Being "inside" gives no extra trust.

Why it matters

The old model was a castle with a wall. Inside the wall, everyone was trusted. But once an attacker gets one password or one laptop, they are inside too. Then they can move everywhere. Today people also work from home, and apps live in the cloud. There is no single wall any more.

What it is

Zero trust means: never trust, always verify. No user, device or network is trusted by default. Every request must prove who it is, and gets only the access it needs.

WordSimple meaning
PerimeterThe outer wall of a network, like the office firewall.
Least privilegeGive only the access needed for the job, nothing more (Chapter 30.2).
Device checkIs this laptop company-owned, patched and running security software?
MicrosegmentationCutting the network into many small parts so one break-in cannot reach everything.
Assume breachPlan as if an attacker is already inside.
Old modelZero trust
Trust the office networkTrust no network
Check once at loginCheck every request
Wide access for staffOnly the apps you need

How to apply it

  1. Know your users, devices and apps. Make a list.
  2. Use strong identity: SSO (one login for all apps) plus MFA.
  3. Check the device before giving access.
  4. Give least privilege. Use short-lived access, not permanent keys.
  5. Split the network. A web server should not reach the HR database.
  6. Log every access and watch for strange requests.

Worked examples

Worked example 1: The office badge

Old way: show your badge once at the gate, then walk into any room.

Zero trust: tap your badge at every door. The finance room opens only for finance staff.

Worked example 2: Working from a cafe

  1. An employee opens the HR app on cafe Wi-Fi.
  2. The system checks: right person? MFA passed? Company laptop? Up to date?
  3. All yes: the HR app opens. Only the HR app, not the whole network.
  4. Laptop missing updates: access is blocked until it is patched.

Worked example 3: Zero trust in AWS

  1. Staff sign in with IAM Identity Center and MFA. No shared root login.
  2. Apps on EC2 use IAM roles, which give short-lived keys, not saved access keys.
  3. Security groups allow the database port only from the app servers.
  4. AWS Verified Access can open an internal web app only after checking the user and device.
  5. CloudTrail logs every API call for review.

Real incident: Target – entry through a vendor (2013)

1. What happened

In late 2013, attackers stole payment card data of about 40 million customers from the US retailer Target.

2. How it happened

  1. Attackers stole login details from a heating and air-conditioning vendor that worked with Target.
  2. They used the vendor's access to get into Target's network.
  3. The network was not split well, so they reached the payment systems in the stores.

3. How to stop it

  1. Give vendors access only to the one system they need.
  2. Split the network so vendor systems cannot reach payment systems.
  3. Check every request, even from known partners.

Real incident: Binance – one hacked DevOps laptop led to a $6.3 billion crypto theft (Oct 2026)

1. What happened

In this lesson you learnt zero trust: never trust a request just because it comes from inside the company or from a known person's device. Check the user, the device and the request every time, and give only the access that is needed. This real case shows what happens when one trusted laptop can reach the money.

  • Binance is the world's largest crypto exchange. An exchange is a company where people buy, sell and keep cryptocurrency.
  • On 29 October 2026, an attacker moved about $6.3 billion in crypto out of Binance wallets. Blockchain firm TRM Labs says most of it left in about 20 minutes. Experts call it the largest crypto theft on record.
  • Binance said its first investigation points to a compromised DevOps engineer's laptop. A DevOps engineer is a person who builds and runs the company's servers and deployments. From that laptop the attacker got into a service container (a small packaged program running on a server) and sent unauthorised withdrawal transactions.
  • Binance said it found no sign that its wallet private keys leaked. A private key is the secret that allows money to leave a crypto wallet. Instead, experts at Elliptic say the attacker got Binance's own systems to sign transactions for them.
  • Binance's co-CEO said it was not one person's mistake and not a "one-click" action, and that more points of breach were found later.
  • Binance paused all deposits and withdrawals, and said it will cover user losses from its own funds. Stablecoin companies such as Tether and Circle froze about $2.7 billion of the stolen money, as reported by TRM Labs.
  • TRM Labs and Chainalysis link the theft to TraderTraitor, a North Korean state hacking group also blamed for the $1.5 billion Bybit theft in 2025. Elliptic agrees it looks similar but asks for caution until the root cause is published. Binance has not named any group.

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

  1. The attacker took control of a DevOps engineer's laptop. The exact way is not public yet. Elliptic notes that this group often tricks staff into running malware, for example as a fake coding test or a fake job project.
  2. From the laptop, the attacker reached a service container inside Binance's network.
  3. Through that access, the attacker got Binance's hot-wallet signing system to sign transactions of their choice. A hot wallet is a wallet that stays online so that normal withdrawals can be sent quickly.
  4. TRM Labs says the attacker prepared for at least 36 hours, tested the plan on small wallets, and got a batch of signed approvals ready in advance.
  5. Then, in one fast burst, the hot wallet was told to send its whole balance to an address the attacker controlled.
  6. The money was quickly split and moved across many blockchains. Part of it was frozen; the rest is still with the attacker.

3. How to stop it / defend (this lesson: zero trust)

Why: in this case the network trusted the laptop, and the signing system trusted the container. Zero trust says each of these steps must be checked again, so one hacked device cannot reach the money.

Controls you can use:

  1. Treat every staff laptop as a possible way in. Keep it updated, run endpoint protection (EDR), and never run code or "tests" sent by strangers or fake recruiters on a work laptop.
  2. Split the network. A developer laptop should have no direct path to the systems that move money. Use a separate, locked-down machine for production work.
  3. Least privilege for services. A container should have only the one permission it needs, and nothing more. Review these permissions often.
  4. Short-lived access. Give engineers access for a few hours with a fresh check of user and device, instead of keys that work forever.
  5. More than one approval for big money moves. Large or unusual withdrawals should need two or more people, plus limits on how much can leave in one go.
  6. Watch for strange actions and stop them automatically. "Send the whole balance to a new address" should trigger an alert and a pause, not run straight away.
  7. Have a plan ready. Binance paused withdrawals and revoked the affected access fast. Practise these steps before a real attack.

Example 1: see who has full admin power (sudo) on a Linux laptop. Run these steps one by one.

  1. Open a terminal on the laptop.
  2. Run getent group sudo
  3. Output: one line, like sudo:x:27:devika,tom.
  4. What it means: the names after the last colon (here devika and tom) can run any command as the administrator. Each extra name is one more account an attacker could use. Keep this list as short as possible.

Example 2: check what an AWS service role is allowed to do.

  1. Open a terminal where the AWS CLI is set up with read access.
  2. Run aws iam list-attached-role-policies --role-name payout-service
  3. Output: a short JSON list, like {"AttachedPolicies": [{"PolicyName": "AdministratorAccess", ...}]}.
  4. What it means: here the payout service has full admin on the AWS account. That is far too much. Replace it with a small policy that allows only the one action the service needs. This is least privilege.

Example 3: see when an engineer's short-lived SSH certificate stops working.

  1. Your company signs a short-lived SSH certificate for you each morning. It is saved next to your key.
  2. Run ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub
  3. Output: several lines. One of them looks like Valid: from 2026-10-31T09:00:00 to 2026-10-31T17:00:00.
  4. What it means: this access works only for that day's working hours. If the laptop is stolen or hacked later, the certificate has already expired, so the attacker cannot use it to log in to servers.

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

  • [ ] I never run code, tests or files from unknown recruiters or strangers on my work laptop.
  • [ ] My laptop is updated and has endpoint protection turned on.
  • [ ] Developer laptops cannot reach payment or money systems directly.
  • [ ] Every service and container has only the permissions it needs, and we review them regularly.
  • [ ] Access to production is short-lived and checks the user and the device each time.
  • [ ] Big or unusual money moves need more than one person and are limited in size.
  • [ ] Alerts fire on unusual transactions, and we have practised how to pause and revoke access fast.

Source: BleepingComputer, "Binance links $6.3 billion crypto theft to compromised DevOps laptop" (Sergiu Gatlan), 30 October 2026; The Hacker News, "Binance Suffers Security Breach Affecting $6.3 Billion in Assets, Nearly $3 Billion Frozen" (Ravie Lakshmanan), 30 October 2026; TechCrunch (Zack Whittaker), 30 October 2026.

Check if you're safe: Password Strength Checker

In short

  • Zero trust = never trust, always verify.
  • Check the user, the device and the request every time.
  • Give least privilege and split the network.
  • Being inside the office network gives no extra trust.