انتساب پر مبنی رسائی کنٹرول کے ساتھ اجازت کے بہتر اصول کیسے لکھیں۔

کوئی بھی ایپلیکیشن جو صارف کے ڈیٹا پر کارروائی کرتی ہے آخر کار انہی مسائل کا سامنا کرنا پڑے گا۔ تمام صارفین کو ایک ہی چیز نظر نہیں آئے گی۔

جونیئر نرسوں کو ہسپتال میں ہر مریض کے ریکارڈ تک رسائی نہیں ہونی چاہیے۔ ٹھیکیداروں کو داخلی مالیاتی رپورٹیں پڑھنے کے قابل نہیں ہونا چاہیے۔ غیر تسلیم شدہ آلات سے صبح 2 بجے لاگ ان ہونے والے ملازمین کو پروڈکشن کنفیگریشن فائلوں میں ترمیم نہیں کرنی چاہیے۔

ایک سادہ کردار پر مبنی نظام واضح معاملات کو اچھی طرح سے ہینڈل کرتا ہے۔ لیکن جیسے جیسے ایپلی کیشنز بڑھتے ہیں اور رسائی کے قواعد زیادہ اہم ہوتے جاتے ہیں، یہ سسٹم ٹوٹنا شروع ہو جاتے ہیں۔ آپ تیزی سے مخصوص کردار تخلیق کریں گے، جیسے: finance_viewer، finance_viewer_us_only، finance_viewer_us_only_readonlyجب تک کہ کردار خود بے قابو نہ ہو جائے۔

انتساب پر مبنی رسائی کنٹرول (ABAC) اسی مسئلے کو حل کرنے کے لیے ڈیزائن کیا گیا تھا۔ "اس صارف کا کیا کردار ہے؟” سے منتقلی "ہم اس صارف، اس وسائل، اس صورتحال کے بارے میں کیا جانتے ہیں؟” رسائی کے فیصلے ان تمام عوامل کی بنیاد پر ایک ساتھ کریں۔

اس گائیڈ میں، آپ یہ سیکھیں گے کہ ABAC کیسے کام کرتا ہے، پچھلے ایکسیس کنٹرول ماڈلز سے یہ کیسے تیار ہوا ہے، پالیسیاں کس طرح تشکیل دی جاتی ہیں، انہیں کوڈ میں کیسے لاگو کرنا ہے، اور انہیں کب استعمال کرنا ہے۔

انڈیکس

شرطیں

اس مضمون سے زیادہ سے زیادہ فائدہ اٹھانے کے لیے، آپ کو ضرورت ہوگی:

• ویب تصدیق کی بنیادی تفہیم (لاگ ان، سیشن، ٹوکن)

• اس بات کا علم کہ کس طرح استعمال کنندگان اور وسائل ایک ایپلی کیشن میں منسلک ہیں۔

• JavaScript یا pseudocode پڑھنے کا تجربہ کریں۔

رسائی کنٹرول تھیوری کے بارے میں پیشگی علم کی ضرورت نہیں ہے۔

رسائی کنٹرول کیسے تیار ہوا؟

یہ سمجھنے کے لیے کہ ABAC کیوں موجود ہے، یہ سمجھنا مددگار ہے کہ ABAC سے پہلے کیا آیا اور ہر نسل کیوں کم ہوئی۔

صوابدیدی اور لازمی رسائی کنٹرول

ابتدائی رسائی کنٹرول ماڈل 1960 اور 1970 کی دہائیوں میں محکمہ دفاع کی ایپلی کیشنز میں سامنے آئے۔ NIST خصوصی اشاعت 800-162 کے مطابق، صوابدیدی رسائی کنٹرول (DAC) اور لازمی رسائی کنٹرول (MAC) موجود ہیں۔

DAC میں، وسائل کا مالک اس بات کا تعین کرتا ہے کہ اس وسائل تک کون رسائی حاصل کر سکتا ہے۔ تصور کریں کہ کون آپ کے کمپیوٹر پر فائلوں کو پڑھ سکتا ہے یا اس میں ترمیم کرسکتا ہے۔ MAC میں، رسائی کا انتظام ایک مرکزی اتھارٹی لیبلز جیسے کہ "خفیہ” یا "ٹاپ سیکریٹ” کے ذریعے کرتی ہے۔ نظام ان لیبلز کو نافذ کرتا ہے، انفرادی مالکان پر نہیں۔

دونوں نے اپنے اصل مقصد کے لیے کام کیا، لیکن جدید نیٹ ورک سسٹمز کی پیچیدگی کے لیے پیمانہ نہیں بنایا۔

شناخت پر مبنی رسائی کنٹرول اور رسائی کنٹرول فہرستیں۔

جیسے جیسے نیٹ ورک بڑھتے ہیں، شناخت پر مبنی رسائی کنٹرول (IBAC) عام ہو جاتا ہے۔ سب سے زیادہ مانوس نفاذ ایک رسائی کنٹرول لسٹ (ACL) ہے، جو کسی وسائل سے وابستہ صارفین یا گروپس کی فہرست ہے جو یہ بتاتا ہے کہ ہر صارف کیا کرسکتا ہے۔

ACLs سادہ اور شفاف ہیں، لیکن یہ نظام کے بڑھنے کے ساتھ ساتھ انتظامی بوجھ پیدا کرتے ہیں۔ تمام نئے صارفین کو تمام متعلقہ فہرستوں میں شامل کیا جانا چاہیے۔ کسی بھی اجازت کی تبدیلی کا مطلب ہے کہ متعدد وسائل میں فہرست تلاش کرنا۔ اور جب کوئی آپ کی تنظیم چھوڑتا ہے، تو آپ کو انہیں ہر جگہ تلاش کرکے ان سے چھٹکارا حاصل کرنا ہوگا۔

ایسا کرنے میں مسلسل ناکامی صارفین کو وہ مراعات جمع کرنے کا سبب بنتی ہے جو انہیں اب نہیں ہونے چاہئیں۔

کردار پر مبنی رسائی کنٹرول

رول پر مبنی رسائی کنٹرول (RBAC) ایک اہم پیشرفت رہی ہے۔ RBAC صارفین کو براہ راست اجازت تفویض کرنے کے بجائے کرداروں کو اجازت دیتا ہے۔ اس کے بعد صارف کو ایک کردار تفویض کیا جاتا ہے۔ ہسپتالوں میں، کرداروں میں شامل ہو سکتے ہیں: nurse، doctor، adminاور billing_staffہر ایک کے پاس مختلف اجازتیں ہیں۔

یہ انتظام کو بہت آسان بنا دیتا ہے۔ نئے ملازمین کو شامل کرنے کا مطلب ہے انہیں مناسب کردار تفویض کرنا۔ ملازم کو ہٹانے کا مطلب کردار کو ختم کرنا ہے۔ نرسیں جو کچھ کر سکتی ہیں اسے تبدیل کرنے کا مطلب ہے نرس کے کردار کو ایک بار اپ ڈیٹ کرنا۔

RBAC کو وسیع پیمانے پر اپنایا گیا ہے اور یہ بہت سی ایپلی کیشنز کے لیے ایک اچھا انتخاب ہے۔ تاہم، ساختی کمزوریاں ہیں. جیسا کہ آپ کی اجازت کے تقاضے زیادہ دانے دار ہوتے جاتے ہیں، آپ کو مزید مخصوص کردار بنانے کی ضرورت ہوگی۔ وہ نرسیں جو صرف اپنے فرش پر مریضوں کو دیکھ سکتی ہیں، صرف اپنی شفٹ کے دوران، یا صرف مخصوص قسم کے ریکارڈز کے لیے بہت مخصوص کرداروں، یا کرداروں کے امتزاج کی ضرورت ہوتی ہے، جو پیچیدہ طریقوں سے تعامل کرتے ہیں۔

اس پھیلاؤ کو ‘کردار دھماکہ’ کہا جاتا ہے۔ کردار اس وقت تک بڑھتے ہیں جب تک کہ RBAC کا انتظام کرنا اتنا ہی مشکل نہ ہو جتنا انفرادی اجازتوں کو بدلنا ہے۔

انتساب پر مبنی رسائی کنٹرول

ABAC کرداروں کے دھماکے کے ردعمل کے طور پر ابھرا۔ مقررہ اجازتوں کو پابند کرنے والے کردار تفویض کرنے کے بجائے، ABAC رسائی کی ہر درخواست کے وقت صارفین، وسائل اور سیاق و سباق کی اصل خصوصیات کا جائزہ لیتا ہے۔

نرسوں کو مریضوں کے ریکارڈ تک رسائی کی وجہ یہ نہیں ہے کہ ان کے پاس مریض کے ریکارڈ موجود ہیں۔ nurse تاہم، چونکہ پوزیشن "نرس” ہے، مریض تفویض کردہ منزل پر ہے، موجودہ شفٹ جاری ہے، اور ریکارڈ کی قسم دیکھ بھال کے دائرہ کار میں ہے۔ اس حقیقت کو تبدیل کرنے سے اس کے مطابق رسائی کا فیصلہ بدل جائے گا۔

جیسا کہ NIST SP 800-162 کے ذریعہ بیان کیا گیا ہے، ABAC یہ ہے:

"ایک رسائی کنٹرول کا طریقہ جس میں موضوع کی تفویض کردہ خصوصیات، آبجیکٹ کی تفویض کردہ خصوصیات، ماحولیاتی حالات، اور ان خصوصیات اور شرائط کی بنیاد پر پالیسیوں کے ایک مخصوص سیٹ کی بنیاد پر کسی چیز پر آپریشن کرنے کی درخواست کو منظور یا مسترد کیا جاتا ہے۔”

وصف پر مبنی رسائی کنٹرول کیا ہے؟

ABAC ایک منطقی رسائی کنٹرول ماڈل ہے جہاں رسائی کے تمام فیصلے کسی وصف کی موجودہ قدر کے خلاف قواعد کے سیٹ کا جائزہ لے کر کیے جاتے ہیں۔ رول اسائنمنٹس میں کوئی پری کمپیوٹ شدہ یا کیش شدہ اندراجات نہیں ہیں۔ جب بھی صارف کچھ کرنے کی کوشش کرتا ہے، نظام پوچھتا ہے: اس صارف، اس وسائل اور اس لمحے کے بارے میں جو کچھ ہم جانتے ہیں، کیا اس کی اجازت ہونی چاہیے؟

یہ ABAC کو بہت درست اور متحرک بناتا ہے۔ اجازتیں وقت کے ساتھ جمع نہیں ہوتی ہیں۔ جب کسی کا کردار تبدیل ہوتا ہے تو اسے دستی طور پر منظم کرنے کی ضرورت نہیں ہے۔ سسٹم ہر بار پراپرٹی کی موجودہ حالت کا جائزہ لیتا ہے۔

اس ماڈل کو NIST کی ABAC گائیڈ میں باضابطہ طور پر بیان کیا گیا ہے کہ یہ دونوں صوابدیدی اور لازمی رسائی کنٹرول تصورات پر لاگو ہوتا ہے، جو اسے ان ماڈلز سے زیادہ اظہار خیال کرتا ہے جو یا تو تنہا حمایت کرتے ہیں۔

Axiomatics جیسی کمپنیاں، بڑی سرکاری ایجنسیاں، اور بڑی کارپوریشنز جو بین تنظیمی ڈیٹا شیئرنگ کا انتظام کرتی ہیں، سبھی ABAC کو پیچیدہ ماحول میں حفاظتی پالیسیوں کی پیمائش کرنے کی صلاحیت کے لیے استعمال کرتی ہیں۔

ABAC کے چار بلڈنگ بلاکس

کوئی بھی ABAC نظام چار قسم کی معلومات پر مشتمل ہوتا ہے: اسے واضح طور پر سمجھنا یہ سمجھنے کی کلید ہے کہ ABAC کیسے کام کرتا ہے۔

1. موضوع کی خصوصیات

موضوع ہے جو بھی یا جو بھی رسائی کی درخواست کر رہا ہے۔ یہ عام طور پر ایک صارف ہوتا ہے، لیکن یہ ایک سروس، ایپلیکیشن، یا خودکار نظام بھی ہو سکتا ہے، جسے NIST ایک غیر شخصی ہستی (NPE) کہتے ہیں۔

موضوع کا وصف بیان کرتا ہے کہ موضوع کون ہے۔

user.jobTitle         = "Nurse Practitioner"
user.department       = "Cardiology"
user.clearanceLevel   = "Confidential"
user.employmentStatus = "Active"
user.location         = "Floor 3"
user.shiftActive      = true

یہ خصوصیات عام طور پر آپ کے شناخت فراہم کنندہ، HR سسٹم، یا صارف کی ڈائرکٹری سے آتی ہیں۔ یہ صارف کے بارے میں حقائق ہیں جنہیں پالیسیوں میں استعمال کیا جا سکتا ہے۔

2. آبجیکٹ کی خصوصیات (وسائل کی خصوصیات)

ایک شے ہر وہ چیز ہوتی ہے جس تک کوئی موضوع رسائی حاصل کرنے کی کوشش کر رہا ہو۔ یہ ایک فائل، ڈیٹا بیس ریکارڈ، API اینڈ پوائنٹ، سروس، یا دیگر محفوظ وسائل ہو سکتا ہے۔

آبجیکٹ کی خصوصیات بیان کرتی ہیں کہ وسیلہ کیا ہے۔

record.type           = "PatientMedical"
record.floor          = "Floor 3"
record.sensitivity    = "High"
record.owner          = "Dr. Williams"
record.department     = "Cardiology"

آبجیکٹ کی خصوصیات کو عام طور پر تفویض کیا جاتا ہے کیونکہ وسائل ان کی زندگی کے دوران تخلیق اور اپ ڈیٹ ہوتے ہیں۔ یہ وسائل کے بارے میں حقائق ہیں جو طے کرتے ہیں کہ اس تک کس کی رسائی ہے۔

3. ایکشن کی خصوصیات

ایک عمل وہ ہے جو ایک مضمون کسی چیز کے ساتھ کرنے کی کوشش کرتا ہے۔ عام کارروائیوں میں پڑھنا، لکھنا، ترمیم کرنا، حذف کرنا، کاپی کرنا، عمل کرنا اور اشتراک کرنا شامل ہیں۔

بہت سے ABAC کے نفاذ میں، خود آپریشن میں درج ذیل خصوصیات ہیں:

action.type           = "read"
action.bulk           = false

پالیسیاں اس بات کو محدود کر سکتی ہیں کہ دیگر خصوصیات سے قطع نظر کن کارروائیوں کی اجازت ہے۔ صارف دستاویز کو پڑھ سکتے ہیں لیکن اسے حذف نہیں کر سکتے، چاہے دیگر تمام خصوصیات مماثل ہوں۔

4. ماحولیاتی حالات

ماحولیاتی حالات حالات کے عوامل ہیں جن کا تعلق مضامین یا اشیاء سے نہیں ہے، لیکن یہ رسائی کے فیصلوں پر اثر انداز ہوتے ہیں۔ NIST اسے "ایک متحرک عنصر کے طور پر بیان کرتا ہے جسے فیصلہ کے وقت ایک خصوصیت کے طور پر استعمال کیا جا سکتا ہے تاکہ موضوع یا اعتراض سے قطع نظر رسائی کے فیصلوں کو متاثر کیا جا سکے۔”

مثالوں میں شامل ہیں:

environment.time           = "14:30"
environment.dayOfWeek      = "Wednesday"
environment.userLocation   = "Corporate Office"
environment.ipAddress      = "192.168.1.10"
environment.deviceStatus   = "compliant"
environment.threatLevel    = "low"

ماحولیاتی حالات ہی ABAC کو حقیقی معنوں میں متحرک بناتے ہیں۔ وہی صارفین، وہی وسائل، اور ایک جیسے اعمال کی اجازت کاروباری اوقات کے دوران قابل اعتماد آلات سے دی جا سکتی ہے، لیکن نامعلوم IP پتوں سے آدھی رات کو انکار کر دیا جاتا ہے۔

ABAC کے فیصلے کیسے کیے جاتے ہیں۔

جب کوئی مضمون کسی چیز پر آپریشن کرنے کی کوشش کرتا ہے، تو ABAC نظام مخصوص عمل سے گزرتا ہے۔

مرحلہ 1: پراپرٹیز جمع کریں۔

نظام مضامین، اشیاء، اعمال، اور ماحول کے بارے میں موجودہ خصوصیات کو جمع کرتا ہے. اس میں صارف کی ڈائریکٹریوں سے استفسار کرنا، وسائل کا میٹا ڈیٹا پڑھنا، اور موجودہ وقت اور مقام کا تعین کرنا شامل ہو سکتا ہے۔

مرحلہ 2: قابل اطلاق پالیسیاں تلاش کریں۔

سسٹم اس بات کی نشاندہی کرتا ہے کہ اس مخصوص درخواست پر کون سی پالیسی لاگو ہوتی ہے۔ مریضوں کے ریکارڈ کو پڑھنے کی درخواستیں کئی پالیسیوں سے مشروط ہو سکتی ہیں، جن میں طبی عملے تک رسائی کی پالیسیاں، گھنٹوں سے باہر رسائی کے لیے پالیسیاں، اور ریکارڈ کی حساسیت کی سطح کے لیے پالیسیاں شامل ہیں۔

مرحلہ 3: ہر پالیسی کا جائزہ لیں۔

ہر قابل اطلاق پالیسی جمع شدہ جائیدادوں کا جائزہ لیتی ہے اور واپسی یا تو اجازت دیتی ہے یا انکار کرتی ہے۔

مرحلہ 4: تنازعات کی ثالثی۔

اگر متعدد پالیسیاں لاگو ہوتی ہیں اور متصادم ہوتی ہیں، تو نظام پہلے سے طے شدہ امتزاج کے اصول استعمال کرتا ہے۔ عام نقطہ نظر "اوور رائڈ انکار” ہیں (اگر پالیسی کہتی ہے انکار، درخواست کو مسترد کر دیا گیا ہے) یا "اوور رائڈ اجازت” (اگر پالیسی کہتی ہے کہ اجازت ہے، درخواست کی اجازت ہے)۔

مرحلہ 5: فیصلے پر عمل کریں۔

سسٹم اپنے حتمی فیصلے کی بنیاد پر رسائی دے گا یا انکار کرے گا۔

یہ عمل ہر بار اس وقت ہوتا ہے جب رسائی کی درخواست کی جاتی ہے۔ رول اسائنمنٹس یا پہلے سے کمپیوٹیڈ پرمیشن ٹیبلز کو کیش نہیں کیا جاتا ہے۔ فیصلہ درخواست کے وقت تمام جائیدادوں کی موجودہ حالت کی عکاسی کرتا ہے۔

ABAC پالیسی کیسے لکھیں۔

پالیسی ABAC کی بنیادی منطق ہے۔ یہ ایک مشروط اصول کے طور پر لکھا گیا ہے جو پراپرٹی کا حوالہ دیتا ہے۔ اچھی طرح سے لکھی گئی پالیسیاں کاروباری قواعد کی طرح پڑھی جاتی ہیں۔ کیونکہ یہ کاروباری اصول ہیں۔

سادہ بولین پالیسی

سب سے بنیادی شکل اس بات کا اندازہ کرتی ہے کہ آیا کچھ خاصیتیں ملتی ہیں۔

// Policy: Only active employees can access internal resources
function canAccessInternalResource(user) {
  return user.employmentStatus === "Active";
}

یہ کیا کرتا ہے: ایک خصوصیت کی تصدیق کرتا ہے: رسائی دینے سے پہلے ملازمت کی حیثیت۔ غیر فعال، معطل یا ختم شدہ صارفین کو ان کے کردار یا ماضی کی رسائی کی تاریخ سے قطع نظر مسترد کر دیا جاتا ہے۔

کثیر وصف کی پالیسی

حقیقی دنیا کی پالیسیاں عام طور پر متعدد خصوصیات کو یکجا کرتی ہیں۔

// Policy: A nurse can read a patient record
// if the patient is on their assigned floor
// and during their active shift

function canReadPatientRecord(user, record, environment) {
  const isNurse = user.jobTitle === "Nurse Practitioner";
  const isAssignedFloor = user.assignedFloor === record.floor;
  const isActiveDuty = user.shiftActive === true;

  return isNurse && isAssignedFloor && isActiveDuty;
}

یہ کیا کرتا ہے: اور منطق کا استعمال کرتے ہوئے تین شرائط کو یکجا کریں۔ رسائی دینے کے لیے تینوں کا درست ہونا ضروری ہے۔ اگر آپ نرس کے فلور اسائنمنٹ کو تبدیل کرتے ہیں، تو آپ بغیر کسی دستی مداخلت کے پچھلی منزل کے ریکارڈ تک فوری رسائی سے محروم ہو جاتے ہیں۔

ماحولیاتی آگاہی کی پالیسی

ماحولیاتی حالات کو شامل کرنا پالیسی کو زیادہ حساس بناتا ہے۔

// Policy: Users can only access sensitive financial records
// during business hours from the corporate network

function canAccessSensitiveFinancialRecord(user, record, environment) {
  const isFinanceStaff = user.department === "Finance";
  const isHighSensitivity = record.sensitivity === "High";
  
  // If this is a high-sensitivity record, apply time and location controls
  if (isHighSensitivity) {
    const currentHour = new Date(environment.timestamp).getHours();
    const isBusinessHours = currentHour >= 9 && currentHour < 17;
    const isCorporateNetwork = environment.ipRange === "corporate";

    return isFinanceStaff && isBusinessHours && isCorporateNetwork;
  }

  // Lower sensitivity records only require finance department membership
  return isFinanceStaff;
}

یہ کیا کرتا ہے: انتہائی حساس وسائل پر سخت کنٹرول کا اطلاق کریں۔ ایک ہی صارف کسی بھی وقت کم حساسیت کے ریکارڈ تک رسائی حاصل کر سکتا ہے، لیکن زیادہ حساسیت کے ریکارڈ کے لیے ضروری ہے کہ وہ کاروباری اوقات کے دوران کارپوریٹ نیٹ ورک پر ہوں۔ پالیسی منطق حقیقی کاروباری قواعد کی عکاسی کرتی ہے۔ حساس ڈیٹا کو مزید تحفظ کی ضرورت ہے۔

ملکیت پر مبنی پالیسی

ABAC صوابدیدی ملکیت کے قوانین کو بھی نافذ کر سکتا ہے۔

// Policy: A user can edit a document
// if they own it, or if they have editor permissions
// and the document isn't locked

function canEditDocument(user, document, action) {
  const isOwner = document.ownerId === user.id;
  const hasEditorPermission = user.permissions.includes("document.edit");
  const isUnlocked = document.status !== "locked";

  return (isOwner || hasEditorPermission) && isUnlocked;
}

یہ کیا کرتا ہے: یہ ملکیت (صارف اور دستاویز کے درمیان تعلق کی خاصیت) کو واضح اجازتوں اور وسائل کی حالت کے ساتھ جوڑتا ہے۔ ایڈیٹرز مقفل دستاویزات میں ترمیم نہیں کر سکتے چاہے ان کے پاس ترمیم کی اجازت ہو۔ مالکان اپنے دستاویزات میں ترمیم کر سکتے ہیں، لیکن مقفل دستاویزات میں نہیں۔

کوڈ میں ABAC کو کیسے نافذ کیا جائے۔

آئیے ایک سادہ ABAC تشخیصی انجن بنائیں جو ان ٹکڑوں کو آپس میں جوڑ دے۔

مرحلہ 1: وصف کی ساخت کی وضاحت کریں۔

سب سے پہلے، اپنی خصوصیات کے لیے ڈیٹا کی واضح ساخت کی وضاحت کریں۔

// A user (subject) requesting access
const user = {
  id: "user-123",
  name: "Sarah Chen",
  department: "Cardiology",
  jobTitle: "Nurse Practitioner",
  clearanceLevel: 2,
  assignedFloor: "Floor 3",
  shiftActive: true,
  employmentStatus: "Active"
};

// A resource (object) being accessed
const patientRecord = {
  id: "record-456",
  type: "PatientMedical",
  floor: "Floor 3",
  sensitivity: 2,
  ownerId: "doctor-789",
  department: "Cardiology"
};

// Environment conditions
const environment = {
  timestamp: new Date().toISOString(),
  ipAddress: "10.0.1.25",
  ipRange: "corporate",
  deviceCompliant: true
};

مرحلہ 2: ایک پالیسی فنکشن لکھیں۔

آپ انفرادی پالیسیوں کو خالص فنکشن کے طور پر لکھتے ہیں جو پراپرٹیز لیتے ہیں اور بولین ویلیوز واپس کرتے ہیں۔

// policies/patientRecord.js

// Policy 1: User must be active and clinical staff
function isClinicalStaff(user) {
  const clinicalTitles = [
    "Nurse Practitioner",
    "Physician",
    "Resident",
    "Medical Assistant"
  ];
  return (
    user.employmentStatus === "Active" &&
    clinicalTitles.includes(user.jobTitle)
  );
}

// Policy 2: Record must be within the user's assigned area
function isAssignedToRecord(user, record) {
  return (
    user.department === record.department &&
    user.assignedFloor === record.floor
  );
}

// Policy 3: User must be on active shift
function isOnActiveShift(user) {
  return user.shiftActive === true;
}

// Policy 4: High-sensitivity records require compliant devices
function meetsDeviceRequirements(record, environment) {
  if (record.sensitivity >= 3) {
    return environment.deviceCompliant === true;
  }
  return true; // No device requirement for lower sensitivity
}

یہ کیا کرتا ہے: ہر پالیسی ایک چھوٹا، فوکسڈ فنکشن ہے۔ یہ پالیسیوں کو آسانی سے انفرادی طور پر جانچنے، آسانی سے پڑھنے کے قابل، اور رسائی کے مختلف فیصلوں میں آسانی سے دوبارہ استعمال کرنے کی اجازت دیتا ہے۔ پالیسی برائے "کیا یہ صارف ایک طبی ملازم ہے؟" وسائل کی مختلف اقسام پر لاگو ہو سکتے ہیں۔

مرحلہ 3: تشخیصی انجن کی تعمیر

پالیسیوں کو فیصلہ کن انجنوں میں یکجا کریں۔

// abac/engine.js

function evaluateAccess(user, resource, action, environment, policies) {
  // Collect all policy results
  const results = policies.map(policy => {
    try {
      return policy(user, resource, action, environment);
    } catch (error) {
      console.error(`Policy evaluation error: ${error.message}`);
      return false; // Fail closed: deny on error
    }
  });

  // Deny-overrides: if any policy denies, access is denied
  return results.every(result => result === true);
}

// Assemble policies for reading patient records
const readPatientRecordPolicies = [
  (user) => isClinicalStaff(user),
  (user, record) => isAssignedToRecord(user, record),
  (user) => isOnActiveShift(user),
  (user, record, action, environment) => meetsDeviceRequirements(record, environment)
];

// Make an access decision
const canRead = evaluateAccess(
  user,
  patientRecord,
  "read",
  environment,
  readPatientRecordPolicies
);

console.log(`Access ${canRead ? "granted" : "denied"}`);
// → Access granted (all conditions met)

یہ کیا کرتا ہے: انجن متعلقہ خصوصیات کو پاس کرتے ہوئے ہر پالیسی فنکشن پر اعادہ کرتا ہے۔ اگر تمام پالیسیاں درست ہوجاتی ہیں تو رسائی دی جاتی ہے۔ اگر یہ غلط لوٹتا ہے تو رسائی سے انکار کر دیا جاتا ہے۔ اسے "جوائننگ ڈینیئل اوور رائیڈز" کہا جاتا ہے۔ کہ try-catch اگر پالیسی کی خرابی واقع ہوتی ہے تو، فیل کلوز سیکیورٹی اصول کے مطابق اجازت دینے کے بجائے رسائی سے انکار کر دیا جاتا ہے۔

مرحلہ 4: پراپرٹی کا مجموعہ شامل کریں۔

حقیقی ایپلی کیشنز میں، خصوصیات متعدد ذرائع سے آتی ہیں۔

// attributes/collector.js

async function collectAttributes(userId, resourceId) {
  // Collect in parallel for performance
  const [user, resource, environment] = await Promise.all([
    fetchUserAttributes(userId),      // From identity provider or HR system
    fetchResourceAttributes(resourceId), // From resource metadata store
    collectEnvironmentConditions()    // Time, IP, device status
  ]);

  return { user, resource, environment };
}

async function fetchUserAttributes(userId) {
  // This would query your user directory, LDAP, or identity provider
  const user = await userDirectory.findById(userId);
  const shift = await shiftService.getActiveShift(userId);
  
  return {
    ...user,
    shiftActive: shift !== null,
    assignedFloor: shift?.floor || null
  };
}

async function collectEnvironmentConditions() {
  return {
    timestamp: new Date().toISOString(),
    ipAddress: request.ip,
    ipRange: await networkService.classifyIP(request.ip),
    deviceCompliant: await deviceService.checkCompliance(request.deviceId)
  };
}

یہ کیا کرتا ہے: انتساب جمع کرنا پالیسی کی تشخیص سے الگ ہے۔ یہ ایک اہم ڈیزائن کا فیصلہ ہے۔ اس کا مطلب ہے کہ آپ اصل صارفین یا وسائل کی ضرورت کے بغیر کسی بھی پراپرٹی ویلیو کا استعمال کرتے ہوئے اپنی پالیسی کی جانچ کر سکتے ہیں۔ اس کا مطلب یہ بھی ہے کہ آپ پالیسی کو تبدیل کیے بغیر پراپرٹی کے ذرائع کو تبدیل کر سکتے ہیں (مثال کے طور پر، آن پریمیسس ڈائرکٹری سے کلاؤڈ شناخت فراہم کرنے والے کی طرف جانا)۔

مرحلہ 5: API کے ساتھ ضم کریں۔

اپنے API ہینڈلر میں تشخیصی انجن کا استعمال کریں۔

// middleware/abac.js

function requireAccess(action, resourceType) {
  return async (req, res, next) => {
    try {
      const { user, resource, environment } = await collectAttributes(
        req.user.id,
        req.params.id
      );

      const policies = getPoliciesFor(resourceType, action);
      const allowed = evaluateAccess(user, resource, action, environment, policies);

      if (!allowed) {
        // Log the denial for audit purposes
        auditLog.record({
          userId: req.user.id,
          resourceId: req.params.id,
          action,
          decision: "denied",
          timestamp: new Date()
        });

        return res.status(403).json({ error: "Access denied" });
      }

      next();
    } catch (error) {
      // Fail closed: deny access on unexpected errors
      return res.status(403).json({ error: "Access denied" });
    }
  };
}

// Use in route definitions
app.get(
  "/patient-records/:id",
  authenticate(),                               // First verify identity
  requireAccess("read", "patientRecord"),       // Then evaluate ABAC
  patientRecordController.getById               // Then handle the request
);

یہ کیا کرتا ہے: ABAC چیکنگ مڈل ویئر میں رہتی ہے جو تصدیق اور روٹ ہینڈلرز کے درمیان چلتی ہے۔ توثیق اس بات کی تصدیق کرتی ہے کہ آپ کون ہیں۔ ABAC اس بات کا تعین کرتا ہے کہ آیا صارف وہ کر سکتا ہے جو وہ کرنے کی کوشش کر رہا ہے۔ یہ علیحدگی توثیق کی منطق کو کاروباری منطق سے دور رکھتی ہے۔

ABAC بمقابلہ RBAC: کون سا کب استعمال کریں؟

RBAC فرسودہ ہے۔ یہ دراصل بہت سی ایپلی کیشنز کے لیے ایک اچھا انتخاب ہے۔ سوال یہ ہے کہ کون سا ماڈل آپ کی مخصوص رسائی کی ضروریات کو پورا کرتا ہے۔

RBAC کی طاقتیں۔

RBAC سمجھنے میں آسان، لاگو کرنے میں آسان، اور آڈٹ کرنے میں آسان ہے۔ RBAC اچھی طرح کام کرتا ہے اگر رسائی کی ضروریات کو مقررہ اجازتوں کے ساتھ کرداروں کی فہرست کے طور پر بیان کیا جا سکتا ہے۔ زیادہ تر SaaS ایپلیکیشنز RBAC سے شروع ہوتی ہیں اور کئی سالوں تک اچھی طرح کام کرتی ہیں۔

عام RBAC چیک میں شامل ہیں:

// Simple RBAC: does the user have the required role?
function canAccess(user, requiredRole) {
  return user.roles.includes(requiredRole);
}

یہ تیز، واضح اور ڈیبگ کرنے میں آسان ہے۔ اگر کوئی مسئلہ پیش آتا ہے تو چیک کریں کہ صارف کے کیا کردار ہیں اور وسائل کو کن کرداروں کی ضرورت ہے۔

جہاں RBAC ٹوٹ جاتا ہے۔

RBAC کا سامنا کرنا پڑتا ہے جب اجازتوں کا انحصار ان عناصر پر ہونا چاہیے جو کرداروں کے ذریعے حاصل نہیں کیے گئے ہیں۔ اگر آپ کو یہ کہنا ہے کہ، "مالیاتی مینیجرز مالی ریکارڈ دیکھ سکتے ہیں، لیکن صرف اپنے علاقے کے لیے اور کاروباری اوقات کے دوران،" یہ اس سے باہر ہے جو اکیلے کردار بیان کر سکتے ہیں۔

ایک بہت ہی مخصوص کردار (finance_manager_us_east_business_hours) اپنے ایپلیکیشن کوڈ میں مشروط منطق شامل کریں جو کردار کے دھماکے کے مسائل کا سبب بنتی ہے یا ABAC کو مؤثر طریقے سے کم منظم طریقے سے دوبارہ تخلیق کرتی ہے۔

RBAC اور ABAC کا موازنہ

بنیادی عنصر	آر بی اے سی	اے بی اے سی
منطق	کرداروں کو تفویض کردہ اجازتیں، صارفین کو تفویض کردہ کردار	پالیسیاں فیصلے کرتے وقت اوصاف کا جائزہ لیتی ہیں۔
دانے دار	موٹے اناج	دانے دار حالات سے متعلق آگاہی
لچکدار	کم اور دیکھو، نئے قوانین کو نئے کردار کی ضرورت ہوتی ہے۔	اعلی، کردار تبدیل کیے بغیر پالیسی کو اپ ڈیٹ کریں۔
توسیع پذیری	پیچیدگی کی وجہ سے کردار کا دھماکہ	کرداروں کی تعداد کے بجائے پالیسی کی پیچیدگی پر مبنی پیمانہ
آڈٹ ایبلٹی	یہ آسان ہے، اپنے رول اسائنمنٹس کو چیک کریں۔	فیصلہ سازی کے لیے لاگنگ کی خصوصیات درکار ہیں۔
پیچیدگی	کم	اعلی اور زیادہ حرکت پذیر حصے
کے لیے بہترین موزوں ہے۔	سادہ اور مستحکم اجازت کا ڈھانچہ	پیچیدہ، متحرک یا سیاق و سباق پر منحصر اجازتیں۔

دو ماڈل کا امتزاج

RBAC اور ABAC مل کر اچھی طرح کام کرتے ہیں۔ ایک عام نمونہ یہ ہے کہ موٹے دانے والے رسائی کنٹرول کے لیے RBAC کا استعمال کیا جائے (یہ صارف ایپلیکیشن کے کون سے حصے دیکھ سکتا ہے) اور ABAC کو ان حصوں کے اندر عمدہ کنٹرول کے لیے استعمال کرنا ہے (وہ کن مخصوص ریکارڈ تک رسائی حاصل کر سکتے ہیں؟)۔

مثال کے طور پر، ایک کردار ہسپتال کے نظام میں مریض کے ریکارڈ کے ایک حصے تک رسائی فراہم کر سکتا ہے۔ اس سیکشن کے اندر، ABAC پالیسیاں اس بات کا تعین کرتی ہیں کہ صارف محکمہ، تفویض شدہ منزل، اور فعال شفٹ کی بنیاد پر کون سے مخصوص ریکارڈز کو دیکھ یا ترمیم کر سکتا ہے۔

حقیقی استعمال کے معاملات

میڈیکل ریکارڈ مینجمنٹ

صحت کی دیکھ بھال اس بات کی واضح مثالوں میں سے ایک ہے کہ ABAC کیوں اہم ہے۔ مریض کی رازداری کے ضوابط درست رسائی کے کنٹرول کی ضرورت ہوتی ہے، اور مریض کی دیکھ بھال کو اس بات کو یقینی بنانے کی ضرورت ہوتی ہے کہ مناسب عملہ ضرورت پڑنے پر تیزی سے ریکارڈ تک رسائی حاصل کر سکے۔

ہسپتال کی ABAC پالیسی کے مطابق، نرسیں صرف مریض کا ریکارڈ دیکھ سکتی ہیں اگر:

1. مریض اس وقت نرس کی طرف سے تفویض کردہ فرش پر ہسپتال میں داخل ہے۔

2. نرسیں شفٹوں میں کام کر رہی ہیں،

3. رسائی ہسپتال کے نیٹ ورک کے اندر ہوتی ہے۔

4. اس قسم کا ریکارڈ نرس کی مشق کے دائرہ کار میں ہے۔

WorkOS میں ABAC تجزیہ ظاہر کرتا ہے کہ ہنگامی حالات میں، ABAC سسٹم خود بخود رسائی کے مراعات کو بڑھا سکتے ہیں۔ مثال کے طور پر، ایمرجنسی روم کے ڈاکٹر فوری دیکھ بھال فراہم کرنے کے لیے خود بخود مریضوں کے ریکارڈ تک وسیع تر رسائی حاصل کر لیتے ہیں۔ یہ رسائی وقت کے لیے محدود اور قریب سے مانیٹر کی گئی ہے۔

ان تمام اصولوں کے لیے RBAC سسٹم میں درجنوں کرداروں کی ضرورت ہوتی ہے، اور یہ کردار اب بھی متحرک طور پر ہنگامی رسائی کے منظرناموں کو سنبھالنے کے لیے جدوجہد کرتے ہیں۔

کارپوریٹ ڈیٹا تک رسائی

بڑی کارپوریشنوں میں عام طور پر محکموں، کرداروں، مقامات اور تنظیمی سطحوں پر ملازمین ہوتے ہیں جنہیں ایک ہی بنیادی ڈیٹا پر مختلف نقطہ نظر کی ضرورت ہوتی ہے۔ امریکی خطے میں مالیاتی مینیجرز کاروباری اوقات کے دوران دستاویزات تک رسائی حاصل کر سکتے ہیں، عالمی ایگزیکٹو کسی بھی وقت ان تک رسائی حاصل کر سکتے ہیں، لیکن مجموعی طور پر ٹھیکیدار ایسا نہیں کر سکتے۔

ABAC ان تمام اصولوں کو پالیسیوں کے طور پر ظاہر کرتا ہے۔ جب کوئی ملازم محکموں کو تبدیل کرتا ہے، چھٹی پر جاتا ہے، یا کردار تبدیل کرتا ہے، تو شناختی نظام میں ان کی صفات کو اپ ڈیٹ کیا جاتا ہے اور دستی ACL اپ ڈیٹس کی ضرورت کو ختم کرتے ہوئے، رسائی خود بخود تبدیل ہو جاتی ہے۔

حکومت اور خفیہ معلومات

امریکی وفاقی حکومت کی جانب سے ABAC کو اپنانے کی وضاحت NIST SP 800-162 میں کی گئی ہے، جسے وفاقی شناخت، اسناد، اور رسائی کے انتظام (FICAM) کی ضروریات کو پورا کرنے کے لیے تیار کیا گیا ہے۔ وفاقی ایجنسیاں مختلف سطحوں کی درجہ بندی اور جاننے کی ضرورت کی بنیاد پر تنظیمی حدود میں اشتراک کردہ معلومات کو سنبھالتی ہیں۔

ABAC ایک ادارے کے تجزیہ کاروں کو اجازت دیتا ہے کہ وہ دوسرے ادارے کی معلومات تک رسائی حاصل کر سکے بغیر دوسرے ادارے کو اکاؤنٹس کی پیشگی فراہمی کی ضرورت ہو۔ تجزیہ کار کی تنظیمی صفات، تنظیمی وابستگی، اور پراجیکٹ اسائنمنٹس کا جائزہ درخواست کے وقت وسائل کی درجہ بندی اور رسائی کے قواعد کے خلاف کیا جاتا ہے۔

کثیر کرایہ دار SaaS درخواست

SaaS ایپلیکیشنز جو متعدد تنظیموں کی خدمت کرتی ہیں، انہیں ہر کرایہ دار کے اندر پیچیدہ اجازت کے ڈھانچے کو سپورٹ کرنا چاہیے جبکہ کرایہ داروں کے درمیان سخت ڈیٹا آئسولیشن کو یقینی بنایا جائے۔

ABAC اسے قدرتی طور پر ہینڈل کرتا ہے۔ وسائل کی خصوصیات جیسے: record.tenantId صارف کی خصوصیات کے خلاف جائزہ لیا گیا۔ user.tenantIdپالیسی کے ذریعے کرایہ دار تک رسائی ممکن نہیں ہے۔ کرایہ دار کے اندر، ABAC اتنی ہی پیچیدگی کی حمایت کرتا ہے جتنی آپ کی کرایہ دار کی پالیسی کی ضرورت ہوتی ہے۔

انٹرپرائز ABAC تحفظات

انٹرپرائز پیمانے پر ABAC کی تعیناتی کئی چیلنجوں کو متعارف کراتی ہے جو چھوٹے پیمانے کے نفاذ میں موجود نہیں ہیں۔

پالیسی انتظامیہ

پالیسیاں لکھی جائیں، ان پر نظرثانی کی جائیں، جانچ کی جائیں، اور تعینات کی جائیں۔ NIST SP 800-162 کے مطابق، اس کے لیے پالیسی مینجمنٹ پوائنٹ (PAP) کی ضرورت ہوتی ہے، جو پالیسیاں بنانے اور ان کے انتظام کے لیے ایک انٹرفیس ہے۔ صحیح ٹولز کے بغیر، پالیسیوں کا آڈٹ اور برقرار رکھنا مشکل ہو جاتا ہے۔

عملی طور پر، اس کا مطلب پالیسیوں کو سنبھالنا ہے جیسے کوڈ: ورژن کنٹرول، کوڈ کا جائزہ، خودکار جانچ وغیرہ۔

وصف معیار اور تازگی

ABAC صرف اتنا ہی اچھا ہے جتنا کہ یہ ان خصوصیات کا جائزہ لیتا ہے۔ مثال کے طور پر، ان صارفین کے لیے جنہوں نے محکمے تبدیل کیے ہیں لیکن جن کی ڈائرکٹری کے اندراجات کو اپ ڈیٹ نہیں کیا گیا ہے، اگر صارف کے اوصاف پرانے ہیں تو رسائی کے فیصلے غلط ہوں گے۔

NIST انتباہ کرتا ہے کہ "وہ صفات جو کبھی کبھار تازہ کی جاتی ہیں وہ اصل وقت میں تازہ ہونے والی خصوصیات کے مقابلے میں بالآخر کم محفوظ ہوتی ہیں۔" ایک قابل اعتماد ذریعہ سے قابل اعتماد انتساب پائپ لائن بنانا اکثر ABAC کی تعیناتی کا سب سے مشکل حصہ ہوتا ہے۔

کارکردگی

ہر درخواست کے لیے پالیسی کا جائزہ لینے کے لیے کارکردگی کی لاگت ہوتی ہے۔ ہر تشخیص کے لیے متعدد ذرائع سے صفات حاصل کرنے کی ضرورت پڑ سکتی ہے۔ اس کو منظم کرنے کے لیے، بہت سے نفاذات انتساب کیچنگ کا استعمال کرتے ہیں، لیکن کیشنگ اوپر بیان کردہ اسٹیلنس کے مسائل کو متعارف کراتی ہے۔

حل یہ ہے کہ ہر پراپرٹی کی قسم کو مناسب ٹائم ٹو لائیو ویلیو (TTL) کے ساتھ کیش کیا جائے جس کی بنیاد پر یہ کتنی جلدی تبدیل ہو سکتی ہے۔ صارف کا شعبہ شاذ و نادر ہی تبدیل ہوتا ہے اور اسے کئی گھنٹوں تک کیش کیا جا سکتا ہے۔ صارف کی ایکٹو شفٹ کی حیثیت ہر 8 گھنٹے بعد بدل سکتی ہے اور اس کے لیے مختصر کیش کی ضرورت ہوتی ہے۔ ریئل ٹائم لوکیشن بالکل بھی کیش نہیں ہو سکتا۔

آڈٹ لاگنگ

چونکہ ABAC متحرک طور پر فیصلے کرتا ہے، آڈیٹنگ کے لیے ہر فیصلے میں استعمال ہونے والی صفات کے ساتھ ساتھ فیصلہ خود بھی ریکارڈ کرنے کی ضرورت ہوتی ہے۔ لاگ انٹری جسے "رسائی سے انکار" کہا جاتا ہے صرف اس صورت میں مفید ہے جب یہ یہ بھی دیکھے کہ رسائی کیوں مسترد کی گئی اور کون سی خصوصیات کس پالیسی پر پورا نہیں اتریں۔

NIST نوٹ کرتا ہے کہ فیصلے کرتے وقت انتساب کی اقدار کو ٹریک کیے بغیر احتساب کے تقاضے پورے نہیں کیے جا سکتے۔

حدود اور چیلنجز

اگرچہ ABAC طاقتور ہے، لیکن یہ رسائی کنٹرول کے تمام مسائل کا مناسب حل نہیں ہے۔ نفاذ شروع کرنے سے پہلے اپنی حدود کے بارے میں ایماندار ہونا اچھا خیال ہے۔

پیچیدگی: NIST SP 800-162 کے مطابق، "ABAC سسٹم آسان رسائی کنٹرول سسٹمز سے زیادہ پیچیدہ ہیں اور اس لیے لاگو کرنا اور برقرار رکھنا زیادہ مہنگا ہے۔" لچک جو ABAC کو طاقتور بناتی ہے اس کے بارے میں استدلال کرنا بھی مشکل بنا دیتا ہے۔ آپ کو صارف کی درجہ بندی کی تمام خصوصیات اور غیر متعین حالات کا معائنہ کرنا چاہئے جو پوچھتے ہیں کہ "میں اس تک رسائی کیوں نہیں کر سکتا؟"

پالیسی تنازعہ: بہت سی پالیسیوں والے پیچیدہ نظاموں میں، پالیسیوں کے درمیان تنازعات ہو سکتے ہیں۔ اگرچہ دونوں پالیسیاں انفرادی طور پر درست نظر آتی ہیں، لیکن جب ایک ساتھ استعمال کیا جائے تو وہ غیر متوقع نتائج پیدا کر سکتی ہیں۔ ان تنازعات کو حل کرنے کے لیے واضح ترجیحی قواعد اور محتاط پالیسی ڈیزائن کی ضرورت ہے۔

پراپرٹی مینجمنٹ اوور ہیڈ: بڑی صارف آبادی میں درست صفات کو برقرار رکھنے کے لیے شناخت کے بنیادی ڈھانچے میں سرمایہ کاری کی ضرورت ہوتی ہے۔ مختلف نظاموں کی خصوصیات کو معمول پر لانے، توثیق کرنے اور مطابقت پذیر رکھنے کی ضرورت ہے۔ جیسا کہ NIST وضاحت کرتا ہے، تنظیموں کو ایک مکمل انتساب کے انتظام کے بنیادی ڈھانچے کی ضرورت ہوتی ہے، نہ کہ صرف ایک پالیسی انجن۔

جانچ مشکل ہے: رسائی ممکنہ طور پر درجنوں خصوصیات کے مجموعے پر منحصر ہے، لہذا کنارے کے معاملات کی جامع جانچ کے لیے سوچ بچار کی ضرورت ہے۔ ایک پالیسی جو عام معاملات میں صحیح طریقے سے کام کرتی ہے وہ غیر معمولی خصوصیات کے امتزاج کے لیے غیر متوقع طور پر برتاؤ کر سکتی ہے۔

ہمیشہ سرمایہ کاری کے قابل نہیں ہوتا ہے۔: آسان رسائی کے تقاضوں کے ساتھ ایپلی کیشنز کے لیے، ABAC غیر ضروری پیچیدگی متعارف کراتا ہے۔ اگر آپ کی ضروریات کو مقررہ اجازتوں کے ساتھ کرداروں کے ایک سیٹ کے طور پر واضح طور پر ظاہر کیا جا سکتا ہے، تو RBAC ایک بہتر انتخاب ہے۔

نتیجہ

انتساب پر مبنی رسائی کنٹرول ایپلی کیشنز کی توثیق کا انتظام کرنے کے طریقے میں حقیقی پیشرفت کی نمائندگی کرتا ہے۔ کرداروں اور اجازتوں کی مسلسل بڑھتی ہوئی فہرست کو برقرار رکھنے کے بجائے، ABAC ہر درخواست کے وقت صارفین، وسائل اور سیاق و سباق کی اصل خصوصیات کا جائزہ لیتا ہے۔

رول دھماکے کے مسئلے کو حل کرتا ہے جو RBAC کے پیچیدہ نفاذ کو متاثر کرتا ہے۔ یہ رسائی کے قواعد کو قابل بناتا ہے جو تکنیکی اندازوں کے بجائے حقیقی کاروباری پالیسیوں کی عکاسی کرتے ہیں۔ متحرک منظرناموں، ہنگامی حالات، وقت پر مبنی پابندیوں، اور کراس تنظیمی رسائی کو ہینڈل کریں جن کا جامد کرداروں کے ساتھ اظہار کرنا مشکل یا ناممکن ہے۔

تاہم، ABAC عالمی سطح پر بہتر نہیں ہے۔ ان کی تعمیر زیادہ پیچیدہ، ڈیبگ کرنا مشکل، اور پراپرٹی مینجمنٹ انفراسٹرکچر میں سرمایہ کاری کی ضرورت ہوتی ہے جس کی سادہ ماڈلز کو ضرورت نہیں ہوتی ہے۔ بہت سی ایپلیکیشنز RBAC پر اچھی طرح کام کرتی ہیں، اور کچھ ایپلی کیشنز RBAC اور ABAC کو ایک ساتھ استعمال کرتی ہیں۔

صحیح سوال یہ نہیں ہے کہ "کیا مجھے ABAC استعمال کرنا چاہئے؟" "کیا میری رسائی کے تقاضے ABAC میں سرمایہ کاری کے لیے کافی پیچیدہ ہیں؟" اگر آپ کے رسائی کے قوانین بار بار تبدیل ہوتے ہیں، وسائل یا ماحولیاتی حالات پر منحصر ہوتے ہیں، یا تنظیمی حدود میں توسیع کرنے کی ضرورت ہوتی ہے، تو ABAC سنجیدہ غور کے قابل ہو سکتا ہے۔

اس بات کی نشاندہی کرکے شروع کریں کہ آپ کا موجودہ ایکسیس کنٹرول ماڈل کہاں پر مسئلہ ہے۔ اگر آپ ایسے کردار تخلیق کر رہے ہیں جو تمام ایج کیسز کی نمائندگی کرتے ہیں، اگر آپ روٹ ہینڈلرز کے اندر مشروط منطق لکھ رہے ہیں جو مخصوص پراپرٹی ویلیوز کو چیک کرتے ہیں، یا اگر آپ کے صارفین وہ مراعات جمع کر رہے ہیں جو انہیں مزید نہیں ہونے چاہئیں، تو یہ نشانیاں ہیں کہ زیادہ اظہار خیال کرنے والا ماڈل مددگار ثابت ہوگا۔

جب کردار کافی نہیں ہوتے ہیں تو ABAC ایک ٹول ہے۔

الفاظ

انتساب پر مبنی رسائی کنٹرول (ABAC): یہ ایک رسائی کنٹرول طریقہ ہے جو مضامین، اشیاء، اعمال، اور ماحولیاتی حالات جیسی صفات پر پالیسیوں کا جائزہ لے کر اتھارٹی کا تعین کرتا ہے۔ NIST اسے ایک نقطہ نظر کے طور پر بیان کرتا ہے جہاں "کسی موضوع پر کسی چیز پر آپریشن کرنے کی درخواست کو تفویض کردہ خصوصیات کی بنیاد پر منظور یا مسترد کیا جاتا ہے۔"

موضوع: وسائل تک رسائی کی درخواست کرنے والا ادارہ۔ عام طور پر ایک انسانی صارف، لیکن یہ ایک سروس، خودکار عمل، یا آلہ بھی ہو سکتا ہے۔ "درخواست گزار" کے نام سے بھی جانا جاتا ہے۔

اعتراض: ایک محفوظ وسیلہ، جیسے فائل، ڈیٹا بیس ریکارڈ، API اینڈ پوائنٹ، سروس، یا سسٹم ریسورس جس کی رسائی کا انتظام ABAC سسٹم کرتا ہے۔

سے شروع: کسی موضوع، شے، عمل، یا ماحول کی خصوصیت کو نام کی قدر کے جوڑے کے طور پر ظاہر کیا جاتا ہے۔ مثال کے طور پر user.department = "Finance" یا record.sensitivity = "High".

موضوع کی خصوصیت: وہ صفات جو صارف یا خدمت کی درخواست کی وضاحت کرتی ہیں، جیسے ملازمت کا عنوان، محکمہ، کلیئرنس کی سطح، یا موجودہ مقام۔

آبجیکٹ کی خصوصیات: وہ خصوصیات جو رسائی حاصل کیے جانے والے وسائل کی وضاحت کرتی ہیں، بشمول قسم، مالک، حساسیت کی سطح، اور محکمہ۔

ماحولیاتی حالات: موضوع اور اعتراض دونوں سے آزاد حالات کے عوامل جو رسائی کے فیصلوں کو متاثر کرتے ہیں۔ مثالوں میں دن کا وقت، ہفتے کا دن، IP پتہ، آلہ کی تعمیل کی حیثیت، یا موجودہ خطرے کی سطح شامل ہیں۔

پالیسی: ایک قاعدہ یا قواعد کا مجموعہ جو انتساب کی قدروں کا اندازہ لگاتا ہے تاکہ یہ تعین کیا جا سکے کہ آیا کسی مخصوص رسائی کی درخواست کی اجازت دی جائے یا مسترد کی جائے۔ ABAC پالیسیاں عام طور پر منطقی حالات کے طور پر لکھی جاتی ہیں۔

پالیسی فیصلہ پوائنٹ (PDP): ABAC نظام کا ایک جزو جو رسائی کے فیصلوں کا حساب لگانے کے لیے پالیسیوں اور خصوصیات کا جائزہ لیتا ہے۔

پالیسی انفورسمنٹ پوائنٹ (PEP): ایک ایسا جزو جو رسائی کی درخواستوں کو روکتا ہے اور PDP کے ذریعے کیے گئے فیصلوں کو نافذ کرتا ہے۔

پالیسی انفارمیشن پوائنٹ (PIP): ایک ایسا جزو جو PDP کو فیصلہ کرنے کے لیے درکار انتساب اقدار کو بازیافت کرتا ہے۔

پالیسی مینجمنٹ پوائنٹ (PAP): ایک ایسا جزو جو پالیسیاں بنانے، جانچنے اور ان کے انتظام کے لیے ایک انٹرفیس فراہم کرتا ہے۔

رول پر مبنی رسائی کنٹرول (RBAC): ایک رسائی کنٹرول ماڈل جو کرداروں اور صارفین کو کرداروں کے لیے اجازتیں تفویض کرتا ہے۔ یہ ABAC سے آسان ہے، لیکن پیچیدہ اور متحرک رسائی کی ضروریات کے لیے کم اظہار خیال کرتا ہے۔

کردار دھماکہ: جیسے جیسے رسائی کے تقاضے زیادہ دانے دار ہوتے جاتے ہیں، RBAC سسٹمز میں زیادہ سے زیادہ مخصوص کردار پھیلتے جاتے ہیں، بالآخر کرداروں کو انفرادی اجازتوں کی طرح منظم کرنا مشکل ہو جاتا ہے۔

صوابدیدی رسائی کنٹرول (DAC): ایک رسائی کنٹرول ماڈل جس میں وسائل کے مالکان کنٹرول کرتے ہیں کہ کون اپنے وسائل تک رسائی حاصل کرسکتا ہے۔ یہ فائل سسٹمز میں عام ہے۔

MAC (لازمی رسائی کنٹرول): ایک رسائی کنٹرول ماڈل جس میں وسائل کے مالک کی ترجیحات سے قطع نظر، درجہ بندی کے لیبلز کا استعمال کرتے ہوئے رسائی کا انتظام مرکزی اتھارٹی کرتا ہے۔

رسائی کنٹرول لسٹ (ACL): وسائل سے وابستہ ایک فہرست جو یہ بتاتی ہے کہ کن صارفین یا گروپس کو کیا اجازت ہے۔ ID پر مبنی رسائی کنٹرول سسٹم میں عام۔

غیر ذاتی ہستی (NPE): انسانی صارف کے علاوہ کوئی ہستی، جیسا کہ ایک خودکار سروس، ایپلیکیشن، یا نیٹ ورک ڈیوائس، جو کسی وسائل تک رسائی کی درخواست کر سکتی ہے۔

انتساب کیشنگ: رسائی کے فیصلوں کے لیے باسی ڈیٹا کو ممکنہ طور پر استعمال کرنے کی بجائے کارکردگی کو بہتر بنانے کے لیے پہلے سے حاصل کردہ پراپرٹی ویلیوز کو اسٹور کرتا ہے۔

اوور رائڈ امتزاج کو مسترد کریں۔: ایک پالیسی کو ملانے والا اصول جہاں اگر وہ پالیسی انکار واپس کرتی ہے، تو پورا فیصلہ مسترد کر دیا جاتا ہے، قطع نظر اس کے کہ کوئی بھی دوسری پالیسی جو اجازت واپس کر سکتی ہے۔

ناکام بند: ایک حفاظتی ڈیزائن کا اصول جو غیر متوقع غلطیوں یا گمشدہ معلومات کی وجہ سے اجازت دینے کے بجائے رسائی سے انکار کر کے غیر مجاز رسائی کے خطرے کو کم کرتا ہے۔

ماخذ: تعریفیں NIST اسپیشل پبلیکیشن 800-162، گائیڈ ٹو ایٹریبیوٹ بیسڈ ایکسیس کنٹرول (ABAC) کی تعریفیں اور کنڈریشنز، جنوری 2014 (اگست 2019 تک کی تازہ کاریوں کے ساتھ)۔