مدیریت دسترسی در Jira فقط اضافهکردن کاربر به یک گروه نیست. دسترسی باید با نقش، پروژه، حساسیت داده و lifecycle کاربر هماهنگ باشد. مدل نامناسب میتواند هم کار تیم را متوقف کند و هم اطلاعات پروژههای حساس را در معرض دید افراد نامرتبط قرار دهد.
چهار مفهوم را از هم جدا کنیم
Group مجموعهای از کاربران است و Project Role نقش آنها را در یک پروژه بیان میکند. Permission Scheme مشخص میکند چه نقش یا گروهی چه کاری میتواند انجام دهد. Issue Security نیز برای محدودکردن مشاهده بعضی issueها در همان پروژه استفاده میشود.
وقتی این لایهها با هم قاطی شوند، ادمین برای حل هر مورد یک گروه موقت میسازد و بعد از مدتی هیچکس نمیداند دلیل وجود آن چیست. نامگذاری، مالکیت و مستندکردن نقشها به اندازه تنظیم فنی مهم است.
اصل حداقل دسترسی
کاربر باید فقط دسترسی لازم برای نقش خود را داشته باشد. دسترسی Browse Projects، مشاهده issueهای حساس، ویرایش فیلدها و اجرای transitionها را جداگانه بررسی کنید. دسترسی ادمین را بهعنوان راهحل سریع برای خطاهای روزمره توزیع نکنید.
برای تیمهای چندگانه، roleهای پایدار مانند Developer، Product Owner، Reporter و Project Administrator معمولاً از گروههای اختصاصی متعدد قابل نگهداریتر هستند.
بازبینی و lifecycle
دسترسیها باید با ورود، جابهجایی و خروج افراد تغییر کنند. فهرست roleها، گروهها و service accountها را دورهای بازبینی کنید و برای دسترسیهای موقت تاریخ انقضا یا مالک مشخص داشته باشید.
پیش از تغییر گسترده، اثر آن را روی پروژههای متصل، automation، integration و گزارشها بررسی کنید. یک ماتریس ساده دسترسی میتواند جلوی تغییر ناخواسته چندین پروژه را بگیرد.
- مالک هر نقش و گروه
- منبع تأیید دسترسی
- دسترسیهای موقت و تاریخ بازبینی
- سناریوی rollback
پرسشهای متداول
آیا برای هر پروژه باید Permission Scheme جدا ساخت؟+
نه الزاماً. اگر چند پروژه الگوی دسترسی یکسان دارند، scheme مشترک نگهداری سادهتری دارد؛ پروژههای حساس باید استثنای مستند داشته باشند.