سیکیورٹی انجینئرنگ ورک لوڈ کی ضرورت کو ایک ایسے ‘کنٹرول’ (control) میں تبدیل کرتی ہے جس کی جانچ اور نگرانی کی جا سکتی ہے اور جسے محفوظ طریقے سے ہٹایا جا سکتا ہے۔ Azure میں، یہ کام Microsoft Entra ٹیننٹ، سبسکرپشن کے اندر Azure Resource Manager، اور ہر سروس کے ڈیٹا پلین (data plane) تک پھیلا ہوا ہے؛ لہذا بظاہر درست نظر آنے والی سیٹنگ بھی غلط دائرہ کار (scope) کا تحفظ کر رہی ہو سکتی ہے۔
ہم فرضی ریسورس گروپ rg-orders-dev میں ایک محدود ڈیولپمنٹ ورک لوڈ استعمال کریں گے۔ اس کا مقصد ان فیصلوں، شواہد اور حدود کو واضح کرنا ہے جو کلاؤڈ سیکیورٹی انجینئر کو کسی کنفیگریشن کو تحفظ کا ذریعہ ماننے سے پہلے قائم کرنے چاہئیں۔
کسی اثاثے (asset) اور خطرے (threat) سے منسلک ضرورت سے آغاز کریں۔ مثال کے طور پر، آرڈر پروسیسنگ API کو عوامی انٹرنیٹ پر ظاہر کیے بغیر ایک ‘سیکرٹ’ (secret) حاصل کرنا چاہیے۔ کنٹرول وہ ترتیب شدہ میکانزم ہے جس کا مقصد اس ضرورت کو پورا کرنا ہے، جبکہ ثبوت (evidence) ایک قابلِ مشاہدہ ریکارڈ ہے جو اس کی کنفیگریشن یا سرگرمی کے بارے میں کسی محدود دعوے کی تائید کرتا ہے۔
ہمارا ورک فلو مستقل نوعیت کا ہے۔ ہم اثاثے، ڈیٹا کی حد، شناخت اور خطرے کی نشاندہی کرتے ہیں؛ مناسب ترین اور مختصر ترین کنٹرول کا انتخاب کرتے ہیں؛ رسائی سے انکار یا ٹریفک کے غیر ارادی راستے پر جانے کی صورت میں متوقع ناکامی کی وضاحت کرتے ہیں؛ اور پھر کنفیگریشن اور رن ٹائم شواہد کے ساتھ مطلوبہ نتیجے کی تصدیق کرتے ہیں۔ صفائی (cleanup) کے عمل میں عارضی اجازتیں، ٹیسٹ سیکرٹس، یا تشخیصی ترتیبات کو اس وقت ہٹا دیا جاتا ہے جب ان کی مزید ضرورت نہیں رہتی، تاکہ ٹیسٹنگ کے عناصر (artifacts) مستقل خطرے یا کمزوری کا باعث نہ بنیں۔
کنفیگریشن کے شواہد اور رن ٹائم کے شواہد مختلف سوالات کے جواب دیتے ہیں۔ رول اسائنمنٹ (role assignment) یا پرائیویٹ اینڈ پوائنٹ کنفیگریشن کنٹرول پلین کی مطلوبہ حالت کو ظاہر کرتی ہے۔ Key Vault کا آڈٹ ایونٹ، اسٹوریج کا تشخیصی لاگ، یا ایپلیکیشن کی ناکامی ریکارڈ شدہ ٹائم ونڈو کے اندر ڈیٹا پلین کی مشاہدہ شدہ کوشش کو ظاہر کرتی ہے۔ ان میں سے کوئی بھی اکیلے یہ ثابت نہیں کرتا کہ ہر راستہ محفوظ ہے یا یہ کہ کسی واقعے کی کوئی اور وجہ نہیں ہے۔
سفارشات سیکیورٹی کی صورتحال میں موجود خامیوں (posture gaps) کی نشاندہی کرتی ہیں، لیکن ان کا نفاذ ‘deny policy’ (انکار کی پالیسی) یا خود کنٹرول کے ذریعے ہی ممکن ہوتا ہے۔
مائیکروسافٹ بنیادی Azure فزیکل انفراسٹرکچر کو محفوظ بناتا ہے، جبکہ صارف ورک لوڈ ڈیٹا، ایپلیکیشن کے رویے، شناختوں (identities) اور رسائی کے انتخاب کا ذمہ دار رہتا ہے۔ مشترکہ ذمہ داری کی اس حد کا مطلب یہ نہیں ہے کہ پلیٹ فارم کے زیرِ انتظام سروس کے لیے صارف کی جانب سے سیکیورٹی کے کسی کام کی ضرورت نہیں ہے۔ اس کا مطلب یہ ہے کہ شواہد یا اصلاحی اقدامات کا انتخاب کرنے سے پہلے ہمیں یہ شناخت کرنی چاہیے کہ ہر پرت (layer) کس فریق کی ملکیت ہے۔
Microsoft Entra ڈائریکٹری صارفین، ایپلیکیشنز اور مینیجڈ شناختوں کی تصدیق (authenticate) کرتی ہے۔ Azure Resource Manager، جسے اکثر ARM کہا جاتا ہے، سبسکرپشن یا ریسورس گروپ میں وسائل (resources) کی تخلیق اور تشکیل (configuration) کے لیے Azure کا کنٹرول پلین ہے۔ ان دائرہ کار (scopes) پر Azure RBAC کرداروں کی تفویض کنٹرول پلین کے اقدامات، جیسے کہ اسٹوریج اکاؤنٹ کی نیٹ ورکنگ کنفیگریشن کو تبدیل کرنا، کی اجازت دیتی ہے۔
سروس کا ڈیٹا پلین وہ مخصوص انٹرفیس ہے جو محفوظ ڈیٹا کو پڑھتا، لکھتا یا استعمال کرتا ہے۔ Key Vault سے خفیہ معلومات (secrets) کا حصول اور Blob ڈیٹا تک رسائی اپنے متعلقہ ڈیٹا پلینز پر ہوتی ہے، جہاں ان کی ڈیٹا پلین کی اجازت اور نیٹ ورک کنٹرولز ARM کی اجازت سے آزادانہ طور پر لاگو ہوتے ہیں۔ ایک ‘Contributor’ جو والٹ (vault) کو تشکیل دے سکتا ہے، ضروری نہیں کہ وہ اس کے خفیہ ڈیٹا (secrets) کو پڑھنے کا بھی مجاز ہو۔
قابلِ استعمال اصول یہ ہے کہ رسائی کامیاب ہونی چاہیے یا نہیں، اس کا فیصلہ کرنے سے پہلے پرنسپل (صارف/سروس)، عمل (action)، دائرہ کار (scope) اور پلین (plane) کی نشاندہی کی جائے۔
ہمارا فرضی ورک لوڈ app-orders-api ہے، جو ایک فرضی سبسکرپشن <subscription-id> کے اندر rg-orders-dev میں موجود Azure App Service کی ایک ایپ ہے۔ یہ منتخب Azure ریجن میں چلتی ہے اور آؤٹ باؤنڈ ورچوئل نیٹ ورک انٹیگریشن کے لیے vnet-orders-dev کا استعمال کرتی ہے۔ ایپلیکیشن کو stordersdev میں آرڈر ڈیٹا اور kv-orders-dev میں ایک خفیہ معلومات (secret) کی ضرورت ہوتی ہے، جبکہ law-sec-01 وہ Log Analytics ورک اسپیس ہے جسے Microsoft Sentinel استعمال کرتا ہے۔
ورچوئل نیٹ ورک ایپلیکیشن کی نیٹ ورک کی حد (boundary) ہے، نہ کہ ہر Azure سروس ریسورس کا مقام۔ stordersdev اور kv-orders-dev بدستور vnet-orders-dev سے باہر Azure پلیٹ فارم کی خدمات (services) کے طور پر موجود ہیں؛ پرائیویٹ اینڈ پوائنٹس (private endpoints) ان خدمات کے لیے ورچوئل نیٹ ورک میں پرائیویٹ نیٹ ورک انٹرفیس قائم کرتے ہیں۔ پرائیویٹ DNS اور سروس کی نیٹ ورک سیٹنگز کو API کی آؤٹ باؤنڈ (outbound) درخواست کو پبلک اینڈ پوائنٹ کے بجائے ان اینڈ پوائنٹ ایڈریسز کی طرف بھیجنا چاہیے۔
ایپ کی ‘مینیجڈ شناخت’ (managed identity) کو بعد میں Key Vault اور Storage سے متعلق مطلوبہ کارروائیوں کے لیے الگ ڈیٹا-پلین (data-plane) اجازتوں کی ضرورت ہوگی۔ Sentinel law-sec-01 پر چلتا ہے، جہاں کنیکٹرز اور تشخیصی (diagnostic) سیٹنگز اس بات کا تعین کرتی ہیں کہ تجزیے کے لیے کون سے ریکارڈز موصول ہوں گے۔ ورک اسپیس صرف اس ڈیٹا کی تفتیش میں معاونت کر سکتا ہے جو درحقیقت اس میں جمع کیا گیا ہو۔
API سے لے کر اس کے پرائیویٹ اینڈ پوائنٹس اور مانیٹرنگ ورک اسپیس تک ورک لوڈ کی حدود (workload boundary) کا تعین کریں۔