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

30. Cloud and AWS Security

By Last updated:

Chala mitrano, Chapter 12 te 16 madhe tumhi AWS var EC2, S3, RDS vaprun purna app chalavla. Aata prashna asa: te surakshit aahe ka? Cloud madhe sarvat jast breaches hack mule nahi, tar chukichya settings mule hotat – public S3 bucket, GitHub var takleli access key, sagalyasathi open security group. Ya chapter madhe AWS cha "Shared Responsibility Model" samjun ghevu, ani tumchya account la step-by-step lock karu. Ghabru naka, he sagle console madhe kahi clicks che kaam aahe. Samjla ka? Chala!

What you will learn in this chapter

  • The Shared Responsibility Model: what AWS secures and what you secure
  • IAM done right: root account, MFA, least privilege, roles instead of keys
  • Network security: security groups, NACLs, private subnets
  • Data protection: S3 Block Public Access, encryption with KMS, secrets
  • Detection: CloudTrail, GuardDuty, AWS Config and Security Hub
  • EC2 metadata (IMDSv2) and SSRF, plus an incident checklist for leaked keys

Scope for this chapter

Work only in your own AWS account. Testing someone else's cloud account, bucket or instance without written permission is illegal. Watch the Free Tier: turn off paid services (GuardDuty, Config, Security Hub trials) after the lab if you do not need them, and keep a billing alarm on (Chapter 12).

Concepts in this chapter

  1. 30.1The Shared Responsibility Model
  2. 30.2IAM Done Right
  3. 30.3Network Security in AWS
  4. 30.4Protecting Data: S3, Encryption and Secrets
  5. 30.5Detection: CloudTrail, GuardDuty, Config and Security Hub
  6. 30.6EC2 Metadata, SSRF and a Leaked-Key Incident Checklist
  7. 30.7Red vs Blue, Project and Real Incidents
  8. 30.8Zero Trust

The chapter recap is at the end of the last concept page.

Chapter 30: Cloud and AWS security — practice tasks

Open chapter lessons · Full guided lab: secure new aws account root mfa cloudtrail (not repeated here)

30.1 Root account checklist (paper)

EasyIT

Why: Root keys in daily use is a critical finding.

What: Mark each practice Safe or Fix.

Data file: root.csv

PracticeStatus
Root MFAOn
Root access keysCreated
Daily console login as rootYes

About this file: Made-up root account habits. Each row is one practice. Columns: Practice = habit; Status = current state.

How:

  1. Read the data file.

Expected output: MFA on Safe; access keys on root Fix; daily root login Fix.

Hint

Use an IAM admin user instead.

Answer / how to check
  1. Two Fix items.

30.2 Enable CloudTrail in your account

MediumBanking

Why: Without logs you cannot investigate.

What: Turn on a multi-region trail in your own AWS account.

How:

  1. AWS Console → CloudTrail → Create trail.
  2. Send to a private S3 bucket.
  3. Make a harmless API call; find it in Event history.

Expected output: Event appears within minutes.

Hint

Never make the log bucket public.

Answer / how to check
  1. You can search for your user name.

30.3 Restrict a security group

EasyLogistics

Why: 0.0.0.0/0 on admin ports is the classic cloud hole.

What: Edit a lab SG: SSH only from your IP.

How:

  1. Find the SG of your lab EC2.
  2. Change SSH source to your.public.ip/32.
  3. Try SSH from another network (phone hotspot) — should fail.

Expected output: SSH works only from home IP.

Hint

Keep 443 open if it is a web server.

Answer / how to check
  1. Hotspot SSH times out.

Extended teaching notes

Why this lesson matters

Part 11 turns tool skills into professional defensive practice: web risks, cloud, SOC work, hardening, cryptography, Indian law and careers. Every example below stays inside systems you own or public teaching material.

Indian company (sample data)

Suppose we are a junior security engineer at an Infosys or TCS client project. You take this lesson's checklist, map it to three production services (for example a Spring Boot API, a Node.js portal and a Python job), and open tickets with evidence and owners.

Global practice

Follow public guidance from OWASP, CERT-In, CISA and cloud provider Well-Architected / security pillars. Cite them in reports.

Everyday analogy

A cricket team that only practises hitting but never fielding loses matches. Offence skills in a lab exist to improve fielding in real systems.

Apply across stacks

Wherever code appears, ask the same questions.

Java / Spring Boot

Parameterise queries, encode output, limit Actuator, patch dependencies.

.NET

EF Core parameters, HTTPS, Data Protection API, patch NuGet.

Node.js

helmet, parameterized SQL, npm audit, lockfiles.

Python

ORM, autoescape, pip-audit, Bandit.

Go / PHP / Ruby

Safe templates, prepared statements, govulncheck / composer audit / Brakeman.

nginx / Apache / Tomcat

Hide versions, TLS, least-open ports.

MySQL / PostgreSQL / MongoDB / Redis

No public ports, auth on, least-privilege users.

AWS / Azure / GCP

Roles not keys, private data stores, cloud logs on.

Defender worksheet

  1. Write a 5-line summary.
  2. Name one related public breach or advisory.
  3. Practise one safe command on a lab you own.
  4. Write the fix for a teammate.

Recap

  • Permission first.
  • Fix over spectacle.
  • Evidence in notes.

Defender's worksheet (do this today)

  1. Write the lesson title and date.
  2. List three owned systems where it applies.
  3. Run one safe lab check and paste evidence.
  4. Write a two-sentence fix for a teammate.
  5. Note one CERT-In or CISA advisory that relates (title + date).

Indian workplace (sample)

At a Wipro or LTIMindtree client SOC, turn this lesson into one playbook step with an owner and a due date.

Global practice

Compare your notes with OWASP, CIS Benchmarks or a cloud Well-Architected security question. Write the overlap in five lines.

Family test

Explain the risk and the fix without jargon. If a parent or sibling can repeat the warning, you are ready to teach juniors.

Common mistakes

  • Skipping permission.
  • Tool collecting without fixing.
  • Publishing lab screenshots that contain secrets.
  • Treating encoding as encryption.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.

Key terms for this page

  • Control: a safeguard (patch, config, process).
  • Finding: a weakness with evidence.
  • Remediation: the fix and how you verified it.
  • Scope: systems you are allowed to touch.
  • Least privilege: only the access required for the task.
  • Defence in depth: several controls in layers.

Mini case study

Suppose we are a junior engineer at Zoho or Freshworks (sample data). A weekly review asks each person to present one control from their area. You pick a control from this lesson, show a before/after screenshot from a lab, and list the production ticket you would open. That habit builds both skill and credibility.