تفویض کردہ رسائی
کسی ڈویلپر کو شامل کریں، بلنگ اپنے اکاؤنٹنٹ کے سپرد کریں، کسی کلائنٹ کو ان کی اپنی سائٹس تک صرف پڑھنے کی رسائی دیں، یا ہماری سپورٹ ٹیم کو کسی مسئلے کا جائزہ لینے دیں۔ ہر اجازت ایک ایسا کردار ہے جس کے اختیارات متعین ہیں، جو کسی تنظیم تک محدود ہے، ڈیٹابیس میں نافذ ہے، اور صرف اضافہ کے قابل آڈٹ لاگ میں درج کیا جاتا ہے۔
ایک ہی لاگ ان کا اشتراک کرنا اکاؤنٹ تک رسائی میں خرابی کا سبب بنتا ہے۔ Zinn Digital® پر ہر شخص کی اپنی شناخت ہوتی ہے، اور رسائی ایک رکنیت ہے — ایک صارف، ایک تنظیم، اور ایک کردار — جسے آپ الگ سے تفویض کر سکتے ہیں، تبدیل کر سکتے ہیں یا منسوخ کر سکتے ہیں۔
ہر معاون ہماری شناخت کی پرت، Keycloak، کے ذریعے اپنی ذاتی حیثیت میں سائن ان کرتا ہے۔ کوئی بھی آپ کا پاس ورڈ ٹائپ نہیں کرتا، کوئی بھی براؤزر سیشن شیئر نہیں کرتا، اور کسی کو ہٹانا پاس ورڈ بدلنے اور یہ جاننے کی بھاگ دوڑ کے بجائے صرف ایک عمل ہے کہ اسے اور کون جانتا تھا۔
اکاؤنٹس درجہ بدرجہ ہیں — ایک ری سیلر تنظیم کلائنٹ تنظیموں پر مشتمل ہوتی ہے، اور کلائنٹ تنظیمیں سائٹس پر مشتمل ہوتی ہیں۔ رکنیت کا اطلاق کسی تنظیم اور اس کے ماتحت تمام چیزوں پر ہوتا ہے، لہذا آپ اپنے دیگر کلائنٹس کو ظاہر کیے بغیر کسی ایجنسی کلائنٹ کو ان کی اپنی تنظیم کا کنٹرول سونپ سکتے ہیں۔
کرایہ داروں کی علیحدگی ایپلی کیشن کوڈ میں ایسا فلٹر نہیں ہے جسے کوئی خرابی نظر انداز کر سکے۔ Postgres Row-Level Security ہر سوال کو کال کرنے والے کے تنظیمی سب ٹری تک محدود کرتی ہے، اس لیے آپ کے دائرہ کار سے باہر کی درخواست واپس کرنے کے لیے کچھ نہیں رکھتی۔
اپنے دائرہ کار سے باہر کسی تنظیم یا سائٹ کی درخواست کریں اور API اجازت کی خرابی کے بجائے ایک عام ریکارڈ نہ ملنے کا جواب دیتا ہے۔ اجازت کی خرابی اس بات کی تصدیق کرے گی کہ ریکارڈ موجود ہے؛ کچھ نہ ملنا کسی بیرونی شخص کو بالکل کچھ نہیں بتاتا۔
اجازتیں تفصیلی کنجیاں ہیں — ماڈیول مع عمل، جیسے sites.restart یا billing.refund — اور کردار انہیں یکجا کرتے ہیں۔ چار کردار ان صورتوں کا احاطہ کرتے ہیں جن کی حقیقی ٹیموں کو ضرورت ہوتی ہے، اور ہر ایک وہ ڈیٹا ہے جو ہم شامل کرتے ہیں، نہ کہ کوڈ میں دفن منطق۔
مکمل کنٹرول: ذیلی تنظیمیں بنائیں، اراکین کو مدعو کریں اور ہٹائیں، کردار تبدیل کریں، API کیز کا نظم کریں، سائٹس بنائیں، دوبارہ شروع کریں، صاف کریں، معطل کریں اور حذف کریں، بلنگ اور رسیدیں چلائیں، ٹکٹ درج کریں اور آڈٹ لاگ پڑھیں۔ وہ کردار جو آپ اپنے لیے رکھتے ہیں۔
تنظیم، اس کے اراکین اور منصوبوں کا کیٹلاگ دیکھتا ہے، اور انوائسز، ادائیگی کے طریقوں اور چارجز کا انتظام کرتا ہے۔ کسی ایک سائٹ کو بھی بنانے، تبدیل کرنے یا حذف کرنے کی کوئی رسائی نہیں — بالکل وہی صورت جو کسی بیرونی بک کیپر کی ہونی چاہیے۔
سائٹس دیکھتا اور تخلیق کرتا ہے، سروسز دوبارہ شروع کرتا ہے، کیشے صاف کرتا ہے، API کیز کا انتظام کرتا ہے اور ٹکٹس پر کام کرتا ہے۔ جان بوجھ کر خارج کردہ: بلنگ، رسیدیں، ادائیگی کے طریقے، اراکین کا انتظام، سائٹ معطلی اور سائٹ کا اخراج۔ کوئی بھی ٹھیکیدار آپ پر بل عائد کیے بغیر یا کسی بھی چیز کو نقصان پہنچائے بغیر تعمیر کر سکتا ہے۔
تنظیم، اس کے اراکین، اس کی سائٹس، اس کی بلنگ، پلان کیٹلاگ، ٹکٹس، ترجمے کی حیثیت اور آڈٹ لاگ کو دیکھ سکتا ہے — اور اس میں سے کچھ بھی تبدیل نہیں کر سکتا۔ اس کلائنٹ کے لیے موزوں اجازت جو واضح رسائی چاہتا ہے، کسی آڈیٹر، یا کسی اسٹیک ہولڈر کے لیے جسے صرف دیکھنے کی ضرورت ہے۔
رسائی سونپنا صرف اسی صورت میں محفوظ ہے جب وہ اکاؤنٹس جنہیں آپ سونپتے ہیں، ان پر قبضہ کرنا مشکل ہو۔ تصدیق ہر سطح پر اکاؤنٹ میں موجود ہر فرد کے لیے Keycloak کے ذریعے چلتی ہے۔
سپورٹ کے کام کا مطلب بعض اوقات آپ کے اکاؤنٹ کے اندر دیکھنا ہوتا ہے۔ اس رسائی کو اسی اجازت کے ماڈل کے تحت کنٹرول کیا جاتا ہے جس طرح باقی ہر چیز کو — عملہ محض ایک عملے کی تنظیم میں موجود ہوتا ہے، جو محدود اجازتوں والے شعبوں میں منظم ہوتا ہے۔
عملے کو سپورٹ، بلنگ اور فنانس، غلط استعمال اور اعتماد و حفاظت، سیلز، آن بورڈنگ، انجینئرنگ اور آپریشنز، مارکیٹنگ، اور مینجمنٹ میں تقسیم کیا گیا ہے۔ ہر کردار مخصوص ماڈیولز اور کارروائیوں کی اجازت دیتا ہے، تاکہ ایک ایجنٹ ایڈمن کنسول کا وہی حصہ دیکھے جس کی ان کے کام کو ضرورت ہے اور باقی نہیں۔
سپورٹ ایجنٹ کا کردار بالکل یہی فراہم کرتا ہے: صارفین کو دیکھنا، ٹکٹ دیکھنا اور ان کا جواب دینا، سائٹس دیکھنا، سائٹ کو دوبارہ شروع کرنا اور اس کا کیشے صاف کرنا۔ اس میں بلنگ کی ترتیبات، رقوم کی واپسی، منصوبوں میں ترمیم اور فلیٹ کا انتظام شامل نہیں ہے۔ جو حل ایک ایجنٹ فراہم کر سکتا ہے وہ کردار تک محدود ہے، نہ کہ نیک نیتی تک۔
customer.impersonate کی اجازت Manager کے کردار کا حصہ نہیں ہے — یہ صرف Super Admin کے پاس ہوتی ہے۔ جب آپ کی طرف سے کوئی سیشن چل رہا ہو، تو ڈیش بورڈ پر نقالی کا ایک مستقل بینر ظاہر ہوتا ہے تاکہ کبھی بھی یہ ابہام نہ رہے کہ کارروائی کون کر رہا ہے۔
ہر مراعات یافتہ اور انتظامی کارروائی صرف اضافے کے لیے مخصوص (append-only) آڈٹ لاگ میں شامل کی جاتی ہے جو عمل کرنے والے، کارروائی، ہدف، معاون میٹا ڈیٹا، IP ایڈریس اور ٹائم اسٹیمپ کو ریکارڈ کرتی ہے — پروڈکشن میں وقت کے لحاظ سے تقسیم شدہ۔ مالکان اور صرف پڑھنے کی رسائی رکھنے والے اراکین اپنی تنظیم کا لاگ خود پڑھ سکتے ہیں۔
عملے کے حساس اور تباہ کن اقدامات پر عمل درآمد سے پہلے اضافی تصدیق یا دو افراد کی منظوری کی ضرورت ہو سکتی ہے، اور نئے شعبہ جات اور کردار کوڈ کی تبدیلی کے بجائے کنفیگریشن کے ذریعے ہوتے ہیں۔
اسکرپٹس، CI پائپ لائنز، CLI، Terraform فراہم کنندہ اور AI ایجنٹس سبھی انسانوں کی طرح اسی اجازت کے ماڈل کے ذریعے تصدیق کرتے ہیں — نہ کوئی مشترکہ انسانی اسناد، نہ کسی بلڈ میں چسپاں کیے گئے دیرپا راز۔
کلیدیں کسی تنظیم کی ملکیت ہوتی ہیں اور ان میں RBAC کے انہی اختیارات سے وابستہ مخصوص دائرہ کار شامل ہوتے ہیں — صرف پڑھنے کے لیے، بلنگ، پروویژننگ۔ پائپ لائن کو کسی رکن کے پورے اکاؤنٹ کے بجائے صرف وہی محدود دائرہ کار دیں جس کی اسے ضرورت ہے۔
ٹیسٹ موڈ اور لائیو موڈ کی کیز الگ الگ ہوتی ہیں، تاکہ ڈیولپمنٹ کے مراحل میں موجود انٹیگریشن غلطی سے یا کاپی کیے گئے انوائرنمنٹ ویری ایبل کے ذریعے پروڈکشن ڈیٹا تک نہ پہنچ سکے۔
ہم راز کا ایک SHA-256 ہیش اور تلاش کا سابقہ محفوظ کرتے ہیں — اصل کلید کبھی نہیں۔ آپ تخلیق کے وقت کلید کو صرف ایک بار دیکھتے ہیں۔ ہر کلید اس بات کا سراغ رکھتی ہے کہ اسے آخری بار کب استعمال کیا گیا تھا اور کسی دوسری چیز کو متاثر کیے بغیر اسے تنہا منسوخ کیا جا سکتا ہے۔
ہمارا MCP سرور کسی بھی MCP کے حامل ایجنٹ کو قدرتی زبان میں آپ کی ہوسٹنگ کا انتظام کرنے کی اجازت دیتا ہے، جو OAuth 2.1 کے ساتھ تصدیق شدہ ہے اور آپ کی تنظیم اور RBAC کردار تک محدود ہے، جس میں فی ٹول منسوخ کیے جانے والے ٹوکنز، تباہ کن اقدامات پر تصدیق، اخراجات کی حدود اور مکمل آڈٹ لاگنگ شامل ہے۔
اکاؤنٹ تک رسائی اور سرور تک رسائی دو مختلف معاملات ہیں۔ سائٹ کی سطح کی اسناد ڈیش بورڈ میں منظم کی جاتی ہیں، کم سے کم مراعات کے ساتھ جاری کی جاتی ہیں، اور قید کی جاتی ہیں تاکہ ایک معاون کا شیل صرف ایک سائٹ کا شیل ہو۔
ایک تنہا آپریٹر ایک تنظیم اور ایک مالک کی رکنیت برقرار رکھتا ہے، اور جب کوئی ٹھیکیدار کسی منصوبے کے لیے آتا ہے تو ڈیولپر کا کردار شامل کرتا ہے۔ جب منصوبہ ختم ہوتا ہے، تو رکنیت ختم کر دی جاتی ہے اور ان کا سائن ان فوری طور پر کام کرنا بند کر دیتا ہے — گھمانے کے لیے کوئی مشترکہ اسناد باقی نہیں بچتی ہیں۔
ایک ایجنسی تنظیمی شجرہ (آرگنائزیشن ٹری) کا استعمال کرتی ہے۔ ہر کلائنٹ کو اس کی اپنی ماتحت تنظیم ملتی ہے، جس میں اس کلائنٹ کی سائٹس ہوتی ہیں، اور کلائنٹ کے اپنے عملے کو وہاں کی رکنیت مل جاتی ہے — رسائی اور آگاہی چاہنے والے اسٹیک ہولڈر کے لیے صرف پڑھنے کی اجازت (ریڈ آنلی)، اور خود کام کرنے کے خواہشمند کلائنٹ کے لیے مالک (اونر) کی اجازت۔ آپ کے عملے کے پاس شجرے کے بالائی حصوں کی رکنیت ہوتی ہے اور وہ پورا پورٹ فولیو دیکھتے ہیں؛ ایک کلائنٹ صرف اپنی شاخ دیکھتا ہے، اور Row-Level Security ہی وہ چیز ہے جو اسے محض وعدے کے بجائے ایک حقیقت بناتی ہے۔
ایک ری سیلر بھی اسی طرح کام کرتا ہے، بس ایک درجے اوپر: ایک ری سیلر تنظیم کلائنٹ کی تنظیموں کو سنبھالتی ہے، جن میں سے ہر ایک کے اپنے اراکین، بلنگ کا منظر اور سائٹس ہوتی ہیں۔ یہی بنیادی ساخت سب اکاؤنٹس، ایجنسی ٹیموں اور ری سیلر کے تنظیمی ڈھانچے کو چلاتی ہے — ان میں سے کسی کے لیے بھی کوئی الگ یا کمزور نظام موجود نہیں ہے۔
کارڈ کے بغیر 14 دن کے آزمائشی ورژن میں سب کچھ دستیاب ہے۔ ادائیگی کی تفصیلات کے بغیر سائن اپ کریں، کسی ساتھی کو مدعو کریں، دیکھیں کہ ہر کردار کس چیز تک رسائی حاصل کر سکتا ہے اور کس تک نہیں، اور اپنا آڈٹ لاگ دوبارہ پڑھیں۔
آج ایک رکنیت کسی تنظیم اور اس کے ماتحت شجرہ جاتی ڈھانچے میں موجود ہر چیز پر اپنا کردار نافذ کرتی ہے، لہٰذا سائٹ کے مجموعوں کو الگ کرنے کا طریقہ تنظیموں کو الگ کرنا ہے — ان سائٹس کو ان کی اپنی ذیلی تنظیم میں رکھیں اور وہاں رکنیت تفویض کریں۔ یہ ایجنسیوں اور ری سیلرز کے لیے ایک واضح ماڈل ہے، جہاں ہر گاہک پہلے ہی اپنی حدود چاہتا ہے۔ فی رکنیت وسائل کی حد بندی، یعنی ایک ہی تنظیم کے اندر ایک رکنیت کو مخصوص سائٹس سے منسلک کرنا، فی الحال دستیاب فیچر کی بجائے ایک منصوبہ بند بہتری ہے۔
ڈویلپر کے کردار میں سائٹ کو حذف کرنا یا سائٹ کو معطل کرنا شامل نہیں ہے — یہ اختیارات مالک کے کردار سے تعلق رکھتے ہیں۔ یہ سائٹس دیکھنے اور بنانے، سروسز دوبارہ شروع کرنے، کیشے صاف کرنے، API کیز کا انتظام کرنے اور ٹکٹوں پر کام کرنے کی اجازت دیتا ہے۔ ڈیپلائمنٹ اور لائیو کرنے کی اجازتیں بھی ڈویلپر کے دائرہ اختیار کا حصہ نہیں ہیں، لہذا پروڈکشن میں منتقل کرنے کا اختیار اکاؤنٹ کے مالک کے پاس ہی رہتا ہے۔ اسے اسٹیجنگ کے ساتھ جوڑیں تاکہ تعمیراتی کام شروع سے ہی لائیو سائٹ سے باہر ہو۔
یہ مکمل طور پر عملے کے کردار پر منحصر ہے، اور ہر کردار اجازت نامے کی کلیدوں کا ایک محدود مجموعہ ہوتا ہے۔ مثال کے طور پر، سپورٹ ایجنٹ آپ کا اکاؤنٹ اور سائٹس دیکھ سکتا ہے، آپ کے ٹکٹس دیکھ سکتا ہے اور ان کا جواب دے سکتا ہے، سائٹ کو دوبارہ شروع کر سکتا ہے اور اس کا کیشے صاف کر سکتا ہے — اور بلنگ کنفیگریشن، ریفنڈز، پلانز یا فلیٹ میں کوئی ردوبدل نہیں کر سکتا۔ بطور صارف سائن ان کرنا ایک الگ اجازت ہے جو صرف Super Admin کے پاس ہوتی ہے، اور جب ایسا ہوتا ہے تو ڈیش بورڈ پر مسلسل بھیس بدلنے (impersonation) کا بینر ظاہر ہوتا ہے۔ ہر بااختیار کارروائی آڈٹ لاگ میں عمل کرنے والے، کارروائی، ہدف، آئی پی اور ٹائم اسٹیمپ کے ساتھ ریکارڈ کی جاتی ہے، اور آپ اپنی تنظیم کا لاگ خود پڑھ سکتے ہیں۔
رکنیت ختم کر دیں اور اس تنظیم تک ان کی رسائی ختم ہو جاتی ہے — ان کی اپنی شناخت برقرار رہتی ہے، لیکن آپ کے اکاؤنٹ میں کوئی کردار اور اس لیے کوئی اجازت نہیں ہوتی۔ API کیز انفرادی طور پر منسوخ کی جاتی ہیں، لہذا کسی اور چیز کو متاثر کیے بغیر پائپ لائن کی کو ختم کیا جا سکتا ہے۔ اگر آپ SAML سنگل سائن آن استعمال کرتے ہیں، تو آپ کے شناختی فراہم کنندہ میں ڈی پروویژننگ سائن ان کو مرکزی طور پر سنبھالتی ہے۔ سائٹ کی سطح کی اسناد جیسے کہ SSH کیز کو ڈیش بورڈ میں منسوخ کر دیا جاتا ہے، اور اس برطرفی کا خود آڈٹ لاگ بنتا ہے۔
نہیں — لیکن اس کی وجہ کے بارے میں واضح ہونا ضروری ہے۔ API کیز تنظیم کی ملکیت ہوتی ہیں، کسی انفرادی رکن کی نہیں، اور وہ اسی اجازت نامے کے کیٹلاگ سے منسلک اپنے تفصیلی دائرہ کار رکھتی ہیں۔ لہٰذا کسی شخص کو کلید سونپنے کے بجائے، آپ اس کام کے لیے ایک کلید بناتے ہیں جو وہ کام کرتا ہے جس کے لیے اس کام کو درکار سب سے محدود دائرہ کار ہوتا ہے، اور کام ختم ہونے پر اس کلید کو منسوخ کر دیتے ہیں۔ خفیہ کا صرف ایک ہیش ہمیشہ محفوظ کیا جاتا ہے، اور ہر کلید ریکارڈ کرتی ہے کہ اسے آخری بار کب استعمال کیا گیا تھا تاکہ غیر استعمال شدہ کلیدوں کو تلاش کرنا اور ریٹائر کرنا آسان ہو۔
جی ہاں۔ ہمارا MCP سرور OAuth 2.1 کے ذریعے ایجنٹس کی توثیق کرتا ہے اور انہیں آپ کی تنظیم اور آپ کے RBAC کردار تک محدود کرتا ہے، جس میں ہر ٹول کے لیے منسوخ ہونے والے ٹوکنز شامل ہیں، تاکہ آپ مکمل رسائی کے بجائے ایک مخصوص صلاحیت فراہم کریں۔ تباہ کن کارروائیوں کے لیے تصدیق درکار ہوتی ہے، اخراجات کی حدیں لاگو ہوتی ہیں، اور ہر کارروائی اسی آڈٹ لاگ میں درج ہوتی ہے جس میں انسانی سرگرمیاں ہوتی ہیں۔
پوسٹگریس کی رو-لیول سیکیورٹی (Row-Level Security) ڈیٹا بیس کے اندر ہی کوئریز کو کال کرنے والے کے تنظیمی سب ٹری تک محدود کرتی ہے، جس میں ایپلیکیشن لیول فلٹر واحد دفاع کے بجائے اضافی دفاع کے طور پر کام کرتا ہے۔ دائرہ کار سے باہر کے ریکارڈز کی درخواستیں اجازت کی خرابی کے بجائے 'نہیں ملا' ظاہر کرتی ہیں، تاکہ کیا موجود ہے اس کے بارے میں کچھ بھی افشا نہ ہو۔ سرور کی طرف، CageFS کے ذریعے ہر سائٹ کی تنہائی ہر کرایہ دار کے شیل اور فائلوں کو ان کی اپنی سائٹ تک ہی محدود رکھتی ہے۔
جی ہاں۔ 14 دن کی آزمائش بغیر کارڈ کے ہے — نہ ادائیگی کی تفصیلات، نہ کوئی پابندی — اور اس میں پانچ سائٹس تک کی Footprint-Free ہوسٹنگ شامل ہے۔ کسی ساتھی کو مدعو کرنے، کوئی کردار تفویض کرنے، اور اس بات کی تصدیق کرنے کے لیے کہ حدود آپ کی ضرورت کے مطابق کام کرتی ہیں، یہ حتمی فیصلہ کرنے سے پہلے کافی ہے۔
بغیر کارڈ کے 14 روزہ آزمائشی مدت شروع کریں، کسی کو مدعو کریں، اور اجازتوں کے ماڈل کو اپنا کام کرتے ہوئے دیکھیں — ایسے کردار جنہیں آپ نام دے سکتے ہیں، ایسے دائرہ کار جنہیں آپ منسوخ کر سکتے ہیں، اور ایک آڈٹ لاگ جو بالکل واضح بتاتا ہے کہ کس نے کیا کیا۔
مفت شروع کریں