کنترل دسترسی نقشمحور (RBAC) یعنی نقش تعیین میکند هر کس چه کاری میتواند بکند، نه خود شخص. برای یک تیم شبکههای اجتماعی به شش نقش نیاز دارید، نه بیست نقش: سازنده محتوا، ویرایشگر، تأییدکننده، منتشرکننده، تحلیلگر و ادمین. هر نفر را به حسابهای کلاینت مشخص محدود کنید تا کسی کارِ غیر از خودش را نبیند و بعد هم ثبت کنید چه کسی چه چیزی را تأیید کرده.
آژانسها معمولاً از دو جهت به خطا میروند. یا همه با یک لاگین مشترک وارد میشوند، یا هر پستی باید منتظر مدیرعامل بماند. هر دو را میشود در یک بعدازظهر حل کرد.
خلاصه: شش نقش، محدود به کلاینت، با تأیید بهعنوان دروازه و ثبت هر امضا. استثناهای فردبهفرد همان چیزی است که کل این مدل را غیرقابل مدیریت میکند.
شش نقشی که تقریباً همه تیمها را پوشش میدهد
| نقش | میتواند | نمیتواند |
|---|---|---|
| سازنده محتوا | پیشنویس پست، آپلود فایل | انتشار، اتصال حسابها |
| ویرایشگر | ویرایش هر پیشنویس در محدوده، ارسال برای تأیید | تأیید کار خودش |
| تأییدکننده | تأیید، رد و کامنت روی پیشنویسها | ویرایش حسابهای متصل |
| منتشرکننده | زمانبندی و انتشار پستهای تأییدشده | تأیید، افزودن کاربر |
| تحلیلگر | مشاهده تحلیلها، خروجی گزارش | دست زدن به محتوا |
| ادمین | اتصال حسابها، مدیریت کاربران و نقشها | هیچچیز؛ پس فقط دو نفر باشد |
دو قانون جلوی خراب شدن این مدل را میگیرد. هیچکس کار خودش را تأیید نمیکند و ادمین دقیقاً با دو نفر میماند تا همیشه یک نفر جایگزین باشد و هیچوقت کمیته تشکیل نشود.
در برابر دسترسیهای فردبهفرد مقاومت کنید. لحظهای که بگویید «سارا، ولی پنجشنبهها هم میتواند پست بگذارد»، سیستمی دارید که شش ماه بعد هیچکس نمیتواند حسابرسیاش کند. برای استثنا، نقش را موقتاً تغییر دهید و بعد برگردانید.
محدوده: بخشی که آژانسها اشتباه میکنند
نقش به تنهایی کافی نیست. سازنده محتوای کلاینت A نباید بتواند کلاینت B را ببیند. این محدوده است و اولین چیزی است که وقتی آژانس از یک لاگین مشترک بزرگتر میشود، میشکند.
محدوده را در سه محور تعریف کنید:
- کلاینت یا برند. مرز سخت. پیمانکار دقیقاً یکی میگیرد.
- کانال. کسی میتواند اینستاگرام و تیکتاک را مدیریت کند بدون اینکه به صفحه لینکدین شرکت دست بزند.
- مرحله. دسترسی به پیشنویس هرگز یعنی دسترسی به انتشار نیست.
این نیاز به جداسازی واقعی دارد، نه یک فیلتر. اگر پیمانکار بتواند انتخابگر حساب را عوض کند و به اینباکس کلاینت دیگری برسد، شما یک نمای پیشفرض دارید، نه ایزولهسازی. فضاهای کاری همان جایی است که Mydrop این خط را میکشد: هر کلاینت فضای خودش را دارد با اعضای خودش، تقویم خودش و حسابهای متصل خودش.
ذینفعان کلاینت مشکل دیگری هستند. بیشترشان اصلاً نباید کاربر باشند. یک پورتال کلاینت بدون لاگین به آنها اجازه میدهد محتوای خودشان را بازبینی و تأیید کنند، بدون صندلی، بدون رمز عبور و بدون سطح دسترسی که بعد از پایان پروژه تا ابد نگه دارید.
تأیید، دروازه است نه نردبان ارشدیت
دسترسیها مشخص میکنند چه کسی میتواند کاری بکند. تأییدها مشخص میکنند چه زمانی. این دو را جدا نگه دارید، وگرنه برای باز کردنِ یک پست جمعهشب مجبور میشوید آدمها را ادمین کنید.
مسیر را بر اساس ریسک بچینید، نه عنوان شغلی:
| محتوا | بازبینها |
|---|---|
| پستهای قالبی و تکراری | یک ویرایشگر |
| کمپین جدید یا ادعای جدید | مدیر کلاینت یا برند |
| محتوای قانونی، نظارتی یا بحرانی | بازبین حقوقی مشخص، بدون جایگزین |
برای دو ردیف اول یک تأییدکننده جایگزین بگذارید تا تعطیلات جلوی انتشار را نگیرد. ردیف سوم واقعاً باید مسدود کند. جریانهای تأیید پست را نگه میدارند تا امضاها کامل شوند؛ اینطوری «تأییدشده» و «منتشرشده» یک رکورد واحد میشوند، نه دو لیست که باید با دست هماهنگ کنید.
لاگ حسابرسی شما باید چه چیزی ثبت کند
«کی این را عوض کرد؟» همیشه در بدترین لحظه ممکن میرسد و لاگی که فقط وضعیت فعلی را ذخیره میکند نمیتواند جوابش را بدهد.
برای هر اقدام پنج مورد را ثبت کنید:
- چه کسی انجامش داد، بهعنوان یک شخص مشخص و هرگز یک حساب مشترک.
- در آن لحظه چه نقشی داشت. آدمها نقششان عوض میشود و لاگی که نقش را هنگام خواندن حل میکند، بیسروصدا تاریخ را بازنویسی میکند.
- چه چیزی تغییر کرد، با نسخه قبلی که هنوز قابل خواندن باشد.
- کی، با ذکر منطقه زمانی.
- تحت کدام تأیید منتشر شد.
دو قانون عملی. سوابق تأیید را طولانیتر از لاگهای عملیاتی نگه دارید، چون تأیید همان چیزی است که در عمل همه دنبالش هستند. و آنها را بر اساس کلاینت و بازه زمانی قابل جستجو کنید، چون هر درخواست حسابرسی دقیقاً با این شکل میآید.
مقایسه فروشندهها از این نظر ساده است: از هر کدام بخواهید تاریخچه تأیید یک پست مشخص از سه ماه پیش را بالا بیاورد. یا در دمو وجود دارد یا ندارد.
قبل از خرید چه چیزهایی را چک کنید
ویژگیهایی که یک مدل دسترسی واقعی را از یک صفحه تنظیمات جدا میکند:
- نقشها برای هر کلاینت قابل تعریف باشند، نه یک نقش سراسری برای هر کاربر.
- ایزولهسازیای که از تغییر حساب جان سالم به در ببرد، با یک لاگین واقعی پیمانکار تست شده باشد.
- مسیر تأیید با بازبینهای مشخص و جایگزین تعریفشده.
- تاریخچه تأیید قابل خروجیگرفتن برای یک پست واحد.
- دسترسی بازبین بدون صندلی، تا امضای کلاینت هزینه لایسنس نداشته باشد.
- SSO و مدیریت دایرکتوری اگر واحد IT فهرست کاربران شما را مدیریت میکند. بیشتر ابزارهای شبکههای اجتماعی این را برای پلنهای سازمانی نگه میدارند؛ پس در اولین تماس بپرسید، نه در مرحله قرارداد.
Planable و Sprout Social هر دو تأیید چندمرحلهای با نقشهای مشخص را پشتیبانی میکنند. Mydrop فضاهای کاری هر کلاینت، نقشها، کامنت روی خود پیشنویس، دروازههای تأیید و لینک بازبینی بدون لاگین را در یک سیستم جمع میکند؛ ترکیبی که آژانسها معمولاً از دو ابزار جداگانه میسازند. برای بقیه چیدمان عملیاتی دور و برش، صفحه آژانسهای شبکههای اجتماعی پشته کاملتر را پوشش میدهد.
همین هفته راهاندازی کنید
سه قدم، به همین ترتیب:
- فهرست همه کسانی که امروز میتوانند پست بگذارند را بنویسید. پیمانکاران سابق و لاگین مشترک را هم حساب کنید. فهرست همیشه بلندتر از چیزی است که انتظارش را دارید.
- به هر نفر یک نقش واحد و یک محدوده کلاینت واحد بدهید. در دور اول هیچ استثنایی قائل نشوید.
- ذینفعان کلاینت را به لینک بازبینی منتقل کنید و حساب کاربریشان را حذف کنید.
یک یادآوری ۹۰ روزه در تقویم بگذارید تا قدم اول را دوباره بردارید، چون دسترسی قدیمی همان خطایی است که هر بار برمیگردد. میتوانید رایگان شروع کنید و قبل از شروع کمپین بعدی، نقشها و فضاهای کاری کلاینتها را نقشه بکشید.
بررسی گوگل
بررسی Trustpilot
Product Hunt comment
