شناخت اور رسائی کا انتظام (IAM) یہ طے کرتا ہے کہ کون سی شناخت تصدیق (authenticate) کر سکتی ہے اور وہ شناخت کسی مخصوص ریسورس (resource) پر کون سے اقدامات (actions) انجام دے سکتی ہے۔ ملٹی کلاؤڈ ماحول میں، ایک کارپوریٹ شناخت فراہم کنندہ (identity provider) ورک فورس کے سائن اِن کا انتظام کر سکتا ہے، جبکہ AWS، Azure اور Google Cloud ہر ایک اپنی انتظامی حدود کے اندر اجازت (authorization) کے فیصلے خود کرتے ہیں۔ کامیاب سائن اِن بذاتِ خود کسی ریسورس API درخواست کی اجازت نہیں دیتا۔ AWS میں، ورک فورس SSO عام طور پر IAM Identity Center کے ذریعے ترتیب دیا جاتا ہے، اور AWS Security Token Service (STS) کے ساتھ IAM رولز (roles) اس کے نتیجے میں عارضی اسناد (credentials) جاری کرتے ہیں۔
اہم حد بندی شناخت فراہم کنندہ، ہر کلاؤڈ کے کنٹرول پلین (control plane)، اور ہر کلاؤڈ کے ڈیٹا پلین (data plane) کے درمیان ہوتی ہے۔ کنٹرول پلین کلاؤڈ ریسورسز اور ان کی کنفیگریشن کا انتظام کرتا ہے۔ ڈیٹا پلین خود ریسورسز تک آنے والی درخواستوں کو سنبھالتا ہے؛ جب ایسی کوئی درخواست کی جاتی ہے تو ہر کلاؤڈ اپنے IAM میں پرنسپل (صارف/شناخت)، عمل، ریسورس اور متعلقہ شرائط کا جائزہ لیتا ہے۔ یہ پلینز شناخت کی معلومات کا اشتراک تو کر سکتے ہیں، لیکن وہ اجازتوں کے کسی ایک مشترکہ (یونیورسل) سیٹ کا اشتراک نہیں کرتے۔
اب ہم ریسورس تک رسائی کا مفہوم لیے بغیر سائن اِن کی حدود کا تعین کر سکتے ہیں۔
ملٹی کلاؤڈ IAM میں ناکامیاں اکثر ایسے جانے پہچانے الفاظ سے شروع ہوتی ہیں جن کے دائرہ کار (scopes) مختلف ہوتے ہیں۔ AWS اکاؤنٹ، AWS وسائل (resources) کے لیے ایک انتظامی حد ہے۔ Azure ٹیننٹ (tenant)، Microsoft Entra ID ڈائریکٹری کی حد ہے، جبکہ Azure وسائل تک رسائی کی اجازت عام طور پر Azure RBAC (کردار پر مبنی رسائی کا کنٹرول) کے ذریعے مینجمنٹ گروپ، سبسکرپشن، ریسورس گروپ، یا ریسورس کی سطح پر دی جاتی ہے۔ Google Cloud میں، تنظیم (organization) اور پروجیکٹ، Cloud IAM پالیسی کے اطلاق اور وسائل کی ملکیت کے لیے الگ الگ دائرہ کار فراہم کرتے ہیں۔
یہ فرق اس لیے اہم ہے کیونکہ شناخت کی رکنیت (identity membership) بذاتِ خود وسائل تک رسائی کی اجازت نہیں ہے۔ Azure میں، Microsoft Entra ID صارف کی تصدیق (authentication) کر سکتا ہے اور گروپ کی رکنیت ظاہر کر سکتا ہے، لیکن درخواست کردہ Azure عمل (action) کی اجازت دینے کے لیے Azure RBAC کا متعلقہ کردار تفویض کرنا ضروری ہے۔ AWS میں، AWS IAM پالیسیاں اور AWS STS (سیکیورٹی ٹوکن سروس) کی اسناد (credentials) اجازت کے عمل میں حصہ لیتی ہیں۔ Google Cloud میں، Cloud IAM متعلقہ وسائل کے درجہ بندی کے نظام (hierarchy) کے لیے اپنی پالیسی بائنڈنگز کا جائزہ لیتا ہے۔ ایک جیسے نظر آنے والے گروپ کے نام ان حدود کے آر پار مساوی رسائی فراہم نہیں کرتے۔
آپریشنل شواہد بھی اسی طرح مخصوص حدود کے حامل ہوتے ہیں۔ کارپوریٹ شناخت فراہم کرنے والے (identity provider) کا سائن اِن ایونٹ یہ تو دکھا سکتا ہے کہ تصدیق ہوئی تھی، لیکن اکیلے یہ ثابت نہیں کر سکتا کہ AWS، Azure یا Google Cloud نے بعد میں آنے والی API درخواست کی اجازت دی تھی۔ کلاؤڈ آڈٹ ریکارڈ اس کلاؤڈ میں کنٹرول پلین یا ریسورس API کی کوشش کو ظاہر کر سکتا ہے، لیکن یہ اس بات کا ثبوت نہیں دیتا کہ کارپوریٹ شناخت فراہم کرنے والے کا لائف سائیکل ڈیٹا درست تھا۔ ہمیں اس پلین (سطح) سے شواہد درکار ہوتے ہیں جس نے فیصلہ کیا تھا، جس میں شناخت، وسائل، عمل اور وقت کا دورانیہ شامل ہو۔
فیصلے کا اصول رسائی کا جائزہ ایک وقت میں ایک کلاؤڈ اور ایک درخواست کے لیے لیں۔ سب سے پہلے پرنسپل (صارف/سروس)، ہدف وسائل، API ایکشن، اور اس اجازت نامہ پلین (authorization plane) کی شناخت کریں جس نے اس کا جائزہ لیا تھا۔
ہم تمام شناختوں کو یکساں سمجھنے کے بجائے ایک محدود ورک لوڈ (bounded workload) کا استعمال کریں گے۔ orders-api سروس پورٹ 8080 پر کام کرتی ہے۔ ورک فورس کی شناخت، orders-workforce-user، ایک ایسے آپریٹر کی نمائندگی کرتی ہے جسے کارپوریٹ شناخت فراہم کرنے والے کے ذریعے انٹرایکٹو رسائی کی ضرورت ہوتی ہے۔ app-operators گروپ مطلوبہ آپریشنل کردار کی نمائندگی کرتا ہے، جبکہ cloud-admins کو جان بوجھ کر الگ رکھا گیا ہے کیونکہ انتظامی رسائی مختلف خطرات اور منظوری کے دائرہ کار کی حامل ہوتی ہے۔
خودکار شناخت orders-ci ہے، جو ایک مسلسل انٹیگریشن (CI) جاب کی نمائندگی کرتی ہے جو ورک لوڈ کو تعینات (deploy) یا منظم کرتی ہے۔ اس کی درخواستیں ورک فورس کے براؤزر سیشنز نہیں ہوتیں۔ یہ طویل عرصے تک کارآمد رہنے والی کلاؤڈ ایکسیس کیز (access keys) رکھنے کے بجائے ہر کلاؤڈ کے لیے مختصر مدت کی فیڈریٹڈ اسناد (federated credentials) حاصل کرتی ہے۔ ہمارے پرووائیڈر (provider) کے دائرہ کار میں AWS اکاؤنٹ dev، Azure ٹیننٹ contoso اور Google Cloud پروجیکٹ orders-prod شامل ہیں؛ بعد میں آنے والی ہر اجازت (authorization) کی درخواست میں ان اہداف میں سے کسی ایک کا واضح طور پر ذکر کرنا لازمی ہوگا۔
اب ہم یہ جائزہ لے سکتے ہیں کہ ورک فورس (workforce) اور CI کے شناختی راستے (identity paths) ہر کلاؤڈ تک کیسے پہنچتے ہیں۔