کلاؤڈ سیکیورٹی پوسچر مینجمنٹ (CSPM) کلاؤڈ کنٹرول پلین کی کنفیگریشن کا موازنہ مطلوبہ سیکیورٹی تقاضوں سے کرتا ہے۔ AWS، Azure اور Google Cloud میں، CSPM ہمیں یہ تعین کرنے میں مدد دیتا ہے کہ آیا وسائل (resources)، شناختیں (identities) اور اکاؤنٹ کی سطح کی ترتیبات (account-level settings) موجودہ طور پر طے شدہ سیکیورٹی معیار (posture) سے مطابقت رکھتی ہیں یا نہیں۔ یہ ایپلیکیشن پیکٹ کے پے لوڈز (payloads) کی جانچ نہیں کرتا اور نہ ہی فعال حملے کی رن ٹائم (runtime) نشاندہی کا متبادل ہے۔
CSPM ٹولز عام طور پر بغیر کسی ایجنٹ (agentless) کے کام کرتے ہیں۔ یہ ہر فراہم کنندہ (provider) کی APIs کو کال کرنے کے لیے ‘صرف پڑھنے کے قابل’ (read-only) اسناد (credentials) استعمال کرتے ہیں، وسائل کی فہرست (inventory) تیار کرتے ہیں اور اس کے مقابلے میں قواعد (rules) کا جائزہ لیتے ہیں۔ اس کی مثالوں میں AWS Config اور Security Hub، Microsoft Defender for Cloud، Google Security Command Center، اور Prowler اور Steampipe جیسے اوپن سورس اسکینرز شامل ہیں۔ جب کوئی وسیلہ (resource) ان میں سے کسی اصول پر پورا نہیں اترتا، تو ٹول اس نتیجے کو فائنڈنگ (finding) کے طور پر رپورٹ کرتا ہے۔
‘فائنڈنگ’ کنفیگریشن کی قابلِ مشاہدہ حالت کے بارے میں ایک بیان ہے، جیسے کہ اسٹوریج ریسورس کی رسائی کی ترتیب (access setting) یا کسی شناخت (identity) کو تفویض کردہ اجازت۔ اس کی افادیت کا انحصار ان شواہد پر ہوتا ہے جنہیں CSPM عمل پڑھ سکتا ہے، اور اس اصول پر ہوتا ہے جو ان شواہد کی تشریح کے لیے استعمال کیا جاتا ہے۔
اب ہم ان فراہم کنندگان کی حدود اور شواہد کے ذرائع کا تعین کر سکتے ہیں جو CSPM کے جائزے (assessment) میں استعمال ہوتے ہیں۔
کنفیگریشن سے متعلق شواہد (evidence) یہ بتاتے ہیں کہ ڈیٹا اکٹھا کرنے کے وقت پرووائیڈر کا کنٹرول پلین کیا رپورٹ کر رہا ہے۔ ایکٹیویٹی لاگز (activity logs) انتظامی کارروائیوں کا تاریخی ریکارڈ فراہم کرتے ہیں، جیسے کہ کسی پرنسپل (صارف یا سروس) کا پالیسی تبدیل کرنا یا کوئی ریسورس (وسیلہ) تخلیق کرنا۔ AWS میں یہ AWS Config اور CloudTrail ہیں، Azure میں Azure Resource Graph اور Activity Log، اور Google Cloud میں Cloud Asset Inventory اور Cloud Audit Logs شامل ہیں۔ یہ ذرائع مل کر یہ تو دکھا سکتے ہیں کہ کوئی سیٹنگ موجود ہے اور یہ بھی بتا سکتے ہیں کہ اسے کس نے تبدیل کیا، لیکن ان میں سے کوئی بھی یہ ثابت نہیں کرتا کہ ایپلی کیشن کی درخواست کامیاب رہی، ڈیٹا تک رسائی حاصل ہوئی، یا نیٹ ورک پیکٹ محفوظ تھا۔
کنفیگریشن ڈرفٹ (Configuration drift) سے مراد منظور شدہ یا متوقع کنفیگریشن اور موجودہ مشاہدہ شدہ کنفیگریشن کے درمیان فرق ہے۔ یہ فرق دستی تبدیلی، آٹومیشن کی غلطی، ڈیپلائمنٹ رول بیک (جس سے پرانی ویلیو بحال ہوئی ہو)، یا مطلوبہ ڈیلیوری کے عمل سے ہٹ کر بنائے گئے ریسورس کی وجہ سے پیدا ہو سکتا ہے۔ CSPM اس فرق کا پتہ تبھی لگا سکتا ہے جب ریسورس اس کی انوینٹری میں موجود ہو اور اس سے متعلق شواہد دستیاب ہوں۔
شواہد کی حد (Evidence boundary) CSPM کی کوئی دریافت (finding) پرووائیڈر کی حدود کے اندر کنفیگریشن کی ایک خاص حالت کی نشاندہی کرتی ہے۔ یہ بذاتِ خود اس بات کا تعین نہیں کرتی کہ آیا اس میں استحصال (exploitability) کا امکان ہے، کاروباری اثرات کیا ہیں، یا رسائی کامیاب رہی ہے۔
کوئی دریافت فالس پازیٹو (false positive) ہو سکتی ہے اگر جانچا جانے والا اصول کسی مسئلے کی نشاندہی کرے حالانکہ قابلِ اطلاق ضرورت (requirement) اس مشاہدہ شدہ حالت کی اجازت دیتی ہو۔ مثال کے طور پر، ایک عمومی اصول ایسے انٹرنیٹ-فیسنگ اینڈ پوائنٹ (internet-facing endpoint) کی نشاندہی کر سکتا ہے جو جان بوجھ کر عوامی (public) رکھا گیا ہو اور ایسے کنٹرولز کے ذریعے محفوظ ہو جنہیں وہ اصول جانچتا ہی نہ ہو۔ محفوظ طریقہ کار یہ ہے کہ پروڈکشن کنفیگریشن تبدیل کرنے سے پہلے ضرورت، ریسورس کے مقصد، ایکسپوزر پاتھ (exposure path)، اور متبادل حفاظتی اقدامات (compensating controls) کی تصدیق کی جائے۔
‘ریڈ پرمیشنز’ (read permissions) کا نہ ہونا اس کے برعکس مسئلہ پیدا کرتا ہے۔ اگر CSPM کی شناخت (identity) کسی ریسورس کی فہرست نہیں بنا سکتی، پالیسی حاصل نہیں کر سکتی، یا متعلقہ سیٹنگ کا معائنہ نہیں کر سکتی، تو جائزے (assessment) کا نتیجہ مکمل ہونے کے بجائے نامکمل ہو سکتا ہے۔ غیر منظم (unmanaged) ریسورس کا بھی عملی اثر وہی ہوتا ہے جب وہ ان اکاؤنٹس، سبسکرپشنز، پروجیکٹس یا انوینٹری کے دائرہ کار سے باہر ہو جن کا جائزہ لیا جا رہا ہے۔
مشترکہ ذمہ داری (shared responsibility) بھی ایک حد مقرر کرتی ہے۔ کلاؤڈ پرووائیڈر بنیادی سروس چلاتا ہے، جبکہ صارف شناخت کی تفویض، نیٹ ورک ایکسپوزر، ریسورس پالیسی، اور ڈیٹا تک رسائی کی کنفیگریشن جیسے فیصلوں کا ذمہ دار رہتا ہے۔ ‘پوسچر چیک’ (posture check) میں کامیابی کا مطلب یہ نہیں کہ وہ ذمہ داری منتقل ہو گئی ہے یا یہ ثابت ہو گیا ہے کہ صارف کے زیرِ انتظام ہر کنٹرول مؤثر ہے۔
فیصلے کا اصول کسی دریافت کا نہ ہونا (absence of findings) تبھی مفید سمجھا جائے جب دائرہ کار، ڈیٹا اکٹھا کرنے کی اجازت، اصول کا اطلاق، اور شواہد کے حصول کا ٹائم ونڈو (time window) تصدیق شدہ ہوں۔
ہم orders-api نامی ایک جان بوجھ کر چھوٹے پیمانے کے ورک لوڈ کا استعمال کریں گے۔ یہ ایک ایسی ایپلیکیشن سروس کی نمائندگی کرتا ہے جو پورٹ 8080 پر کام کرتی ہے اور آرڈر کا ڈیٹا متعلقہ کلاؤڈ فراہم کنندہ (provider) کے اپنے آبجیکٹ اسٹوریج ریسورس میں محفوظ کرتی ہے۔ اس کا ہر ورژن اپنے فراہم کنندہ کی حدود کے اندر ہی رہتا ہے، لہذا یہ فرض نہیں کیا جاتا کہ کوئی شناخت (identity)، اسٹوریج کی اجازت، یا کوئی نتیجہ (finding) ایک کلاؤڈ سے دوسرے کلاؤڈ میں منتقل ہوگا۔
AWS میں، orders-api رول orders-api-role اور بکیٹ orders-data-s3 کا استعمال کرتا ہے۔ Azure میں، یہ مینیجڈ شناخت orders-api-mi اور اسٹوریج اکاؤنٹ ordersdatast استعمال کرتا ہے۔ Google Cloud میں، یہ سروس اکاؤنٹ orders-api-sa اور بکیٹ orders-data-gcs استعمال کرتا ہے۔ یہ شناخت کنندگان (identifiers) فرضی ہیں، لیکن جس حد یا دائرہ کار کی یہ نشاندہی کرتے ہیں، اسے دوبارہ استعمال کیا جا سکتا ہے۔
ہم اس بات کا جائزہ لے سکتے ہیں کہ کس طرح ہر ورک لوڈ کی شناخت اپنے فراہم کنندہ کے مخصوص وسائل (resources) تک ہی محدود رہتی ہے۔