راهنمای عملی اجرای سیاستهای امنیتی در سازمان
خلاصهٔ کاملتر
این یادداشت نسخهی نوشتاری یک سخنرانی در BSidesSeattle است و به یک حقیقت مهم اشاره میکنه: تیمهای امنیتی مدام سیاست تعریف و اجرا میکنن، اما تعریف سیاست بخش آسون ماجراست؛ بخش سخت، دانستن این است که واقعاً چه چیزی قابلاجراست و بعد اجرای آن.
گام اول، گرفتن ورودی است. معمولاً بین «سیاست» (چیزی که میخوای درست باشه، مثل بازبینی همتا روی تغییرات production) و «کنترل» (نحوهی اجرا، مثل قواعد branch protection) فاصلهای برای تفسیر وجود داره. باید از کسانی که قراره با این کنترلها زندگی کنن (مهندسی، محصول، SRE برای production و IT برای سیاستهای سازمانی) ورودی بگیری؛ آنها میخوان بدونن «چقدر طول میکشه؟» و مهمتر «وقتی خراب شد کی پاسخگوست؟».
گام بعد، اطلاعرسانیه؛ خیلی بیشتر از آنچه فکر میکنی و از چند راه (ایمیل، اسلک، جلسات). قبل، حین و بعد از اجرا بگو چه چیزی، کِی و مهمتر از همه «چرا» تغییر میکنه. مردم با اصطکاک کنار میان اگه دلیلش را بفهمن و وقتی نفهمن وسوسه میشن دورش بزنن.
بعد، پایلوت. همانطور که تغییر را بدون تست به production نمیفرستی، به کاربرها هم نفرست. یک پایلوت خوب چند عنصر داره: گروهی نماینده و متنوع از کاربران واقعی (نقشها، دستگاهها و سیستمعاملهای مختلف)، بازهی زمانی مناسب (سیاستی که هر ۹۰ روز نیاز به تأیید داره را نمیشه در دو هفته تست کرد)، یک کانال پشتیبانی، و معیار موفقیت روشن برای تصمیم go/no-go. سپس بر اساس بازخورد تکرار میکنی؛ اگه کاربرها راهی برای دور زدن کنترل پیدا کنن، یعنی سیاستت کار نمیکنه.
در اجرا، نویسنده چند توصیه داره: اجرای سیاست را قابلمشاهده کن (نشاندادن مقایسهی کاربر با همتایانش مؤثره)، کسی که سیاست را تعریف کرده باید مجریاش باشه تا درد اصطکاک را حس کنه، و برای استثناها از همان ابتدا برنامه داشته باش، چون همیشه استثنا هست (کاربران دارای معلولیت، کشورهای خاص، دستگاههای دمو، گردشکارهای خودکار).
نکات کلیدی:
- تعریف سیاست آسونه؛ سختی در قابلاجرا بودن و اجرای واقعی است
- از ذینفعان ورودی بگیر و «چرا»ی تغییر را فراوان اطلاعرسانی کن
- پایلوت با کاربران واقعی متنوع، بازهی کافی و معیار موفقیت روشن
- اجرای قابلمشاهده، مسئولیت مجری=تعریفکننده، و مدیریت همیشگی استثناها
