از یک جریان کامل کسب‌وکار آغاز کنید
فرض کنید شرکتی در چند منطقه فعالیت می‌کند. فروش، مشخصات مشتری را در سامانه ثبت می‌کند، پیشنهاد قیمت را ایمیل می‌زند، سفارش را به مالی می‌فرستد و تحلیلگر گزارش می‌گیرد. داده علاوه بر پایگاه اصلی در پیوست، پوشه مشترک، حافظه موقت رابط و پشتیبان نیز وجود دارد. برچسب‌گذاری سامانه اصلی، نسخه‌های دیگر را پوشش نمی‌دهد. ابتدا جریانی انتخاب کنید که مبدأ، گیرندگان و شرط پایان آن قابل پیگیری باشد؛ چنین محدوده‌ای از ارسال جدول خالی به همه واحدها آزمون‌پذیرتر است.
مسئول پروژه همراه کارکنان کسب‌وکار مسیر را طی کند و موضوع داده، محل، هدف استفاده، گیرنده، شرط نگهداری و مالک پاسخ‌گو را ثبت کند. یک سامانه معادل یک نوع داده نیست: کاتالوگ عمومی، اطلاعات تماس مشتری و قیمت منتشرنشده ممکن است در یک بستر باشند اما کنترل متفاوت بخواهند. مشخص کنید چه کسی هر مورد را تأیید کرده و کدام بخش هنوز روشن نیست؛ فرض نباید به‌صورت موجودی تأییدشده ثبت شود.
خروجی این مرحله فهرست جریان با محدوده روشن است، نه طبقه‌بندی نهایی کل شرکت. مالک کسب‌وکار دامنه را تأیید کند، مدیر سامانه مسیر ذخیره و انتقال را بررسی کند و تیم امنیت اشتراک بیرونی و خروجی انبوه را مشخص کند. برای داده بی‌مالک، مسئول موقت و موعد رسیدگی تعیین کنید؛ بی‌مالک بودن مجوز دسترسی همگانی نیست.
پیش از انتخاب برچسب، پیامد را بسنجید
پیامد افشا، تغییر نادرست و در دسترس نبودن را جداگانه بررسی کنید. FIPS 199 مؤسسه NIST طبقه‌بندی امنیتی را با محرمانگی، یکپارچگی، دسترس‌پذیری و اثر احتمالی مرتبط می‌کند، اما دامنه آن اطلاعات و سامانه‌های فدرال آمریکا است. شرکت می‌تواند از روش تحلیل الهام بگیرد، بدون آنکه آن را فهرست الزام‌آور همه کشورها و صنایع بداند. مراحل این مقاله پیشنهاد اجرایی JOTOglobal است، نه تأیید انطباق.
برای نمونه، خواندن قالب عمومی قیمت شاید محدودیت کمی بخواهد، اما دستکاری اطلاعات پرداخت همچنان به کسب‌وکار آسیب می‌زند. سفارش عادی ممکن است بسیار محرمانه نباشد ولی توقف طولانی آن پذیرفتنی نباشد. از کارکنان بخواهید کار، افراد و روش جایگزین متأثر را توضیح دهند؛ «خیلی مهم است» کافی نیست. نام سطوح می‌تواند مطابق سیاست موجود باشد، به شرط آنکه استدلال بین واحدها توضیح‌پذیر و قابل بازبینی باشد.
اثر تجمیع و تغییر کاربرد را جدا ثبت کنید. خطر یک رکورد با فایل جامع روابط مشتری لزوماً یکسان نیست. انتقال داده پشتیبانی داخلی به پیمانکار بیرونی نباید صرفاً برچسب قبلی را به ارث ببرد. امنیت دلیل تصمیم را مستند کند و مالک کسب‌وکار نیاز را تأیید کند. بررسی مقررات بخشی، اطلاعات شخصی یا پردازش فرامرزی با متخصص مناسب است؛ برچسب خودکار نتیجه حقوقی ایجاد نمی‌کند.
طبقه‌بندی را به مجوز عملیاتی تبدیل کنید
برای هر دسته داده قاعده‌ای تعیین کنید: چه کسی بخواند، تغییر دهد، خروجی بگیرد، به چه کسی بفرستد و چه کسی استثنا را تأیید کند. در مثال فرضی قیمت، فروش قیمت جاری را می‌خواند، تأییدکننده تخفیف را تغییر می‌دهد و شریک نسخه تأییدشده می‌گیرد. پوشه مشترک دلیل مجوز یکسان نیست. قواعد باید رابط وب، API و فایل خروجی را پوشش دهند، نه فقط دکمه یک صفحه را.
مدیر سامانه قواعد را به نقش، گروه یا شرط مبتنی بر ویژگی نگاشت کند و ارتباط تنظیمات با تصمیم کسب‌وکار را نگه دارد. لینک اشتراک، گیرندگان و شرط انقضای مشخص بخواهد و دسترسی همکار موقت نیز در پایان رسیدگی شود. برای نگهداری پشتیبان و مجوز پس از بازیابی مسئول تعیین کنید. حذف داده جاری لزوماً نسخه‌ها را پاک نمی‌کند و بازیابی موفق هم مسدود ماندن حساب قدیمی را ثابت نمی‌کند. هر کنترل اجرا‌نشده باید شکاف قابل پیگیری باشد.
کنترل را با کار واقعی بیازمایید
پذیرش به تصویر نمایش برچسب محدود نشود. نماینده کسب‌وکار نمونه پالایش‌شده آماده کند و با حساب کارمند عادی، تأییدکننده، همکار بیرونی و فرد جداشده، خواندن، تغییر، خروجی و اشتراک را بیازماید. هم موفقیت کار مجاز و هم شکست عمل ممنوع را ثابت کنید. پاسخ سرور و سابقه ممیزی را ببینید؛ مخفی بودن دکمه اثبات کنترل مجوز نیست. بدون تأیید از داده حساس واقعی برای آزمون استفاده نکنید.
یک انتقال نسخه یا بازیابی را نیز امتحان کنید تا روشن شود مجوز همراه جریان داده مؤثر می‌ماند. نوع حساب، شناسه نمونه، نتیجه مورد انتظار و واقعی، محل لاگ و بازبین را ثبت کنید، نه جزئیات مشتری یا اعتبارنامه را. مدیر سامانه مغایرت را اصلاح کند، مالک کسب‌وکار امکان ادامه کار لازم را تأیید کند و بازبین مستقل همان آزمون را تکرار کند. بستن ایراد به مدرک نیاز دارد، نه اطمینان شفاهی.
برای استثنا و تغییر مسئول تعیین کنید
هنگام تحویل، فهرست جریان، دلیل طبقه‌بندی، نگاشت قواعد، شواهد آزمون و موارد باز را با هم ارائه کنید. مالک کسب‌وکار مسئول تغییر هدف و گیرندگان، مدیر مسئول تنظیمات، امنیت مسئول پوشش کنترل و نشانه‌های غیرعادی، و مسئول پروژه متولی برنامه بازبینی است. مجوز موقت دلیل، دامنه، تأییدکننده، مدت و شرط لغو بخواهد. فوریت نباید به معافیت دائمی بی‌پایان تبدیل شود.
رابط تازه، ادغام واحدها، تغییر گیرنده بیرونی، تجمیع انبوه یا تغییر بازیابی باید بازبینی محدوده مربوط را فعال کند، نه اینکه تا بررسی سالانه منتظر بماند. ابتدا تغییر جریان و سپس اعتبار فرض‌های مجوز را بررسی کنید. برای برچسب پیشنهادی ابزار خودکار، تأیید انسانی و سابقه اصلاح نگه دارید. ابزار می‌تواند موارد جاافتاده را پیدا کند، اما جای توضیح کسب‌وکار درباره علت حفاظت را نمی‌گیرد.
پیشرفت را با شواهد کنترل بسنجید
اشتباه رایج، دادن بالاترین سطح به همه داده‌ها یا سنجیدن پیشرفت فقط با تعداد فایل برچسب‌خورده است. محدودیت افراطی ممکن است راه میان‌بر ایجاد کند و شمار برچسب خطر نسخه و خروجی را نشان نمی‌دهد. موضوعات دارای مالک تأییدشده، کنترل نگاشت‌شده و آزمون موفق را با دامنه آمار و مسیرهای پوشش‌نداده ثبت کنید. این شاخص داخلی را به درصد اثبات‌نشده کاهش خطر تبدیل نکنید.
این روش برای کامل کردن چرخه یک سناریوی کسب‌وکار است و جای فهرست طبقه‌بندی بخشی، ارزیابی قرارداد یا بررسی تخصصی انطباق را نمی‌گیرد. پس از پذیرش مرحله، به جریان بعدی بروید و قواعد آزموده را دوباره استفاده کنید. مدیریت باید بداند دلیل طبقه‌بندی چیست، چه کسی دسترسی را تأیید کرده، استثنا چه وقت پایان می‌یابد و کدام مدرک کارکرد کنترل را نشان می‌دهد. پاسخ‌گویی مداوم به این پرسش‌ها فهرست را به ابزار عملیاتی تبدیل می‌کند.
منابع
NIST FIPS 199: https://csrc.nist.gov/pubs/fips/199/final