دسترسی در ابزار مدیریت پروژه: چه کسی باید چه چیزی را ببیند

در این مقاله می‌خوانید

1. اول فهرست کنید: چه چیزی در ابزار پروژه حساس است
2. سه اصل که همه‌چیز از آن‌ها می‌آید
3. کمترین دسترسی لازم
4. نیاز به دانستن
5. جداسازی وظایف
6. نقش‌ها: ساده نگهشان دارید
7. تابلوها را بر اساس مرز دسترسی بچینید
8. تابلوی داخلی و تابلوی مشترک با مشتری
9. یک تابلو برای هر پیمانکار یا تیم بیرونی
10. تابلوی امنیتی جدا
11. کارهای مدیریتی و منابع انسانی جدا
12. پنهان کردن در رابط کاربری کافی نیست
13. چطور ابزار خودتان را آزمایش کنید
14. چرخهٔ عمر دسترسی: ورود، جابه‌جایی، خروج
15. ورود
16. جابه‌جایی
17. خروج
18. ردپا: لاگ فعالیت و بایگانی
19. ورود به حساب: در اصلی
20. داده کجا ذخیره می‌شود
21. چک‌لیست بازبینی فصلی
22. جمع‌بندی
23. منابع و مطالعهٔ بیشتر

تابلوی پروژه به‌مرور چیزهایی را در خود جمع می‌کند که کسی هنگام ساختنش فکرش را نکرده بود: قرارداد امضاشدهٔ مشتری در پیوست یک کارت، آدرس سرور آزمایشی در یک نظر، فهرست باگ‌های امنیتی که هنوز رفع نشده‌اند، بحث دربارهٔ قیمت پیشنهادی به مشتری بعدی. و هم‌زمان، فهرست اعضای تابلو هم به‌مرور بلند می‌شود: پیمانکاری که سه ماه پیش پروژه‌اش تمام شد، کارمندی که به تیم دیگری رفت، کسی از واحد فروش که یک بار برای دیدن یک کارت اضافه شد.

در بیشتر تیم‌هایی که دیده‌ام، دسترسی در ابزار مدیریت پروژه یک بار هنگام راه‌اندازی تنظیم می‌شود و بعد دیگر کسی به آن نگاه نمی‌کند. این راهنما دربارهٔ همان نگاه دوباره است: چه چیزهایی در ابزار پروژه حساس‌اند، نقش‌ها را چطور طراحی کنیم، تابلوها را چطور بر اساس مرز دسترسی بچینیم، چرا پنهان کردن در رابط کاربری کافی نیست، و یک چک‌لیست بازبینی فصلی که بشود واقعاً اجرایش کرد.

اول فهرست کنید: چه چیزی در ابزار پروژه حساس است

پیش از بحث دربارهٔ نقش‌ها، ببینید واقعاً چه چیزی را محافظت می‌کنید. این فهرست را برای ابزار فعلی‌تان مرور کنید:

• پیوست‌ها: قرارداد، پیش‌فاکتور، مستندات فنی مشتری، تصویر صفحه‌هایی که داده‌های واقعی کاربران را نشان می‌دهند.
• نظرها و توضیح کارت‌ها: جایی که آدم‌ها چیزهایی می‌نویسند که در سند رسمی نمی‌نویسند، از جمله، متأسفانه، گاهی رمز عبور و آدرس سرور.
• باگ‌های امنیتی: کارتی که توضیح می‌دهد چطور می‌شود از یک آسیب‌پذیری سوءاستفاده کرد، تا وقتی رفع نشده، خودش یک نقشهٔ حمله است.
• نام مشتری‌ها و جزئیات قرارداد: بعضی مشتری‌ها نمی‌خواهند حتی نامشان در ابزار پیمانکار دیده شود.
• نقشهٔ راه و برنامهٔ محصول: چیزی که رقیب دوست دارد ببیند.
• گفت‌وگوها: گفت‌وگوی تیمی و پیام مستقیم، که معمولاً از همه بی‌پرواترند.
• کارهای منابع انسانی: استخدام، ارزیابی، جابه‌جایی. این‌ها هرگز نباید در تابلویی باشند که کل تیم می‌بیند.

نتیجهٔ این فهرست معمولاً دو چیز است: چند تابلو که باید محدودتر شوند، و چند نوع اطلاعات که اصلاً نباید در ابزار پروژه باشند. رمز عبور جایش در مدیر رمز عبور است، نه نظر یک کارت؛ هر چقدر هم دسترسی تابلو محدود باشد. اگر قالب کارت‌هایتان جایی برای «اطلاعات اتصال» دارد، آن را حذف کنید. دربارهٔ اینکه یک کارت خوب چه چیزهایی باید و نباید داشته باشد، در مقالهٔ کارت خوب چه شکلی است نوشته‌ام.

سه اصل که همه‌چیز از آن‌ها می‌آید

کمترین دسترسی لازم

هر کس باید دقیقاً به آنچه برای کارش لازم است دسترسی داشته باشد، نه بیشتر. این اصل قدیمی امنیت است و در ابزار پروژه یعنی: عضویت پیش‌فرض در همهٔ تابلوها نه؛ نقش مدیر برای همه نه؛ «فعلاً اضافه‌اش کن، بعداً درستش می‌کنیم» نه، چون بعداً هرگز نمی‌رسد.

نیاز به دانستن

کسی که می‌تواند چیزی را ببیند، لزوماً نباید آن را ببیند. برنامه‌نویس پروژهٔ الف به تابلوی پروژهٔ ب نیاز ندارد، حتی اگر هر دو در یک شرکت باشند و «چیز محرمانه‌ای در آن نباشد». هر تابلوی اضافه در فهرست کسی، یعنی یک سطح دیگر که اگر حساب او به خطر بیفتد، لو می‌رود.

جداسازی وظایف

کسی که کار را انجام می‌دهد، لزوماً نباید کسی باشد که سوابقش را پاک می‌کند. برای همین، حذف دائمی و مدیریت اعضا باید در دست تعداد کمی باشد و تاریخچهٔ فعالیت نباید قابل‌ویرایش باشد.

نقش‌ها: ساده نگهشان دارید

اغلب ابزارها نقش‌ها را در سطح تابلو تعریف می‌کنند. یک مدل سه‌سطحی برای بیشتر تیم‌ها کافی است:

کار	مالک	مدیر	عضو
دیدن تابلو، کارت‌ها، نظرها و پیوست‌ها	بله	بله	بله
ساختن و جابه‌جا کردن کارت، نظر دادن	بله	بله	بله
ساختن و چیدن ستون‌ها	بله	بله	بسته به ابزار
افزودن و حذف اعضا	بله	بله	خیر
تغییر نقش دیگران	بله	محدود	خیر
بایگانی یا حذف کل تابلو	بله	خیر	خیر

این جدول یک الگوی رایج است، نه قانون؛ ابزار شما ممکن است مرزها را کمی متفاوت بکشد. آنچه مهم است این است که بدانید مرزها در ابزار شما کجاست. یک بار جدول بالا را برای ابزار خودتان پر کنید؛ اگر جایی جواب را نمی‌دانید، همان جا را آزمایش کنید.

دو توصیهٔ عملی:

• هر تابلو دست‌کم دو نفر با نقش مدیریتی داشته باشد. اگر تنها مالک تابلو به مرخصی برود یا از شرکت برود، کسی نمی‌تواند عضو تازه اضافه کند یا عضو قدیمی را بردارد.
• تعداد مدیرها را کم نگه دارید. دو یا سه نفر برای هر تابلو کافی است. «همه مدیرند» یعنی هیچ‌کس مسئول نیست.

تابلوها را بر اساس مرز دسترسی بچینید

بیشتر ابزارها دسترسی را در سطح تابلو کنترل می‌کنند، نه در سطح هر کارت. پس تصمیم «چه چیزی در کدام تابلو باشد» در واقع تصمیم دسترسی است. چند الگوی کاربردی:

تابلوی داخلی و تابلوی مشترک با مشتری

اگر مشتری باید پیشرفت را ببیند، یک تابلوی جداگانه برای او بسازید که فقط کارهای قابل‌اشتراک در آن است. بحث‌های داخلی، تخمین‌های هزینه و باگ‌هایی که هنوز نمی‌خواهید مشتری ببیند، در تابلوی داخلی می‌مانند. بله، این یعنی کمی کار دوباره؛ ولی جایگزینش این است که هر نفر هر بار پیش از نوشتن نظر فکر کند «آیا مشتری این را می‌بیند؟»، که دیر یا زود اشتباه می‌شود.

یک تابلو برای هر پیمانکار یا تیم بیرونی

پیمانکار را به تابلوی اصلی پروژه اضافه نکنید. یک تابلو با کارهای مربوط به او بسازید و هماهنگی را آنجا انجام دهید. وقتی کارش تمام شد، تابلو را بایگانی کنید و عضویتش را بردارید.

تابلوی امنیتی جدا

باگ‌های امنیتی را تا زمان رفع در تابلویی با اعضای محدود نگه دارید. بعد از رفع و انتشار، اگر لازم است، خلاصه‌ای در تابلوی اصلی ثبت شود.

کارهای مدیریتی و منابع انسانی جدا

استخدام، ارزیابی و بودجه، تابلوی خودشان را دارند. هرگز «یک ستون مخفی» در تابلوی تیم نسازید؛ اگر ابزار دسترسی در سطح ستون ندارد، آن ستون مخفی نیست.

همین منطق برای گفت‌وگو هم صادق است. گفت‌وگوی تابلو برای همهٔ اعضای آن تابلوست؛ بحثی که نباید همه ببینند، جایش آنجا نیست. دربارهٔ اینکه چه بحثی کنار کار بماند و چه بحثی جای دیگر، در مقالهٔ گفت‌وگو کنار کار بیشتر نوشته‌ام.

پنهان کردن در رابط کاربری کافی نیست

این مهم‌ترین بخش این راهنماست و کمتر از بقیه به آن توجه می‌شود. وقتی ابزاری می‌گوید «کاربران غیرعضو این تابلو را نمی‌بینند»، دو معنای کاملاً متفاوت می‌تواند داشته باشد:

1. تابلو در فهرست تابلوهای آن کاربر نمایش داده نمی‌شود، ولی اگر نشانی مستقیم یک کارت یا پیوست را داشته باشد، سرور آن را تحویل می‌دهد.
2. سرور برای هر درخواست، چه تابلو باشد، چه ستون، کارت، برچسب، نظر یا پیوست، بررسی می‌کند که درخواست‌کننده عضو آن تابلوست، و اگر نیست، هیچ داده‌ای برنمی‌گرداند.

فقط دومی کنترل دسترسی است. اولی پنهان کردن است. این اشتباه آن‌قدر رایج است که «کنترل دسترسی شکسته» در فهرست OWASP از مهم‌ترین ریسک‌های امنیتی وب است، و یکی از شکل‌های رایجش دقیقاً همین است: سرور فرض می‌کند اگر کاربر شناسهٔ یک شیء را دارد، اجازهٔ دیدنش را هم دارد.

چطور ابزار خودتان را آزمایش کنید

لازم نیست متخصص امنیت باشید. با دو حساب کاربری، یکی عضو یک تابلو و دیگری غیرعضو، این آزمایش‌ها را انجام دهید:

• با حساب عضو، نشانی یک کارت را از نوار مرورگر کپی کنید. با حساب غیرعضو، در مرورگر دیگری بازش کنید. چه می‌بینید؟
• همین کار را برای نشانی مستقیم یک پیوست انجام دهید. پیوست‌ها اغلب از مسیر جداگانه‌ای تحویل داده می‌شوند و گاهی بررسی دسترسی را دور می‌زنند.
• با حساب غیرعضو، در جست‌وجوی کلی ابزار، عبارتی را جست‌وجو کنید که می‌دانید فقط در آن تابلو هست.
• عضوی را از تابلو حذف کنید و ببینید آیا صفحه‌ای که از قبل در مرورگرش باز بود، هنوز به‌روزرسانی دریافت می‌کند.
• اعلان‌ها و ایمیل‌ها را بررسی کنید: آیا کسی که دیگر عضو نیست، هنوز خلاصهٔ تغییرات را دریافت می‌کند؟
• اگر ابزار امکان بیرون بردن داده دارد، ببینید چه کسانی می‌توانند کل داده‌های یک تابلو را بیرون ببرند.

اگر هر کدام از این آزمایش‌ها داده‌ای به حساب غیرعضو نشان داد، با فروشنده تماس بگیرید و تا رفعش، اطلاعات حساس را از آن ابزار بیرون نگه دارید. این آزمایش را در هنگام انتخاب نرم‌افزار مدیریت پروژه هم انجام دهید، نه فقط بعد از خرید.

در بردماگ این بررسی در سرور و برای هر درخواست انجام می‌شود: کسی که عضو یک تابلو نیست، نه آن تابلو را می‌بیند و نه ستون، کارت، برچسب، نظر یا پیوستی از آن را، حتی با داشتن نشانی مستقیم. با این حال، توصیه‌ام این است که آزمایش‌های بالا را روی هر ابزاری، از جمله ابزار ما، خودتان انجام دهید؛ ادعای فروشنده جای آزمایش را نمی‌گیرد.

چرخهٔ عمر دسترسی: ورود، جابه‌جایی، خروج

بیشتر نشت‌های دسترسی در ابزار پروژه نتیجهٔ حمله نیستند؛ نتیجهٔ فراموشی‌اند. دسترسی‌ها اضافه می‌شوند و هیچ‌وقت برداشته نمی‌شوند. چاره، یک چرخهٔ روشن است.

ورود

• عضو تازه فقط به تابلوهایی اضافه شود که از روز اول به آن‌ها نیاز دارد.
• نقش پیش‌فرض «عضو» است؛ نقش مدیریتی با دلیل و به‌صورت جداگانه داده می‌شود.
• حساب کاربری شخصی باشد. حساب مشترک («پشتیبانی» یا «کارآموز» که چند نفر رمزش را دارند) ردپا را بی‌معنی می‌کند و برداشتن دسترسی یک نفر را ناممکن.

جابه‌جایی

وقتی کسی از تیمی به تیم دیگر می‌رود، معمولاً به تابلوهای تازه اضافه می‌شود و از تابلوهای قدیمی حذف نمی‌شود. یک سال بعد، او به همهٔ تابلوهای شرکت دسترسی دارد. قاعده ساده است: جابه‌جایی یعنی هم افزودن و هم حذف، در همان روز.

خروج

خروج از شرکت یا پایان قرارداد پیمانکار باید یک چک‌لیست ثابت داشته باشد:

1. حساب کاربری غیرفعال شود، در همان روز آخر کار، نه هفتهٔ بعد.
2. عضویت در همهٔ تابلوها برداشته شود.
3. اگر فرد مالک تابلویی بود، مالکیت پیش از غیرفعال کردن به نفر دیگری منتقل شود.
4. کارت‌های باز او به نفر دیگری سپرده شوند، تا کاری بی‌صاحب نماند.
5. اگر به اطلاعات حساس دسترسی داشت (رمزها، کلیدها)، آن‌ها عوض شوند، حتی اگر فکر می‌کنید لازم نیست.

ردپا: لاگ فعالیت و بایگانی

کنترل دسترسی جلوی دیدن را می‌گیرد؛ ردپا به شما می‌گوید چه اتفاقی افتاده. هر دو لازم‌اند.

لاگ فعالیت باید به این پرسش‌ها جواب بدهد: چه کسی، چه زمانی، چه کاری روی کدام کارت کرد؟ چه کسی عضوی را اضافه یا حذف کرد؟ چه کسی تاریخ سررسید را عوض کرد؟ این لاگ نه فقط برای امنیت، که برای حل اختلاف‌های روزمره هم ارزشمند است: «من این کارت را جابه‌جا نکردم» با یک نگاه به لاگ تمام می‌شود.

بایگانی به‌جای حذف یعنی اشتباه قابل‌برگشت است. کسی که تصادفی یک ستون پر از کارت را پاک می‌کند، اگر ابزار بایگانی داشته باشد، یک دقیقه وقت از دست داده؛ اگر نداشته باشد، شاید هفته‌ها کار. حذف دائمی را به تعداد کمی از افراد محدود کنید و ترجیحاً فقط برای مواردی که قانون یا قرارداد آن را لازم می‌کند.

بردماگ برای هر تابلو لاگ فعالیت دارد و تابلو، ستون و کارت را بایگانی می‌کند، نه فقط حذف. هر ابزاری که انتخاب می‌کنید، این دو را پیش از نیاز آزمایش کنید.

ورود به حساب: در اصلی

بهترین طراحی نقش‌ها هم وقتی حساب یک نفر به خطر بیفتد بی‌اثر است. چند قاعدهٔ پایه:

• رمز عبور هر نفر برای این ابزار یکتا باشد و در مدیر رمز عبور نگه داشته شود.
• اگر ابزار ورود با کد یک‌بارمصرف (مثلاً پیامکی) دارد، برای کسانی که نقش مدیریتی دارند جدی بگیرید.
• شمارهٔ موبایل و ایمیل حساب‌ها به‌روز باشد، تا بازیابی رمز به دست صاحب حساب برسد، نه به شماره‌ای که دیگر مال او نیست.
• روی رایانه‌های مشترک از حساب خارج شوید.

داده کجا ذخیره می‌شود

کنترل دسترسی در خود ابزار فقط نیمی از تصویر است. نیم دیگر این است که داده‌ها روی چه سروری، در کدام کشور و زیر کنترل چه کسی‌اند. برای بعضی سازمان‌ها، الزام این است که داده‌های پروژه اصلاً از شبکهٔ داخلی بیرون نرود. اگر در این وضعیت هستید یا مطمئن نیستید، مقالهٔ نصب روی سرور خودتان یا ابری را بخوانید.

یک نکتهٔ دیگر برای وقتی که ابزار را عوض می‌کنید: داده‌های قدیمی در ابزار قبلی چه می‌شوند؟ اگر از ترلو یا ابزار دیگری مهاجرت کرده‌اید، پس از اطمینان از انتقال کامل، دسترسی‌ها را در ابزار قبلی هم ببندید؛ تابلوی فراموش‌شده‌ای که هنوز عضو دارد، همان ریسک قبلی را دارد. مراحلش را در راهنمای مهاجرت از ترلو آورده‌ام.

چک‌لیست بازبینی فصلی

هر سه ماه یک بار، یک ساعت در تقویم بگذارید و این‌ها را مرور کنید. بهتر است دو نفر با هم انجامش دهند: یکی که تیم را می‌شناسد و یکی که ابزار را.

1. فهرست همهٔ حساب‌های فعال را با فهرست کارکنان و پیمانکاران فعلی مقایسه کنید. هر حسابی که صاحبش دیگر با شما کار نمی‌کند، غیرفعال شود.
2. برای هر تابلوی فعال، فهرست اعضا را مرور کنید. هر عضوی که در سه ماه گذشته فعالیتی در آن نداشته، دلیلی برای ماندن دارد؟
3. نقش‌های مدیریتی را بشمارید. آیا هر تابلو دست‌کم دو و حداکثر چند مدیر دارد؟
4. تابلوهای پروژه‌های تمام‌شده را بایگانی کنید.
5. در نظرها و پیوست‌ها، رمز عبور، کلید یا اطلاعات اتصال جست‌وجو کنید. اگر پیدا شد، حذف شود و خود رمز هم عوض شود.
6. یکی از آزمایش‌های بخش «پنهان کردن کافی نیست» را دوباره انجام دهید، به‌خصوص اگر ابزار در این فاصله به‌روزرسانی شده.
7. نتیجه را با تاریخ ثبت کنید. بازبینی بعدی با مقایسه با همین فهرست سریع‌تر است.

این کار را می‌توانید به‌صورت یک کارت تکراری در تابلوی تیم مدیریت ثبت کنید، تا فراموش نشود. نکته‌های هماهنگی بیشتر در راهنمای همکاری در تیم نرم‌افزاری آمده است.

جمع‌بندی

دسترسی در ابزار مدیریت پروژه یک تنظیم یک‌باره نیست؛ یک عادت است. اول بدانید چه چیزی حساس است و چه چیزی اصلاً نباید در ابزار باشد. نقش‌ها را ساده و کم‌تعداد نگه دارید. تابلوها را بر اساس مخاطب بچینید، چون در بیشتر ابزارها تابلو مرز دسترسی است. ورود، جابه‌جایی و خروج افراد را با چک‌لیست انجام دهید و هر فصل یک بار همه‌چیز را بازبینی کنید.

و مهم‌تر از همه، فرق «پنهان» و «محافظت‌شده» را آزمایش کنید. با دو حساب و یک نشانی کپی‌شده، در چند دقیقه می‌فهمید ابزار شما واقعاً دسترسی را در سرور کنترل می‌کند یا فقط دکمه‌ها را پنهان کرده است. این چند دقیقه، ارزان‌ترین بیمه‌ای است که برای داده‌های پروژه می‌توانید بخرید.

منابع و مطالعهٔ بیشتر

• OWASP Top 10: A01 Broken Access Control — توضیح OWASP دربارهٔ کنترل دسترسی شکسته، شکل‌های رایج و راه پیشگیری.
• OWASP Authorization Cheat Sheet — اصول عملی پیاده‌سازی مجوز در سرور، از جمله «پیش‌فرض: رد» و بررسی در هر درخواست.
• OWASP API Security: Broken Object Level Authorization — همان خطای «شناسه را دارد، پس اجازه دارد» با مثال‌های واقعی.
• NIST Glossary: Least Privilege — تعریف مرجع اصل کمترین دسترسی.