سیکیورٹی انجینئرنگ کا آغاز اس بات کے تعین سے ہوتا ہے کہ کون کسی ریسورس (resource) پر عمل کر سکتا ہے، کن راستوں سے اس تک رسائی ممکن ہے، اور نتیجے کا ریکارڈ کن شواہد کے ذریعے رکھا جاتا ہے۔ ہماری سب سے چھوٹی حد (boundary) ایک گوگل کلاؤڈ پروجیکٹ میں موجود ‘کلاؤڈ اسٹوریج بکیٹ’ (Cloud Storage bucket) ہے، جس تک ‘کلاؤڈ رن سروس’ (Cloud Run service) کے ذریعے رسائی حاصل کی جاتی ہے۔ یہ کورس اس حد کو شناخت (identity)، نیٹ ورک، انکرپشن، سراغ رسانی (detection)، اور تصدیقی کنٹرولز تک وسعت دے گا۔
آئیڈینٹٹی اینڈ ایکسس مینجمنٹ (IAM) کسی ‘پرنسپل’ (صارف یا سروس) کو کسی ریسورس پر مجاز عمل کرنے کا اختیار دیتی ہے۔ IAM کی ‘اجازت دینے والی پالیسیاں’ (allow policies) آرگنائزیشن، فولڈر یا پروجیکٹ سے بکیٹ تک منتقل (inherit) ہو سکتی ہیں۔ ‘سروس اکاؤنٹ’ دراصل ورک لوڈ کی شناخت (workload identity) ہوتا ہے، نہ کہ کسی انسانی ایڈمنسٹریٹر کا اکاؤنٹ۔ صرف ‘رن ٹائم سروس اکاؤنٹ’ کو بکیٹ کی اجازت دینے سے ‘ڈیٹا پلین ریکویسٹ’ کی حد محدود ہو جاتی ہے۔
نیٹ ورک کنٹرولز ریسورس کی اجازتوں کے بجائے ٹریفک کے راستوں کو منظم کرتے ہیں۔ VPC فائر وال کے اصول ‘کمپیوٹ انجن’ (Compute Engine) کے نیٹ ورک انٹرفیسز کے لیے ٹریفک کا جائزہ لیتے ہیں۔ کلاؤڈ کی مینجمنٹ سروس (Cloud KMS) معاونت شدہ ریسورسز کے لیے کسٹمر کے زیرِ کنٹرول انکرپشن کیز (encryption keys) کا انتظام کرتی ہے۔ سیکیورٹی کمانڈ سینٹر سیکیورٹی کی صورتحال اور خطرات کی نشاندہی سے متعلق معلومات اکٹھی کرتا ہے۔ ہر کنٹرول ایک مختلف سوال کا جواب دیتا ہے، لہذا ان میں سے کوئی بھی IAM کی اجازت (authorization) کا متبادل نہیں ہے۔
آئیے جائزہ لیتے ہیں کہ آرگنائزیشن، پروجیکٹ اور ریسورس کے کنٹرولز کس طرح ایک ورک لوڈ کی حد پر یکجا ہوتے ہیں۔
فرض کریں کہ example-payments-project نامی پروجیکٹ us-central1 ریجن میں ایک Cloud Run سروس کی میزبانی کرتا ہے۔ اس کا ‘رن ٹائم سروس اکاؤنٹ’ (runtime service account) منظور شدہ رسیدوں کو example-receipts-bucket میں محفوظ کرتا ہے۔ ایک ایڈمنسٹریٹر گروپ کنفیگریشن کا جائزہ لیتا ہے۔ ایک الگ ‘مسلسل انٹیگریشن اور ڈیلیوری’ (CI/CD) سروس اکاؤنٹ نئے ورژنز (revisions) کو تعینات (deploy) کرتا ہے۔ ان شناختوں (identities) کو الگ رکھنے سے یہ یقینی بنتا ہے کہ تعیناتی کے لیے استعمال ہونے والی اسناد (credentials) خود بخود ڈیٹا تک رسائی کی اسناد نہ بن جائیں۔
خطرات کے ماڈل (threat model) میں ڈویلپر کی اسناد کا غیر محفوظ ہونا (compromised credential)، رن ٹائم رول کا ضرورت سے زیادہ وسیع ہونا، اور ڈیٹا کا غیر ارادی طور پر باہر منتقل ہونا (unintended export) شامل ہیں۔ Cloud Run سروس کو صرف ان مخصوص ‘بکٹ ایکشنز’ (bucket actions) کی ضرورت ہوتی ہے جو اس کے کام کے لیے لازمی ہیں۔ ایڈمنسٹریٹر گروپ کو محدود اور کنٹرولڈ انتظامی رسائی درکار ہوتی ہے۔ تعیناتی کرنے والی شناخت (deployment identity) کو صرف تعیناتی کے اجازت ناموں کی ضرورت ہوتی ہے، نہ کہ وسیع آپریشنل انتظامی اختیارات کی۔ اس سے ‘کم سے کم استحقاق’ (least privilege) کا اصول محض ایک عمومی ارادے کے بجائے جانچ کے قابل ضرورت (testable requirement) کے طور پر قائم ہوتا ہے۔
آئیں، ان شناختوں، ریجن اور ڈیٹا کے وسائل کا تصور کریں جو اس ورک لوڈ کے حفاظتی دائرہ کار (security scope) کا تعین کرتے ہیں۔