اکنون من برای یک شرکت فروشنده نرم افزار کار می کنم، به ویژه راه حل های کنترل دسترسی. و تجربه من "از زندگی گذشته" با طرف مشتری - یک موسسه مالی بزرگ - مرتبط است. در آن زمان، گروه کنترل دسترسی ما در بخش امنیت اطلاعات نمی توانست از شایستگی های بزرگ در IdM ببالد. ما در این فرآیند چیزهای زیادی یاد گرفتیم، مجبور شدیم دسته ای از دست اندازها را پر کنیم تا مکانیزمی کارآمد برای مدیریت حقوق کاربر در سیستم های اطلاعاتی در شرکت ایجاد کنیم.
با ترکیب تجربیاتم در مشتری با دانش و شایستگی های فروشنده، می خواهم اساساً یک دستورالعمل گام به گام را با شما به اشتراک بگذارم: چگونه یک مدل کنترل دسترسی مبتنی بر نقش در یک شرکت بزرگ ایجاد کنید، و چه چیزی در پایان. دستورالعمل من شامل دو بخش است: اول - ما در حال آماده شدن برای ساخت یک مدل هستیم، دوم - ما در واقع آن را می سازیم. قبل از قسمت اول، مقدماتی.
NB متأسفانه ساختن یک الگو یک نتیجه نیست، بلکه یک فرآیند است. یا بهتر بگوییم، حتی بخشی از فرآیند ایجاد یک اکوسیستم کنترل دسترسی در شرکت. بنابراین برای مدت طولانی با بازی هماهنگ شوید.
ابتدا اجازه دهید تعریف کنیم - کنترل دسترسی مبتنی بر نقش چیست؟ فرض کنید یک بانک بزرگ با ده ها یا حتی صدها هزار کارمند (سوژه) دارید که هر کدام ده ها حق دسترسی به صدها سیستم اطلاعاتی درون بانکی (اشیاء) دارند. و اکنون تعداد اشیاء را در تعداد سوژه ها ضرب کنید - این همان تعداد اتصال است که حداقل باید ابتدا بسازید و سپس کنترل کنید. آیا واقعا می توان آن را به صورت دستی انجام داد؟ البته نه - نقش ها برای حل این مشکل ظاهر شدند.
نقش مجموعه ای از مجوزهایی است که یک کاربر یا گروهی از کاربران برای انجام وظایف کاری خاص به آن نیاز دارند. هر کارمند می‌تواند یک یا چند نقش داشته باشد و هر نقش می‌تواند شامل یک تا چندین مجوز باشد که به یک کاربر در آن نقش مجاز است. نقش‌ها را می‌توان به موقعیت‌ها، بخش‌ها یا وظایف عملکردی کارمندان مرتبط کرد.
نقش ها معمولاً از مجوزهای فردی کارکنان در هر سیستم اطلاعاتی ایجاد می شوند. سپس نقش های تجاری جهانی از نقش های هر سیستم شکل می گیرد. به عنوان مثال، یک نقش تجاری مدیر اعتبار شامل چندین نقش جداگانه در سیستم های اطلاعاتی است که در دفتر مشتری بانک استفاده می شود. بیایید بگوییم، مانند سیستم اصلی بانکی خودکار، صندوق، سیستم مدیریت اسناد الکترونیکی، مدیر خدمات و غیره. نقش های تجاری، به عنوان یک قاعده، به ساختار سازمانی گره خورده است - به عبارت دیگر، به مجموعه ای از بخش ها و موقعیت های شرکت در آنها. به این ترتیب ماتریس نقش جهانی تشکیل می شود (در جدول زیر مثالی می زنم).
شایان ذکر است که ساختن یک الگوی 100٪ به سادگی غیرممکن است و تمام حقوق لازم را برای کارکنان هر موقعیت در یک ساختار تجاری فراهم می کند. بله، این لازم نیست. به هر حال، الگو نمی تواند ثابت باشد، زیرا به محیط دائما در حال تغییر بستگی دارد. و از تغییر در فعالیت های تجاری شرکت که بر این اساس بر تغییر ساختار و عملکرد سازمانی تأثیر می گذارد. و از عدم تامین کامل منابع و از عدم رعایت شرح وظایف و از سودجویی به قیمت امنیت و از بسیاری عوامل دیگر. بنابراین لازم است الگویی ساخته شود که بتواند تا 80 درصد نیازهای کاربران را به حقوق اولیه ضروری در هنگام منصوب شدن در سمتی پوشش دهد. و 20٪ باقیمانده آنها می توانند در صورت لزوم بعداً در برنامه های جداگانه بازجویی کنند.
البته، می توانید بپرسید: "چی، اصلاً الگوی 100٪ وجود ندارد؟" خوب، چرا، این اتفاق می افتد، به عنوان مثال، در ساختارهای غیر انتفاعی که در معرض تغییرات مکرر نیستند - در برخی از موسسات تحقیقاتی. یا در سازمان های مجتمع نظامی-صنعتی با امنیت بالا که امنیت حرف اول را می زند. این اتفاق می افتد، و در یک ساختار تجاری، اما در چارچوب یک واحد واحد، که کار آن یک فرآیند نسبتا ایستا و قابل پیش بینی است.
مزیت اصلی مدیریت نقش، ساده سازی صدور حقوق است، زیرا تعداد نقش ها به طور قابل توجهی کمتر از تعداد کاربران سیستم اطلاعاتی است. و این برای هر صنعتی صادق است.
بیایید یک شرکت خرده فروشی را در نظر بگیریم: این شرکت هزاران فروشنده را استخدام می کند، اما آنها مجموعه حقوق یکسانی در سیستم N دارند و تنها یک نقش برای آنها ایجاد می شود. یک فروشنده جدید به شرکت آمد - به طور خودکار نقش لازم در سیستم را که قبلاً تمام اختیارات لازم را دارد به او اختصاص داده شد. همچنین با یک کلیک می توانید حقوق هزاران فروشنده را به طور همزمان تغییر دهید، به عنوان مثال گزینه جدیدی برای تولید گزارش اضافه کنید. شما نیازی به انجام هزار عملیات ندارید، یک حق جدید را به هر حساب پیوند دهید - فقط این گزینه را به نقش اضافه کنید و برای همه فروشندگان به طور همزمان ظاهر می شود.
یکی دیگر از مزایای مدیریت مبتنی بر نقش، اجتناب از مجوزهای ناسازگار است. یعنی کارمندی که نقش خاصی در نظام دارد نمی تواند همزمان نقش دیگری داشته باشد که حقوق آن با حقوق اولی تلفیق نشود. یک مثال واضح ممنوعیت ترکیب عملکردهای ورودی و کنترل یک تراکنش مالی است.
هر کسی که علاقه مند به چگونگی ایجاد کنترل دسترسی مبتنی بر نقش در وهله اول است، می تواند
شیرجه رفتن به تاریخ
اگر به تاریخ بپردازیم، برای اولین بار جامعه فناوری اطلاعات در مورد روش های کنترل دسترسی در دهه 70 قرن بیستم فکر کرد. اگرچه برنامه ها در آن زمان بسیار ساده بودند، اما، مانند اکنون، همه واقعاً می خواستند به راحتی دسترسی به آنها را مدیریت کنند. اعطا، تغییر و کنترل حقوق کاربر - فقط برای اینکه درک دسترسی هر یک از آنها آسانتر باشد. اما در آن زمان استانداردهای مشترکی وجود نداشت، اولین سیستم های کنترل دسترسی در حال توسعه بود و هر شرکتی بر اساس ایده ها و قوانین خاص خود بود.
بسیاری از مدل‌های کنترل دسترسی مختلف اکنون شناخته شده‌اند، اما بلافاصله ظاهر نشدند. اجازه دهید در مورد کسانی که سهم ملموسی در توسعه این مسیر داشته اند صحبت کنیم.
اولین و احتمالا ساده ترین مدل است کنترل دسترسی اختیاری (انتخابی). (DAC - کنترل دسترسی اختیاری). این مدل مستلزم اشتراک حقوق توسط همه شرکت کنندگان در فرآیند دسترسی است. هر کاربر به اشیا یا عملیات خاصی دسترسی پیدا می کند. در واقع در اینجا مجموعه موضوعات حقوق با مجموعه اشیاء مطابقت دارد. مشخص شد که این مدل بسیار انعطاف‌پذیر و نگهداری آن بسیار دشوار است: فهرست‌های دسترسی به مرور زمان بسیار بزرگ و کنترل آن دشوار می‌شود.
مدل دوم است کنترل دسترسی اجباری (MAC). طبق این مدل، هر کاربر مطابق با دسترسی صادر شده به سطح خاصی از محرمانه بودن داده، به شی دسترسی پیدا می کند. بر این اساس، اشیا باید بر اساس میزان محرمانه بودن دسته بندی شوند. برخلاف اولین مدل انعطاف پذیر، برعکس، این یکی بیش از حد سختگیر و محدود کننده بود. استفاده از آن زمانی که شرکت دارای منابع اطلاعاتی بسیار متنوعی است خود را توجیه نمی کند: برای محدود کردن دسترسی به منابع مختلف، باید دسته های زیادی را معرفی کنید که همپوشانی ندارند.
با توجه به نقص آشکار این دو روش، جامعه فناوری اطلاعات به توسعه مدل هایی ادامه داده است که انعطاف پذیرتر و در عین حال کم و بیش جهانی برای حمایت از انواع مختلف سیاست های کنترل دسترسی سازمانی هستند. و این زمانی بود که ظاهر شد مدل سوم کنترل دسترسی مبتنی بر نقش! این رویکرد امیدوارکننده ترین بود، زیرا نه تنها به مجوز هویت کاربر، بلکه به عملکردهای کاری وی در سیستم ها نیز نیاز دارد.
اولین ساختار الگوی نقش توصیف شده توسط دانشمندان آمریکایی دیوید فریلو و ریچارد کوهن از موسسه ملی استاندارد و فناوری ایالات متحده در سال 1992 ارائه شد. سپس این اصطلاح برای اولین بار ظاهر شد RBAC (کنترل دسترسی مبتنی بر نقش). این مطالعات و توصیف اجزای اصلی و همچنین روابط آنها، اساس استاندارد INCITS 359-2012 را تشکیل داد که تا به امروز معتبر است و مورد تایید کمیته بین المللی استانداردهای فناوری اطلاعات (INCITS) است.
این استاندارد نقش را اینگونه تعریف می‌کند: «یک کارکرد شغلی در چارچوب یک سازمان با برخی از معناشناسی مرتبط در رابطه با اختیارات و مسئولیت‌هایی که به کاربر اختصاص داده شده به آن نقش اختصاص داده شده است». این سند عناصر اساسی RBAC - کاربران، جلسات، نقش ها، مجوزها، عملیات و اشیاء، و همچنین روابط و روابط بین آنها را ایجاد می کند.
این استاندارد حداقل ساختار لازم را برای ساختن یک الگوی نقش فراهم می کند - ترکیب حقوق در نقش ها و سپس صدور دسترسی به کاربران از طریق این نقش ها. مکانیسم های ترکیب نقش ها از اشیا و عملیات مشخص شده است، سلسله مراتب نقش ها و وراثت قدرت ها شرح داده شده است. در واقع، در هر شرکتی نقش هایی وجود دارد که ترکیبی از قدرت های اولیه است که برای همه کارکنان شرکت ضروری است. این ممکن است دسترسی به ایمیل، به EDMS، به پورتال شرکتی و غیره باشد. این مجوزها را می توان در یک نقش کلی به نام "کارمند" گنجاند و در هر یک از نقش های سطح بالاتر لازم نیست که همه حقوق اولیه را بارها و بارها فهرست کنید. فقط نشان دادن نشانه وراثت نقش "کارمند" کافی است.
بعدها، استاندارد با ویژگی های دسترسی جدید مرتبط با محیط همیشه در حال تغییر تکمیل شد. قابلیت معرفی محدودیت های استاتیک و پویا اضافه شده است. ایستا دلالت بر عدم امکان ترکیب نقش ها دارد (همان ورودی و کنترل عملیات ذکر شده در بالا). محدودیت های دینامیکی را می توان با تغییر پارامترهایی مانند زمان (ساعت یا روزهای کاری/غیر کاری)، مکان (دفتر/خانه) و مواردی از این دست تعریف کرد.
به طور جداگانه ، باید در مورد آن گفت کنترل دسترسی مبتنی بر ویژگی (ABAC). این رویکرد مبتنی بر اعطای دسترسی با استفاده از قوانین اشتراک ویژگی است. این مدل را می توان به طور جداگانه استفاده کرد، اما اغلب اوقات به طور فعال الگوی نقش کلاسیک را تکمیل می کند: می توانید ویژگی های کاربران، منابع و دستگاه ها و همچنین زمان یا مکان را به یک نقش خاص اضافه کنید. این به شما امکان می‌دهد از نقش‌های کمتری استفاده کنید، محدودیت‌های اضافی را معرفی کنید و دسترسی به حداقل کافی را داشته باشید، و در نتیجه امنیت را افزایش دهید.
به عنوان مثال، اگر حسابدار در منطقه خاصی کار می کند، می توان اجازه دسترسی به حساب ها را داشت. سپس مکان متخصص با یک مقدار مرجع خاص مقایسه می شود. یا فقط در صورتی می‌توانید به حساب‌ها دسترسی داشته باشید که کاربر از دستگاهی وارد شده در رجیستر حساب‌های مجاز وارد شود. یک مکمل خوب برای الگو، اما به دلیل نیاز به ایجاد قوانین و جداول مجوزها یا محدودیت‌ها، به ندرت به تنهایی استفاده می‌شود.
من مثالی از استفاده از ABAC از "زندگی گذشته" خود می زنم. بانک ما چندین شعبه داشت. کارمندان دفاتر مشتری در این شعب دقیقاً همان عملیات را انجام می دادند، اما مجبور بودند در سیستم اصلی فقط با حساب های موجود در منطقه خود کار کنند. ابتدا، ما شروع به ایجاد نقش های جداگانه برای هر منطقه کردیم - و بسیاری از این نقش ها با قابلیت های تکراری، اما با دسترسی به حساب های مختلف وجود داشت! سپس، با استفاده از ویژگی مکان برای یک کاربر و پیوند آن به محدوده خاصی از حساب‌ها برای بررسی، تعداد نقش‌های موجود در سیستم را به میزان قابل توجهی کاهش دادیم. در نتیجه، نقش‌ها فقط برای یک شعبه باقی ماند که برای موقعیت‌های مربوطه در سایر بخش‌های سرزمینی بانک تکرار شد.
و اکنون بیایید در مورد مراحل مقدماتی لازم صحبت کنیم که بدون آنها ساختن یک الگوی کار به سادگی غیرممکن است.
مرحله 1. یک مدل کاربردی ایجاد کنید
ارزش دارد که با ایجاد یک مدل عملکردی - یک سند سطح بالا که عملکرد هر واحد و هر موقعیت را به تفصیل شرح می دهد شروع شود. به عنوان یک قاعده، اطلاعات آن را از اسناد مختلف وارد می کند: شرح وظایف و مقررات برای بخش های فردی - بخش ها، بخش ها، بخش ها. مدل عملکردی باید با تمام بخش های ذینفع (کسب و کار، کنترل داخلی، امنیت) توافق شده و توسط مدیریت شرکت تایید شود. این سند برای چیست؟ تا الگو به آن مراجعه کند. به عنوان مثال، شما می خواهید یک الگو بر اساس حقوق موجود کارکنان بسازید - از سیستم تخلیه شده و "به یک مخرج مشترک کاهش می یابد". سپس هنگام توافق در مورد نقش های دریافت شده با صاحب کسب و کار سیستم، می توان به یک مورد خاص از مدل عملکردی اشاره کرد که بر اساس آن این یا آن حق در نقش گنجانده شده است.
مرحله 2. ما سیستم های فناوری اطلاعات را ممیزی می کنیم و یک برنامه اولویت بندی تهیه می کنیم
در مرحله دوم، ممیزی سیستم های IT باید انجام شود تا درک شود که چگونه دسترسی به آنها سازماندهی شده است. به عنوان مثال، شرکت مالی من چندین صد سیستم اطلاعاتی را اداره می کرد. در همه سیستم ها برخی از اصول مدیریت نقش وجود داشت، در بیشتر آنها - برخی از نقش ها، اما بیشتر بر روی کاغذ یا در فهرست سیستم - مدت زیادی است که منسوخ شده اند و دسترسی به آنها بر اساس درخواست واقعی کاربر توزیع شده است. به طور طبیعی، ساختن یک الگو در چند صد سیستم به طور همزمان غیرممکن است، شما باید از جایی شروع کنید. ما یک تجزیه و تحلیل عمیق از فرآیند کنترل دسترسی برای تعیین سطح بلوغ آن انجام دادیم. در فرآیند تجزیه و تحلیل، معیارهایی برای اولویت بندی سیستم های اطلاعاتی - بحرانی بودن، آمادگی، برنامه هایی برای از کار انداختن و غیره ایجاد شد. با کمک آنها، ما دنباله ای برای توسعه / به روز رسانی الگوهای نقش برای این سیستم ها ساختیم. و سپس - شامل الگوهای نقش در طرح برای ادغام با راه حل مدیریت هویت برای کنترل خودکار دسترسی.
بنابراین، چگونه می توان بحرانی بودن سیستم را تعیین کرد؟ به سوالات زیر به خودتان پاسخ دهید:
- آیا این سیستم به فرآیندهای عملیاتی مرتبط است که کسب و کار اصلی شرکت به آن بستگی دارد؟
- آیا اختلال در سیستم بر یکپارچگی دارایی های شرکت تأثیر می گذارد؟
- حداکثر زمان توقف مجاز سیستم چقدر است که پس از رسیدن به آن امکان بازگرداندن فعالیت پس از وقفه وجود ندارد؟
- آیا نقض یکپارچگی اطلاعات در سیستم می تواند منجر به عواقب جبران ناپذیری اعم از مالی و اعتباری شود؟
- انتقاد به تقلب وجود عملکردی که با کنترل ناکافی آن امکان انجام اقدامات جعلی داخلی / خارجی وجود دارد.
- الزامات قانونی و همچنین قوانین و رویه های داخلی برای این سیستم ها چیست؟ آیا برای عدم رعایت مقررات از سوی رگولاتورها مجازاتی در نظر گرفته خواهد شد؟
در شرکت مالی خود، ما حسابرسی به این صورت انجام دادیم. مدیریت یک روش حسابرسی بازبینی حق دسترسی ایجاد کرده است تا ابتدا با کاربران موجود و حقوق مربوط به آن دسته از سیستم های اطلاعاتی که در لیست اولویت اول قرار دارند، برخورد کند. بخش امنیتی صاحب این فرآیند شده است. اما برای به دست آوردن تصویری کامل از حقوق دسترسی در شرکت، لازم بود بخش‌های فناوری اطلاعات و بازرگانی در این فرآیند مشارکت داشته باشند. و در اینجا اختلافات، سوء تفاهم ها و گاهی اوقات حتی خرابکاری آغاز شد: هیچ کس نمی خواهد از وظایف فعلی خود جدا شود و در یک نگاه اول درگیر برخی از فعالیت های نامفهوم شود.
NB شرکت‌های بزرگ با فرآیندهای توسعه‌یافته فناوری اطلاعات احتمالاً با روش حسابرسی فناوری اطلاعات - کنترل‌های عمومی فناوری اطلاعات (ITGC) آشنا هستند، که به شما امکان می‌دهد کاستی‌ها را در فرآیندهای فناوری اطلاعات شناسایی کرده و کنترل را برای بهبود فرآیندها مطابق با بهترین عملکرد (ITIL، COBIT، IT) ایجاد کنید. حاکمیت و غیره) چنین ممیزی به فناوری اطلاعات و کسب و کار اجازه می دهد تا یکدیگر را بهتر درک کنند و یک استراتژی توسعه مشترک ایجاد کنند، ریسک ها را تجزیه و تحلیل کنند، هزینه ها را بهینه کنند و رویکردهای کارآمدتری برای کار ایجاد کنند.
یکی از حوزه های حسابرسی تعیین پارامترهای دسترسی منطقی و فیزیکی به سیستم های اطلاعاتی است. ما داده‌های به‌دست‌آمده را مبنایی برای استفاده بیشتر در ساختن یک الگو قرار دادیم. در نتیجه چنین ممیزی، ما یک رجیستر سیستم های فناوری اطلاعات داریم که در آن پارامترهای فنی آنها مشخص شده و توضیحاتی ارائه شده است. علاوه بر این، برای هر سیستم، یک مالک از جهت کسب‌وکار که در راستای منافع آن اداره می‌شد، تعیین می‌شد: این او بود که مسئول فرآیندهای تجاری بود که این سیستم در خدمت آنها بود. یک مدیر خدمات فناوری اطلاعات نیز منصوب شد که مسئول اجرای فنی نیازهای تجاری در یک IS خاص است. بحرانی ترین سیستم ها برای شرکت و پارامترهای فنی آن ها، تاریخ راه اندازی و از کار انداختن و ... ثبت شد که این پارامترها کمک زیادی به روند آماده سازی برای ساخت الگو کرد.
مرحله 3 یک متدولوژی ایجاد کنید
رمز موفقیت هر کسب و کاری روش درست است. بنابراین، هم برای ساختن یک الگو و هم برای انجام حسابرسی، باید روشی ایجاد کنیم که در آن تعامل بین بخش‌ها، تثبیت مسئولیت در مقررات شرکت و غیره را شرح دهیم.
ابتدا باید تمام اسناد موجود را که روش اعطای دسترسی و حقوق را تعیین می کنند، بررسی کنید. به روشی خوب، فرآیندها باید در چندین سطح مستند شوند:
- الزامات عمومی شرکت؛
- الزامات مربوط به حوزه های امنیت اطلاعات (بستگی به فعالیت های سازمان دارد).
- الزامات فرآیندهای تکنولوژیکی (دستورالعمل ها، ماتریس های دسترسی، دستورالعمل ها، الزامات پیکربندی).
در شرکت مالی ما، اسناد منسوخ زیادی پیدا کردیم - مجبور شدیم آنها را با فرآیندهای جدیدی که معرفی می شد، مطابقت دهیم.
به دستور مدیریت، کارگروهی تشکیل شد که نمایندگانی از حوزه های امنیتی، فناوری اطلاعات، تجارت و کنترل داخلی در آن حضور داشتند. در این دستور اهداف ایجاد گروه، جهت فعالیت، دوره وجود و مسئولیت هر یک از طرفین مشخص شد. علاوه بر این، ما یک روش حسابرسی و یک روش برای ساختن یک الگو ایجاد کرده‌ایم: آنها مورد توافق همه نمایندگان مسئول حوزه‌ها و تأیید مدیریت شرکت قرار گرفتند.
اسنادی که مراحل انجام کار، مهلت‌ها، مسئولیت‌ها و غیره را شرح می‌دهند. - تضمینی که در راه رسیدن به هدف گرامی ، که در ابتدا برای همه واضح نیست ، هیچ کس سؤالی نخواهد داشت "چرا ما این کار را انجام می دهیم ، چرا به آن نیاز داریم و غیره". و هیچ فرصتی برای "پرش" یا کند کردن روند وجود نخواهد داشت.
مرحله 4. اصلاح پارامترهای مدل کنترل دسترسی موجود
ما از نظر کنترل دسترسی به اصطلاح "گذرنامه سیستم" را تهیه می کنیم. در واقع این پرسشنامه یک سیستم اطلاعاتی خاص است که تمامی الگوریتم های مدیریت دسترسی به آن در آن ثبت شده است. شرکت‌هایی که قبلاً راه‌حل‌های کلاس IdM را پیاده‌سازی کرده‌اند احتمالاً با چنین پرسش‌نامه‌ای آشنا هستند، زیرا با آن است که مطالعه سیستم‌ها آغاز می‌شود.
برخی از پارامترهای مربوط به سیستم و مالکان از رجیستری فناوری اطلاعات به پرسشنامه سرازیر شده اند (مرحله 2، حسابرسی را ببینید)، اما موارد جدیدی اضافه شده است:
- نحوه مدیریت حساب ها (مستقیماً در پایگاه داده یا از طریق رابط های برنامه)؛
- نحوه ورود کاربران به سیستم (با استفاده از یک حساب جداگانه یا استفاده از حساب AD، LDAP و غیره)؛
- چه سطوح دسترسی به سیستم استفاده می شود (سطح برنامه، سطح سیستم، استفاده از منابع فایل شبکه توسط سیستم).
- توضیحات و پارامترهای سرورهایی که سیستم روی آنها اجرا می شود.
- چه عملیات مدیریت حساب پشتیبانی می شود (مسدود کردن، تغییر نام، و غیره)؛
- چه الگوریتم ها یا قوانینی برای تشکیل شناسه کاربر سیستم استفاده می شود.
- از چه ویژگی می توان برای ایجاد پیوند با یک سابقه در مورد یک کارمند در سیستم پرسنلی (نام کامل، شماره پرسنل و غیره) استفاده کرد.
- تمام ویژگی های حساب ممکن و قوانین برای پر کردن آنها؛
- چه حقوق دسترسی در سیستم وجود دارد (نقش ها، گروه ها، حقوق اتمی و غیره، آیا حقوق تودرتو یا سلسله مراتبی وجود دارد).
- مکانیسم های جداسازی حقوق دسترسی (بر اساس موقعیت ها، تقسیمات، عملکرد و غیره)؛
- آیا سیستم قوانینی برای تفکیک حقوق (SOD - Segregation of Duties) دارد و چگونه کار می کند.
- نحوه پردازش رویدادهای غیبت، انتقال، اخراج، به روز رسانی داده های کارکنان و غیره در سیستم.
این لیست می تواند ادامه یابد و پارامترهای مختلف و سایر نهادهایی که در فرآیند کنترل دسترسی دخیل هستند را به تفصیل شرح دهد.
مرحله 5: شرح مجوز کسب و کار را ایجاد کنید
سند دیگری که هنگام ساختن یک الگو به آن نیاز خواهیم داشت، راهنمایی برای تمام اختیارات (حقوق) ممکنی است که می توان در یک سیستم اطلاعاتی به کاربران اعطا کرد، همراه با شرح مفصلی از عملکرد تجاری که در پشت آن قرار دارد. اغلب قدرت‌های موجود در سیستم با نام‌های خاصی رمزگذاری می‌شوند که از حروف و اعداد تشکیل شده‌اند و کارمندان کسب‌وکار نمی‌توانند بفهمند که چه چیزی در پشت این شخصیت‌ها نهفته است. سپس آنها به سرویس فناوری اطلاعات می روند و در آنجا ... همچنین نمی توانند به سؤال مثلاً در مورد حقوقی که به ندرت استفاده می شود پاسخ دهند. سپس باید تست های بیشتری انجام دهید.
خوب است اگر قبلاً یک شرح تجاری وجود داشته باشد یا حتی اگر این حقوق به گروه ها و نقش ها مرتبط باشد. برای برخی از برنامه ها، بهترین روش ایجاد چنین راهنمای در مرحله توسعه است. اما این اغلب اتفاق نمی افتد، بنابراین دوباره به بخش فناوری اطلاعات می رویم تا اطلاعات مربوط به تمام حقوق ممکن را جمع آوری کرده و آنها را شرح دهیم. راهنمای ما در نهایت شامل موارد زیر خواهد بود:
- نام مرجع، از جمله موضوعی که حق دسترسی به آن اعمال می شود.
- اقدامی که مجاز به انجام آن با شیء است (مشاهده، تغییر و غیره، امکان محدودیت، به عنوان مثال، بر اساس سرزمین یا گروهی از مشتریان)؛
- کد مرجع (کد و نام تابع/درخواست سیستم که می تواند با استفاده از مرجع اجرا شود)؛
- شرح اختیار (توضیح مفصلی از اقدامات در IS هنگام اعمال اختیار و پیامدهای آنها برای فرآیند؛
- وضعیت مجوز: "فعال" (اگر مجوز به حداقل یک کاربر اختصاص داده شده باشد) یا "فعال نیست" (اگر از مجوز استفاده نشده باشد).
مرحله 6 ما داده های مربوط به کاربران و حقوق را از سیستم ها تخلیه می کنیم و آن را با منبع پرسنل مقایسه می کنیم
در مرحله نهایی آماده سازی، باید داده هایی را از سیستم های اطلاعاتی درباره همه کاربران و حقوقی که در حال حاضر دارند بارگذاری کنید. دو سناریو در اینجا ممکن است. اول اینکه بخش امنیتی دسترسی مستقیم به سیستم دارد و ابزاری برای دانلود گزارش های مربوطه دارد که نادر است اما بسیار راحت است. دوم: درخواستی را به IT ارسال می کنیم تا گزارشات را در قالب مورد نیاز دریافت کند. تمرین نشان می دهد که نمی توان با IT مذاکره کرد و اطلاعات لازم را در بار اول به دست آورد. لازم است چندین رویکرد تا زمان دریافت اطلاعات به شکل و قالب مورد نظر انجام شود.
چه داده هایی باید آپلود شوند:
- نام کاربری
- نام کارمندی که به او اختصاص داده شده است
- وضعیت (فعال یا مسدود شده)
- تاریخ ایجاد حساب
- آخرین تاریخ استفاده
- فهرست حقوق/گروه ها/نقش های موجود
بنابراین ما با تمامی کاربران و با تمام حقوقی که به آنها اعطا شده است تخلیه هایی از سیستم دریافت کرده ایم. و آنها بلافاصله تمام حساب های مسدود شده را کنار می گذارند ، زیرا کار بر روی ساخت یک الگو فقط برای کاربران فعال انجام می شود.
سپس، اگر شرکت شما ابزار خودکاری برای بستن دسترسی به کارکنان اخراج شده ندارد (این غیر معمول نیست) یا اتوماسیون تکه‌کاری وجود دارد که همیشه به درستی کار نمی‌کند، باید همه «روح‌های مرده» را شناسایی کنید. ما در مورد حساب های کارمندان اخراج شده صحبت می کنیم که حقوق آنها به دلایلی مسدود نشده است - آنها باید مسدود شوند. برای انجام این کار، داده های آپلود شده را با منبع پرسنل مقایسه می کنیم. تخلیه پرسنل نیز باید از قبل از واحد رهبری پایگاه پرسنل دریافت شود.
به طور جداگانه، لازم است حساب هایی را کنار بگذارید که صاحبان آنها در پایگاه پرسنل یافت نشدند و به کسی اختصاص داده نشدند - یعنی بدون مالک. برای این لیست، به تاریخ آخرین استفاده نیاز داریم: اگر کاملاً جدید باشد، هنوز باید به دنبال صاحبان آن بگردیم. این ممکن است شامل حساب‌های پیمانکاران خارجی یا حساب‌های خدماتی باشد که به کسی اختصاص داده نشده‌اند، اما با هر فرآیندی مرتبط هستند. برای روشن شدن مالکیت حساب، می توانید نامه هایی با درخواست پاسخ به تمام بخش ها ارسال کنید. هنگامی که صاحبان پیدا می شوند، داده های مربوط به آنها را وارد سیستم می کنیم: به این ترتیب، تمام حساب های فعال شناسایی می شوند و بقیه مسدود می شوند.
به محض اینکه آپلودهای ما از سوابق غیر ضروری پاک شد و فقط حساب‌های فعال باقی ماند، می‌توانیم شروع به ساختن یک الگو برای یک سیستم اطلاعاتی خاص کنیم. اما در مقاله بعدی در این مورد صحبت خواهم کرد.
نویسنده: لیودمیلا سواستیانووا، مدیر تبلیغات سولار inRights
منبع: www.habr.com