4.7 شناخت اور رسائی کا انتظام
جائزہ اور محرکات
آپ کے نظاموں تک پہنچنے والی ہر درخواست مضمر دعویٰ رکھتی ہے: مجھے یہ کرنے کی اجازت ہے۔ شناخت اور رسائی کا انتظام (IAM) یہ طے کرنے کا نظم و ضبط ہے کہ آیا وہ دعویٰ سچ ہے۔ یہ دو الگ سوالوں کا جواب دیتا ہے جنہیں لوگ مسلسل ملاتے ہیں۔ تصدیق ثابت کرتی ہے کہ آپ کون ہیں۔ اجازت طے کرتی ہے کہ ثابت کرنے کے بعد آپ کیا کر سکتے ہیں۔ ان دو خیالات کو اپنے ذہن میں الگ رکھیں اور اس میدان کی آدھی الجھن غائب ہو جاتی ہے۔
بڑی ٹیموں کے لیے شناخت خاموشی سے آپ کا سب سے اہم کنٹرول بن چکی ہے۔ باب 4.3 یہ نکتہ بناتا ہے کہ شناخت نئی حد ہے، اور باب 4.1 اس کے اوپر zero trust بناتا ہے: جب آپ نیٹ ورک پر بھروسہ چھوڑ دیں تو بھروسہ کرنے کو صرف توثیق شدہ شناخت اور واضح پالیسی باقی رہتی ہے۔ اس تبدیلی کا مطلب ہے کہ کمزور پاس ورڈ ری سیٹ کا بہاؤ یا بھولا ہوا سروس اکاؤنٹ اب چھوٹا بگ نہیں۔ یہ سامنے کا دروازہ ہے۔ زیادہ تر حقیقی خلاف ورزیاں میموری کی حفاظت کی خامیوں کے چالاک استحصال نہیں؛ وہ چرائی ہوئی اسناد، ضرورت سے زیادہ وسیع اجازتیں، اور وہ اکاؤنٹس ہیں جو مہینوں پہلے بند ہو جانے چاہیے تھے۔
انٹرپرائز اور سرکاری ترتیبوں میں داؤ بڑھتے ہیں۔ عالمی انٹرپرائز درجنوں باہم ملی ڈائریکٹریاں، ہر مہینے ہزاروں شامل ہونے اور جانے والے، اور ایسے شراکت دار سنبھالتا ہے جنہیں آپ کے نظاموں کے ٹکڑے تک دائرہ بند رسائی چاہیے۔ سرکاری ایجنسی اس پر اسمارٹ کارڈ کی اسناد، لازمی شناخت کی یقین دہانی کی سطحیں، اور آڈیٹرز تہہ دار کرتی ہے جو تحریری طور پر پوچھیں گے کہ دیے گئے دن کسی ریکارڈ کو ٹھیک کون چھو سکتا تھا۔ یہ باب اس بارے میں رائے رکھتا ہے کہ شناخت کی ایسی تہہ کیسے بنائی جائے جو آپ کے لوگوں کو ٹھپ کیے بغیر ان سوالوں کا اچھا جواب دے۔
بنیادی اصول
- تصدیق اور اجازت مختلف مسائل ہیں۔ شناخت ثابت کرنے اور اجازت دینے کو الگ ڈیزائن اور الگ ریویو چاہئیں۔
- ایک شناخت، بہت سے نظام۔ ہر شناخت کی آبادی کے لیے سچ کے واحد ماخذ پر یکجا ہوں؛ ڈائریکٹری کا پھیلاؤ سلامتی کا بگ ہے۔
- ڈیفالٹ سے کم از کم استحقاق۔ صفر رسائی سے شروع کریں اور جان بوجھ کر جوڑیں، انسانوں اور مشینوں دونوں کے لیے۔
- ہر سند عارضی ہے۔ طویل مدت کے رازوں پر قلیل مدت، خودکار طور پر جاری اسناد کو ترجیح دیں۔
- ڈی پروویژننگ اتنی ہی اہم ہے جتنی پروویژننگ۔ رسائی جو اپنی ضرورت سے زیادہ جیے خالص خطرہ ہے۔
- فشنگ کے خلاف مزاحم یادداشت کے قابل سے بہتر ہے۔ تصدیق کو passkeys اور ہارڈ ویئر کی پشت پناہی والے عناصر کی طرف لے جائیں۔
- مشینیں بھی شناختیں ہیں۔ ورک لوڈز، پائپ لائنز، اور سروسز کو منظم شناخت چاہیے، مشترک جامد چابیاں نہیں۔
- رسائی زندگی کا چکر ہے، واقعہ نہیں۔ شیڈول پر دیں، ریویو کریں، اور منسوخ کریں، اور ثابت کریں کہ آپ نے کیا۔
سفارشات
تصدیق کو اجازت سے الگ کریں، اور دونوں کو مرکزی کریں
ایک شناخت فراہم کنندہ (IdP) سے تصدیق کریں، ایسا نظام جو شناخت کی توثیق کرتا اور ٹوکن جاری کرتا ہے جن پر دوسرے نظام بھروسہ کرتے ہیں۔ پھر ہر ایپلیکیشن کو اس ٹوکن کی اٹھائی شناخت اور خصوصیات سے اپنی اجازت کے فیصلے کرنے دیں۔ یہ تقسیم آپ کو تصدیق ایک بار سب کے لیے مضبوط کرنے دیتی ہے جبکہ باریک اجازت کی منطق اس ڈیٹا کے قریب رکھتی ہے جس کی وہ حفاظت کرتی ہے۔ سنگل سائن آن (SSO) اپنائیں، جہاں ایک تصدیق بہت سی ایپلیکیشنز تک رسائی دیتی ہے، تاکہ آپ کے لوگوں کے پاس چالیس کمزور لاگ اِن کی بجائے ایک مضبوط لاگ اِن ہو۔ فیڈریشن وہی اعتماد تنظیمی حدوں کے پار بڑھاتی ہے، شراکت دار کی شناختوں کو آپ کے نظاموں تک رسائی دیتی ہے بغیر آپ کے ان کے پاس ورڈ منظم کیے۔
ہر جدید پروٹوکول اس کام کے لیے استعمال کریں جس کے لیے وہ ہے
تین معیار زیادہ تر کام کرتے ہیں، اور ہر ایک کا کام ہے۔ OpenID Connect (OIDC) OAuth 2.0 پر بنی شناخت کی تہہ ہے؛ ویب اور موبائل سائن اِن کے لیے یہ صارف کون ہے کا جواب دینے کو اسے استعمال کریں۔ OAuth 2.0 تفویض شدہ رسائی کا اجازت کا فریم ورک ہے؛ اسے ایپلیکیشن کو صارف کی طرف سے اس کا پاس ورڈ دیکھے بغیر API کال کرنے دینے کو استعمال کریں (باب 2.3)۔ Security Assertion Markup Language (SAML) پرانا XML پر مبنی فیڈریشن کا معیار ہے؛ یہ قائم شدہ کاروباری ایپلیکیشنز میں انٹرپرائز SSO کا کام کا گھوڑا ہے۔ عام غلطی OAuth سے سیدھے تصدیق کروانا ہے۔ OAuth وسائل تک رسائی دیتا ہے؛ OIDC اس کے اوپر شناخت قائم کرتا ہے۔ نئی صارف کی طرف والی سائن اِن کے لیے OIDC چنیں، SAML وہاں رکھیں جہاں آپ کا انٹرپرائز کیٹلاگ مانگے، اور اپنا ٹوکن فارمیٹ ایجاد نہ کریں۔
تصدیق کو فشنگ کے خلاف مزاحم بنائیں
اکیلے پاس ورڈز پیمانے پر ناقابل دفاع ہیں۔ بغیر استثنا ہر انسانی اکاؤنٹ کے لیے کثیر عنصری تصدیق (MFA) لازمی کریں، جو آپ کچھ جانتے ہیں، آپ کے پاس کچھ ہے، اور آپ کچھ ہیں کو ملاتی ہے۔ پھر کمزور عناصر سے آگے بڑھیں: SMS پر ایک بار کے کوڈ فشنگ کے قابل اور SIM بدلنے کے قابل ہیں۔ مضبوط منزل passkeys اور بنیادی WebAuthn معیار (عوامی چابی کی تصدیق کے لیے براؤزر API) ہیں، جو لاگ اِن کو ہارڈ ویئر میں رکھی نجی چابی اور حقیقی سائٹ کی origin سے باندھتے ہیں، تاکہ جعلی صفحہ چرانے کے قابل کچھ نہ سمیٹ سکے۔ Passkeys بغیر پاس ورڈ بھی ہیں، جس کا آپ کے صارفین شکریہ ادا کریں گے۔ اکاؤنٹ کی بحالی اور پاس ورڈ ری سیٹ کو تصدیق کی سطح کا حصہ سمجھیں، کیونکہ حملہ آور جو آپ کا MFA نہ ہرا سکے وہ ری سیٹ کے بہاؤ پر حملہ کرے گا۔
شامل ہونے-منتقل ہونے-جانے کا زندگی کا چکر منظم کریں، اور جلد ڈی پروویژن کریں
شناخت زندگی کا چکر ہے۔ شامل ہونے والے کو پہلے دن درست رسائی چاہیے۔ منتقل ہونے والے کو، جو کردار بدلتا ہے، نئی رسائی چاہیے اور، فیصلہ کن طور پر، پرانی ہٹنی چاہیے، ورنہ وہ آہستہ آہستہ پوری عمارت کی چابیاں جمع کر لیتا ہے۔ جانے والے کو تمام نظاموں میں فوراً تمام رسائی کھونی چاہیے، مثالی طور پر اپنے آخری دن کے منٹوں میں۔ اسے مستند ماخذ سے چلائیں، عموماً انسانی وسائل کا نظام، تاکہ وہاں حیثیت کی تبدیلی نیچے خود بخود پروویژن اور ڈی پروویژن کرے۔ اسے خودکار کریں۔ دستی آف بورڈنگ کی چیک لسٹیں ہمیشہ کچھ چوکتی ہیں، اور جو اکاؤنٹ چوکتا ہے وہی واقعے کی رپورٹ میں ظاہر ہوتا ہے۔
اجازت کا ماڈل چنیں اور اسے policy-as-code کے طور پر بیان کریں
کردار پر مبنی رسائی کے کنٹرول (RBAC) سے اجازتیں دیں، جہاں آپ اجازتیں کام کے فعل کے کرداروں کو اور لوگ کرداروں کو تفویض کرتے ہیں، کیونکہ اس پر استدلال سادہ اور آڈٹ آسان ہے۔ خصوصیت پر مبنی رسائی کے کنٹرول (ABAC) تک وہاں پہنچیں جہاں آپ کو شعبہ، ڈیٹا کی درجہ بندی، مقام، یا دن کے وقت جیسی خصوصیات پر سیاق سے باخبر فیصلے چاہیے۔ زیادہ تر پختہ ادارے ہائبرڈ چلاتے ہیں: موٹی اجازتوں کے لیے RBAC، باریک شرائط کے لیے ABAC۔ جو بھی چنیں، اجازت کو policy-as-code کے طور پر بیان کریں: قواعد جو کنسول میں کلک کرنے کی بجائے ورژن کنٹرول شدہ، قابل ٹیسٹ، قابل ریویو شکل میں لکھے ہوں۔ Policy-as-code رسائی کے فیصلوں کو قابل آڈٹ، قابل موازنہ، اور ماحول بھر میں مستقل بناتا ہے، اور آپ کو اجازت کی تبدیلی بھیجنے سے پہلے ٹیسٹ کرنے دیتا ہے۔
just-in-time رسائی اور PAM سے کم از کم استحقاق نافذ کریں
کم از کم استحقاق کا اصول لاگو کریں: ہر شناخت کو کم از کم وہ رسائی ملے جو اسے چاہیے اور اس سے زیادہ نہیں۔ کھڑا استحقاق دشمن ہے، کیونکہ مستقل دی گئی اجازت ہر اس حملہ آور کو دستیاب اجازت ہے جو کسی بھی وقت اس اکاؤنٹ پر اترے۔ just-in-time (JIT) رسائی کو ترجیح دیں، جہاں شخص مقررہ کھڑکی کے لیے بلند حقوق کی درخواست کرتا ہے، منظوری کے بعد انہیں پاتا ہے، اور کھڑکی بند ہونے پر خود بخود کھو دیتا ہے۔ اپنے سب سے خطرناک اکاؤنٹس کے لیے privileged access management (PAM) اپنائیں: ایسا نظام جو انتظامی اسناد کو vault کرتا ہے، مراعات یافتہ سیشنز کی ثالثی اور ریکارڈنگ کرتا ہے، اور طلب پر بلندی جاری کرتا ہے۔ ہدف صفر کھڑی انتظامی رسائی ہے، تاکہ مکمل سمجھوتا شدہ لیپ ٹاپ بھی کچھ پائیدار نہ دے۔
مشینوں اور ورک لوڈز کو حقیقی شناخت دیں
انسان آپ کی شناختوں کا صرف آدھا حصہ ہیں۔ سروسز، پائپ لائنز، کنٹینرز، اور فنکشنز سب کسی چیز سے تصدیق کرتے ہیں، اور اکثر ترتیب کی فائل میں چسپاں طویل مدت کے راز کے ساتھ کرتے ہیں۔ جامد چابیاں منظم ورک لوڈ شناخت سے بدلیں: قلیل مدت کی اسناد جو ورک لوڈ کو اس بنیاد پر خود بخود جاری ہوں کہ وہ کہاں چلتا ہے اور کیا ہے۔ سروس سے سروس تصدیق کے لیے باہمی TLS (mTLS) استعمال کریں، جہاں کنکشن کے دونوں فریق سرٹیفکیٹ پیش کرتے ہیں۔ جو بھی باقی راز ہوں انہیں گردش کے ساتھ مخصوص راز کے مینیجر میں رکھیں، سورس کوڈ یا امیجز میں کبھی نہیں (باب 4.2)۔ قلیل مدت کی، خودکار طور پر گھمائی جانے والی ورک لوڈ کی اسناد کلاؤڈ کی اسناد کے لیک ہونے کی واحد عام ترین وجہ ہٹاتی ہیں۔
شناخت کو کنٹرول پلین بنائیں، اور رسائی کا مسلسل ریویو کریں
zero trust فن تعمیر (باب 4.1) میں شناخت وہ جگہ ہے جہاں پالیسی طے اور نافذ ہوتی ہے، اس لیے اس کے مطابق وہاں سرمایہ لگائیں۔ پھر رسائی کے ریویو سے چکر بند کریں، جسے recertification بھی کہتے ہیں: شیڈول پر، ہر نظام کا مالک تصدیق کرتا ہے کہ رسائی رکھنے والے ہر شخص اور مشین کو اب بھی اس کی ضرورت ہے، اور جس کا جواز نہ دے سکے اسے منسوخ کرتا ہے۔ ہر تصدیق اور اجازت کا واقعہ آڈٹ کے نشان میں کھلائیں جو جواب دے کس نے کیا، کب، اور کس پالیسی کے تحت رسائی کی (باب 4.6)۔ رسائی کے ریویو استحقاق کے رینگنے سے لڑنے کا طریقہ ہیں، اجازتوں کا آہستہ جمع ہونا جہاں کوئی ایک اجازت کبھی غیر معقول نہ لگی مگر مل کر اکاؤنٹ کو بہت طاقتور بنا دیتی ہیں۔
سمجھوتے: فوائد اور نقصانات
| فیصلہ | فوائد | نقصانات |
|---|---|---|
| SSO کے ساتھ مرکزی IdP | ایک مضبوط لاگ اِن، مستقل پالیسی، آسان آڈٹ | ناکامی کا واحد نقطہ؛ بندش سب کو باہر کر دیتی ہے |
| RBAC | سادہ، قابل آڈٹ، مانوس | کرداروں کا پھٹنا؛ سیاق کے حساس ضروریات کے لیے موٹا |
| ABAC | باریک، سیاق سے باخبر، خصوصیات کے ساتھ پیمائش کرتا ہے | ڈیزائن، ٹیسٹ، اور استدلال مشکل |
| Passkeys / WebAuthn | فشنگ کے خلاف مزاحم، بغیر پاس ورڈ، مضبوط | بحالی اور آلے کے کھونے کے بہاؤ کو محتاط ڈیزائن چاہیے |
| Just-in-time رسائی | تقریباً صفر کھڑا استحقاق | رگڑ؛ تیز، قابل اعتماد منظوری کے راستے چاہئیں |
| شراکت داروں کے ساتھ فیڈریشن | کوئی بیرونی پاس ورڈ کا انتظام نہیں؛ دائرہ بند اعتماد | اعتماد شراکت دار کی اپنی صفائی پر منحصر |
| طویل مدت کی سروس کی چابیاں | قائم کرنے میں معمولی آسان | لیک کی طرف مائل؛ اسناد کی خلاف ورزیوں کی اوپری وجہ |
مرکزی کھنچاؤ سلامتی بمقابلہ رگڑ ہے۔ ہر کنٹرول جو حملے کی سطح سکیڑتا ہے (ہر چیز پر MFA، JIT بلندی، قلیل مدت کی سند) کسی کے دن میں ایک قدم بھی جوڑتا ہے، اور لوگ ان کنٹرولز کے گرد راستہ نکالتے ہیں جو بہت تکلیف دیں۔ محفوظ راستے کو آسان راستہ بنا کر حل کریں: SSO تاکہ مضبوط تصدیق ایک ٹیپ ہو، passkeys تاکہ ٹائپ کرنے کو پاس ورڈ نہ ہو، اور خودکار پروویژننگ تاکہ درست رسائی بس ظاہر ہو جائے۔ اپنا رگڑ کا بجٹ وہاں خرچ کریں جہاں دھماکے کا دائرہ سب سے بڑا ہے، مراعات یافتہ اور پروڈکشن رسائی پر، اور روزمرہ رسائی کو تقریباً بغیر رگڑ رکھیں۔
اپنی ٹیم کے ساتھ بحث کے سوالات
آج جانے والے کسی شخص کی تمام رسائی آپ واقعی کتنی جلدی منسوخ کر سکتے ہیں، اور آپ کو کیسے پتا کہ کام ہوا؟ ڈی پروویژننگ کی رفتار آپ کی شناخت کی پختگی کا براہ راست پیمانہ ہے، کیونکہ جانے والا جس کی رسائی باقی رہے وہ حقیقی اجازتوں والا غیر نگرانی شدہ اکاؤنٹ ہے۔ درجنوں غیر منسلک نظاموں والے بڑے ادارے میں ایماندار جواب اکثر “ہمیں یقین نہیں” ہوتا ہے، اور خلا عموماً وہ ایپلیکیشنز ہیں جو مرکزی شناخت فراہم کنندہ سے کبھی نہیں جڑیں۔ حالیہ حقیقی رخصتی لائیں اور ہر نظام کا سراغ لگائیں جسے وہ چھو سکتے تھے، ٹائم اسٹیمپس جانچیں کہ ہر رسائی دراصل کب ختم ہوئی۔ ہدف طے کریں، جیسے انسانی وسائل کی حیثیت کی تبدیلی کے ایک گھنٹے کے اندر مکمل منسوخی، اور اسے آلہ دار بنائیں تاکہ آپ امید کرنے کی بجائے ثابت کر سکیں۔ اگر کوئی نظام کسی کے دستی قدم یاد رکھنے پر انحصار کرتا ہے تو یہ وہ اکاؤنٹ ہے جسے مستقبل کی خلاف ورزی استعمال کرے گی۔
آپ کے پاس اب بھی کھڑا مراعات یافتہ رسائی اور طویل مدت کی جامد اسناد کہاں ہیں، اور انہیں ختم کرنے کو کیا درکار ہوگا؟ کھڑے انتظامی حقوق اور مستقل سروس کی چابیاں وہ دو اثاثے ہیں جو حملہ آور سب سے زیادہ چاہتے ہیں، کیونکہ وہ پائیدار اور طاقتور ہیں۔ ہر اس انسان کی فہرست بنائیں جس کے پاس ہمیشہ چالو پروڈکشن یا انتظامی رسائی ہے اور ہر سروس جو جامد چابی سے تصدیق کرتی ہے، پھر ایمانداری سے پوچھیں کہ ان میں سے کون just-in-time بلندی یا قلیل مدت کی ورک لوڈ شناخت پر جا سکتا ہے۔ متصادم غور آپریشنل خوف ہے: ٹیمیں کھڑی رسائی رکھتی ہیں کیونکہ break-glass کے لمحات اس کے ساتھ محفوظ لگتے ہیں، اس لیے آپ کو کھڑے حقوق ہٹانے سے پہلے ہنگامی بلندی تیز اور قابل اعتماد بنانی ہوگی۔ فہرست بحث میں لائیں اور آئٹمز کو دھماکے کے دائرے سے درجہ بند کریں، پہلے پروڈکشن اور انتظامی رسائی کو ہدف بناتے ہوئے۔ جس انجام کا ہدف رکھنا ہے وہ صفر کھڑی انتظامی رسائی اور کوئی جامد چابی نہیں جو ایک تعیناتی سے زیادہ جیے۔
کیا آپ کے پاس فی شخص اور فی ورک لوڈ ایک مستند شناخت ہے، یا کئی، اور پھیلاؤ آپ کو کیا لاگت دے رہا ہے؟ ڈائریکٹری کا پھیلاؤ، جہاں وہی انسان پانچ نظاموں میں بھٹکتی خصوصیات کے ساتھ پانچ اکاؤنٹس کے طور پر موجود ہے، وہ جگہ ہے جہاں ڈی پروویژننگ کے خلا اور یتیم رسائی جنم لیتی ہیں۔ ہر شناخت کی آبادی کے لیے سچ کے واحد ماخذ پر یکجا ہونا بڑی ٹیم کی سب سے زیادہ لیوریج والی سرمایہ کاریوں میں سے ایک ہے، کیونکہ ہر نیچے کا کنٹرول اس جاننے پر منحصر ہے کہ دو ریکارڈ ایک ہی شخص ہیں۔ اپنی شناخت کے اسٹورز کی فہرست لائیں اور نقشہ بنائیں کون سے مستند ہیں بمقابلہ کون سی آسان نقلیں ہیں جنہیں کوئی منظم نہیں کرتا۔ سمجھوتا یہ ہے کہ یکجا ہونا بڑی، بے رونق منتقلی ہے جو فیچر کے کام کے ساتھ توجہ کے لیے مقابلہ کرتی ہے۔ فیصلہ کریں کہ آیا آڈٹ کی تکلیف اور خلاف ورزی کے خطرے میں پھیلاؤ کی جاری لاگت اس منتقلی کو اگلے واقعے کے بعد کی بجائے ابھی فنڈ کرنے کا جواز دیتی ہے۔
کیا آپ کے مضبوط ترین تصدیقی عناصر واقعی فشنگ کے خلاف مزاحم ہیں، اور پاس ورڈز ہمیشہ کے لیے ریٹائر کرنے سے آپ کو کیا روک رہا ہے؟ وہ عنصر جسے حملہ آور فش نہیں کر سکتا وہی ہے جو اسناد کی چوری کو آپ کا غالب خلاف ورزی کا راستہ ہونے سے ختم کرتا ہے، اور WebAuthn سے بندھے passkeys واحد وسیع طور پر تعینات ہونے والا اختیار ہیں جو وہ معیار پار کرتا ہے۔ بڑے ادارے میں ایماندار تصویر عموماً ملی جلی ہوتی ہے: کچھ کے لیے passkeys، دوسروں کے لیے SMS پر ایک بار کے کوڈ، اور پرانی ایپلیکیشنز کی لمبی دم جو اب بھی اکیلا پاس ورڈ قبول کرتی ہیں۔ متصادم غور حقیقی ہے، کیونکہ passkeys مشکل مسئلہ بحالی اور آلے کے کھونے کی طرف منتقل کرتے ہیں، اور بے ڈھنگا بحالی کا بہاؤ نیا نرم ہدف بنتا ہے جس کی طرف حملہ آور بس مڑ جاتا ہے۔ عنصر کی قسم سے کوریج کے اعداد، ان ایپلیکیشنز کی فہرست جو اب بھی پاس ورڈ پر واپس جاتی ہیں، اور اکاؤنٹ کی بحالی کا ڈیزائن شدہ راستہ لائیں جس پر آپ پرعزم سماجی انجینئرنگ کی کوشش کے خلاف بھروسہ کریں۔ انٹرپرائز اور سرکاری ترتیبوں میں ہدف کو کسی بھی لازمی یقین دہانی کی سطح سے جوڑیں، کیونکہ اعلیٰ یقین دہانی کا نظام جو پھر بھی فشنگ کے قابل عنصر کی اجازت دے اس میں سلامتی کے ساتھ تعمیل کا بھی خلا ہے۔
آپ کیسے طے کرتے ہیں کہ ہر شناخت کو کون سی رسائی ملتی ہے، اور کیا آپ اس فیصلے کے بھیجنے سے پہلے اسے diff، ٹیسٹ، اور ثابت کر سکتے ہیں؟ “کسی نے کنسول میں اجازتوں پر کلک کیا” اور “ریویو شدہ، ورژن کنٹرول شدہ پالیسی” کے درمیان کا خلا اس رسائی کے ماڈل کا فرق ہے جس کا آپ آڈٹ کر سکتے ہیں اور جس پر آپ صرف معافی مانگ سکتے ہیں۔ بڑی ٹیم کے لیے دباؤ ہر ایپلیکیشن کو اپنے مخصوص اصول اگانے دینا ہے، جو خاموشی سے RBAC کی طرف کرداروں کا پھٹنا اور ABAC کی طرف ناقابل ٹیسٹ شرائط پیدا کرتا ہے، یہاں تک کہ کوئی نہیں بتا سکتا کہ دی گئی اجازت دراصل کیا اجازت دیتی ہے۔ متصادم غور ترسیل کی رفتار ہے، کیونکہ اجازت کو policy-as-code کے طور پر بیان کرنا ریویو کا قدم جوڑتا ہے جو کنسول کلک نہیں جوڑتا، اور ڈیڈ لائن کے تحت ٹیمیں رگڑ کی ناراضی رکھتی ہیں جب تک پہلا ناکام آڈٹ یا ضرورت سے وسیع اجازت ان کا مقدمہ نہ بنا دے۔ حقیقی اجازت کی تبدیلی لائیں اور سراغ لگائیں کہ اسے کیسے تجویز، ٹیسٹ، ریویو، اور واپس کیا جائے گا، ساتھ یہ گنتی کہ آپ کے کتنے کردار ہیں اور کتنوں کی کوئی وضاحت نہیں کر سکتا۔ انٹرپرائز اور سرکاری ترتیبوں میں آڈیٹر آپ سے مانگے گا کہ دکھائیں دیے گئے دن کسی ریکارڈ تک ٹھیک کون اور کس اصول کے تحت پہنچ سکتا تھا، اور صرف قابل موازنہ، قابل ٹیسٹ پالیسی بھاگ دوڑ کے بغیر یہ جواب دیتی ہے۔
رسائی کے ریویو نے آخری بار کب کچھ حقیقی منسوخ کیا، اور جب استحقاق کا رینگنا غیر چیک رہے تو جوابدہ کون ہے؟ رسائی کے ریویو وہ کنٹرول ہیں جو اجازتوں کے آہستہ جمع ہونے سے لڑتے ہیں جہاں کوئی ایک اجازت کبھی غیر معقول نہ لگی، اور ریویو جو کبھی کچھ منسوخ نہ کرے وہ ریویو کا تھیٹر ہے جو سلامتی کی بجائے کاغذی کارروائی پیدا کرتا ہے۔ بڑے ادارے میں ناکامی کا انداز مہر لگانا ہے: نظام کے مالک ایک بیٹھک میں سینکڑوں اندراجات کی recertify کرتے ہیں، سب منظور کرتے ہوئے کیونکہ ہر ایک کا حقیقی جائزہ تھکا دینے والا ہے اور رسائی بہتی رکھنے کی ترغیب اسے کاٹنے کی ترغیب سے مضبوط ہے۔ متصادم غور یہ ہے کہ بامعنی ریویو مالک کا وقت لیتے اور کبھی کبھار کسی کا ورک فلو توڑتے ہیں جب رسائی جس پر وہ خاموشی سے انحصار کرتے تھے غائب ہو، اس لیے ریویو کو بے امتیاز فہرست کی بجائے ہدف شدہ اور خطرے پر مبنی بنانا ہوگا۔ اپنے آخری چکر کی منسوخی کی شرح، فی شخص اوسط استحقاق کی تعداد، اور ہر نظام کی recertification کا مالک کون ہے کی شہادت لائیں۔ انٹرپرائز اور سرکاری ترتیبوں میں ہر ریویو کے جوابدہ افسر اور اس تال کا نام لیں جس کے وہ پابند ہیں، کیونکہ استحقاق کا رینگنا جسے پکڑنے کا کوئی ذمہ دار نہ ہو ٹھیک وہ حالت ہے جس کا آڈیٹر اور حملہ آور دونوں فائدہ اٹھاتے ہیں۔
شعبہ جاتی نقطۂ نظر
اسٹارٹ اپ۔ شناخت خریدیں، بنائیں نہیں۔ SSO، لازمی passkeys، اور ایک کلک آف بورڈنگ کے ساتھ ایک میزبانی والا شناخت فراہم کنندہ مٹھی بھر انجینئروں کو فی نشست فیس پر انٹرپرائز درجے کی حیثیت دیتا ہے۔ فراہم کنندہ کی اندرونی ورک لوڈ شناخت پر انحصار کریں تاکہ آپ کی پائپ لائن میں ایک بھی طویل مدت کی کلاؤڈ چابی نہ ہو، اور ٹوکن کی ہینڈلنگ ایجاد کرنے کی بجائے جسے آپ برقرار رکھنے کی استطاعت نہیں رکھتے OIDC اور OAuth 2.0 تیار استعمال کریں۔
چھوٹا کاروبار۔ عملے پر شناخت کے ماہر کے بغیر ان ٹولز میں پہلے سے بنڈل SSO اور MFA کو ترجیح دیں جن کی آپ ادائیگی کرتے ہیں، اور انہیں الگ پلیٹ فارم ڈھونڈنے کی بجائے چالو کریں۔ شامل ہونے-منتقل ہونے-جانے کے مسئلے کو بھرتی کے مالک سے بندھی مختصر تحریری چیک لسٹ سمجھیں، اور passkeys کو ترجیح دیں کیونکہ وہ پاس ورڈ ری سیٹ کا ہیلپ ڈیسک کا بوجھ ہٹاتے ہیں جو سنبھالنے کو آپ کے پاس کسی کو دینے کے لیے نہیں۔ مشترک لاگ اِن سے بچیں، کیونکہ وہ سستی عادت ہے جو بعد میں منسوب کرنا اور منسوخ کرنا ناممکن بناتی ہے۔
بڑا ادارہ۔ کام بہت سی ڈائریکٹریوں اور ٹیموں میں یکجا ہونا اور نظم و نسق ہے: انسانی وسائل کے نظام سے چلنے والا ایک مستند شناخت فراہم کنندہ، خودکار شامل ہونے-منتقل ہونے-جانے کے بہاؤ، کام کے فعل کے لیے RBAC اور سیاق کے لیے ABAC، اور سیشن کی ریکارڈنگ کے ساتھ privileged access management۔ اجازت کو policy-as-code کے طور پر بیان کریں تاکہ تبدیلیاں قابل موازنہ اور قابل ٹیسٹ ہوں، شیڈول شدہ رسائی کے ریویو چلائیں جو واقعی منسوخ کریں، اور انٹرفیس معیاری بنائیں تاکہ ایپلیکیشنز ہر ایک اپنا لاگ اِن اگانے کی بجائے مرکزی شناخت سے جڑیں۔
حکومت۔ خریداری کے قواعد، شفافیت، اور عوامی جوابدہی ڈیزائن چلاتے ہیں۔ تصدیق کو PIV یا CAC اسمارٹ کارڈز جیسی ہارڈ ویئر کی اسناد سے باندھیں، NIST SP 800-63 کے مطابق شناخت کی یقین دہانی کی سطحیں طے کریں تاکہ زیادہ خطرے کے نظام اعلیٰ یقین دہانی کے عناصر مانگیں، اور ناقابل تبدیل آڈٹ لاگز رکھیں جو بالکل جواب دیں کہ کس نے کیا اور کب رسائی کی۔ شہری کی طرف والی شناخت کی سادہ زبان کی ہینڈلنگ شائع کریں، گاہک اور افرادی قوت کے شناخت کے اسٹیکس الگ رکھیں، اور یقینی بنائیں کہ حساس نظام پر ہر مراعات یافتہ عمل ان آڈیٹرز کے لیے ثالثی اور ریکارڈ ہو جو پوچھیں گے۔
مثالیں
اسٹارٹ اپ۔ بیس افراد کا اسٹارٹ اپ شناخت کی ٹیم کا عملہ نہیں دے سکتا، اس لیے خریدتا ہے۔ ہر ملازم واحد میزبانی والے شناخت فراہم کنندہ سے ای میل، کوڈ کی میزبانی، کلاؤڈ کنسول، اور اندرونی ایپ میں SSO سے سائن اِن کرتا ہے، اور passkeys لازمی ہیں اس لیے فش کرنے کو پاس ورڈ نہیں۔ آف بورڈنگ ایک کلک ہے: شناخت فراہم کنندہ میں شخص کو بند کرنا ہر جگہ ایک ساتھ رسائی کاٹتا ہے۔ اپنی پروڈکٹ کے لیے وہ صارف کی سائن اِن کو OIDC اور انضمام کو دائرہ بند ٹوکنز سے ان کی API کال کرنے دینے کو OAuth 2.0 استعمال کرتے ہیں۔ سروس سے کلاؤڈ کی تصدیق فراہم کنندہ کی اندرونی ورک لوڈ شناخت استعمال کرتی ہے، اس لیے ان کی پائپ لائن میں کہیں ایک بھی طویل مدت کی کلاؤڈ چابی نہیں۔ اس کی لاگت معمولی فی نشست فیس ہے اور یہ انہیں بہت سے انٹرپرائزز کے چلانے سے مضبوط شناخت کی حیثیت خریدتا ہے۔
بڑا ادارہ۔ کثیر قومی بینک نے دہائی میں چار ڈائریکٹریاں اور سینکڑوں ایپلیکیشنز جمع کی ہیں، کچھ SAML سے فیڈریٹڈ، کچھ اپنے مقامی لاگ اِن کے ساتھ۔ وہ یکجا ہونے کے پروگرام کو فنڈ کرتا ہے: انسانی وسائل کے نظام سے چلنے والا ایک مستند شناخت فراہم کنندہ، خودکار شامل ہونے-منتقل ہونے-جانے کے بہاؤ کے ساتھ جو بھرتی پر پروویژن اور برطرفی کے منٹوں میں منسوخ کرتے ہیں۔ RBAC معیاری کام کے فعل ڈھکتا ہے جبکہ ABAC سرحد پار رسائی کے لیے ڈیٹا کے مقام اور کلیئرنس کے اصول نافذ کرتا ہے۔ منتظمین کے پاس کھڑی پروڈکشن رسائی نہیں؛ وہ privileged access management کے نظام سے just-in-time بلندی کی درخواست کرتے ہیں جو ہر سیشن ریکارڈ کرتا ہے۔ سہ ماہی رسائی کے ریویو نظام کے مالکان کو recertify یا منسوخ کرنے پر مجبور کرتے ہیں، اور ہر فیصلہ policy-as-code کے طور پر بیان ہے تاکہ آڈیٹر بالکل دیکھ سکیں کیا اور کب بدلا۔
حکومت۔ وفاقی ایجنسی اپنی افرادی قوت کو personal identity verification (PIV) اسمارٹ کارڈز، اور فوجی مساوی، common access card (CAC)، جاری کرتی ہے، تاکہ تصدیق پاس ورڈ کی بجائے ہارڈ ویئر کی سند سے بندھی ہو۔ اس کا شناخت کا پروگرام وفاقی شناخت، سند، اور رسائی کے انتظام (FICAM) کے طریقے کی پیروی کرتا ہے اور National Institute of Standards and Technology کی گائیڈ NIST SP 800-63 کے مطابق شناخت کی یقین دہانی کی سطحیں طے کرتا ہے، تاکہ زیادہ خطرے کے نظام اعلیٰ یقین دہانی کی اسناد مانگیں۔ شہری کی طرف والی سروسز مضبوط MFA کے ساتھ کم یقین دہانی کی سطح پر الگ گاہک شناخت کا اسٹیک استعمال کرتی ہیں۔ رسائی کے ریویو اور ناقابل تبدیل آڈٹ لاگز براہ راست ایجنسی کی مسلسل اجازت کی شہادت (باب 4.6) میں کھلتے ہیں، اور درجہ بند نظام پر ہر مراعات یافتہ عمل کی ثالثی اور ریکارڈنگ ہوتی ہے۔
کاروباری جواز: محرکات، ROI اور TCO
شناخت کی سرمایہ کاری پر واپسی آپ کے غالب خلاف ورزی کے راستے کو خطرناک زون سے نکالنے سے آتی ہے۔ چرائی اسناد اور ضرورت سے زیادہ اجازتوں والے اکاؤنٹس حقیقی واقعات کا بڑا حصہ چلاتے ہیں، اور ہر ایک بھاری دم رکھتا ہے: واقعے کا جواب، ضابطے کے جرمانے، خلاف ورزی کی اطلاع، اور دیرپا ساکھ کا نقصان۔ اکیلی فشنگ کے خلاف مزاحم MFA سب سے عام دراندازی کا راستہ ختم کرتی ہے، اور خودکار ڈی پروویژننگ یتیم اکاؤنٹس کا خلا بند کرتی ہے جو معمول کی رخصتی کو نمائش بنا دیتا ہے۔ یہ خرچ ہوئے ہر ڈالر پر دستیاب سستی ترین خطرے کی کمیوں میں سے ہیں۔
ملکیت کی کل لاگت حقیقی مگر محدود ہے۔ اس میں شناخت فراہم کنندہ کی لائسنسنگ، privileged access management اور راز کا پلیٹ فارم، ہر ایپلیکیشن کو مرکزی شناخت میں جوڑنے کی انجینئرنگ، اور رسائی کے ریویو کی جاری محنت شامل ہے۔ بڑی لاگت تنظیمی ہے: ڈائریکٹریاں یکجا کرنا اور پرانی ایپلیکیشنز پر SSO دوبارہ لگانا سست، بے رونق کام ہے جو فیچرز سے مقابلہ کرتا ہے۔ اسے متبادل کے مقابل تولیں۔ بکھری شناخت وہی پیسہ ہمیشہ دستی آف بورڈنگ، آڈٹ کی بھاگ دوڑ، اور ہیلپ ڈیسک کے پاس ورڈ ری سیٹ کی شکل میں خرچ کرتی ہے، ساتھ اس خلاف ورزی کی آخری لاگت جسے بکھراؤ ممکن بناتا ہے۔ جب قیادت کے سامنے دلیل رکھیں تو شناخت کو zero trust کے کنٹرول پلین کے طور پر پیش کریں: یکجا ہونا اور خودکاری ایک بار کی سرمایہ کاری ہے جو خلاف ورزی کا خطرہ اور آڈٹس، آف بورڈنگ، اور رسائی کی معاونت کی بار بار کی لاگت دونوں کم کرتی ہے۔
ضد نمونے اور خامیاں
- یتیم اکاؤنٹس۔ رسائی جو شخص یا مقصد سے زیادہ جیتی ہے، خاص طور پر غیر نگرانی شدہ سروس اکاؤنٹس اور بھولے ہوئے ٹھیکیدار۔
- ہر جگہ کھڑا ایڈمن۔ just-in-time بلندی کی بجائے ہمیشہ چالو مراعات یافتہ رسائی، ہر سمجھوتا شدہ ایڈمن اکاؤنٹ کو پائیدار طاقت دیتی ہوئی۔
- طویل مدت کی جامد چابیاں۔ ترتیب یا CI میں چسپاں سروس کی اسناد جو کبھی ختم نہیں ہوتیں اور آخرکار لیک ہو جاتی ہیں۔
- ڈائریکٹری کا پھیلاؤ۔ وہی شخص بہت سے غیر منظم اکاؤنٹس کے طور پر، اس لیے کوئی تبدیلی کبھی پوری طرح نہیں پھیلتی۔
- مشترک اکاؤنٹس۔ کئی لوگوں کی استعمال کی اسناد، منسوب کرنا تباہ کرتے اور منسوخ کرنا ناممکن بناتے ہوئے۔
- SMS آپ کے مضبوط عنصر کے طور پر۔ فشنگ کے قابل، SIM بدلنے کے قابل ایک بار کے کوڈز کو کافی MFA سمجھنا۔
- کرداروں کا پھٹنا۔ اتنے زیادہ باریک RBAC کردار کہ ماڈل ناقابل آڈٹ ہو جائے اور کوئی نہ جانے کردار کیا دیتا ہے۔
- دستی چیک لسٹ کے طور پر ڈی پروویژننگ۔ انسانی آف بورڈنگ کے قدم جو لازماً وہ ایک اکاؤنٹ چوکتے ہیں جو اہم ہے۔
- تصدیق کے لیے OAuth۔ رسائی کے ٹوکن کو OIDC استعمال کرنے کی بجائے شناخت کا ثبوت سمجھنا۔
- ریویو کا تھیٹر۔ رسائی کی recertifications جن پر مہر لگتی ہے بغیر کسی کے ضرورت کا حقیقی جائزہ لیے۔
پختگی کا ماڈل
- سطح 1، آغاز: ہر ایپلیکیشن کا اپنا لاگ اِن ہے۔ پاس ورڈز بغیر مستقل MFA۔ پروویژننگ اور آف بورڈنگ دستی، ردعملی، اور سست ہیں؛ یتیم اکاؤنٹس جمع ہوتے ہیں۔ سروس کی اسناد طویل مدت کی جامد چابیاں ہیں۔ کوئی رسائی کے ریویو نہیں؛ اجازتیں دی جاتی ہیں اور دوبارہ نہیں دیکھی جاتیں۔
- سطح 2، ترقی: SSO مرکزی شناخت فراہم کنندہ سے بڑی ایپلیکیشنز کو ڈھکتا ہے، مگر کوریج ٹیموں میں ناہموار ہے۔ زیادہ تر انسانی رسائی کے لیے MFA لازمی ہے۔ بنیادی RBAC موجود ہے۔ شامل ہونے-منتقل ہونے-جانے کا عمل انسانی وسائل کے نظام سے جزوی طور پر خودکار ہے۔ کچھ مراعات یافتہ اکاؤنٹس vault میں ہیں۔ رسائی کے ریویو کبھی کبھار اور غیر مستقل ہوتے ہیں۔
- سطح 3، معیار بندی: یکجا شناخت فراہم کنندہ افرادی قوت کے لیے مستند ہے، خودکار پروویژننگ اور فوری ڈی پروویژننگ ادارے بھر میں نافذ۔ فشنگ کے خلاف مزاحم MFA معیاری اور دستاویزی ہے۔ RBAC جمع ABAC policy-as-code کے طور پر بیان ہے۔ سیشن کی ریکارڈنگ کے ساتھ privileged access management موجود ہے۔ ورک لوڈ شناخت زیادہ تر جامد چابیوں کی جگہ لیتی ہے۔ شیڈول شدہ رسائی کے ریویو نافذ اور تحریری پالیسی کے مقابل آڈٹ ہوتے ہیں جس کی ہر ٹیم پیروی کرتی ہے۔
- سطح 4، انتظام: شناخت کا پروگرام بنیادی خطوط کے مقابل ناپا اور ڈیٹا سے کنٹرول کیا جاتا ہے۔ آپ انسانی وسائل کی حیثیت کی تبدیلی سے مکمل منسوخی تک ڈی پروویژننگ کا وقت، آبادی کے حساب سے MFA اور passkey کی کوریج، کھڑی مراعات یافتہ رسائی والے اکاؤنٹس کی گنتی، اب بھی استعمال میں طویل مدت کی جامد چابیوں کی تعداد، یتیم اکاؤنٹس کی گنتی، اور رسائی کے ریویو کی منسوخی کی شرحیں ٹریک کرتے ہیں۔ میٹرکس اہداف رکھتی ہیں، جیسے ایک گھنٹے کے اندر مکمل منسوخی اور صفر خالص نئے کھڑے ایڈمن کی اجازتیں، اور حد کی خلاف ورزی کندھے اچکانے کی بجائے تحقیقات ٹرگر کرتی ہے۔ اجازت کی تبدیلیاں پائپ لائن میں ٹیسٹ ہوتی ہیں اور رسائی کی اجازت پر آگے بڑھنے یا نہ بڑھنے کا ہر فیصلہ عادت کی بجائے شہادت سے چلتا ہے۔
- سطح 5، ہم آہنگی: شناخت zero trust کا مسلسل بہتر ہوتا کنٹرول پلین ہے، سلامتی، خطرے، اور شامل ہونے-منتقل ہونے-جانے کی منصوبہ بندی سے پورے ادارے میں مربوط۔ Passkeys ڈیفالٹ ہیں اور پاس ورڈز ریٹائر ہو رہے ہیں۔ صفر کھڑا استحقاق just-in-time بلندی سے حاصل ہوتا ہے، اور تمام ورک لوڈز قلیل مدت، خودکار طور پر گھمائی اسناد اور mTLS استعمال کرتے ہیں۔ اجازت مکمل policy-as-code ہے۔ رسائی کے ریویو مسلسل اور خطرے پر مبنی ہیں، ڈی پروویژننگ تقریباً فوری ہے، اور ہر فیصلہ خود بخود آڈٹ کی شہادت پیدا کرتا ہے۔ ماڈل خطرے کے اشارے بدلنے پر ڈھلتا ہے، مقررہ تال کی بجائے رسائی کو متحرک طور پر سخت یا ڈھیلا کرتے ہوئے۔
بحث کے لیے خیالات
- صفر کھڑی انتظامی رسائی تک پہنچنے کو کیا درکار ہوگا، اور کون سا break-glass راستہ اسے محفوظ بنائے گا؟
- آپ کے ماحول میں ABAC سادہ RBAC پر رہنے کے مقابل اپنی پیچیدگی کے قابل کہاں ہے؟
- آپ کو پاس ورڈز کو passkeys کے حق میں کتنی جارحیت سے ریٹائر کرنا چاہیے، اور کون سا بحالی کا بہاؤ انہیں بدلتا ہے؟
- کون سی ایپلیکیشنز اب بھی آپ کے مرکزی شناخت فراہم کنندہ سے باہر ہیں، اور انہیں وہاں کیا رکھتا ہے؟
- آپ شراکت داروں اور گاہکوں کو ان کی سلامتی کی صفائی وراثت میں پائے بغیر دائرہ بند رسائی کیسے دیتے ہیں؟
- کون سی واحد میٹرک آپ کی ڈی پروویژننگ کی رفتار کو بہترین گرفت میں لیتی ہے، اور کیا آپ اسے آج ناپ رہے ہیں؟
اہم نکات
- تصدیق ثابت کرتی ہے کہ آپ کون ہیں؛ اجازت طے کرتی ہے کہ آپ کیا کر سکتے ہیں۔ انہیں الگ ڈیزائن اور ریویو کریں۔
- SSO کے ساتھ ایک مستند شناخت فراہم کنندہ پر یکجا ہوں؛ ڈائریکٹری کا پھیلاؤ سلامتی کا نقص ہے، سہولت نہیں۔
- شامل ہونے-منتقل ہونے-جانے کے زندگی کے چکر کو خودکار کریں اور ڈی پروویژننگ کو تیز اور قابل ثبوت بنائیں۔
- صارف کی سائن اِن کے لیے OIDC، تفویض شدہ API رسائی کے لیے OAuth 2.0، اور جہاں انٹرپرائز کیٹلاگ مانگے وہاں SAML استعمال کریں؛ OAuth کو تصدیق کے طور پر استعمال نہ کریں۔
- تصدیق کو فشنگ کے خلاف مزاحم passkeys اور WebAuthn کی طرف لے جائیں؛ ہر جگہ MFA لازمی کریں اور کمزور عناصر کو عارضی اقدام سمجھیں۔
- just-in-time رسائی اور privileged access management سے کم از کم استحقاق نافذ کریں؛ صفر کھڑے ایڈمن حقوق کا ہدف رکھیں۔
- مشینوں کو قلیل مدت کی ورک لوڈ اسناد اور mTLS سے حقیقی شناخت دیں؛ طویل مدت کی جامد چابیاں ختم کریں۔
- شناخت کو zero trust (باب 4.1) کا کنٹرول پلین بنائیں، اور مسلسل رسائی کے ریویو اور آڈٹ کی شہادت (باب 4.6) سے چکر بند کریں۔
حوالہ جات اور مزید مطالعہ
- National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines (identity assurance, authentication, and federation levels)
- National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
- National Institute of Standards and Technology, SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
- National Institute of Standards and Technology, SP 800-53: Security and Privacy Controls, Access Control (AC) and Identification and Authentication (IA) families
- The OAuth 2.0 Authorisation Framework, IETF RFC 6749, and the OAuth 2.0 Security Best Current Practice
- OpenID Connect Core 1.0 specification, OpenID Foundation
- Security Assertion Markup Language (SAML) 2.0 specification, OASIS
- Web Authentication (WebAuthn) Level 2, W3C Recommendation, and FIDO2 / FIDO Alliance passkey specifications
- Federal Identity, Credential, and Access Management (FICAM) architecture and playbooks, U.S. General Services Administration
- FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors
- Open Policy Agent (OPA) documentation, Cloud Native Computing Foundation (policy-as-code for authorisation)