نمای کلی کاربران و دسترسی
در پایان این راهنما میدانید برای هر عضو تیم، هر سرویس و هر محیط کاری در گدارAI چه نوع هویت و سطح دسترسی تعریف کنید. هدف این بخش این است که از همان روز اول، دسترسیها قابل توضیح، قابل ابطال و قابل پایش باشند.
گدارAI فقط یک توکن برای عبور درخواست به مدل نمیدهد. هر درخواست با یک هویت، یک محدوده دسترسی، یک مسیر مصرف و یک سابقه قابل بررسی همراه است. این طراحی وقتی ارزشش را نشان میدهد که تیم پرداخت، تیم پشتیبانی و سرویس سفارش هرکدام باید با مدلها کار کنند، اما نباید همه به یک اندازه اختیار داشته باشند.
اگر فقط میخواهید یک درخواست آزمایشی بفرستید، از توکن دسترسی شخصی شروع کنید. اگر قرار است اپلیکیشن شما در محیط عملیاتی کار کند، از کاربر مجازی و VAT استفاده کنید.
مدل ذهنی ساده
در گدارAI هویت و دسترسی را با پنج پرسش طراحی کنید:
- چه کسی یا چه چیزی درخواست میفرستد؟
- این هویت به کدام تیم یا واحد سازمانی تعلق دارد؟
- چه نقشی دارد و چه مجوزهایی برایش لازم است؟
- از چه نوع توکنی استفاده میکند؟
- اگر دسترسی باید قطع شود، کدام توکن یا هویت را ابطال میکنید؟
پاسخ این پرسشها معمولاً شما را به این ساختار میرساند:
| نیاز | انتخاب پیشنهادی |
|---|---|
| ورود و کار با پنل | کاربر انسانی |
| آزمایش و توسعه فردی | توکن دسترسی شخصی (PAT) |
| اجرای سرویس، اتوماسیون یا پردازشگر | کاربر مجازی + کلید دسترسی مجازی (VAT) |
| تفکیک مسئولیت محصولی یا عملیاتی | تیم |
| تفکیک بخشهای بزرگ سازمان | واحد سازمانی |
| تعیین اختیار مدیریتی | نقش و مجوز |
مسیر پیشنهادی راهاندازی
۱. فضای کاری را از تیمها جدا ببینید
فضای کاری مرز اصلی داده، کاربران، اتصالها و سیاستهاست. تیم مرز کار روزمره است؛ مثلاً «تیم پرداخت»، «تیم پشتیبانی» یا «تیم داده». اگر همه چیز را فقط در سطح فضای کاری نگه دارید، بعداً مشخص کردن مالک مصرف، بودجه و توکنها سخت میشود.
۲. کاربران انسانی را دعوت کنید
در بخش «کاربران»، اعضای فضای کاری را با ایمیل دعوت کنید، نقش اولیه بدهید و بعد در صورت نیاز آنها را به تیمها اضافه کنید. نقش tenant_admin را برای افراد کمتعداد نگه دارید.
برای شروع یک تیم کوچک، معمولاً یک یا دو مدیر فضای کاری کافی است. بقیه افراد را با نقش «عضو» یا «عضو فقطخواندنی» وارد کنید و اختیارهای روزمره را از مسیر تیم بدهید.
۳. تیمها را بر اساس مالکیت واقعی بسازید
تیم خوب معمولاً صاحب یک محصول، سرویس، بودجه یا محدوده مدل است. برای مثال، اگر سرویس «پیگیری سفارش» و سرویس «پیشنهاد محصول» مصرف و مسئولیت متفاوت دارند، دو تیم جدا میتواند گزارش مصرف و ابطال توکن را سادهتر کند.
۴. برای سرویسها کاربر مجازی بسازید
سرویس عملیاتی نباید با توکن یک فرد کار کند. برای هر اپلیکیشن مهم یک کاربر مجازی بسازید، آن را به تیم مناسب وصل کنید و برایش VAT صادر کنید.
اگر سرویس محیط عملیاتی با PAT یک فرد کار کند، خروج آن فرد از سازمان یا ابطال توکن شخصی او میتواند سرویس را از کار بیندازد. برای سرویسهای پایدار از VAT استفاده کنید.
۵. نقشها و مجوزها را حداقلی نگه دارید
نقش، بستهای از مجوزهاست. مجوز، اختیار دقیق انجام یک کار است. بهتر است بهجای مدیرکردن افراد در سطح کل فضای کاری، برای هر نقش فقط مجوزهای لازم را انتخاب کنید.
یک مثال ملموس
فرض کنید یک فروشگاه آنلاین از گدارAI برای پاسخگویی به مشتریان استفاده میکند.
| بخش | طراحی پیشنهادی |
|---|---|
| مدیر فنی | کاربر انسانی با نقش tenant_admin |
| تیم پشتیبانی | تیم support-prod با اعضای پشتیبانی |
| سرویس پاسخگویی سفارش | کاربر مجازی order-support-api و یک VAT مستقل |
| گزارشگیر مالی | نقش سفارشی با مجوزهای مالی و مشاهده لاگ فراداده |
| کارآموز یا ناظر | readonly_member یا نقش سفارشی فقطخواندنی |
با این مدل، اگر سرویس پاسخگویی به مشکل خورد، فقط VAT همان سرویس را میچرخانید یا ابطال میکنید. اگر یکی از اعضای پشتیبانی جابهجا شد، سرویس از کار نمیافتد. اگر مصرف تیم بالا رفت، در لاگها و متریکها مالک درخواست روشن است.
از کدام صفحه ادامه بدهم؟
- برای شناخت مرزها، مدل فضای کاری، واحد سازمانی و تیم را بخوانید.
- برای دعوت و تغییر وضعیت افراد، مدیریت کاربران را ببینید.
- برای ساخت تیم و مدیریت اعضا، مدیریت تیمها را دنبال کنید.
- برای سرویسها و محیط عملیاتی، مدیریت کاربران مجازی و VAT را بخوانید.
- برای انتخاب نقش و مجوز، مدیریت نقشها و مجوزها را ببینید.
پرسشهای پرتکرار
آیا برای هر کاربر باید توکن جدا بسازم؟
برای آزمایش انسانی بله، هر فرد بهتر است PAT خودش را داشته باشد. برای سرویسها، توکن را به کاربر مجازی بدهید نه به فرد.
آیا تیم همان نقش است؟
خیر. تیم محدوده کار و مالکیت را مشخص میکند؛ نقش و مجوز مشخص میکنند کاربر چه کاری میتواند انجام دهد.
اگر فقط یک تیم داریم، باز هم کاربر مجازی لازم است؟
اگر سرویس یا اپلیکیشن شما قرار است بدون حضور یک فرد کار کند، بله. کاربر مجازی چرخه عمر سرویس را از چرخه عمر افراد جدا میکند.