خدمات امنیتی (Security Service)

خدمات امنیتی نباید با مفاهیم امنیتی مخصوص .NET یکی دانسته شود. خدمات امنیتی نوعی بررسی و هماهنگی با کد، فوق داده‌ها و MSIL است و تضمین می‌کند که CLR به آنچه که انتظار داشت، رسیده است، چه از طریق همان برنامه‌نویس یا یک منبع مورد اعتماد، و دستیابی به ارجاعات بعدی نیز غیرممکن می‌سازد که بسته به ایزوله‌سازی است که دستیابی تضمین شده باشد.
در .NET سیستم اجرای مجازی (VES) تمام بازرسی‌های امنیتی را اداره می‌کند. امنیت نوع، از طریق مطابقت دادن انواع مستحکم موجود در فوق داده‌ها با MSIL متناظر (متغیرهای محلی و شیارهای پشته) به واسطه VES پیاده می‌شود. شما می‌توانید به صورت یک نمودار فنی به آن نگاه کنید، خطی خیلی واضح و پر کشیده شده است که از فوق داده‌ها به MSIL اشاره می‌کند و اطمینان پیدا می‌کند که همه چیز با تعاریف صحیح و فضای حافظه مطابقت دارد.
VES همچنین ایمنی نسخه‌ای را پوشش می‌دهد، چون VES همه چیز را مشخص می‌کند، در ادامه کار بازرسی خود درستی همه اطلاعات را تحقیق می‌کند، ازجمله آزمایش نسخه را. VES همچنین از این موضوع اطمینان حاصل می‌کند که CLR آنچه را خواهد دید که او بدست می‌آورد. به عبارت دیگر CLR در محدودة فرضیاتی کار خواهد کرد که VES دربارة کد کرده است.
اما برای آنکه درخصوص کد فرضیه‌ای صورت بگیرید CLR باید مطمئن باشد که کد بخوبی اجرا می‌شود. VES با فراهم کردن سه متد مداخله می‌کند که کد می‌تواند از این سه متد جهت اجرایی شدن استفاده کند. بارکنندة کلاس، احضار محیطی بر کد قانونی و برای اهداف انتقال یک COM مدیریت نشده با عملکرد چندمحیطی استفاده از دو مورد آخر ممکن است منجر به مشکلات کارکردی گردد، بنابراین بهتر است که موقع نوشتن یا انتقال کد از آنها خودداری کنید و فقط به بارکنندة کلاس بچسبید. بارکنندة کلاس، مراحل پیاده‌سازی اجرا را به اطلاعات مربوط به مراحل اجرا دریک فوق داده وصل می‌کند. VES همچنین از بارکنندة کلاس برای شناسایی شخصی استفاده می‌کند که سعی در دسترسی به یک نوع دارد ولذا از توانایی تعیین قابلیت دسترسی آن بهره می‌برد.
بعلاوه VES، از طریق CTS، به مجوزهای دسترسی به کدها که در فوق داده ذخیره می‌شوند، دسترسی پیدا می‌کند. VES هرنوع را مطابق با مجوزها بررسی می‌کند و هر نوع مجوزدار را با یک stub در لودری علامت می‌گذارد که به CLR می‌گوید تا مجوزها را به آنکه stub اشاره می‌کند اعمال کند. به چنین امنیتی امنیت اعلانی (declrative) گفته می‌شود.
● امنیت چارچوب کاری (Framework)
امنیت دسترسی کدی و امنیت براساس نقش و وظیفه، دو نوع امنیت ارائه شده توسط خود چارچوب کاری .NET می‌باشند. این‌ها مکانیزم‌هایی هستند که به منظور حفظ یک ذهنیت ساده مربوط به یک کاربرد برای تصمیم‌گیری بنا نهاده شده‌اند. نظریه ساده‌انگاری براساس یکنواختی، و امکان‌گذاری از امنیت کدی به امنیت وظیفه‌ای و بالعکس می‌باشد. اصولی که به امنیت .NET ثبات و استحکام می‌بخشد، عبارتند از: مجوز، اصول و خط مشی امنیتی.
امنیت دسترسی کدی، همانطوریکه احتمالاً اطلاع داشته باشید، درجات متعدد اعتماد را برای یک برنامه فراهم می‌سازند، این درجات را براساس اطلاعاتی که اسمبلی می‌دهد می‌تواند تغییر دهد، مانند برنامه‌نویس، نسخه (نگارش) و مانند آن، چون این اطلاعات در کد ذخیره می‌شود. هنگامی که فرآیندی تعیین می‌کند که‌ آیا می‌توان به کد خاصی دسترسی داشت، زمان اجرای پشته فراخوانی جاری کد را برای مجوز جستجو می‌کند، هرچند اگر نتواند مجوز را پیدا کند. استثنائی را به وجود می‌آورد.
امنیت برپایه نقش و وظیفه، تصمیمات اختیاری و دلخواه را براساس مقدار اصلی می‌گیرد که از رشته جاری درخواست کرده است. نقش‌های فهرست شده در مقدار اصلی در مرحلة بعد ارزیابی شده و عملکرد توانایی درخواست شده یا داده می‌شود یا داده نمی‌شود.
برنامه‌نویسان نرم‌افزارهای مالی و کدنویسان بانک‌ اطلاعاتی ممکن است قبلاً با مفهوم امنیت براساس نقش و وظیفه آشنا باشند. معمولاً در این موارد، هنگامیکه یک کلاینت خواهان دسترسی به قسمت معینی از سیستم یا منبع می‌باشد، یم وارسی صورت می‌گیرد که درنتیجه آن مشخص می‌شود که درخواست کلاینت از کدام نقش نشأت گرفته است. فرض کنیم که عضوی از گروه Alpha تلاش می‌کند که به یک منبع واقع در عضوی از گروه omega دسترسی داشته باشد. Alpha شروع به ارتباط می‌کند و omega اولین اصل از رشته ارتباط را دریافت می‌کند. در مرحله بعد، اصل ازنظر نقش آنالیز می‌شود و omega متقاعد می‌شود که گروه کاری alpha برای همة منابع مجوز ندارد (فقط برای دوتا از آنها مجوز دارد). Omega ارتباط را قبول می‌کند اما درخواست alpha را به دو منبع محدود می‌کند. اگر alpha سعی در دسترسی به منابعی جز این دو مورد بود، درخواست او رد می‌شد.
● اهدای مجوزها
مجوز بدنه اصلی بلوک امنیت را تشکیل می‌دهد. بعضی‌ها به مجوز به عنوان یک پاسخ منطقی نگاه می‌کنند، که به یک استعلام مبنی بر کسب دسترسی داده می‌شود، درحالی که برخی دیگر اعتقاد دارند مجوز یک کلید مناسب برای یک قفل است. هر دونظریه درست است. مجوزها در .NET ازطریق درخواست‌ها، اهداءها و نیازها استفاده می‌شود. کد مجوزها را به این دلیل درخواست می‌کند تا ببیند آیا می‌تواند به یک فایل دسترسی پیدا کند. اگر کد دراثر این مجوزها خراب نشود، شما می‌توانید توسط یک تابع به کد مجوز اعطا کنید. اگر با مجوزهای آماده کنار بیایید ، ممکن است یک لایه اضافه شده از مجوز بنام تقاضا را پیاده‌سازی کنید، بعبارت دیگر هنگامی که کد ممکن است مجوزهای اولیه موردنیاز برای تأمین خواسته را داشته باشد، می‌تواند درخواست مجوز یا مجوزهای ویژه‌ای را بکند. هردو امنیت دسترسی کدی و امنیت برپایه نقش، فهرستی از مجوزها را دارند.
● حصول نمایش از طریق یک اصل
آیا تا کنون از واسطه‌ای درخواست کرده‌اید تا برای کسب دسترسی از برنامه وارد عمل شود؟ اصل دقیقاً همین کار را می‌کند. یک اصل بسته به شرایط حاکم، مجوز لازم را براساس درخواست شما جهت ورود بدست می‌آورد. CLR به اصل اجازه می‌دهد ولی به شما اجازه نمی‌دهد، زیرا CLR تنها آنچه را که اصل قرار است انجام دهد، به شما اجازه انجام می‌دهد.
یکی از اصل‌های معمولی ارائه اجرای بی‌هدف می‌باشد که برای تشخیص آنچه که یک شخص شناسایی نشده می‌تواند ببیند، قابل استفاده است. هرچند این مسأله دریک برنامه روزمره عملی نیست. برای تست کردن و اشکال‌زدایی موقعیت‌ها خیلی مفید است و برای تعیین تکلیف در مواقعی که مجوز نشاندهنده آن است که شما برنامه‌ریزی نکرده‌اید، بی‌نهایت سودمند است. اصل‌های سفارشی و سلیقه‌ای توسط برنامه کاربردی در شرایط فوری ایجاد می‌شوند تا یک نیاز و فوریت جاری را رفع کنند. این‌ها قابلیت استفاده پایه‌ای یک اصل معمولی را گسترش می‌دهند، اما وابسته به داشتن ماژول‌های شناسایی و انواع داده شده به آنها توسط برنامه می‌باشند. این وابستگی عنصری ، امنیتی، اصل سفارشی امنیتی می‌دهد. چون نیازمند خواسته‌ای است که برای کارکردن لازم دارد.
● خط مشی امنیتی (Securty Policy)
مقرراتی را که CLR از آنها تبعیت می‌کند در مجموع خط‌مشی امنیتی گفته می‌شود. مدیر محلی این قوانین قابل پیکربندی را تعیین می‌کند. هنگامیکه یک اسمبلی سعی در بارکردن دارد، خط‌مشی امنیتی این موضوع را بررسی می‌کند که چه مجوزهایی را CLR می‌تواند به اسمبلی بدهد. امکانات و حالت‌های مختلفی را مشخص می‌کند، اگر اسمبلی از آنها به سلامت گذشت، مجوزهای موردنیاز را صادر می‌کند و درغیر اینصورت اجازة اجرا شدن برنامه را نمی‌دهد.
سه سطح خط‌مشی امنیتی را مشخص می‌کنند: خط‌مشی ماشین محلی، خط‌مشی حوزه برنامه کاربردی و خط‌مشی کاربر.runtime از هر سه خط‌مشی برای فیلتر کردن خط‌مشی نهایی استفاده می‌کند و سپس آن را در اسمبلی وضع و مجوز آن را مشخص می‌کند. خط‌مش‌های کاربردی و حوزه برنامه هردو مجموعه مجوزهای داده شده را تعیین می‌کنند، و سپس مجوزهایی که فیلتر نمی‌شوند خط‌مشی امنیتی می‌شوند.
● حوزه‌های برنامه‌های کاربردی
هر برنامه‌ای که در .NET دریک حوزه‌ای اجرا می‌شود که توسط یک میزبان مدیریت می‌شود. این میزبان ممکن است یک میزبان هسته (.EXE ها را از یک هسته اجرا می‌کند)، یک میزبان مرورگر (کد را از یک پایگاه وب اجرا می‌کند) ، یک میزبان سروری (ASP.NET؛ کدی را اجرا می‌کند که درخواست‌های سروری را کنترل می‌کند) و یک میزبان سفارشی باشد. وقتی که یکی از اینها حوزه برنامه را می‌سازد، مثلاً میزبان هسته، (که ویندوز خواهد بود) یک خط‌مشی را تعریف می‌کند(sets) که کد باید تحت آن حوزه با آن درگیر باشد. خط‌مشی تولید شده قابل ازدیاد نیست ولی می‌تواند توسط میزبان منعطف‌تر و سازگارتر گردد
پس از تنظیم و تعریف یک خط‌مشی حوزه برنامه‌ای، خط‌مشی جدید تنها به اسمبلی‌هایی اعمال می‌شود که بعد از آن بار می‌شوند. اسمبلی‌هایی که خط‌مشی قبلی دارند نمی‌توانند از خط‌مشی جدید استفاده کنند و برهمان خط‌مشی قبلی خواهند بود مگر آنکه دوباره بار شوند، به محض آنکه اسمبلی اصلی بار شد و اولین ارجاع به اسمبلی دیگر به عمل آمد نوبت به بارکننده می‌رسد و اسمبلی را در حوزه برنامه مناسب قرار می‌دهد و سپس اطلاعات (به عنوان مدرک) را که قابل اعتماد بودن آنرا ثابت می‌کند به runtime باز می‌گرداند (اطلاعات نسخه‌ای را جهت تحقیق برگشت می‌دهد).

منبع : جنوبی‌ها