DevSecOps سیکیورٹی کے فیصلوں اور شواہد کو سافٹ ویئر کی ترسیل کے عمل میں شامل کرتا ہے، بجائے اس کے کہ انہیں صرف حتمی جائزے (final review) کے طور پر دیکھا جائے۔ ملٹی کلاؤڈ (multicloud) مسلسل انضمام اور مسلسل ترسیل (CI/CD) کی پائپ لائن میں، بنیادی سوال یہ نہیں ہے کہ کون سا کلاؤڈ ایپلی کیشن کو چلا رہا ہے۔ بلکہ اہم بات یہ ہے کہ کون سا جزو (component) سورس کوڈ تبدیل کر سکتا ہے، بلڈ کوڈ (build code) چلا سکتا ہے، آرٹیفیکٹ (artifact) شائع کر سکتا ہے، یا پرووائیڈر کی ڈیپلائمنٹ API کو کال کر سکتا ہے۔ یہی صلاحیتیں سیکیورٹی کی حدود کا تعین کرتی ہیں۔
اس کورس کے لیے، پرووائیڈر کے سیاق و سباق میں AWS، Microsoft Azure اور Google Cloud شامل ہیں۔ ہر پرووائیڈر کے پاس اپنے وسائل (resources) اور شناخت (identity) کی حدود ہوتی ہیں، جبکہ ایک مرکزی CI کنٹرول پلین پائپ لائن کی تعریفوں، جاب شیڈولنگ، منظوریوں اور ریکارڈ شدہ نتائج کو مربوط کرتا ہے۔ یہ سبق ایک محدود ورک لوڈ (bounded workload) قائم کرتا ہے تاکہ بعد میں ٹھوس شناختوں، آرٹیفیکٹس اور ڈیپلائمنٹ کے اہداف کے مقابلے میں کنٹرولز کا جائزہ لیا جا سکے۔
ملٹی کلاؤڈ پائپ لائن کا سیکیورٹی جائزہ اس وقت تک شروع نہیں ہو سکتا جب تک یہ واضح نہ ہو کہ کون سے حصے دائرہ کار (scope) میں ہیں، کیونکہ اس دائرہ کار سے باہر موجود کوئی ‘رنر’ (runner) یا ‘رجسٹری’ (registry) بغیر کسی جائزے کے ریلیز کو تبدیل کر سکتی ہے۔ پائپ لائن کی حدود ان ریپوزٹریز، کنٹرول پلین سروسز، رنرز، شناختوں، آرٹیفیکٹ اسٹورز اور ڈیپلائمنٹ انٹرفیسز کا مجموعہ ہیں جو کسی تبدیلی کو ریلیز میں تبدیل کرنے کے عمل میں حصہ لیتے ہیں۔ اس کا آغاز تب ہوتا ہے جب ریپوزٹری میں ہونے والی تبدیلی پائپ لائن کے رویے پر اثر انداز ہو سکتی ہے، اور یہ ان پرووائیڈر API ایکشنز تک پھیلی ہوتی ہے جو ورک لوڈ کو تخلیق یا تبدیل کرتے ہیں۔ ڈیپلائے شدہ ایپلی کیشن کے لیے رن ٹائم درخواستیں (runtime requests) اس حد سے باہر ہوتی ہیں، اگرچہ بعد میں ملنے والے شواہد ریلیز کو رن ٹائم رویے سے جوڑ سکتے ہیں۔
مرکزی کنٹرول پلین، جس کا نام ci-control ہے، خود بخود AWS، Azure یا Google Cloud کے اندر موجود نہیں ہوتا۔ اس کے رنرز بلڈ اور ڈیپلائمنٹ کے کام (jobs) انجام دیتے ہیں اور پھر AWS اکاؤنٹ dev، Azure سبسکرپشن dev اور Google Cloud پروجیکٹ orders-dev کے ساتھ الگ الگ تصدیق (authenticate) کرتے ہیں۔ ایک رنر پرووائیڈر کی حدود کا حصہ تبھی بنتا ہے جب اسے وہاں خود ہوسٹ (self-hosted) کیا جائے۔ اس کا مقام نیٹ ورک ایکسپوزر اور دستیاب شناختی میکانزم کو تبدیل کرتا ہے، لیکن یہ محدود دائرہ کار والی پرووائیڈر کی اجازت (authorization) کی ضرورت کو ختم نہیں کرتا۔
اب ہم یہ پتہ لگا سکتے ہیں کہ کون سے اجزاء ہر پرووائیڈر کی حدود کو عبور کرتے ہیں۔
ایک مرکزی پائپ لائن (pipeline) تکرار (duplication) کو تب ہی کم کرتی ہے جب اس کے کنٹرولز کا مستقل اطلاق کیا جائے۔ کریڈینشل پھیلاؤ (Credential sprawl) تب ہوتا ہے جب بہت سے جابز (jobs)، ریپوزٹریز، یا پرووائیڈر کے ماحول وسیع رسائی والے الگ الگ اور طویل عرصے تک کارآمد رہنے والے کریڈینشلز (اسناد/رسائی کی معلومات) کو برقرار رکھتے ہیں۔ تعیناتی (deployment) کے لیے استعمال ہونے والا کوئی لیک شدہ کریڈینشل اس جاب کی مدت ختم ہونے کے بعد بھی فعال رہ سکتا ہے، اور مشترکہ کریڈینشل آڈٹ ریکارڈز کے لیے پائپ لائن کے ایک رن (run) کو دوسرے سے ممتاز کرنا مشکل بنا دیتا ہے۔ ہر رن کے لیے مخصوص، مختصر مدت والے کریڈینشلز استعمال کی مدت اور متاثرہ ڈیپلائمنٹ لین (deployment lane) دونوں کو محدود کرتے ہیں۔
اسکین کنٹرولز میں بھی انحراف (drift) آ سکتا ہے۔ AWS کے راستے میں ایک ناکامی کی حد (threshold) اور Azure یا Google Cloud کے راستے میں مختلف حد کے ساتھ کیا جانے والا ‘وُلنریبلٹی اسکین’ (vulnerability scan) ایک ہی سیکیورٹی فیصلے کی نمائندگی نہیں کرتا، چاہے ہر راستے میں ایک ہی اسکینر استعمال ہو رہا ہو۔ پائپ لائن کو جانچے گئے آرٹیفیکٹ (artifact)، اصولوں کے مجموعے، نتیجے اور گیٹ (gate) کے نتائج کو ریکارڈ کرنا چاہیے۔ ایک کامیاب جاب لاگ اس بات کا ثبوت ہے کہ جاب نے اپنے ریکارڈ شدہ وقت کے دوران کامیابی کی اطلاع دی؛ لیکن یہ بذاتِ خود اس بات کا ثبوت نہیں ہے کہ پرووائیڈر کی جانب موجود تمام وسائل اب مطلوبہ حالت (intended state) کے مطابق ہیں۔
کراس کلاؤڈ (cross-cloud) کاپی کرنے کا عمل ایک اور حد (boundary) کا اضافہ کرتا ہے۔ رجسٹریز کے درمیان کاپی کی جانے والی امیج کو تبدیل کیا جا سکتا ہے، نامکمل طور پر کاپی کیا جا سکتا ہے، یا کسی جانے پہچانے ٹیگ کے تحت پروموٹ (promote) کیا جا سکتا ہے۔ ٹیگز ایک قابلِ تبدیلی حوالہ (mutable reference) کی نشاندہی کرتے ہیں، جبکہ ‘ڈائجسٹ’ (digest) امیج کے مخصوص مواد کی شناخت کرتا ہے۔ قابلِ استعمال اصول یہ ہے کہ ہر پرووائیڈر ایکشن (provider action) کی آزادانہ طور پر اجازت دی جائے اور ہر ہینڈ آف (handoff) کے دوران عین اسی آرٹیفیکٹ کا ثبوت ساتھ رکھا جائے۔
چلنے والا ورک لوڈ orders-api ہے، جو ایک ایسی سروس ہے جو پورٹ 8080 پر لسن (listen) کرتی ہے۔ ایپلیکیشن کا سورس orders-api-repo میں موجود ہے، جبکہ انفراسٹرکچر کے اعلانات (declarations) orders-infra-repo میں ہیں۔ ایک ‘بلڈ’ (build) عمل فرضی کنٹینر امیج orders-api:1.0 تیار کرتا ہے؛ انفراسٹرکچر میں تبدیلیوں کا جائزہ Terraform اسٹیک orders-infra کے طور پر لیا جاتا ہے۔ سورس اور انفراسٹرکچر ریپوزٹریز کو الگ رکھنے سے بعد کے کنٹرولز کو یہ سہولت ملتی ہے کہ وہ ہر قسم کی تبدیلی کے لیے مختلف جائزہ (review)، عمل درآمد (execution)، اور تعیناتی (deployment) کے اجازت نامے تفویض کر سکیں۔
امیج کو aws-ecr/orders-api، azure-acr/ordersapi، اور gcp-ar/orders-api پر پروموٹ کیا جاتا ہے، اور پھر پرووائیڈر کے مخصوص API ایکشنز کے ذریعے ان کی نامزد ڈیولپمنٹ حدود (development boundaries) میں تعینات کیا جاتا ہے۔ پروموشن کا مطلب ہے اسی تصدیق شدہ امیج ڈائجسٹ کو ہر رجسٹری میں کاپی کرنا، نہ کہ ہر کلاؤڈ کے لیے سورس سے دوبارہ تعمیر (rebuild) کرنا۔ دوبارہ تعمیر کرنے سے الگ الگ آرٹیفیکٹس بنیں گے جن کے مواد اور ثبوت میں فرق آ سکتا ہے، حالانکہ وہ orders-api:1.0 ٹیگ ہی شیئر کر رہے ہوں گے۔
ہم ان آرٹیفیکٹ اور انفراسٹرکچر کے راستوں کا جائزہ لے سکتے ہیں جنہیں یہ ورک لوڈ واضح کرتا ہے۔