Security+ Academy · पाठ

क्लाउड भंडारण सुरक्षा और डेटा उजागर होने के जोखिम

जानिए कि गलत तरीके से कॉन्फ़िगर किए गए S3 बकेट, Azure Blob कंटेनर और GCS बकेट डेटा को कैसे उजागर करते हैं तथा बकेट नीतियाँ और अभिगम नियंत्रण कैसे लागू करें।

पाठ 2, कुल 4 में से13 चरण

क्लाउड भंडारण सुरक्षा और डेटा उजागर होने के जोखिम, CoddyKit पर Security+ Academy का एक निःशुल्क पाठ है। यह 4 में से 2वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Security+ Academy सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Security+ Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

Cloud Object Storage की मूल बातें

Cloud object storage — AWS S3, Azure Blob Storage और Google Cloud Storage (GCS) — files को flat namespaces में objects के रूप में store करता है, जिन्हें buckets या containers कहा जाता है। Traditional file systems के विपरीत, permissions filesystem ACLs के बजाय buckets और objects से जुड़ी policies के माध्यम से नियंत्रित होती हैं। Object storage बड़े पैमाने के data के लिए आदर्श है, लेकिन permissions का सावधानीपूर्वक configuration आवश्यक है, क्योंकि एक गलत configured bucket सार्वजनिक internet पर terabytes संवेदनशील data उजागर कर सकता है।

Public Bucket के गलत कॉन्फ़िगरेशन

Cloud storage की सबसे आम vulnerability एक सार्वजनिक रूप से सुलभ bucket है — ऐसा storage bucket जिसकी access policy anonymous read access (या write access) की अनुमति देती है। इस गलत configuration के कारण दर्जनों बड़ी breaches हुई हैं: Verizon (14M customer records), FedEx (119,000 passports), Capital One (100M credit card applications)। Attackers सभी ज्ञात AWS account naming patterns में public buckets खोजने के लिए automated scanners का उपयोग करते हैं, इसलिए misconfiguration मौजूद होने के बाद खोज करना बहुत आसान हो जाता है।

# Check if S3 bucket is publicly accessible
aws s3api get-bucket-policy --bucket my-bucket
aws s3api get-bucket-acl --bucket my-bucket

# Block all public access (AWS recommended default)
aws s3api put-public-access-block \
  --bucket my-bucket \
  --public-access-block-configuration \
  'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'

Bucket Policies बनाम ACLs

Cloud storage में access controls के दो प्रकार होते हैं, जो एक-दूसरे से conflict कर सकते हैं। Bucket policies bucket से जुड़े JSON documents होते हैं, जो परिभाषित करते हैं कि कौन-से principals कौन-सी actions कर सकते हैं। Access Control Lists (ACLs) legacy per-object permission grants होती हैं। AWS consistency के लिए ACLs को Disable करके bucket policies का उपयोग करने की सलाह देता है। जब दोनों मौजूद हों, तो सबसे अधिक अनुमति वाली policy प्रभावी होती है — अर्थात अत्यधिक अनुमति वाला ACL, bucket policy के access को restrict करने पर भी public access दे सकता है।

# S3 bucket policy example — restrict to specific account
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': { 'AWS': 'arn:aws:iam::123456789012:root' },
    'Action': 's3:GetObject',
    'Resource': 'arn:aws:s3:::my-bucket/*'
  }]
}
# All other principals implicitly denied

Object Storage में स्थिर अवस्था में एन्क्रिप्शन

Cloud storage providers स्थिर अवस्था में objects के लिए server-side encryption देते हैं। SSE-S3 (AWS) AWS-managed keys का स्वतः उपयोग करता है। SSE-KMS AWS Key Management Service में customer-managed keys का उपयोग करता है, जिससे बेहतर audit trails (हर decryption CloudTrail में logged होता है) और key rotation control मिलता है। SSE-C customer-provided keys का उपयोग करता है, जिन्हें customer पूरी तरह AWS के बाहर manage करता है। संवेदनशील data के लिए customer-managed keys वाला SSE-KMS सबसे मजबूत control और compliance evidence देता है।

# Enforce encryption on S3 bucket (deny unencrypted uploads)
{
  'Effect': 'Deny',
  'Principal': '*',
  'Action': 's3:PutObject',
  'Resource': 'arn:aws:s3:::my-secure-bucket/*',
  'Condition': {
    'StringNotEquals': {
      's3:x-amz-server-side-encryption': 'aws:kms'
    }
  }
}

ट्रांज़िट के दौरान एन्क्रिप्शन

स्थिर अवस्था में सही तरह encrypted data भी उजागर हो सकता है, यदि उसे unencrypted channels से भेजा जाए। सभी cloud storage APIs को केवल HTTPS/TLS के माध्यम से access किया जाना चाहिए। S3 में bucket policies aws:SecureTransport: false वाले requests को Deny करके HTTPS लागू कर सकती हैं। Pre-signed URLs — अस्थायी authenticated URLs, जो objects तक सीमित समय के लिए access देते हैं — में हमेशा HTTPS का उपयोग होना चाहिए और exposure की अवधि कम करने के लिए उनका expiration time छोटा रखा जाना चाहिए।

# S3 bucket policy — deny HTTP (require HTTPS)
{
  'Effect': 'Deny',
  'Principal': '*',
  'Action': 's3:*',
  'Resource': ['arn:aws:s3:::my-bucket', 'arn:aws:s3:::my-bucket/*'],
  'Condition': {
    'Bool': { 'aws:SecureTransport': 'false' }
  }
}

Data Classification और Storage Tiers

सभी data को समान स्तर की सुरक्षा की आवश्यकता नहीं होती। संवेदनशील data (PII, PHI, financial records) को encrypted, access-restricted buckets में store करना चाहिए और audit logging Enabled होनी चाहिए। कम संवेदनशील data को अधिक व्यापक access दिया जा सकता है। Data classification labels object बनाते समय लागू किए जाने चाहिए और data को उचित रूप से configured storage में अपने-आप भेजने के लिए उपयोग किए जाने चाहिए। Classification tags के आधार पर data को अधिक सुरक्षित storage में अपने-आप ले जाने वाली policies, संवेदनशील data के low-security buckets में पहुँच जाने की संभावना कम करती हैं।

Cloud Storage Access की Logging और Monitoring

अनधिकृत access का बाद में पता लगाने और compliance auditing के लिए access logging अत्यंत महत्वपूर्ण है। AWS S3 access logs और CloudTrail data event logging हर object-level API call रिकॉर्ड करते हैं — किसने object का अनुरोध किया, किस IP से और किस समय। Azure Blob diagnostic logging और GCS audit logs भी ऐसी ही सुविधा देते हैं। इन logs के बिना data breach का पता चलने पर कोई forensic evidence नहीं होता, जिससे exposure का scope निर्धारित करना असंभव हो जाता है।

# Enable S3 access logging
aws s3api put-bucket-logging \
  --bucket my-bucket \
  --bucket-logging-status '{
    "LoggingEnabled": {
      "TargetBucket": "my-access-logs-bucket",
      "TargetPrefix": "my-bucket-logs/"
    }
  }'

Cross-Account Access के जोखिम

Cloud storage को अक्सर accounts (dev, staging, production, third-party partners) के बीच साझा किया जाता है। लापरवाही से configured cross-account access अत्यधिक permissions दे सकता है। Best practices में wildcard principals के बजाय bucket policies में explicit account IDs का उपयोग करना, यह restrict करने के लिए AWS Organizations SCPs का उपयोग करना कि किन external accounts को access दिया ही जा सकता है, cross-account grants की नियमित auditing करना और inter-account data transfers के लिए public internet access के बजाय AWS PrivateLink को प्राथमिकता देना शामिल है।

Versioning और Delete Protection

Object versioning किसी object के सभी versions, deleted versions सहित, बनाए रखता है। यह accidental deletion, objects के ransomware encryption और insider threat से सुरक्षा देता है। Critical data के लिए versioning को Object Lock (S3 Glacier Vault Lock equivalent) के साथ मिलाएँ — यह WORM (Write Once, Read Many) policy है, जो निर्धारित retention period के दौरान किसी भी deletion या modification को रोकती है। Object Lock financial और healthcare industries में immutable records संबंधी regulatory requirements पूरी कर सकता है।

# Enable S3 versioning
aws s3api put-bucket-versioning \
  --bucket my-critical-bucket \
  --versioning-configuration Status=Enabled

# Enable Object Lock (immutable storage)
aws s3api put-object-lock-configuration \
  --bucket my-critical-bucket \
  --object-lock-configuration \
  'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=365}}'

Storage Misconfigs का CSPM Detection

Cloud Security Posture Management (CSPM) tools cloud storage configurations को security benchmarks के अनुसार अपने-आप scan करते हैं। CSPM checks में शामिल हैं: क्या कोई buckets सार्वजनिक रूप से accessible हैं? क्या स्थिर अवस्था में encryption Enabled है? क्या logging Enabled है? क्या critical buckets पर versioning Enabled है? क्या bucket policies अत्यधिक अनुमति वाली हैं? Prisma Cloud, Wiz और AWS Security Hub जैसे CSPM tools continuous compliance monitoring देते हैं और attackers के पहले configuration drift का पता चलने पर alert करते हैं।

Pre-Signed URLs और अस्थायी Access

Pre-signed URLs specific objects तक सीमित समय का access देते हैं और recipient के पास AWS credentials होना आवश्यक नहीं होता। ये external parties के साथ files साझा करने में उपयोगी हैं। Security risks में शामिल हैं: intended sharing window समाप्त होने के बाद भी बने रहने वाले बहुत लंबे expiration time वाले URLs, recipients द्वारा intended audience से बाहर URLs forward करना, और URLs में embedded tokens का server logs में दिखाई देना। हमेशा सबसे कम व्यावहारिक expiration time निर्धारित करें और pre-signed URLs की logging से बचें।

# Generate a pre-signed URL (expires in 3600 seconds)
aws s3 presign s3://my-bucket/report.pdf \
  --expires-in 3600

# Returns a URL valid for 1 hour
# After expiry, the URL returns 403 Forbidden
# Best practice: shortest expiry viable for the use case

त्वरित जाँच

इस lesson में दिए गए CompTIA Security+ (SY0-701) concepts की अपनी समझ जाँचें।

इंटरैक्टिव पाठ में इसका उत्तर दें

Lesson का पुनरावलोकन

इस lesson में आपने सीखा: public bucket misconfigurations cloud storage data breaches का सबसे आम कारण हैं, SSE-KMS, CloudTrail के माध्यम से audit logging के साथ सबसे मजबूत encryption control देता है, और Object Lock के साथ object versioning, ransomware और critical data की insider deletion से सुरक्षा देता है। आगे हम IAM roles और service accounts के साथ cloud identity का अध्ययन करेंगे।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Security+ Academy सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 30
पाठ: 120

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “क्लाउड भंडारण सुरक्षा और डेटा उजागर होने के जोखिम” पाठ निःशुल्क है?

हाँ — Security+ Academy अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “क्लाउड भंडारण सुरक्षा और डेटा उजागर होने के जोखिम” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Security+ Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“क्लाउड भंडारण सुरक्षा और डेटा उजागर होने के जोखिम” में मैं क्या सीखूँगा?

जानिए कि गलत तरीके से कॉन्फ़िगर किए गए S3 बकेट, Azure Blob कंटेनर और GCS बकेट डेटा को कैसे उजागर करते हैं तथा बकेट नीतियाँ और अभिगम नियंत्रण कैसे लागू करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Security+ Academy का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Security+ Academy शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Security+ Academy शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 2वाँ पाठ है।

“क्लाउड भंडारण सुरक्षा और डेटा उजागर होने के जोखिम” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Security+ Academy पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Security+ Academy पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

साझी ज़िम्मेदारी मॉडल: IaaS, PaaS, SaaS
क्लाउड भंडारण सुरक्षा और डेटा उजागर होने के जोखिम
क्लाउड पहचान: IAM भूमिकाएँ और सेवा खाते
क्लाउड सुरक्षा स्थिति प्रबंधन (CSPM)

← Security+ Academy पर वापस जाएँ