مجوزدهی — چه کسی مجاز است چه کاری انجام دهد و چگونه آن را اثبات میکنید
Control Center دو پرسش مجوزدهی را پاسخ میدهد و این دو واقعاً متفاوتاند. «آیا این فرد میتواند این عملیات را فراخوانی کند؟» دربارهٔ انسانها، نقشها و مخزنها است. «آیا این عامل میتواند این اثر را پدید آورد؟» دربارهٔ کنشها، آرگومانها و دامنهٔ اثر است — آن یکی به گاردریلها مربوط میشود.
این صفحه به پرسش نخست میپردازد، بههمراه سابقهای که هر دو از خود بهجا میگذارند.
یک نقطهٔ تصمیم
بخش با عنوان “یک نقطهٔ تصمیم”هر تصمیم مجوزدهی در سمت انسان از یک تابع واحد میگذرد:
can(principal, permission, resource) → allow | deny + whyیک مجوز به شکل <domain>:<tier> است — tickets:write،
members:administer، repos:read. این کاتالوگ استخراجشده است، نه
دستنویس: از خودِ سطح عملیات محاسبه میشود (پیشوند نام عملیات دامنه را میدهد
و حداقل نقشی که از قبل اعمال میکند، رده را)، بنابراین هر ~550 عملیات بدون
آنکه کسی چیزی تایپ کند، یک مجوز دارد.
همین استخراج، همان ویژگیای است که ارزش محافظت دارد. یعنی یک عملیات تازه بهطور پیشفرض دروازهبندی میشود — حالت شکست یک مدل دستیِ حاشیهخورده این است که کسی فراموش میکند، و چیزی که فراموش میشود همان دروازه است. یک تست ratchet مجموعهٔ دامنههای حاصل را تثبیت میکند، بنابراین افزودن یک عملیات زیر پیشوندی تازه، تصمیمی در نامگذاری است که یک انسان میگیرد، نه یک اتفاق.
این چهار رده دقیقاً با نقشهای توکار متناظرند:
| رده | حداقل نقش | نمونه |
|---|---|---|
read |
مهمان | tickets:read |
write |
عضو | tickets:write |
administer |
ادمین | members:administer |
own |
مالک | workspace:own |
نقشها
بخش با عنوان “نقشها”پنج نقش توکار — مالک، ادمین، عضو، بیننده، مهمان — پیشتنظیمهایی روی همان کاتالوگ هستند. مالکیت یک جایگاه واحد در هر فضای کاری است که با انتقال مالکیت بهصورت صریح واگذار میشود (در غیر این صورت مالکی که میرود، قابل حذف نیست: لغو تأمین SCIM هر مالک فضای کاری را رد میکند — اول مالکیت را واگذار کنید).
نقشهای سفارشی فقط کم میکنند. یک نقش سفارشی یک پیشتنظیم پایه نام میبرد
(admin، member، viewer یا guest — هرگز owner) و مجموعهای از مجوزها
که از آن حذف میشود — «ادمین، اما نمیتواند اعضا را مدیریت کند». هرگز نمیتواند
بیش از پایهاش اعطا کند و همین است که ورودشان به یک نصب موجود را بیخطر
میکند: هر بررسی موجود همچنان یک کران بالای معتبر میماند. اعضا آنها را به
شکل custom:<id> نگه میدارند و کلاینتی که برای فهمیدن آن مقدار بیش از حد
قدیمی باشد، بهجای حدسزدن به مهمان بازمیگردد.
زیر نقشها اعطاهای هر مخزن قرار دارند (none / read / review /
write): عضویت در فضای کاری هرگز بیسروصدا اختیاراتی فراتر از میزبان کد
نمیدهد. هر سطحی که کد را در معرض دید میگذارد آنها را بررسی میکند — از جمله
آنهایی که از پهلو به کد میرسند، مثل یک ترمینال یا نشستی از ویرایشگر که روی
worktree یک فضا باز شده است.
اختیار سرور
بخش با عنوان “اختیار سرور”برخی عملیات اصلاً دربارهٔ یک فضای کاری نیستند: تنظیمات سطح کل نصب، پیکربندی SSO، گواهیهای ارائهدهنده، مدیریت مدل، پشتیبانگیری از کل نصب. اینها اختیار سرور را اعلام میکنند و برای همه بهجز اپراتور نصب (مالک ثبتشدهٔ سرور) رد میشوند. بهعمد فقط یک هویت اپراتور و یک تعریف از آن وجود دارد.
رد حسابرسی
بخش با عنوان “رد حسابرسی”هر تصمیم مجوزدهی — اجازه و رد — به یک رد حسابرسی که برای هر فضای کاری جداگانه نگه داشته میشود و با هش زنجیره شده است، افزوده میشود.
گزارشی که فقط ردها را ثبت کند به «چه چیزهایی را مسدود کردیم؟» پاسخ میدهد، اما به «این عامل واقعاً چه کرد و چه کسی آن را مجاز دانست؟» نه — پرسشی که بررسی یک حادثه از آن آغاز میشود. بنابراین هر ورودی کل زنجیرهٔ اسناد را ثبت میکند: principal کنشگر، انسانی که به نمایندگی از او عمل شده، واگذاریای که از آن رسیده، کنش و آرگومانهایش (بهصورت چکیده)، تصمیم، و قاعدهای که تصمیم را گرفته است.
ورودیها زنجیره شدهاند: هش هر ورودی، هش ورودی قبلی را در بر میگیرد؛ پس ویرایش، حذف یا جابهجایی هر ردیف، همهٔ هشهای پس از آن را میشکند. تأیید زنجیره کل زنجیره را از نو استخراج میکند و نخستین حلقهای را نام میبرد که برقرار نمیشود. یک گزارش حسابرسی که نمیتوانید بررسی کنید، یک گزارش است؛ آنکه میتوانید از نو استخراج کنید، مدرک است.
دو پیامد که دانستنشان ارزش دارد:
- جدول حسابرسی از هرس مبتنی بر عمر معاف است. یک زنجیرهٔ هش را نمیتوان از میانه کوتاه کرد. نگهداشت به شکل برونبری و سپس کوتاهسازی است، و کوتاهسازی یک نقطهٔ بازرسی بهجا میگذارد که هش پایانی بخش حذفشده را حمل میکند، بنابراین آنچه باقی میماند همچنان تا ابتدا قابلتأیید است.
- این رد کنار خط زمانی فعالیت مینشیند، نه روی آن. خط زمانی آن چیزی است که مردم انجام دادند؛ اینجا آن چیزی است که مجاز یا رد شده است. یک شناسهٔ همبستگی مشترک، یک فراخوانی را در هر دو میخواند.
بهصورت JSON جداشده با خط جدید برونبری میشود و میتواند به یک SIEM جریان یابد (Splunk، Elastic، Sentinel — یک نقطهٔ پایانی HTTP با یک توکن bearer). جریاندهی از روی طراحی بدون تضمین است: پایینبودن یک SIEM هرگز نباید فراخوانی ابزار یک عامل را مسدود کند، و نسخهٔ پایدار و قابلتأیید در هر حالت روی دیسک است.
نشستها
بخش با عنوان “نشستها”یک نصب میتواند حداکثر عمر نشست و مهلت بیکاری را تعیین کند. هر دو در بررسی گواهی دستگاه اعمال میشوند؛ همان جایی که هر مسیر احرازشده از آن میگذرد — محدودیتی از جنس نشست که کلاینت بتواند نادیده بگیرد، به یک پرسشنامه پاسخ میدهد، نه به یک مهاجم. یک نصب همچنین میتواند SSO را الزامی کند که جفتکردن دستی دستگاههای جدید را غیرفعال میکند (با یک محافظ قفلشدن: تا وقتی هیچ اتصال SSO کارآمدی وجود ندارد، درخواست را رد میکند).
این چه چیزی نیست
بخش با عنوان “این چه چیزی نیست”- ACLهای هر شیء نیست. بهعمد هیچ مجوزی برای هر تیکت یا هر پیام وجود ندارد. جداسازی در سطح مخزن همان چیزی است که تیمها واقعاً درخواست میکنند و وجود دارد؛ اشتراکگذاری هر شیء سطحی ترکیباتی است که اینجا تقاضای اثباتشدهای ندارد.
- موتور سیاستی نیست که در یک DSL پیکربندی کنید. واژگان بهعمد بسته است، تا کل سیاست بتواند نمایش داده، توضیح داده و برشمرده شود.
- جایی جز سرور اعمال نمیشود. بررسیهای سمت کلاینت تنها برای پرهیز از ارائهٔ کنترلی وجود دارند که رد خواهد شد. تصمیم معتبر همیشه تصمیم سرور است.