دسترسی را با نقش، نوع نامه و اقدام تعریف کنید
برای تعریف سطح دسترسی در اتوماسیون اداری، فقط فهرست سمت‌ها کافی نیست. باید معلوم باشد چه کسی روی کدام نامه و در کدام وضعیت، اجازه مشاهده، ارجاع، ویرایش یا تأیید دارد. جانشینی نیز باید دامنه مشخص، زمان شروع و پایان و سابقه قابل پیگیری داشته باشد؛ در اختیار گذاشتن رمز مدیر، جانشینی قابل کنترل ایجاد نمی‌کند.
این راهنما برای مسئول اداری و مدیر پروژه است که می‌خواهند قواعد را پیش از تنظیم سامانه بنویسند. جدول‌ها و سناریوی آن پیشنهاد طراحی با داده فرضی‌اند؛ نه بیان امکانات تأییدشده همه محصولات. هدف، ادامه کار در غیاب مسئول همراه با محدودماندن دسترسی است.
پنج اختیار متفاوت را در یک گزینه جمع نکنید
مشاهده نامه با اجازه تصمیم‌گیری درباره آن یکسان نیست. ممکن است کارشناس برای پاسخ به استعلام نیاز به خواندن پیوست داشته باشد، اما اجازه تأیید هزینه یا ارسال نامه به بیرون سازمان را نداشته باشد. عبارت کلی «دسترسی کامل کارتابل» این تفاوت را پنهان می‌کند.
در راهنمای امنیتی OWASP، حداقل‌بودن اختیارات، رد دسترسی در نبود مجوز صریح و کنترل مجوز در هر درخواست توصیه شده است. کاربرد عملی برای این پروژه آن است که نبودن دکمه در صفحه را به‌تنهایی معیار امنیت ندانیم؛ بازکردن نشانی نامه یا پیوست هم باید با مجوز معتبر کنترل شود.
| اختیار | پرسش لازم پیش از تنظیم |
|---|---|
| مشاهده | فقط موضوع و شماره، یا متن و تمام پیوست‌ها؟ |
| ویرایش | پیش‌نویس خود کاربر، یا نسخه ثبت‌شده دیگران؟ |
| ارجاع و رونوشت | به کدام سمت یا واحد و با چه دامنه‌ای؟ |
| تأیید یا رد | کدام نوع درخواست و در کدام مرحله؟ |
| چاپ و خروجی | آیا دریافت فایل یا خروجی گروهی مجاز است؟ |
یک جدول اختیارات کوچک برای شروع بسازید
سناریوی فرضی زیر مربوط به درخواست خرید ملزومات یک واحد است. وضعیت نامه و رابطه کاربر با درخواست، در کنار سمت او اهمیت دارد. برای مثال، «کارشناس واحد» نباید به معنی دیدن تمام نامه‌های تمام کارشناسان باشد. محدودیت مالی یا محرمانگی را مطابق سیاست واقعی سازمان به جدول اضافه کنید.
برای هر خانه مبهم، یک تصمیم روشن ثبت کنید. اگر سامانه نمی‌تواند قاعده را اجرا کند، آن مورد باید پیش از استقرار به عنوان محدودیت یا توسعه موردنیاز مشخص شود.
| نقش در این سناریو | دامنه مجاز پیشنهادی | مرز اختیار |
|---|---|---|
| درخواست‌کننده | پیش‌نویس خود و مشاهده نتیجه درخواست | تأیید درخواست خودش مجاز نیست. |
| مدیر واحد | بررسی درخواست‌های واحد در مرحله مربوط | نامه واحد دیگر خارج از دامنه است. |
| جانشین موقت | بررسی درخواست‌های عادی تعیین‌شده در بازه مصوب | نامه مستثناشده و اختیار خارج از تفویض ممنوع است. |
| دبیرخانه | ثبت و مسیریابی در محدوده مسئولیت تعریف‌شده | ثبت شماره، مجوز تأیید محتوای نامه نیست. |
| مدیر سامانه | تنظیم دسترسی مطابق درخواست مصوب | نقش فنی به‌تنهایی نباید مجوز تصمیم اداری تلقی شود. |
جانشینی با ارجاع یک نامه چه تفاوتی دارد؟
ارجاع، مسئول انجام یک کار مشخص را تغییر می‌دهد. جانشینی می‌تواند اجازه اقدام روی مجموعه‌ای محدود از کارهای یک سمت را در یک بازه زمانی ایجاد کند. بنابراین پیش از تنظیم، روشن کنید قرار است فقط یک درخواست منتقل شود یا درخواست‌های جدید آن سمت هم به جانشین برسد.
برای نمونه، مستندات Power Automate امکان واگذاری یک درخواست تأیید به فرد دیگر را توضیح می‌دهد و میان اختیار تأییدکننده و درخواست‌کننده تفاوت می‌گذارد. این قابلیتِ یک ابزار مشخص، به معنی جانشینی کامل کارتابل یا وجود همان رفتار در اتوماسیون راهبرد نیست.
- سمت واگذارکننده، حساب شخص جانشین و مرجع تأیید جانشینی را تعیین کنید.
- تاریخ و ساعت شروع و پایان را همراه منطقه زمانی بنویسید؛ پایان روز اداری با پایان روز تقویمی یکسان نیست.
- دامنه را مشخص کنید: نامه‌های جدید، موارد در انتظار، نوع درخواست و واحد مربوط.
- موارد مستثنا مانند نامه محرمانه، پیوست محدود یا تأیید خاص را جدا بنویسید.
- تکلیف واگذاری دوباره به نفر سوم را تعیین کنید؛ در نمونه پیشنهادی این راهنما، بدون مجوز مستقل ممنوع است.
نمونه قابل آزمایش برای مرخصی مدیر
فرض کنید مدیر واحد از ساعت ۸ روز اول تا ساعت ۱۶ روز سوم غایب است. جانشین فقط می‌تواند درخواست خرید عادی همان واحد را بررسی کند؛ نامه محرمانه و درخواست متعلق به خود جانشین از این اختیار مستثنا هستند. برای این موارد باید مسیر جایگزین مصوب وجود داشته باشد تا کار بلاتکلیف نماند.
در محیط آزمایش، چهار نامه ساختگی بسازید: خرید عادی واحد، نامه محرمانه، درخواست واحد دیگر و درخواست خود جانشین. نتیجه مورد انتظار را پیش از اجرای دمو بنویسید. تنها مورد اول باید در دامنه اختیار جانشینی نمونه قرار بگیرد؛ برای بقیه، تصمیم جایگزین یا عدم دسترسی باید قابل مشاهده باشد.
در سابقه اقدام لازم است بتوان فهمید چه شخصی، به اتکای کدام اختیار جانشینی و در چه زمانی تصمیم گرفته است. نمایش صرف نام مدیر غایب، بدون مشخص‌بودن اقدام‌کننده واقعی، برای پیگیری این سناریو کافی نیست. این یک معیار پذیرش پیشنهادی است و باید در نسخه مورد بررسی آزموده شود.
پایان جانشینی را هم مثل شروع آن آزمایش کنید
قطع جانشینی فقط حذف نام از یک فهرست نیست. پس از پایان بازه، مجوز موقت باید در درخواست‌های تازه به سامانه دوباره ارزیابی شود. اگر جانشین از نقش اصلی خود مجوز مستقلی دارد، آن مجوز را با مجوز موقت اشتباه نگیرید؛ آزمون باید دقیقاً نشان دهد کدام اختیار از کدام نقش آمده است.
لغو دسترسی، فایل‌هایی را که پیش‌تر به‌طور مجاز دانلود شده‌اند از دستگاه کاربر پاک نمی‌کند. بنابراین درباره مجازبودن دانلود، محل نگهداری و جمع‌آوری نسخه‌های خارج سامانه هم تصمیم سازمانی لازم است. صرف پایان جانشینی را تضمین حذف تمام نسخه‌های اطلاعات معرفی نکنید.
- پیش از شروع بازه، تلاش برای اقدام جانشینی باید ناموفق باشد.
- در میانه بازه، درخواست مجاز و نامجاز را با حساب‌های آزمایشی جدا کنترل کنید.
- بعد از پایان بازه، همان نشانی ذخیره‌شده نامه و پیوست را دوباره درخواست کنید؛ صرف مشاهده تصویر قدیمی مرورگر معیار نیست.
- لغو زودهنگام جانشینی را نیز امتحان کنید؛ یک صفحه از قبل بازمانده نباید مجوز منقضی‌شده را معتبر کند.
- کارهای نیمه‌تمام را به مسئول مصوب بعدی برگردانید یا ارجاع دهید؛ از ساخت تصمیم نهایی تکراری جلوگیری شود.
چک‌لیست پذیرش برای جلسه دمو
این کنترل‌ها را فقط با حساب و اطلاعات ساختگی در محیط مجاز انجام دهید. نتیجه هر آزمون را با وضعیت مورد انتظار، شاهد و مسئول اصلاح ثبت کنید. مشاهده چند مسیر موفق جای ارزیابی امنیتی کامل را نمی‌گیرد؛ هدف این چک‌لیست، آشکارکردن اختلاف میان قواعد اداری و رفتار نسخه ارائه‌شده است.
| آزمون | نتیجه قابل قبول |
|---|---|
| کاربر نامرتبط نشانی مستقیم نامه را باز می‌کند | متن و پیوست خارج از مجوز نمایش داده نمی‌شود. |
| جانشین درخواست خودش را بررسی می‌کند | طبق قاعده نمونه، تأیید به مسیر مستقل می‌رود. |
| جانشینی منقضی یا لغو می‌شود | اختیار موقت در درخواست بعدی اعمال نمی‌شود. |
| مدیر و جانشین روی یک درخواست اقدام می‌کنند | رفتار هم‌زمانی مشخص است و تصمیم متناقض بی‌توضیح ثبت نمی‌شود. |
| سمت کاربر تغییر می‌کند | دسترسی قبلی بازبینی و اثر مجوزهای مستقل مشخص می‌شود. |
| سابقه اقدام مرور می‌شود | شخص اقدام‌کننده، زمان و مبنای اختیار قابل پیگیری است. |
برای بررسی اتوماسیون راهبرد چه چیزی آماده کنیم؟
یک مسیر پرتکرار، فهرست سمت‌ها و جدول اختیارات آن را همراه چند نامه کاملاً ساختگی آماده کنید. سپس موارد حساس مانند جانشینی، پیوست محدود و اقدام هم‌زمان را در جلسه بررسی مطرح کنید. فرایند داخلی کامل یا مکاتبات واقعی مشتری و کارکنان برای شروع لازم نیست.
اتوماسیون اداری راهبرد محصول موجود برای بررسی و ارائه متناسب با نیاز سازمان است. پشتیبانی از هر یک از قواعد این مقاله، از جمله جانشینی زمان‌دار و استثناهای دسترسی، باید در نسخه موجود تأیید شود؛ موارد نیازمند توسعه باید جداگانه در پیشنهاد همکاری بیایند.
اگر هنوز با کارتابل و مسیر گردش نامه آشنا نیستید، راهنمای مکمل «اتوماسیون اداری چیست؟ راهنمای انتخاب و بررسی دمو» را در بخش راهنماهای مرتبط بخوانید. برای بررسی امکان اجرای جدول اختیارات سازمان، از پیوند محصول یا درخواست بررسی نیاز همین صفحه استفاده کنید.
منابع و مطالعه بیشتر
تعریف‌ها و نکات فنی با منابع زیر بررسی شده‌اند؛ سناریوها و چک‌لیست‌ها پیشنهادهای این راهنما هستند.
