Cloud Security Full Course | EP:01 | Cloud Security in Hindi | Security Fundamentals | PentestHint

Main ideas / lessons conveyed

What “cloud” is and why it exists

• Before cloud computing, organizations had to host services themselves (e.g., web hosting, email hosting) by purchasing/maintaining hardware and hiring teams to manage troubleshooting and traffic.
• This was inefficient when demand spikes (e.g., a university results announcement increases website usage suddenly).
• Cloud computing helps by letting users scale/upgrade resources without repeatedly changing physical servers.

Cloud reduces operational burden and cost

• In the cloud, you subscribe to services rather than manage hardware teams.
• Examples given:
  • Email services via a provider (example mentioned: Microsoft Outlook / email subscriptions; also a “Provided Consulting.com” example for email sending).
  • Collaboration tooling mentioned: Microsoft Teams (described as rented software/services in the cloud).

Cloud isn’t “magic,” it’s remote infrastructure

• “Cloud” is described as standard server infrastructure that you access remotely.
• Performance depends on server configuration:
  • RAM, storage, and response time (illustrated with data centers like Instagram/Facebook).
• Users can remotely manage hardware and software in cloud environments.

Two cloud concepts: service models + deployment models

• Deployment models mentioned:
  • Public cloud
  • Private cloud
  • Hybrid cloud
• Service models emphasized:
  • IaaS as “infrastructure as a service” (speaker intended to distinguish the service layers; some text appears partially mis-transcribed).

Examples of deployment models (contextual use cases)

• Public cloud: services accessible over the internet.
• Private cloud: data/services should not be exposed publicly; access restricted (example: internal employee/leave portal; VPN + IP whitelisting).
• Hybrid cloud: combination of public + private depending on where processing vs publishing happens (example concept: private data analytics with public-facing results).

Cloud penetration testing feasibility across deployment types

Cloud penetration testing is possible in all three types, but access/constraints differ:

• Public cloud pentesting: test endpoints accessible from the public internet.
• Private cloud pentesting: requires VPN or being inside the infrastructure to reach private IPs.
• Hybrid cloud pentesting: targets both public-accessible portions and private sections (depending on access paths).

---

Method / workflow for cloud penetration testing (as described)

1) Read and follow cloud provider policies (permission/compliance step)

• Cloud penetration testing differs from normal pentesting because cloud providers impose specific rules and restrictions.
• Some actions may be prohibited depending on the provider/environment (e.g., “in AWS…/in Azure…” style restrictions—wording may be distorted).
• Because actions can be blocked or violate terms:
  • Always read provider policy first.
• Testing may require explicit written authorization:
  • The speaker suggests contacting the provider (example mentioned: Microsoft Azure) and waiting for confirmation/permission.

2) Create a cloud pentesting plan before executing

The plan includes:

• Identify endpoints

  • An “endpoint” is where you connect to reach an application/service.
  • Endpoints can include:
    • APIs
    • Protocols
    • Ports (e.g., 0–1023 described as “known” ports; mention that companies can change ports like 8080)

• Scope the testing to allowed components

  • If testing a web application, test only that app’s relevant endpoints/services (not the entire environment).

• Consider billing/usage constraints

  • Cloud billing is based on usage (examples mentioned: per click/visit/traffic).
  • High traffic or repeated actions can inflate the bill quickly.

• Design testing to avoid breaking availability

  • The site has a practical threshold for concurrent users/load.
  • Therefore:
    • control request rates and distribute load carefully.

• Define where you can access

  • Public endpoints vs VPN/private IP access paths.

3) Execute the plan, then detect and fix vulnerabilities

• During execution, typical pentest targets include:
  • Open endpoints/services (general references to common protocols/ports such as FTP/SMTP).
  • Insecure APIs
    • The speaker emphasizes weaknesses in authentication/authorization:
      • Attempt to exploit authN/authZ issues.
• The approach is similar to normal pentesting, but:
  • cloud policy restrictions affect what you can do.

4) Handle operational and security controls specific to cloud

• Monitoring / detection
  • Use monitoring tooling/telemetry to distinguish legitimate user activity from attacks (speaker references Apache tooling/monitoring concepts).
• Network distribution via CDN
  • Use a CDN (Content Delivery Network) to serve traffic from nearby regions rather than hammering one backend location.
  • Provider example mentioned: Amazon CloudFront
  • Benefit: improved resilience and reduced backend load impact.

---

Key conceptual comparisons (IaaS vs higher-level services)

The speaker breaks down “who controls what”:

• On-premises (full control required)

  • To manage fully, you handle:
    • application, data, runtime, middleware, operating system, virtualization, server, storage, networking

• Infrastructure as a Service (IaaS)

  • User controls more than higher-level services, but not everything.
  • In general framing:
    • you manage application + data
    • the provider manages underlying infrastructure aspects like server/storage/networking

• Platform/software managed services (limited control)

  • You do not manage operating system configuration details.
  • Example cited: Microsoft Office 365 (described as not giving access to OS/config).

---

Tools / practical learning resources mentioned

• Cloud provider practice recommendations

  • DigitalOcean
    • Suggested as suitable for learning/testing with low cost (example mentioned: “$5/month”).
    • Speaker notes these providers may have limited transparency about restrictions.
  • AWS
    • Mentioned as offering free subscription for a year (with email signup).

• Containers and learning environments

  • Containerization is described as a way to run repeatable testing environments without heavy virtualization overhead.
  • Mentioned:
    • Docker
    • Kubernetes (appears later as an orchestrator)

• Container-based pentesting use case

  • Example workflow described:
    • Pull a “Open Security Mobile Security Framework”-type container image (name appears partially exact/approximate).
    • Run it with specified ports (example: 8000).
    • Access it via a local IP/loopback (example: 127.0.0.1).
  • Benefit:
    • tools/dependencies run inside the container rather than being installed on the host OS.

---

Security/coding issues discussed as causes of vulnerabilities

• Vulnerabilities arise from misconfiguration and insecure coding, even if the infrastructure is “safe.”
• Examples (high-level):
  • Developers focus on time/space complexity and may still miss safety checks that lead to memory/buffer issues.
  • Buffer overflow-type logic is mentioned as an example of what developers might fail to prevent.

---

Cloud testing limitations / policy challenges (explicitly stated)

• Lack of transparency
  • Providers may not disclose full restrictions (example: DigitalOcean allegedly doesn’t show all run restrictions).
• Re-testing the same server can change results
  • Policies and cloud behavior can alter outcomes between runs.
• Best practice proposed
  • After the security audit, create repeatable test cases and document the methodology/procedure for future use.

---

What the speaker said about the session structure / next steps

• Wrap-up of “today’s session”:
  • cloud fundamentals + cloud pentesting basics.
• Next session/topics promised (future lectures):
  • More on Azure and Google Cloud Platform (GCP)
  • Which tools are suitable for penetration testing
  • How to read policies and identify allowed/disallowed actions
  • Approaches to handle “lock of transparency”
• Mentions continuing components:
  • Docker/Kubernetes
  • a platform/console for running instances and practicing

---

Speakers / sources featured (as mentioned in subtitles)

• PenTestHint (video/channel brand)
• Microsoft Azure
• Amazon Web Services (AWS)
• Google Cloud Platform (GCP)
• DigitalOcean
• Microsoft Office 365
• Microsoft Teams
• Apache (monitoring/tooling referenced)
• Amazon CloudFront (CDN example)
• Docker
• Kubernetes
• Open Security Mobile Security Framework (container/tool example)
• Open Security / “Mobile Security Framework” (named tool component)
• Paytm (payment gateway/API example context)
• Google (example source for public data in the COVID example)