مدیریت نقشها و مجوزها
نقشها و مجوزها مشخص میکنند هر کاربر در فضای کاری گدارAI چه کاری میتواند انجام دهد. نقش، بستهای از چند مجوز است. مجوز، کوچکترین واحد اختیار است؛ مثل دیدن کاربران، مدیریت تیمها یا مشاهده محتوای لاگ درخواستها.
این صفحه برای مدیران فضای کاری و مسئولان امنیت/عملیات نوشته شده است؛ کسانی که باید دسترسی را بدون بازکردن بیدلیل اختیارها مدیریت کنند.
تیم، محدوده کار را مشخص میکند. نقش و مجوز، اختیار انجام کار را مشخص میکنند. این دو مکمل هم هستند، نه جایگزین هم.
نقشهای سیستمی
گدارAI چند نقش سیستمی آماده دارد:
| نقش | کاربرد پیشنهادی |
|---|---|
proxy_admin | نقش سطح بالا برای مدیریت گسترده؛ معمولاً برای کاربران عادی مستندات لازم نیست |
tenant_admin | مدیر فضای کاری با اختیار گسترده |
billing_manager | مدیریت امور مالی، کیف پول، گزارشها و اسناد مالی |
org_admin | مدیریت در محدوده واحد سازمانی |
team_admin | مدیریت روزمره تیم و کاربران مجازی/توکنهای تیمی |
member | عضو عادی با دسترسی محدود |
readonly_member | مشاهده محدود بدون تغییر |
نقش tenant_admin را کمتعداد نگه دارید. این نقش به بخشهای حساسی مثل کاربران، نقشها، اتصالها، سیاستها، تنظیمات، مالی و محتوای لاگها دسترسی گسترده دارد.
نقش سفارشی چیست؟
نقش سفارشی برای زمانی است که نقشهای آماده یا زیادی باز هستند یا زیادی محدود. در بخش «نقشها» میتوانید نقش سفارشی ایجاد کنید، نام نمایشی بدهید و مجوزهای لازم را انتخاب کنید.
ایجاد نقش سفارشی ممکن است به پلن تجاری شما وابسته باشد. اگر این قابلیت در پلن فعال نباشد، پنل پیام ارتقا نمایش میدهد.
ساخت نقش سفارشی
- بخش «نقشها» را باز کنید.
- گزینه «ایجاد نقش» را انتخاب کنید.
- در «شناسه فنی»، مقدار پایدار وارد کنید؛ مثل
support_observer. - در «نام نمایشی»، نام خوانا بنویسید؛ مثل «ناظر پشتیبانی».
- در «توضیحات»، هدف نقش را کوتاه توضیح دهید.
- از فهرست «مجوزها»، فقط اختیارهای لازم را انتخاب کنید.
- نقش را ایجاد کنید.
نام نقش را بر اساس مسئولیت بسازید، نه نام فرد. support_observer بهتر از ali_role است، چون بعداً برای چند نفر قابل استفاده است.
گروههای مجوز
مجوزهای گدارAI در چند گروه اصلی قرار دارد:
| گروه | نمونه مجوزها | کاربرد |
|---|---|---|
| سیاستها | policy:list، policy:manage | مشاهده یا مدیریت سیاستهای زمان اجرا |
| نقشها | role:list، role:manage | مشاهده یا مدیریت نقشها |
| کاربران | user:list، user:manage | مشاهده، دعوت و مدیریت کاربران |
| تیمها | team:create، team:read، team:manage، team:delete | ساخت و مدیریت تیمها |
| واحدهای سازمانی | org_unit:create، org_unit:read، org_unit:manage، org_unit:delete، org_unit:list | مدیریت ساختار سازمانی |
| کاربران مجازی | virtual_account:create، virtual_account:read، virtual_account:manage، virtual_account:delete | مدیریت کاربر مجازی و VAT |
| حسابهای ارائهدهنده | provider_account:create، provider_account:read، provider_account:manage، provider_account:delete | مدیریت اتصالهای مدل |
| تنظیمات | settings:list، settings:manage | مشاهده یا تغییر تنظیمات فضای کاری |
| مالی | billing:read، billing:manage، billing:profile_manage، billing:documents_read، billing:codes_redeem | کیف پول، گزارش مالی، هویت مالی، اسناد و کدها |
| لاگ درخواستها | logs:read_metadata، logs:read_content، logs:export، logs:manage_views، logs:replay | مشاهده، خروجی و بازپخش امن لاگها |
در نام فنی مجوزهای کاربر مجازی، عبارت virtual_account باقی مانده است. در متن آموزشی، آن را به «کاربر مجازی و VAT» توضیح دهید.
مجوزهای لاگ را با احتیاط بدهید
بین این دو مجوز تفاوت مهمی وجود دارد:
| مجوز | سطح دسترسی |
|---|---|
logs:read_metadata | مشاهده فراداده، وضعیت، زمان، مدل، هزینه و خلاصه |
logs:read_content | مشاهده محتوای ذخیرهشده درخواست و پاسخ، در صورت اجازه سیاست ثبت داده |
logs:read_content میتواند به محتوای پرامپت، پاسخ مدل یا داده مشتری دسترسی بدهد. این مجوز را فقط به افراد یا نقشهایی بدهید که واقعاً به آن نیاز دارند.
نقشهای سیستمی را ویرایش کنیم؟
در گدارAI، نقشهای سیستمی برای شروع امن و قابل پیشبینی آماده شدهاند. برخی نقشهای سیستمی مثل proxy_admin و tenant_admin محافظتشدهاند و نباید مثل نقش عادی تغییر کنند.
اگر نیاز متفاوت دارید، بهجای تغییر نقشهای اصلی، نقش سفارشی بسازید.
نقش اصلی و مجوزهای مؤثر
یک کاربر ممکن است بیش از یک نقش داشته باشد. گدارAI برای نمایش، یک «نقش اصلی» انتخاب میکند؛ اما مجوزهای مؤثر از مجموع نقشها و عضویتهای معتبر محاسبه میشود.
اولویت نمایش نقش معمولاً از نقشهای پرقدرتتر شروع میشود؛ مثل tenant_admin، سپس org_admin، team_admin، member و readonly_member.
تفاوت نقش با مجوز عضو تیم
نقشها برای اختیارهای کلیتر هستند. مجوزهای عضو تیم برای عملیات محدود در همان تیم به کار میروند؛ مثلاً اجازه ساخت، ویرایش یا چرخش کلیدهای همان تیم.
قاعده عملی:
- اگر اختیار در کل فضای کاری اثر دارد، نقش مناسبتر است.
- اگر اختیار فقط داخل یک تیم لازم است، مجوز عضو تیم را بررسی کنید.
چند الگوی پیشنهادی
ناظر پشتیبانی
برای فردی که فقط باید وضعیت درخواستها را ببیند:
logs:read_metadatasettings:list- بدون
logs:read_contentمگر با نیاز واقعی
مدیر مالی
برای مسئول مالی:
- نقش
billing_manager - یا نقش سفارشی با مجوزهای مالی لازم
- بدون مجوزهای مدیریت نقش یا کاربر، مگر ضرورت سازمانی
اپراتور سرویسها
برای فردی که کاربر مجازی و VATها را مدیریت میکند:
virtual_account:readvirtual_account:manage- در صورت نیاز
virtual_account:create - دسترسی خواندن حساب ارائهدهنده، نه لزوماً مدیریت آن
پرسشهای پرتکرار
آیا بهتر است همه مدیران تیم tenant_admin باشند؟
خیر. اگر اختیار فرد فقط مربوط به یک تیم است، team_admin یا مجوزهای عضو تیم انتخاب امنتری است.
چرا نقش سفارشی باید حداقلی باشد؟
چون هر مجوز اضافه سطح ریسک را بالا میبرد. نقش خوب فقط همان کارهایی را مجاز میکند که برای وظیفه لازم است.
آیا logs:export همان logs:read_content است؟
خیر. خروجی گرفتن و دیدن محتوای ذخیرهشده دو اختیار جدا هستند. اگر خروجی شامل payload باشد، باید هم سیاست ثبت داده و هم مجوزهای مرتبط را جدی بررسی کنید.