تعاریف اساسی

ما با سیستم عامل تماس خواهیم گرفت حفاظت شده , اگر وسیله ای برای محافظت در برابر طبقات اصلی تهدیدات شرح داده شده در § 1.1 فراهم کند. یک سیستم عامل محافظت شده باید شامل ابزارهایی برای محدود کردن دسترسی کاربر به منابع آنها و همچنین ابزارهایی برای احراز هویت کاربری باشد که شروع به کار با سیستم عامل می کند. علاوه بر این، سیستم عامل محافظت شده باید دارای ابزاری برای مقابله با استنتاج تصادفی یا عمدی باشد. سیستم عاملخراب.

اگر سیستم عامل محافظتی را نه در برابر همه کلاس های اصلی تهدیدات، بلکه فقط در برابر برخی از آنها فراهم کند، چنین سیستم عاملی نامیده می شود. تا حدی محافظت شده است . به عنوان مثال، سیستم عامل MS-DOS با بسته ضد ویروس نصب شده یک سیستم تا حدی محافظت شده است - از ویروس های رایانه ای محافظت می شود.

تماس خواهیم گرفت خط مشی امنیتی مجموعه ای از هنجارها، قوانین و شیوه های حاکم بر ذخیره سازی و پردازش اطلاعات ارزشمند. همانطور که برای سیستم عامل اعمال می شود، خط مشی امنیتی تعیین می کند که کدام کاربران می توانند با سیستم عامل کار کنند، کدام کاربران به کدام اشیاء سیستم عامل دسترسی دارند، کدام رویدادها باید در گزارش های سیستم ثبت شوند و غیره.

سیاست امنیتی کافی ما چنین سیاست امنیتی را که سطح کافی از امنیت را برای سیستم عامل فراهم می کند، می نامیم. باید تاکید کرد که یک سیاست امنیتی کافی لزوماً یک سیاست امنیتی نیست که حداکثر امنیت ممکن را برای سیستم به دست آورد.

رویکردهای ساختمان حفاظت شدهسیستم های عامل

دو رویکرد اصلی برای ایجاد سیستم عامل ایمن وجود دارد - تکه تکهو مجتمع

در تکه تکه رویکرد، ابتدا محافظت در برابر یک تهدید سازماندهی می شود، سپس از تهدید دیگر و غیره. نمونه ای از رویکرد تکه تکه وضعیتی است که یک سیستم عامل محافظت نشده (به عنوان مثال Windows-95) به عنوان پایه در نظر گرفته شود، یک بسته آنتی ویروس، یک سیستم رمزگذاری، یک سیستم برای ثبت اقدامات کاربر و غیره بر روی آن نصب شده است.

نقطه ضعف اصلی رویکرد تکه تکه آشکار است - هنگام استفاده از این رویکرد، زیرسیستم حفاظت از سیستم عامل مجموعه ای از محصولات نرم افزاری متفاوت است که معمولاً توسط تولید کنندگان مختلف تولید می شود. این ابزارهای نرم افزاری مستقل از یکدیگر کار می کنند، سازماندهی تعامل نزدیک آنها تقریبا غیرممکن است. علاوه بر این، عناصر فردی چنین زیرسیستم حفاظتی ممکن است در حضور یکدیگر به درستی کار نکنند، که منجر به کاهش شدید قابلیت اطمینان سیستم می شود. از آنجایی که زیرسیستم حفاظتی که بر اساس یک رویکرد تکه تکه ایجاد شده است، جزء جدایی ناپذیر سیستم عامل نیست، اگر برخی از عملکردهای حفاظتی در نتیجه اقدامات غیرمجاز کاربر متخلف غیرفعال شوند، عناصر باقی مانده از سیستم عامل به عملکرد عادی داشته باشد، که باعث کاهش بیشتر قابلیت اطمینان حفاظت می شود.

در یکپارچه رویکرد سازماندهی حفاظت سیستم توابع حفاظتیدر مرحله طراحی معماری سیستم عامل وارد سیستم عامل شده و جزء لاینفک آن هستند. عناصر فردی زیرسیستم حفاظت، که بر اساس یک رویکرد یکپارچه ایجاد شده اند، در حل مشکلات مختلف مربوط به سازماندهی حفاظت از اطلاعات از نزدیک با یکدیگر تعامل دارند. از آنجایی که زیرسیستم حفاظت به طور کلی توسعه یافته و آزمایش شده است، تضاد بین آن وجود دارد اجزای جداگانهتقریبا غیرممکن. زیرسیستم حفاظت که بر اساس یک رویکرد یکپارچه ایجاد شده است، می تواند به گونه ای تنظیم شود که در صورت بروز نقص های مرگبار در عملکرد آن عناصر کلیدیباعث از کار افتادن سیستم عامل می شود که مانع از غیرفعال کردن عملکردهای محافظتی سیستم توسط مهاجم می شود. هنگام استفاده از یک رویکرد پراکنده، چنین سازماندهی زیرسیستم حفاظت غیرممکن است.

به عنوان یک قاعده، یک زیرسیستم حفاظت از سیستم عامل، که بر اساس یک رویکرد یکپارچه ایجاد شده است، به گونه ای طراحی می شود که عناصر جداگانه آن قابل تعویض باشند و ماژول های نرم افزار مربوطه را بتوان با ماژول های دیگری جایگزین کرد که رابط ارائه شده برای تعامل نرم افزار مربوطه را پیاده سازی می کنند. ماژول با سایر عناصر زیرسیستم حفاظت.

پادمان های اداری

سازماندهی حفاظت موثر و قابل اعتماد از سیستم عامل تنها با کمک نرم افزار و سخت افزار غیر ممکن است. این بودجه باید با اقدامات حفاظتی اداری تکمیل شود. بدون پشتیبانی مستمر واجد شرایط توسط مدیر، حتی مطمئن ترین نرم افزار و سخت افزار محافظت به داستان تبدیل می شود.

اصلی اقدامات اداریحفاظت.

1. نظارت مداوم بر عملکرد صحیح سیستم عامل، به ویژه زیر سیستم حفاظتی آن. اگر سیستم عامل از ثبت رویداد پشتیبانی کند، این کنترل راحت‌تر سازماندهی می‌شود. در این حالت، سیستم عامل به طور خودکار مهمترین رویدادهایی را که در حین عملکرد سیستم رخ داده است، در یک گزارش ویژه (یا چندین گزارش) ثبت می کند.

2. سازماندهی و حفظ یک سیاست امنیتی کافی. خط مشی امنیتی باید به طور مداوم تنظیم شود و به سرعت به تغییرات در پیکربندی سیستم عامل، نصب، حذف و تغییرات پیکربندی برنامه پاسخ دهد. محصولات نرم افزاریو توسعه سیستم عامل، تلاش مزاحمان برای غلبه بر حفاظت از سیستم عامل و غیره.

3. آموزش کاربران سیستم عامل در مورد لزوم رعایت تدابیر امنیتی در هنگام کار با سیستم عامل و نظارت بر رعایت این اقدامات.

4. ایجاد و به روز رسانی منظم نسخه های پشتیبان از برنامه ها و داده های سیستم عامل.

5. نظارت مستمر بر تغییرات در داده های پیکربندی و سیاست امنیتی سیستم عامل. توصیه می شود اطلاعات مربوط به این تغییرات را در رسانه های غیر الکترونیکی ذخیره کنید تا برای مهاجمی که بر حفاظت سیستم عامل غلبه کرده است، پنهان کردن اقدامات غیرمجاز خود دشوارتر شود.

سیاست امنیتی کافی

وظیفه انتخاب و حفظ یک خط مشی امنیتی مناسب یکی از مهمترین وظایف یک مدیر سیستم عامل است. اگر سیاست امنیتی اتخاذ شده در سیستم عامل ناکافی باشد، این می تواند منجر به دسترسی غیرمجاز یک کاربر مخرب به منابع سیستم و همچنین کاهش قابلیت اطمینان سیستم عامل شود. از سوی دیگر، هر سیاست امنیتی کافی در عمل قابل اجرا نیست.

به طور کلی، عبارت زیر درست است: اپرا بهتر است سیستم امنیتی است، کار با آن برای کاربران و مدیران دشوارتر است. این به دلیل عوامل زیر است.

1. یک سیستم امنیتی که اطلاعات هوشمندی ندارد همیشه قادر به تعیین مخرب بودن یک اقدام کاربر خاص نیست. بنابراین، سیستم حفاظتی یا برخی از انواع دسترسی های غیرمجاز را سرکوب نمی کند و یا برخی از اقدامات کاملاً قانونی کاربران را ممنوع می کند. هرچه امنیت سیستم بالاتر باشد، طبقه بندی آن دسته از اقدامات قانونی کاربران که توسط زیرسیستم حفاظت غیرمجاز تلقی می شوند، بیشتر می شود. به عنوان مثال، اگر کاربر خاصی از ایجاد فایل روی هارد دیسک منع شود، این کاربر نمی تواند برنامه ای را که نیاز به ایجاد فایل های موقت برای عملکرد عادی داشته باشد، راه اندازی کند. از نظر سیاست امنیتی مورد بررسی، ایجاد پرونده موقت اقدامی غیرمجاز است و سرکوب آن اشتباهی ندارد. فقط در این سیاست امنیتی کلاس اقدامات غیرمجاز آنقدر گسترده است که در کار عادی کاربران با سیستم عامل اختلال ایجاد می کند.

2. هر سیستمی که عملکردهای امنیت اطلاعات را فراهم می کند، مدیران را ملزم می کند تا تلاش های خاصی را برای حفظ یک خط مشی امنیتی کافی انجام دهند. هرچه عملکردهای محافظتی در سیستم عامل بیشتر باشد، زمان و هزینه بیشتری برای حفظ حفاظت باید صرف کنید.

3. زیرسیستم حفاظتی سیستم عامل، مانند هر بسته نرم افزاری دیگری، منابع سخت افزاری کامپیوتر را مصرف می کند. هرچه عملکردهای حفاظتی سیستم عامل پیچیده تر باشد، زمان پردازنده، رم و سایر منابع سخت افزاری رایانه بیشتر برای حفظ عملکرد زیرسیستم حفاظتی صرف می شود و منابع کمتری برای برنامه های کاربردی باقی می ماند. در برخی موارد، برای مثال، اگر سیستم عامل از کنترل دسترسی معتبر با کنترل جریان اطلاعات پشتیبانی کند، زیرسیستم حفاظت از سیستم عامل می تواند بیش از نیمی از منابع سخت افزاری رایانه را مصرف کند.

4 حفظ یک سیاست امنیتی بسیار محکم می تواند بر قابلیت اطمینان سیستم عامل تأثیر منفی بگذارد. یکی از نمونه‌های چنین سیاست امنیتی در پرسش‌های متداول Windows NT توضیح داده شده است. Windows NT به مدیران اجازه می دهد تا حقوق فرآیندهای سیستم را برای دسترسی به اشیاء سیستم عامل محدود کنند. اگر کاربر شبه SISTEM که فرآیندهای سیستم از طرف او اجرا می شود، از دسترسی به فایل های اجرایی فرآیندهای سیستم محروم شود، سیستم عامل، همانطور که انتظار دارید، نمی تواند بوت شود. در این حالت، یک سیاست امنیتی بیش از حد سخت‌گیرانه منجر به از کار افتادن آنی سیستم عامل می‌شود، در موارد دیگر، چنین سیاست امنیتی می‌تواند منجر به خطاها و خرابی‌های سخت در فرآیند کارکرد سیستم عامل شود که حتی خطرناک تر.

بنابراین، هنگام تعریف یک خط مشی امنیتی کافی، نباید سعی کنید به بالاترین سطح ممکن امنیت سیستم عامل دست یابید. سیاست امنیتی مناسب و بهینه یک سیاست امنیتی است که نه تنها به مزاحمان اجازه می دهد تا اقدامات غیرمجاز انجام دهند، بلکه منجر به اثرات منفی ذکر شده در بالا نمی شود.

هیچ سیاست امنیتی کافی برای همه موارد وجود ندارد. اینکه کدام خط مشی امنیتی کافی خواهد بود نه تنها با معماری سیستم عامل، بلکه با پیکربندی تعیین شده آن نیز تعیین می شود. برنامه های کاربردیو غیره. یک سیاست امنیتی که برای یک سیستم عامل معین کافی است، احتمالاً برای نمونه دیگری از همان سیستم عامل ناکافی است. اکثر سیستم عامل های مدرن کاملاً همه کاره هستند و می توان از آنها برای حل طیف گسترده ای از وظایف استفاده کرد. می توان از یک سیستم عامل برای اطمینان از عملکرد یک سیستم بانکی خودکار، یک وب سرور و یک سیستم مدیریت اسناد الکترونیکی استفاده کرد. بدیهی است که تهدیدات امنیتی برای هر سه کاربرد سیستم عامل کاملاً متفاوت است و بنابراین، یک سیاست امنیتی مناسب در هر مورد متفاوت خواهد بود.

تعریف و حفظ یک خط مشی امنیتی مناسب سیستم عامل به طور کلی می تواند به چند مرحله تقسیم شود.

1. تحلیل تهدید.مدیر سیستم عامل تهدیدات امنیتی احتمالی را برای این نمونه از سیستم عامل در نظر می گیرد. در میان تهدیدات احتمالی، خطرناک ترین آنها متمایز است، محافظتی که باید از آن حداکثر نیرو و منابع را اختصاص دهید.

2. تشکیل الزامات برای سیاست امنیتی... مدیر تعیین می کند که از چه ابزارها و روش هایی برای محافظت در برابر تهدیدات خاص استفاده شود. به عنوان مثال، محافظت در برابر دسترسی غیرمجاز به برخی از شی های سیستم عامل را می توان با استفاده از کنترل دسترسی حل کرد، یا ابزار رمزنگاری، یا استفاده از ترکیبی از این وسایل. مدیر باید برای هر تهدید امنیتی سیستم عامل انتخابی مشابه داشته باشد و بهترین دفاع در برابر هر تهدید را انتخاب کند. در همان زمان، مدیر اثرات جانبی احتمالی گزینه‌های مختلف سیاست امنیتی را تجزیه و تحلیل می‌کند و میزان ظاهر شدن عوامل جانبی منفی در هر گزینه سیاست امنیتی را ارزیابی می‌کند. به عنوان یک قاعده، مدیر باید مصالحه کند و خود را به خاطر محافظت ناکافی سیستم عامل در برابر تهدیدات فردی یا مشکلات خاصی برای کاربران هنگام کار با سیستم کنار بگذارد.

3. تعریف رسمی سیاست امنیتی.مدیر به وضوح مشخص می کند که دقیقاً چگونه الزامات فرموله شده در مرحله قبل باید برآورده شوند. او تصمیم می گیرد که آیا این الزامات را می توان تنها با ابزارهای داخلی سیستم عامل برآورده کرد یا اینکه بسته های حفاظتی اضافی باید نصب شوند. در حالت دوم، نرم افزار مورد نیاز انتخاب می شود. فرموله می شوند الزامات لازمبه پیکربندی سیستم عامل و همچنین الزامات برای پیکربندی بسته های حفاظتی اضافی، در صورت لزوم نصب چنین بسته هایی. علاوه بر این، مدیر باید روشی را برای ایجاد تغییرات لازم در خط مشی امنیتی در شرایط اضطراری، به عنوان مثال، پس از شناسایی واقعیت ورود غیرمجاز توسط یک کاربر مخرب، فراهم کند. نتیجه این مرحله یک لیست دقیق از تنظیمات پیکربندی سیستم عامل و بسته های حفاظتی اضافی است که نشان می دهد در چه شرایطی چه تنظیماتی باید تنظیم شوند.

4. اجرای سیاست امنیتی.در آغاز این مرحله، مدیر سیستم عامل ایده روشنی از اینکه یک سیاست امنیتی کافی باید چگونه باشد، دارد. وظیفه این مرحله این است که پیکربندی سیستم عامل و بسته های حفاظتی اضافی را مطابق با خط مشی امنیتی که به طور رسمی در مرحله قبل تعریف شده است، درآورد.

5. نگهداری و اصلاح سیاست امنیتی.در این مرحله سیستم عامل مطابق با خط مشی امنیتی تعریف شده در مرحله سوم عمل می کند. وظیفه مدیر نظارت بر رعایت سیاست امنیتی و ایجاد تغییرات لازم با ظاهر شدن تغییرات در عملکرد سیستم عامل است. به عنوان مثال، اگر یک محصول نرم افزاری جدید بر روی سیستم عامل نصب شده باشد، ممکن است لازم باشد سیاست امنیتی به گونه ای تنظیم شود که محصول نرم افزاری بتواند به طور عادی کار کند.

استانداردهای امنیتی اتاق عملسیستم های

هیچ استاندارد امنیتی خاصی برای سیستم عامل ها وجود ندارد. برای ارزیابی امنیت سیستم عامل ها از استانداردهای توسعه یافته برای سیستم های کامپیوتری به طور کلی استفاده می شود.

معروف ترین استاندارد برای امنیت سیستم های کامپیوتری، معیارهای ارزیابی سیستم کامپیوتری مورد اعتماد است که توسط وزارت دفاع ایالات متحده در سال 1983 ایجاد شد. حداقل حفاظت، عملاً هیچ حفاظتی وجود ندارد) تا A1 (حداکثر حفاظت).

کلاس D1. بدون نیاز این کلاس شامل تمامی سیستم عامل هایی است که الزامات بالاترین کلاس ها را برآورده نمی کنند.

کلاس C1. سیستم عامل از کنترل دسترسی انتخابی (اختیاری) پشتیبانی می کند. کاربری که شروع به کار با سیستم می کند باید هویت خود را تایید کند (تایید شود).

کلاس C2. تمام الزامات کلاس C1 برآورده شده است. همه موضوعات و اشیاء سیستم عامل دارای شناسه های منحصر به فرد هستند. تمام اقدامات همه موضوعات دسترسی که به صراحت مجاز نیستند ممنوع است. رویدادهایی که به طور بالقوه برای حفظ امنیت سیستم عامل خطرناک هستند، در یک گزارش ویژه (گزارش حسابرسی) ثبت می شوند که فقط توسط کاربران ممتاز قابل اجرا است. تمام اطلاعات حذف شده از رم رایانه یا از رسانه های ذخیره سازی خارجی به صورت فیزیکی حذف می شوند و متعاقباً توسط هیچ موضوعی قابل دسترسی نیست.

کلاس B1. تمام الزامات کلاس C2 برآورده شده است. تمایز معتبر (اجباری) دسترسی به اشیاء سیستم عامل پشتیبانی می شود. پشتیبانی از برچسب زدن اطلاعات صادر شده

کلاس B2. تمام الزامات کلاس B1 برآورده شده است. زیرسیستم امنیتی سیستم عامل یک مدل امنیتی به طور رسمی تعریف شده و به خوبی مستند شده را پیاده سازی می کند. کانال های مخفی نشت اطلاعات نظارت می شود. رابط زیرسیستم حفاظتی به طور واضح و رسمی تعریف شده است، معماری و اجرای آن به طور کامل مستند شده است. الزامات دقیق تری برای شناسایی، احراز هویت و کنترل دسترسی ارائه شده است.

بسیاری از سیستم عامل های معروف الزامات کلاس C2 را برآورده می کنند: تعدادی از نسخه های یونیکس، Wndows NT، OS / 400، VAX / VMS و IBM MVS با بسته RACF. سیستم عامل های بسیار کمی برای رایانه های شخصی وجود دارد که الزامات کلاس های حفاظت بالاتر را برآورده می کند. این امر از یک سو با «شدت منابع» بالای زیرسیستم‌های حفاظتی که الزامات کلاس B1 و بالاتر را برآورده می‌کنند، و از سوی دیگر با مشکلاتی در حصول اطمینان از عملکرد عادی نرم‌افزارهای رایج در چنین عملیاتی توضیح داده می‌شود. سیستم های. اگر الزامات کلاس C2 اجازه استفاده از نرم افزار توسعه یافته برای محیط های نرم افزاری دیگر را در یک سیستم عامل محافظت شده می دهد (به عنوان مثال، Microsoft Office برای ویندوز 95 را می توان در Windows NT اجرا کرد)، در این صورت الزامات برای کلاس های حفاظت بالاتر آنقدر سخت است که به طور قابل توجهی با عملکرد برنامه های کاربردی توسعه یافته بدون در نظر گرفتن این الزامات تداخل ایجاد می کند. به عنوان مثال، یک ویرایشگر متن مایکروسافت ورد که در سیستم عاملی راه اندازی می شود که الزامات کلاس B1 را برآورده می کند، هنگام باز کردن اسناد با برچسب های امنیتی مختلف به طور همزمان به درستی عمل نمی کند.

از معایب اصلی کتاب نارنجی می توان به موارد زیر اشاره کرد:

ابزار رمزنگاری محافظت از اطلاعات به هیچ وجه در نظر گرفته نمی شود.

مسائل حصول اطمینان از محافظت از سیستم در برابر حملات با هدف غیرفعال کردن موقت سیستم (حملات کلاس "انکار سرویس") عملاً در نظر گرفته نمی شود.

توجه کافی به مسائل محافظت از سیستم محافظت شده در برابر اثرات منفی اشکالات نرم افزاری و ویروس های رایانه ای نمی شود.

مسائل مربوط به تعامل چندین نسخه از سیستم های محافظت شده در یک شبکه کامپیوتری محلی یا جهانی با جزئیات در نظر گرفته نشده است.

الزامات حفاظت از نشت اطلاعات محرمانهاز یک سیستم محافظت شده بر روی ذخیره اطلاعات محرمانه در پایگاه های داده متمرکز هستند و برای محافظت از جریان اسناد الکترونیکی چندان مناسب نیستند.

استانداردهای امنیتی و سیاست امنیتی کافی

اگر یک سیستم عامل بر اساس هر کلاس امنیتی از یک سیستم استاندارد خاص تأیید شود، این به هیچ وجه به این معنی نیست که اطلاعات ذخیره شده و پردازش شده در این سیستم مطابق با کلاس مربوطه محافظت می شود. امنیت یک سیستم عامل نه تنها با معماری آن، بلکه توسط سیاست امنیتی فعلی تعیین می شود.

به عنوان یک قاعده، صدور گواهینامه یک سیستم عامل برای کلاس خاصی از حفاظت با تهیه الزامات برای یک سیاست امنیتی کافی همراه است. سختگیرانهاجرای آن امنیت یک نمونه خاص از سیستم عامل الزامات کلاس حفاظت مربوطه را برآورده می کند.

به عنوان مثال، اجازه دهید برخی از الزامات پیکربندی سیستم عامل Windows NT را در نظر بگیریم که باید برای مطابقت با کلاس امنیتی سیستم عامل C2 از "کتاب نارنجی" رعایت شود:

در دیسکهای سختفقط سیستم فایل NTFS استفاده می شود.

استفاده از رمزهای عبور کمتر از شش کاراکتر ممنوع است.

شبیه سازی OS / 2 و POS1X ممنوع است.

دسترسی ناشناس و مهمان ممنوع است.

راه اندازی هر گونه دیباگر ممنوع است.

کلید پاور و دکمه RESET برای کاربران قابل دسترسی نیست.

خاموش کردن سیستم عامل بدون ورود کاربر به سیستم ممنوع است.

خط مشی امنیتی ممیزی به گونه ای طراحی شده است که وقتی گزارش امنیتی سرریز می شود، سیستم عامل از کار می افتد (هنگ می کند). پس از آن، بازیابی عملکرد سیستم فقط توسط مدیر انجام می شود.

اشتراک گذاری منابع رسانه ای قابل جابجایی (فلاپی دیسک، سی دی رام و غیره) بین کاربران ممنوع است.

نوشتن در فهرست راهنمای سیستم و فایل های اولیه سیستم عامل فقط برای مدیران و فرآیندهای سیستم مجاز است.

هنگام تعریف یک خط مشی امنیتی کافی، مدیر سیستم عامل باید در درجه اول بر محافظت از سیستم عامل در برابر تهدیدات خاص برای امنیت آن تمرکز کند. متأسفانه امروزه معمولاً موقعیتی پیش می آید که یک مدیر الزامات یک خط مشی امنیتی را نه بر اساس مجموعه ای از تهدیدها که باید در برابر آنها محافظت شود، بلکه بر اساس برخی توصیه های انتزاعی برای حفظ امنیت یک سیستم عامل خاص تشکیل می دهد. بیشتر اوقات ، الزامات استانداردهای مختلف امنیتی برای سیستم های رایانه ای به عنوان چنین توصیه هایی در نظر گرفته می شود - "محبوب ترین" استانداردهای کتاب نارنجی است. در نتیجه، این امکان وجود دارد که یک سیستم عامل دارای گواهینامه برای یک کلاس حفاظتی بسیار بالا، در برابر برخی تهدیدات آسیب پذیر شود، حتی اگر خط مشی امنیتی الزامات کلاس حفاظت مربوطه را برآورده کند.

معرفی

دو رویکرد اصلی برای تفسیر مفهوم محافظت شده وجود دارد سیستم خودکارقابل استفاده برای سیستم عامل ها (OS). رویکرد اول نشان می‌دهد که امنیت سیستم‌عامل با اجرای برخی از الزامات امنیتی مشخص شده اولیه، از جمله وجود مجموعه خاصی از مکانیسم‌های حفاظتی، بررسی عدم وجود لیست از پیش تعریف‌شده آسیب‌پذیری‌ها و غیره تضمین می‌شود. در رویکرد دوم، امکان استفاده از سیستم عامل به عنوان بخشی از یک سیستم خودکار (AS) در نظر گرفته شده است. صاحبان آنها (کاربران) حیاتی در نظر گرفته می شوند و بنابراین سیستم عامل باید مجموعه ای از ابزارهای حفاظتی مناسب برای تهدیدات امنیتی این سیستم های خاص را فراهم کند. در نگاه اول، این دو رویکرد با یکدیگر تناقض ندارند، زیرا بعید است که سخنرانان منتقد از راه حل هایی استفاده کنند که حداقل اجرا نمی شوند. حداقل الزاماتبرای ایمنی در همان زمان، سیستم عامل، زمانی که تمام الزامات امنیتی برآورده می شود، می تواند از خارج، به عنوان مثال، توسط توسعه دهنده آن، کنترل شود. V شرایط مشخص شدهرویکرد دوم نشان می‌دهد که راه‌حل‌های محافظت‌شده به معنای راه‌حل‌هایی هستند که در ادبیات انگلیسی زبان با عبارت Trured یا به تعبیر داخلی، قابل اعتماد نشان داده می‌شوند.

بنابراین، توصیه می شود یک سیستم عامل محافظت شده (معتمد) را در نظر بگیرید که نه تنها الزامات امنیتی تعیین شده را به طور پیشین اجرا می کند، بلکه برای تهدیدات امنیتی خاص سیستم های خودکار داخلی نیز مناسب است، از جمله که امکان نفوذ غیرمجاز بر کار آن وجود ندارد. از بیرون، در حالی که مالک (کاربر) یک سیستم عامل محافظت شده باید ایده روشنی از الگوریتم عملکرد مکانیسم های حفاظتی آن در همه حالت های عملکرد داشته باشد.

این نیاز در حال تبدیل شدن به فوریت بیشتر و بیشتر است سال های گذشته. به روز رسانی خودکار، اطلاع رسانی خودکار توسعه دهندگان در مورد خطاهای نرم افزار، انواع خدمات آنلاین به طور قابل توجهی کیفیت مصرف کننده برنامه و نرم افزار سیستم عامل سیستم عامل را افزایش می دهد، اما، از طرف دیگر، همه چیز را ایجاد می کند. امکانات بیشتربرای سازندگان نرم افزار و، از جمله سیستم عامل، برای نظارت بر اقدامات کاربر. برای تعدادی از کاربردهای سیستم عامل های محافظت شده، موضوع اعتماد به توسعه دهنده آن مهم تر از حجم و کیفیت اجرای مکانیزم های امنیتی استاندارد در این سیستم عامل است.

این ملاحظات است که می تواند رشد علاقه به سیستم عامل های محافظت شده داخلی را توضیح دهد که اخیراً در فدراسیون روسیه از طرف ارگان های دولتی و شرکت های صنعتی مورد توجه قرار گرفته است. یک انگیزه اضافی در این زمینه تصمیم دولت فدراسیون روسیه برای ممنوعیت پذیرش نرم افزارهای خارج از کشور به منظور خرید برای رفع نیازهای ایالتی و شهرداری بود. پیش‌بینی می‌شود که در صورت تصویب و تصویب برنامه توسعه بخش روسی اینترنت، «تا سال 2025، تمام سازمان‌های دولتی و شرکت‌های استراتژیک به رایانه‌های روسی مجهز خواهند شد. پایه عنصربا یک سیستم عامل داخلی در هیئت مدیره.

در شرایط مدرن، یک سیستم‌عامل محافظت‌شده داخلی امیدوارکننده باید شرایط زیر را برآورده کند:

• الزامات تضمین استقلال فن آوری (جایگزینی واردات) فدراسیون روسیه در مهمترین زمینه های اطلاعات، مخابرات و ارتباطات را برآورده کنید.
• مناسب برای عملکرد در شبکه های کامپیوتری، هم جدا شده و هم متصل به اینترنت (یا سایر شبکه های مخابراتی)، از جمله شبکه هایی که جهت پردازش اطلاعات طبقه بندی شده به عنوان اسرار دولتی یا داده های شخصی هستند.
• پیاده سازی مکانیسم های مدرن برای تضمین امنیت اطلاعات با در نظر گرفتن امکان پردازش اطلاعات طبقه بندی شده به عنوان اسرار دولتی در این سیستم عامل، هم از نظر برآورده کردن الزامات رسمی اسناد و استانداردهای نظارتی مربوطه و هم از نظر ارائه حفاظت واقعی در برابر امنیت فعلی. تهدیدها

توسعه‌دهنده چنین سیستم‌عاملی باید زیرساخت خوبی برای توسعه و نگهداری نرم‌افزارهای کاربردی و سیستمی خود داشته باشد. باید مکانیسم هایی برای اطمینان از اطمینان به توسعه دهنده سیستم عامل، امکان اثبات علمی ایمنی راه حل های نرم افزاری و سخت افزاری پیاده سازی شده در آن پیاده سازی شود.

سوالات مطالعه (بخش اصلی):

1. مروری بر سیستم عامل های محافظت شده خانواده لینوکس

اعتقاد بر این است که سیستم عامل لینوکس (به طور دقیق تر، GNU / Linux) در سال 1991 توسط برنامه نویس 21 ساله فنلاندی لینوس توروالدز ایجاد شد. در واقع، L. Torvalds هسته سیستم عامل Minix را از ابتدا بازنویسی کرد، یک "کلون" غیرقابل توجه از سیستم عامل یونیکس.

برای مدت طولانی، تنها مزیت لینوکس نسبت به سایر سیستم های یونیکس، خلوص مجوز بود کد برنامهسیستم عامل لینوکس، که به شما اجازه می دهد تا طیف گسترده ای از سیستم های اطلاعاتی را بدون نگرانی در مورد مشکلات احتمالی مجوزها مستقر کنید. تا حدود سال 2000، لینوکس از دیگر سیستم‌عامل‌های یونیکس متمایز نبود، و از نظر عملکرد و قابلیت اطمینان به طور قابل توجهی از بسیاری از آنها پایین‌تر بود.

برای مدت طولانی، باز بودن کد برنامه سیستم عامل لینوکس تنها عاملی بود که این سیستم عامل را برای توسعه دهندگان نرم افزار کاربردی جذاب می کرد. با این حال، با گذشت زمان، انواع نرم افزارهای اقتباس شده برای سیستم عامل لینوکس به "توده بحرانی" خاصی رسیده است و وضعیت تغییر کرده است. با تبدیل شدن سیستم عامل لینوکس به استاندارد واقعی در دنیای سیستم عامل های یونیکس، برنامه نویسان بیشتر و بیشتر نرم افزارهای کاربردی و سیستمی را طراحی کردند که برای اجرای سیستم عامل لینوکس طراحی شده بودند و اجزای سیستم عامل تحت آزمایش و بهینه سازی دقیق تری قرار گرفتند. . از زمانی، افزایش محبوبیت لینوکس به یک فرآیند خودپایدار تبدیل شده است، و اکنون این سیستم‌عامل‌ها بیش از 90 درصد از سیستم‌عامل خانواده یونیکس را تشکیل می‌دهند.

هنگام مقایسه سیستم‌عامل خانواده لینوکس با سیستم‌عامل محبوب‌تر خانواده‌های مایکروسافت ویندوز یا سیستم‌عامل مک، یک ویژگی مشخصه سیستم‌های Lin ux قابل توجه است - آنها در ابتدا بیشتر بر روی کاربران حرفه‌ای بسیار ماهر متمرکز بودند. نسبت قابل توجهی از اقدامات مورد نیاز برای پیکربندی سیستم و در برخی موارد برای وارد کردن آن به آن شرایط کار، توسط ویرایش دستیفایل های پیکربندی، ویرایش یا نوشتن از ابتدا اسکریپت های مختلف و غیره. به همین دلیل، نسخه های اولیه سیستم عامل لینوکس عملاً برای کاربر عمومی غیر قابل دسترس بود، اکنون این اشکال تا حد زیادی برطرف شده است، نسخه های مدرن سیستم عامل لینوکس فقط نیاز دارند. حداقل آموزش

اغلب، کاربران حتی نمی دانند که با سیستم عاملی از این خانواده کار می کنند، به عنوان مثال، سیستم عامل محبوب تلفن همراه اندروید در واقع یک بسته نرم افزاری سیستمی است که بر روی پلت فرم یک سیستم عامل از خانواده لینوکس مستقر شده است.

در میان بسیاری از کاربران سیستم عامل لینوکس، این عقیده وجود دارد که این سیستم عامل با یک زیرسیستم حفاظتی غیرمعمول قدرتمند و عملاً آسیب ناپذیر متمایز می شود. استدلال‌هایی که از این دیدگاه حمایت می‌کنند معمولاً به عنوان داشتن مکانیزم‌های کنترل دسترسی اختیاری، احراز هویت و ممیزی اولیه که مشابه یا حتی پایین‌تر از سایر سیستم‌های عامل هستند، ذکر می‌شوند. همچنین این بحث وجود دارد که فقدان تقریباً کامل نرم افزارهای مخرب برای سیستم عامل های لینوکس نتیجه این واقعیت است که این سیستم در برابر محافظت بسیار بهتری دارد. حملات ویروسیبه عنوان مثال، سیستم عامل خانواده مایکروسافت ویندوز. این کاملا اشتباه است. در واقع، ویروس های سیستم عامل لینوکس عملاً "در طبیعت" جامعه هکرها یافت نمی شوند، اما این به هیچ وجه به دلیل امنیت بالای این سیستم عامل ها نیست. برای یک برنامه نویس معمولی دشوار نیست که مطمئن شود نوشتن یک ویروس کامپیوتری یا سایر برنامه های مخرب برای یک سیستم عامل لینوکس دشوارتر نیست (به استثنای برخی از کلاس های باریک). بد افزار) از نوشتن یک برنامه مشابه، به عنوان مثال، برای سیستم عامل خانواده مایکروسافت ویندوز. تعداد ناچیز ویروس‌های لینوکس عمدتاً به این دلیل است که توسعه‌دهندگان بدافزار ترجیح می‌دهند پلتفرم‌های نرم‌افزاری محبوب‌تری را هدف قرار دهند، که فعالیت‌های غیرقانونی مجرمان سایبری بیشترین درآمد را برای آنها ایجاد می‌کند.

ویژگی های امنیتی اساسی سیستم عامل لینوکس از اولین نسخه های سیستم عامل یونیکس که در اوایل دهه 70 قرن گذشته توسعه یافتند به ارث رسیده است. بر اساس الزامات سازگاری با نسخه های قدیمی تر، سیستم عامل لینوکس همچنان از تعدادی مکانیسم و ​​مفاهیم امنیتی قدیمی پشتیبانی می کند. به ویژه، "نابهنگاری" زیر در زیرسیستم های حفاظتی اکثر این سیستم عامل ها وجود دارد:

• همه اشیاء دسترسی (موجودات) باید به عنوان اشیاء فایل تفسیر شوند، ویژگی های امنیتی انواع دیگر اشیاء را نمی توان به درستی توصیف کرد. به معنی منظمسیستم عامل
• شناسه‌های حساب کاربری منحصربه‌فرد جهانی پشتیبانی نمی‌شوند، همه شناسه‌های کاربر و گروه فقط در یک نمونه سیستم‌عامل منحصربه‌فرد هستند:
• مجموعه حقوق دسترسی موضوعات (فرآیندها) به نهادها (فایل ها، دایرکتوری ها) بسیار محدود است، تنها سه حق دسترسی پشتیبانی می شود: خواندن، نوشتن و اجرا، و مالک هر نهاد نیز مشخص شده است.
• امتیازات superuser root عملا نامحدود است.
• هیچ مکانیزمی برای تخصیص خودکار ویژگی های امنیتی به موجودیت های تازه ایجاد شده بر اساس ویژگی های امنیتی کانتینرها (کاتالوگ ها) که این موجودیت ها در آن ایجاد می شوند وجود ندارد.
• یک مکانیسم نامناسب و بالقوه خطرناک SUID / SGID برای تغییر پویا قدرت سوژه های دسترسی استفاده می شود.
• مکانیسم‌های جعل هویت افراد دسترسی که دسترسی مشتری به فرآیند سرور را فراهم می‌کنند پشتیبانی نمی‌شوند.
• پشتیبانی نشده تولید خودکارپیام‌های حسابرسی زمانی که موضوعات خاصی به نهادهای خاصی اشاره می‌کنند.
• ابزارهای پشتیبانی شده برای به حداقل رساندن حقوق کاربر بسیار ابتدایی هستند.
• کنترل یکپارچگی اجباری پشتیبانی نمی شود.
• ایزوله پشتیبانی نمی شود محیط نرم افزار، حتی به طور جزئی

به طور جداگانه، شایان ذکر است که مشکلات امنیتی رابط گرافیکی X Window System که در نسخه های مدرن سیستم عامل لینوکس برای تعامل با فرآیندهای کاربر مورد استفاده قرار می گیرد. علاقه مندان به لینوکس دوست دارند سیستم عامل مایکروسافت ویندوز را به دلیل امنیت ناکافی زیرسیستم گرافیکی آن مورد انتقاد قرار دهند، به عنوان مثال: "در مایکروسافت ویندوز NT، هر فرآیند، صرف نظر از سطح امتیاز آن، می تواند پیامی را به پنجره یک فرآیند دیگر ارسال کند (از جمله یک فرآیند بیشتر). یک ممتاز!)، و هیچ راهی برای تعیین فرستنده پیام وجود ندارد! ... ما پنجره ای از برخی از برنامه های ممتاز را پیدا می کنیم (و چنین فرصتی داریم)، ​​کنترل عنصر کنترل مورد علاقه خود را دریافت می کنیم ( دکمه ها، آیتم های منو، ویرایش خطوط) و ... ورودی کاربر را شبیه سازی می کنیم !!! روند ممتاز همه چیز را برای ما انجام خواهد داد بدون اینکه به چیزی شک کنیم!»

در واقع، این مشکل نه تنها برای سیستم عامل های خانواده مایکروسافت ویندوز معمولی است. در سال 1994، R. Braaten در یک پست هیجان انگیز در کنفرانس comp.security. یونیکس تهدید برنامه گرافیکی X Window System مبنی بر سرقت اطلاعات محرمانه خطاب به دیگری را فرموله کرده است. برنامه گرافیکی... در سیستم عامل خانواده مایکروسافت ویندوز، از سیستم عامل شروع می شود ویندوز ویستا، کنترل اجباری یکپارچگی موجودیت های گرافیکی معرفی شد که امنیت زیرسیستم گرافیکی را به میزان قابل توجهی افزایش داد، اما چنین اتفاقی در سیستم پنجره X رخ نداد.

چندین بار در روسیه و خارج از کشور تلاش هایی برای ایجاد یک سیستم عامل محافظت شده بر اساس سیستم عامل خانواده لینوکس انجام شده است. از نظر تاریخی می توان در نظر گرفت که اولین پروژه در این راستا سیستم عامل Linux-Mandrake Russian Edition است که توسط گروهی از علاقه مندان در سال های 1999-2000 توسعه یافته است. و بعداً به پروژه ALT Linux OS که توسط Alt Linux پشتیبانی می شود "رشد" کرد. از سال 2005، توزیع سیستم عامل ALT Linux کاملا مستقل بوده است. زیرسیستم امنیتی ALT Linux OS چندین نوآوری جالب دارد (ذخیره جداگانه داده های احراز هویت کاربران مختلف، به حداقل رساندن تعداد برنامه های SUID و SGID)، که با این حال، به طور قابل توجهی بر امنیت کلی سیستم عامل تأثیر نمی گذارد. بر این اساس، می توان فرض کرد که توسعه دهندگان سیستم عامل لینوکس ALT با استفاده از این سیستم عامل عمدتاً در سازمان هایی که هیچ الزامات بالایی برای امنیت اطلاعات ذخیره شده و پردازش شده وجود ندارد (به عنوان مثال، در مدارس، دانشگاه ها) هدایت می شوند. ، و غیره.).

Suid، setuid، و setgid (به ترتیب مخفف عبارت "set user ID on execution" و "set group ID upon execution") پرچم های مجوز یونیکس هستند که به کاربران اجازه می دهند فایل های اجرایی را به ترتیب با حقوق مالک یا گروهی اجرا کنند. فایل اجرایی

در سیستم های مشابه یونیکس، برنامه با حقوق کاربری که تماس گرفته راه اندازی می شود برنامه مشخص شده... این امنیت اضافی را فراهم می کند، زیرا یک فرآیند دارای امتیاز کاربر نمی تواند به دسترسی نوشتن به فایل های مهم سیستم، مانند / etc / passwd که متعلق به root superuser است، دسترسی پیدا کند. اگر بیت suid روی یک فایل اجرایی تنظیم شده باشد، در حین اجرا، این برنامه به طور خودکار "userID موثر" را به شناسه کاربری که این فایل را دارد تغییر می دهد. یعنی صرف نظر از اینکه چه کسی این برنامه را راه اندازی می کند، در هنگام اجرا از حقوق صاحب این فایل برخوردار است.

بیت suid توسط دنیس ریچی اختراع شد و در سال 1979 توسط AT&T در ایالات متحده ثبت شد. بعداً، پتنت 4135240 "محافظت از محتویات فایل داده" در دسترس عموم قرار گرفت.

برنامه ای با مجموعه بیت suid "بالقوه خطرناک" است. در یک مورد "عادی"، او اجازه نخواهد داد کاربر معمولیکاری را انجام دهید که خارج از اختیارات او است (مثلاً برنامه passwd فقط به کاربر اجازه می دهد رمز عبور خود را تغییر دهد). اما، حتی یک خطای جزئی در چنین برنامه ای می تواند منجر به این واقعیت شود که یک مهاجم می تواند آن را مجبور به انجام برخی اقدامات دیگر کند که توسط نویسنده برنامه ارائه نشده است.

اولین تلاش برای ساخت یک سیستم‌عامل بسیار ایمن بر اساس سیستم‌عامل مبتنی بر لینوکس ظاهراً سیستم‌عامل فونیکس بود که از سال 2001 در دانشگاه پلی‌تکنیک دولتی سنت پترزبورگ توسعه یافت. این سیستم‌عامل به میزان محدودی در Jet Infosystems مورد استفاده قرار گرفت.

برای مدتی، امن ترین سیستم عامل روسی خانواده لینوکس، سیستم موبایل نیروهای مسلح (MSVS) بود که به دستور وزارت دفاع روسیه توسط موسسه تحقیقاتی تمام روسیه برای اتوماسیون کنترل در غیر صنعتی توسعه یافت. Sphere (VNIINS) بر اساس سیستم عامل لینوکس Red Hat Enterprise. OS WSWS در سال 2002 برای تامین نیروهای مسلح به کار گرفته شد. برای سال‌های متمادی از آن به طور گسترده در انواع سیستم‌های کامپیوتری نظامی و دو منظوره استفاده می‌شود؛ نسخه‌های دسکتاپ و سرور برای کار بر روی سیستم‌های معمولی طراحی شده‌اند. کامپیوترهای خانگی... آخرین نسخه WSWS 5.0 تا به امروز که در سال 2011 تایید شده است، حاوی هسته است نسخه لینوکس 2.6.32 و glibc نسخه 2.5 ساخت 2006.

glibc کتابخانه گنو سی است. Glibc یک کتابخانه C است که فراخوانی های سیستمی و توابع اولیه مانند open، malloc، printf و غیره را ارائه می دهد. کتابخانه C برای همه برنامه های مرتبط به صورت پویا استفاده می شود. این توسط بنیاد نرم افزار آزاد برای سیستم عامل های گنو نوشته شده است. glibc تحت مجوز GNU LGPL منتشر شده است.

نصب نرم افزار اضافی در WSWS بسیار دشوار است.

در سال 2006، چین شروع به عرضه سیستم عامل Kylin به ارتش و سازمان های دولتی کرد که توسط دانشگاه ملی فناوری های دفاعی چین بر اساس سیستم عامل FreeBSD توسعه یافته بود. نام OS به معنای حیوانی افسانه ای است که اغلب در فولکلور چینی همراه با اژدها و ققنوس ذکر شده است. کیت توزیع سیستم عامل Kylin مدتی است که برای دانلود در دسترس بوده است، به گفته کارشناسان، این سیستم عامل دارای هیچ مکانیزم امنیتی برجسته ای نیست، هیچ کس از پشتیبانی از کنترل دسترسی اجباری، کنترل یکپارچگی اجباری، sandboxing و غیره اشاره ای نمی کند. در سال 2013 Ubuntu Kylin پروژه OS به طور رسمی راه اندازی شد، ظاهرا هیچ ارتباطی با Kylin OS نداشت، به جز نام. Ubuntu Kylin یک نسخه کاملاً پشتیبانی شده از لینوکس اوبونتو است چینی هاو چندین برنامه های از پیش نصب شدهمخصوص چین (تقویم قمری، دسترسی آسان به شبکه های اجتماعی چینی، ارائه دهندگان موسیقی چینی و غیره).

کیت توزیع در www.ubuntukylin.com موجود است.

شواهدی وجود دارد که در نتیجه نصب چندین بسته نرم افزاری اضافی، توزیع معمولی اوبونتو به راحتی به سیستم عامل Ubuntu Kylin OS تبدیل می شود. هیچ اطلاعاتی مبنی بر تفاوت زیرسیستم امنیتی این سیستم عامل با زیرسیستم امنیتی سیستم عامل لینوکس اوبونتو وجود ندارد.

خانواده سیستم عامل های داخلی ROSA از سال 2009 توسط گروه شرکت های ROSA مبتنی بر سیستم عامل لینوکس ماندریوا تولید می شود و در حال حاضر آخرین شعبه پشتیبانی شده آن است. خانواده ROSA OS شامل OS محافظت شده تایید شده ROSA Chrom و ROSA Nickel (پشتیبانی از کنترل دسترسی اجباری اعلام شده است)، ROSA Cobalt و همچنین چندین توزیع رایگان است که کیفیت مصرف کننده آنها توسط کاربران بسیار رتبه بندی شده است. در بهار سال 2015، STC IT ROSA به یکی از پنج شرکت روسی تبدیل شد که درخواست پشتیبانی دولتی برای محصولات نرم افزاری داخلی کردند.

در سال 2010، جوانا روتکووسکا، محقق مشهور امنیت سیستم عامل لهستانی، اعلام کرد که در حال توسعه یک سیستم عامل امن Qubes بر اساس سیستم عامل است. فدورا لینوکس... ابزارهای حفاظتی اضافی برای این سیستم عامل بر اساس کپسوله سازی اعمال شده و برنامه های سیستمیبه ماشین های مجازی مجزا تبدیل می شوند که تعامل آنها از طریق هایپروایزر Xen پیاده سازی می شود.

Hypervisor (eng. Hypervisor؛ از یونانی باستان. چندین سیستم عامل را روی یک کامپیوتر میزبان اجرا می کند. هایپروایزر همچنین جداسازی سیستم عامل از یکدیگر، حفاظت و امنیت، اشتراک منابع بین سیستم عامل های مختلف در حال اجرا و مدیریت منابع را فراهم می کند.

هایپروایزر همچنین می تواند (و باید) وسایل ارتباط و تعامل با یکدیگر را فراهم کند (مثلاً از طریق تبادل فایل یا اتصالات شبکه) به گونه ای که گویی این سیستم عامل ها بر روی کامپیوترهای فیزیکی مختلف اجرا می شوند.

خود هایپروایزر به نوعی یک سیستم عامل مینیمال (میکروکرنل یا نانوهسته) است. این سیستم عامل های تحت کنترل خود را با یک سرویس ماشین مجازی، مجازی سازی یا شبیه سازی واقعی (فیزیکی) ارائه می دهد. سخت افزارماشین خاص و این ماشین های مجازی را مدیریت می کند و منابعی را برای آنها تخصیص می دهد و آزاد می کند. هایپروایزر به هر یک از ماشین های مجازی با یک سیستم عامل خاص اجازه "روشن کردن"، راه اندازی مجدد، "خاموش" مستقل را می دهد. با این حال، سیستم عاملی که در یک ماشین مجازی تحت کنترل یک هایپروایزر اجرا می شود، ممکن است، اما مجبور نیست، "بداند" که در یک ماشین مجازی اجرا می شود و نه بر روی سخت افزار واقعی.

انتقال داده بین ماشین‌های مجازی در سیستم‌عامل Qubes مبتنی بر یک خط‌مشی امنیتی در سراسر سیستم است که می‌تواند به طور بالقوه از کنترل دسترسی اجباری، کنترل یکپارچگی اجباری، جعبه‌شنی ایمنی و غیره پشتیبانی کند. در غیر این صورت کار کاربر مانند یک سیستم عامل لینوکس معمولی فدورا انجام می شود. ویندوز برنامه های متعلق به ماشین های مجازی مختلف بر روی یک دسکتاپ مشترک اجرا می شوند، گویی حالت بدون درز در نرم افزار فعال است. جعبه مجازی(در بومی سازی روسی این حالت "حالت یکپارچه سازی نمایش" نامیده می شود).

بعداً، ایده مشابهی توسط شرکت داخلی "NeoBIT" اجرا شد که یک سیستم عامل ترکیبی "Linux over Febos" را تولید کرد که در آن برنامه های کاربردی در ماشین های مجازی سیستم عامل لینوکس اجرا می شوند که به نوبه خود به عنوان برنامه های کاربردی برای عمل می کنند. سیستم عامل "فبوس" - خود توسعه یافته"NeoBIT" که هیچ ربطی به خانواده سیستم عامل لینوکس ندارد. در واقع، سیستم عامل "فبوس"، تا آنجا که از توضیحات موجود می توان قضاوت کرد، حاوی چیزی به جز یک میکروکرنل، یک هایپروایزر و یک مانیتور امنیتی نیست، تمام رابط های برنامه در ماشین های مجازی سیستم عامل لینوکس قرار می گیرند.

OS "Zarya" توسط JSC "مؤسسه تحقیقات مرکزی اقتصاد انفورماتیک و سیستم های کنترل" (TsNII EISU) به دستور وزارت دفاع روسیه در سال 2013 توسعه یافته است. این سیستم عامل مبتنی بر OS CentOS Linux است، طرح های معماری آن در دسترس است اینترنت دارای هیچ ویژگی منحصر به فردی نیست و به طور قابل توجهی آن را از سایر سیستم عامل های خانواده لینوکس متمایز می کند. برخی منابع سیستم عامل "زاریا" را به عنوان نسل بعدی سیستم عامل MSVS معرفی می کنند. سیستم عامل Zarya با بسته های نرم افزاری Libre Office، GIMP و Chromium سازگار است؛ نسخه های سیستم عامل برای دسکتاپ، سرور و سیستم های تعبیه شده وجود دارد.

در سال 2013-2014 توسط شرکت "رد سافت" به سفارش سرویس فدرالضابطان روسیه سیستم عامل "GosLinux" را توسعه دادند، همچنین بر اساس OS CentOS، که به عنوان یک سیستم عامل امن با عملکردهایی قرار می گیرد که به "دادگران اجازه می دهد تا داده های شخصی بدهکاران و مدعیان را بدون نیاز به پردازش کنند." وجوه اضافیحفاظت از اطلاعات، و همچنین اعمال می شود امضای الکترونیکبرای انتشار اسناد در در قالب الکترونیکی". وب سایت رسمی FSSP روسیه بیان می کند که "بهبودهای اصلی انجام شده توسط پیمانکار مربوط به زیرسیستم رمزنگاری و پیش پیکربندی ابزارهای امنیت اطلاعات داخلی است."

به طور کلی، با وجود نقص های امنیتی آشکار سیستم عامل لینوکس، طیف وسیعنه همیشه توسعه موفقیت آمیز سیستم عامل های محافظت شده مبتنی بر آنها، در حال حاضر سیستم عامل های این خانواده هنوز تقریباً یک پلت فرم ایده آل برای ایجاد یک سیستم عامل محافظت شده داخلی هستند. مکانیسم‌های حفاظتی گاهی بدوی و قدیمی که در سیستم‌عامل خانواده لینوکس استفاده می‌شوند، اجازه می‌دهند، بدون نیاز به بازکاری اساسی، مسدود کردن یا در نظر گرفتن ویژگی‌های آن‌ها، مکانیسم‌های مدرن کنترل دسترسی اجباری و مبتنی بر نقش، کنترل یکپارچگی اجباری را در سیستم عامل پیاده‌سازی و به دست آورند. یک توجیه نظری دقیق برای امنیت و تأیید راه حل حاصل. بنابراین، ترکیبی از قابلیت اطمینان بالا، کیفیت های قابل قبول مصرف کننده، کد منبع باز و امکان اصلاح نسبتا آسان مکانیسم های حفاظتی سیستم عامل لینوکس این امکان را فراهم می کند که بر اساس آنها یک سیستم عامل داخلی بسیار امن با هزینه بسیار کمتر ایجاد شود. تلاشی نسبت به اینکه از ابتدا ایجاد شده باشد یا بر روی پلتفرم های دیگر ساخته شده باشد.

2-معماری، هدف و زمینه های کاربرد سیستم عامل Astra Linux Special Edition ویژه منظوره

2.1. انتصاب OSSN

هنگام ساختن و نوسازی نیروگاه های هسته ای موجود، یک کار فوری استفاده از آن است راه حل های استاندارداستانداردسازی و یکسان سازی بسترهای سخت افزاری و نرم افزاری از جمله سیستم عامل، محیط های توسعه نرم افزار، سیستم ها و مجتمع های نرم افزار کاربردی برای پشتیبانی از عملکرد سرویس های اطلاعاتی فعلی سیستم خودکار. چنین رویکردی، اول از همه، با کاهش هزینه‌های استقرار و مدیریت مؤلفه‌های AU، کاهش زمان توسعه و / یا انتقال نرم‌افزار مورد نیاز برای عملکرد آنها، افزایش کارایی فرآیند آموزش برای پرسنل مدیریت و عملیات مرتبط است. زیرساخت اطلاعاتی آنها

یک جنبه اضافی که برای شرایط مدرن مرتبط است، مسائل مربوط به محدود کردن استفاده از محصولات ساخته شده خارجی در اتحادیه AU است (عمدتاً آنهایی که به نفع مقامات دولتی عمل می کنند)، که مشابه داخلی برای آن وجود دارد. به ویژه، تغییرات اعمال شده در قوانین فدرال "در مورد اطلاعات، فناوری اطلاعات و حفاظت از اطلاعات" و "در مورد سیستم قرارداد در تهیه کالاها، کارها، خدمات برای رفع نیازهای ایالتی و شهری" مستقیماً با نرخ جایگزینی واردات مرتبط است. بر اساس روند توسعه بازار نرم افزار روسیه.

علاوه بر این، در مسیر حل این مشکل عامل مهمانطباق دقیق چنین پیشرفت هایی با استانداردهای ملی در زمینه امنیت اطلاعات است، به عنوان مثال، برای ASZI GOST 51583-2014 "امنیت اطلاعات" است. روش ایجاد سیستم های خودکار در یک نسخه محافظت شده. مقررات عمومی "و الزامات سیستم های صدور گواهینامه داخلی برای ابزارهای امنیت اطلاعات برای الزامات امنیت اطلاعات.

از این نظر، OSSN به اندازه کافی بیشتر جنبه های مورد بحث در بالا را در نظر می گیرد. مطابق با مستندات فنیهدف اصلی OSSN ایجاد سیستم های خودکار در اجرای حفاظت شده (ASZI) است که اطلاعات حاوی اطلاعات را پردازش می کند. راز دولتیبا یک مهر نه بالاتر از "فوق سری". در حالت کلی، همراه با حفاظت از چنین اطلاعاتی، AS پیاده‌سازی شده با استفاده از OSSN می‌تواند از انواع اطلاعات زیر محافظت کند:

• اطلاعات محرمانه؛
• راز تجارت؛
• اطلاعات شخصی.

قابلیت های مشخص شده OSSN توسط گواهی های زیر برای انطباق شرکت کنندگان سیستم های صدور گواهینامه داخلی برای محصولات امنیت اطلاعات مطابق با الزامات امنیت اطلاعات تأیید می شود (جدول 2.1).

جدول 2.1.

این گواهی ها زمینه استفاده از OSSN را به عنوان بخشی از AS کلاس های مختلف امنیتی در برابر دسترسی غیرمجاز به اطلاعات (NSD) و سطوح کنترل عدم وجود قابلیت های اعلام نشده (NDV) به عنوان بخشی از اجزای سیستم فراهم می کند (جدول 2.2).

از جدول 2.2 نتیجه می شود که OSSN، در حالت شدید، برای استفاده در AS چند کاربره، که کاربران آن قدرت های متفاوتی برای دسترسی به اطلاعات پردازش شده (کلاس 1B) دارند، مطابق با کلاس 3 حفاظت در برابر دسترسی غیرمجاز و سطح 2 کنترل، گواهی شده است. عدم وجود NDV

بنابراین، در حال حاضر، OSSN یک سیستم عامل است که در هر سه سیستم گواهینامه ابزارهای امنیت اطلاعات برای الزامات امنیت اطلاعات تایید شده است.

2.2. معماری OSSN

اساس معماری OSSN پروژه Debian GNU / Linux است - انجمنی از توسعه دهندگان نرم افزار آزاد که اساس آن سیستم عامل خانواده GNU / Linux مبتنی بر هسته های لینوکسهسته.

در این رابطه، به طور کلی، معماری OSSN با راه حل های معماری GNU / Linux مطابقت دارد (شکل 2.1).

در عین حال، ویژگی های پیاده سازی با ویژگی های پیاده سازی سیستم عامل پروژه Debian GNU / Linux مطابقت دارد، به ویژه:

• پشتیبانی فعال از آخرین نسخه های استانداردها در پروژه های لینوکس FSH و LSB.
• وجود بیش از یازده پورت رسمی (پورت) برای معماری های مختلف پردازنده؛
• وجود یک سیستم مدیریت بسته نرم افزاری APT (ابزار بسته بندی پیشرفته) با سیاست سختگیرانه در رابطه با نرم افزار توسعه یافته، پشتیبانی از شبکه گسترده ای از مخازن و مکانیزم استاندارد برای انتخاب نرم افزار ترجیحی از بین چندین گزینه (جایگزین).
• تعداد زیادی (بیش از 40 هزار) بسته نرم افزار کاربردی سازگار؛
• سیستم پیشرفته حذف خطا، ارائه کیفیت بالاکد راننده، خدمات سیستم و حفظ ثبات بالای سیستم عامل بر اساس پروژه Debian GNU / Linux.

با توجه به قابل حمل بودن توزیع پروژه Debian GNU/Linux به معماری های مختلف پردازنده، OSSN از پورت کردن به معماری های زیر نیز پشتیبانی می کند:

• amd64 - پردازنده های اینتلو AMD با میکرو معماری پردازندهالف؛ 86-64;
• armel / armhf- 32 و 64 بیتی هسته های پردازندهتوسعه توسط ARM Limited.
• s390.r - فضای کاربری 64 بیتی برای رایانه های اصلی IBM System z.

نسخه های موجود کیت توزیع OSSN بر اساس این پورت ها هستند. نامگذاری آنها بر اساس نسخه کیت توزیع و شماره نسخه متفاوت است. نسخه انتشار کیت توزیع، مشخصات کیت توزیع را تعیین می کند: پورت پشتیبانی شده (پلت فرم سخت افزار) و محدوده. شماره نسخه - دو یا سه رقمی، شناسایی نسخه کیت توزیع OSSN.

در کیت توزیع OSSN نصب شده، نام کامل انتشار کیت توزیع در فایل / etc / astra-veision در قالب زیر ذخیره می شود:

EDITION V.U.Y (نام)

که در آن از نماد زیر استفاده می شود:

EDITION - نسخه کیت توزیع (برای OSSN "SE" است).

V اولین رقم شماره انتشار مرتبط با نام آن است.

U شماره نسخه انتشار است.

Y - شماره به روز رسانی در نسخه منتشر شده (اگر چنین به روز رسانی وجود نداشته باشد، شماره به روز رسانی وجود ندارد).

(نام) - نام انتشار کیت توزیع به الفبای لاتین (مرتبط با نسخه آن و اولین رقم شماره نسخه)، به عنوان یک قاعده، نام شهرهای قهرمان فدراسیون روسیه برای این مورد استفاده می شود. .

انتشار کیت توزیع OSSN و نامگذاری آنها برای نسخه 1.4 در جدول ارائه شده است. 2.3.

نسخه فعلی 1.5 است.

انتشار "Smolensk" سیستم عامل ویژه Astra Linux Special Edition برای کار بر روی بودجه طراحی شده است. تکنولوژی محاسباتیبا معماری پردازنده x86-64.

نسخه Novorossiysk برای کار بر روی رایانه های تلفن همراه و جاسازی شده با معماری پردازنده ARM در نظر گرفته شده است.

معماری ARM (از ماشین پیشرفته RISC انگلیسی - ماشین پیشرفته RISC؛ گاهی اوقات - Acorn RISC Machine) خانواده ای از هسته های ریزپردازنده 32 بیتی و 64 بیتی مجاز است که توسط ARM Limited توسعه یافته است.

RISC (کامپیوتر مجموعه دستورات کاهش یافته) یک معماری پردازشگر است که در آن عملکرد با ساده کردن دستورالعمل ها افزایش می یابد تا رمزگشایی آنها ساده تر و زمان اجرا کوتاه تر شود. اولین پردازنده های RISC حتی دستورالعمل های ضرب و تقسیم نداشتند. همچنین اورکلاک را آسان‌تر می‌کند و فوق‌اسکالر (موازی‌سازی دستورالعمل‌ها در چندین واحد اجرایی) را کارآمدتر می‌کند.

نسخه مورمانسک برای اجرا بر روی پردازنده های مرکزی IBM System Z طراحی شده است.

IBM System z (که قبلاً به عنوان IBM eServer zSeries شناخته می‌شد) نام تجاری است که توسط IBM برای نشان دادن خطی از مین‌فریم‌ها ایجاد شده است.

حرف Z از «زمان خاموشی صفر» می آید که به معنای «زمان خاموشی صفر» است که به شما امکان می دهد سرور را 24 ساعت شبانه روز، 7 روز هفته و 365 روز در سال فعال نگه دارید.

نسخه Sevastopol یک کیت توزیع Astra Linux Special Edition است که برای کار بر روی کامپیوترهای دسکتاپ، موبایل و جاسازی شده با معماری پردازنده MIPS طراحی شده است.

MIPS (Microprocessor without Interlocked Pipeline Stage) یک ریزپردازنده است که توسط MIPS Computer Systems (در حال حاضر MIPS Technologies) مطابق با مفهوم طراحی پردازنده‌های RISC (یعنی برای پردازنده‌هایی با مجموعه دستورالعمل‌های ساده شده) توسعه یافته است. مدل های اولیه پردازنده ساختار 32 بیتی داشتند، نسخه های بعدی 64 بیتی ظاهر شدند.

نسخه Kerch یک کیت توزیع Astra Linux Special Edition است که برای کار بر روی سرورهای با کارایی بالا بر اساس پلت فرم های معماری پردازنده POWER طراحی شده است.

POWER یک مجموعه دستورالعمل محدود معماری ریزپردازنده (RISC) است که توسط IBM طراحی و توسعه یافته است. این نام بعداً به عنوان Performance Optimization With Enhanced RISC (بهینه سازی عملکرد بر اساس معماری پیشرفته RISC) رونویسی شد. این کلمه همچنین به مجموعه ای از ریزپردازنده ها با استفاده از مجموعه دستورالعمل های مشخص شده اشاره دارد. آنها به عنوان یک واحد پردازش مرکزی در بسیاری از ریز رایانه ها، سیستم های تعبیه شده، ایستگاه های کاری، مین فریم ها و ابر رایانه ها استفاده می شوند.

در آینده (اگر به طور خاص در متن ذکر نشده باشد)، هنگام در نظر گرفتن OSSN به عنوان یک نسخه توزیع، از نسخه "Smolensk" نسخه 1.4 استفاده می شود. این نسخه بر اساس توزیع Debian GNU / Linux 7.0 (Wheezy) است. جزئیات معماری آن نسبت به معماری عمومی گنو / لینوکس (شکل 2.1) در شکل نشان داده شده است. 2.2.

در شکل نشان داده شده است. 2.2 مؤلفه های اساسی، کتابخانه ها و ابزارهای توسعه به عنوان بخشی از کیت توزیع OSSN، عملکردهای اساسی زیر را اجرا می کنند:

• راه اندازی برنامه ها، بارگیری آنها در RAM و مدیریت اجرای آنها.
• پشتیبانی چندوظیفه ای پیشگیرانه؛
• ارسال منابع سخت افزاری کامپیوتر بین برنامه های در حال اجرا؛
• ارتباطات بین فرآیندی؛
• سازماندهی مکانیسم حافظه مجازی؛
• پشتیبانی I/O و سازماندهی منطقیدستگاه های ذخیره سازی ( دیسکهای سخت، درایوهای SSD، درایوهای نوری، درایوهای USB);
• پشتیبانی از سیستم فایل؛
• پشتیبانی از ورودی / خروجی به دستگاه های جانبی؛
• پشتیبانی از پشته های پروتکل های شبکه؛
• ارائه حالت عملکرد چند کاربره؛
• ارائه یک خط فرمان رابط کاربری CLI (واسط خط فرمان).
• ارائه یک رابط کاربری گرافیکی (رابط کاربری گرافیکی) برای یک رابط کاربری گرافیکی، از جمله برای رایانه های مجهز به صفحه نمایش های لمسیکه از ورودی چند نقطه ای پشتیبانی می کنند.
• پشتیبانی از توسعه و اشکال زدایی نرم افزارهای کاربردی با رابط کاربری CLI و GUI.

برای سازماندهی یک زیرساخت شبکه دامنه مستقر شده بر اساس OSSN، کیت توزیع آن شامل OpenLDAP، اجرای متن باز پروتکل LDAP است. برای تولید کلیدهای رمزگذاری، گواهینامه های کلید عمومی و انجام رمزگذاری داده ها برای اتصالات SSL / TLS، کیت توزیع OSSN شامل بسته رمزنگاری OpenSSL است.

پشتیبانی از OpenLDAP و OpenSSL اجرای تابع فضای کاربر یکپارچه (EPP) را در زیرساخت دامنه Astra Linux Directory (ALD) با پشتیبانی از کنترل‌کننده‌های دامنه اضافی و ایجاد روابط اعتماد بین آنها فراهم می‌کند.

علاوه بر اجزای اصلی، کتابخانه ها و ابزارهای توسعه، کیت توزیع OSSN شامل نرم افزار عمومی است که عملکردهای زیر را اجرا می کند:

• پردازش اطلاعات اسنادی (متن، ویرایشگرهای صفحه گسترده و ابزارهایی برای ایجاد مطالب ارائه و دسترسی به پایگاه داده های رابطه ایداده ها)؛
• اسکن، چاپ و انتقال اطلاعات اسنادی؛
• دسترسی به اطلاعات ذخیره شده در پایگاه داده های رابطه ای، از جمله پشتیبانی از نرم افزار 1C و نرم افزار برای کار با سایت های جغرافیایی PostGIS;

جدول 2.5. نام و نسخه های نرم افزار عمومی توزیع کننده OSSN.

دسترسی به اطلاعات از طریق سرور پردازش داده های فرامتن (سرور و سرویس گیرنده HTTP).

• پیام های ایمیل (سرورهای SMTP / IMAP و مشتری)؛
• کار با گرافیک و چند رسانه ای (صدا، ویدئو).

نام و نسخه انواع نرم افزارهای ذکر شده در جدول ارائه شده است. 2.5.

یکی از ویژگی های کلیدی کیت توزیع OSSN این است که شامل یک سیستم امنیت اطلاعات است که عملکردهای زیر را ارائه می دهد:

• احراز هویت کاربر با استفاده از زیرساخت PAM (Pluggable Authentication Modules) به صورت محلی و درون EPP، احراز هویت دو مرحله ای بر اساس امضای دیجیتالیو زیرساخت کلید عمومی که توسط رسانه خارجی اطلاعات احراز هویت "Rutoken" پشتیبانی می شود.
• شناسایی کاربر با استفاده از محیط ماژولار NSS (Name Service Switch) به صورت محلی و درون EPP؛
• کنترل دسترسی اختیاری فرآیندها (موضوع جلسات) به منابع (موجودات) با پشتیبانی از استانداردهای حداقل ACL و Extended ACL - Role DP-model - MROSL DP-model که عناصر اساسی آن در سخنرانی های بعدی مورد بحث قرار خواهد گرفت.

به جای سیستم کنترل دسترسی اجباری SELinux، Astra Linux Special Edition از یک مدل DP اجباری مبتنی بر نقش موجودیت اجباری برای کنترل دسترسی و جریان اطلاعات (MROSL DP-model) استفاده می کند.

• بر اساس مدل MROSL DP، کنترل اجباری دسترسی فرآیندها به منابع، که اجرای آن در OSSN در سطوح مکانیزم ارتباط بین فرآیندی، از جمله سیستم های فایل rtos و tmpfs، TCP / IP (IPv4) انجام می شود. پشته پروتکل، در سطح مجازی سیستم فایل(VFS) و در سیستم های فایل از خانواده extfs (Ext2، Ext3، Ext4)؛
• جداسازی فضاهای آدرس فرآیندها؛
• ثبت (ثبت کردن) و ممیزی رویدادها، به عنوان یک سیستم متمرکز با عملکرد اطلاع رسانی به مدیر امنیتی در مورد تلاش های دستکاری، پیاده سازی شده است.
• تمیز کردن RAM و مناطق آزاد شده داده در رسانه با سیستم های فایل Ext2، Ext3، Ext4:
• کنترل نظارتی یکپارچگی موجودیت های سیستم فایل، از جمله تغییر ناپذیری فایل های اجرایی و انطباق با توزیع مرجع OSSN، بر اساس کتابخانه libgost، که تابع هش را مطابق با GOST R 34.11-94 پیاده سازی می کند، و کنترل یکپارچگی اجباری، که از دسترسی افراد در معرض خطر به اطلاعات محافظت شده پس از رهگیری کنترل و افزایش امتیاز جلوگیری می کند (عناصر کنترل یکپارچگی اجباری نیز در مدل MROSL DP مشخص شده است و در فصل 2 مورد بحث قرار گرفته است).
• بر اساس کنترل یکپارچگی اجباری، یک محیط نرم افزار بسته که به شما امکان می دهد برای هر حساب کاربری یک لیست جداگانه از نرم افزارهای مجاز برای استفاده تعریف کنید، با قابلیت دانلود زنجیره های کلید سلسله مراتبی برای تأیید امضای دیجیتال فایل های اجرایی ELF (Executable و فرمت قابل پیوند) که مطابق با GOST R 34.10-2001 اجرا شده است.
• علامت گذاری اسناد با سطوح محرمانه هنگام چاپ آنها؛
• اطمینان از بازیابی قابل اعتماد OSSN پس از خرابی؛
• اجرای قوانین برای کنترل دسترسی به رسانه های خارجی (برای این، نهادهایی با برچسب های غیر مستقیم در مدل MROSL DP مشخص می شوند).
• ارائه دسترسی به پایگاه‌های اطلاعاتی رابطه‌ای مطابق با الزامات مدیریت دسترسی به اطلاعات حاوی اطلاعات تشکیل دهنده یک راز دولتی با مهری نه بالاتر از "محرمانه"، سازگار با کنترل دسترسی اجباری و کنترل یکپارچگی اجباری اجرا شده در OSSN (برای این منظور، MROSL DP- مدل برای استفاده با DBMS استاندارد PostgreSQL برای OSSN توسعه داده شد.
• ارائه دسترسی به اطلاعات از طریق سرور پردازش داده های فرامتن، تبادل پیام های ایمیل مطابق با الزامات مدیریت دسترسی به اطلاعات حاوی اطلاعات تشکیل دهنده یک راز دولتی با مهری که بالاتر از "محرمانه" نباشد. علاوه بر این، یک بسته الحاقی برای ماژول PaX (ابزاری برای محدود کردن حقوق دسترسی به صفحات حافظه) به هسته توزیع OSSN اضافه شده است که اجرای نرم افزار را در کمترین امتیاز و محافظت در برابر سوء استفاده از انواع مختلف تضمین می کند. آسیب پذیری های موجود در آن توسط:
• ممنوع کردن نوشتن در ناحیه حافظه که به عنوان اجرایی مشخص شده است.
• منع ایجاد مناطق حافظه اجرایی؛
• ممنوعیت حرکت بخش کد؛
• ممنوعیت ایجاد یک پشته اجرایی؛
• تخصیص تصادفی فضای آدرس فرآیند. یکی از اجزای مهم OSSN، زیرسیستم امنیتی PARSEC است که سیستم استاندارد لینوکس از امتیازات طراحی شده برای انتقال حقوق کاربران برای انجام وظایف یک مدیر OSSN با پشتیبانی از کنترل دسترسی اجباری و کنترل یکپارچگی اجباری را گسترش می دهد. زیرسیستم PARSEC از امتیازات توسعه یافته زیر پشتیبانی می کند:
• ارسال سیگنال به فرآیندها، با نادیده گرفتن قوانین کنترل دسترسی اختیاری و اجباری.
• تغییر سطوح دسترسی (برچسب های اجباری) حساب های کاربری و تعیین امتیازات دیگر.
• تغییر سطوح محرمانه (برچسب های اجباری) محرمانه بودن فایل ها.
• مدیریت خط مشی حسابرسی؛
• هنگام خواندن و جستجوی فایل ها (به استثنای تابع نوشتن) قوانین کنترل دسترسی اجباری را نادیده بگیرید.

• یک سوکت ممتاز ایجاد کنید و سطح حریم خصوصی آن را تغییر دهید.
• تغییر زمان دسترسی به فایل؛
• نادیده گرفتن کنترل دسترسی اجباری توسط سطوح محرمانه و دسته بندی های غیر سلسله مراتبی.
• تنظیم امتیازات فایل؛
• مجموعه ای از امتیازات منسجم را برای فرآیند انتخاب شده تنظیم کنید.
• سطح حریم خصوصی نقطه اتصال شبکه را تغییر دهید.

زیرسیستم امنیتی PARSEC این امتیازات توسعه یافته را با استفاده از مکانیزم رهگیری فراخوانی سیستم (قلاب) پیاده سازی می کند، که آرگومان های درخواست فرآیند را رهگیری و تجزیه و تحلیل می کند و آنها را مطابق با قوانین تعیین شده کنترل دسترسی اجباری مجاز یا رد می کند. بنابراین، در OSSN، زمینه اجباری (سطوح محرمانه بودن، دسترسی و یکپارچگی مورد استفاده در درخواست) در طول اجرای هر درخواست به صورت محلی یا از راه دور (در EPP) فرآیند در حال اجرا خوانده می شود.

یکی از ویژگی های منحصر به فرد زیرسیستم امنیتی PARSEC اجرای آن به عنوان یک ماژول XPARSEC است که عملکرد سرور X.Org و مدیر پنجره Fly-wm را گسترش می دهد. به لطف این ماژول، سرور X.Org قادر است امتیازات کلاینت X.Org (برنامه با رابط کاربری گرافیکی) را تعیین کرده و با استفاده از پروتکل X-پروتکل اصلاح شده به مدیر پنجره Fly-wm که عملیات ممتاز را انجام می دهد، انتقال دهد. در طول راه اندازی مشتری X.Org با زمینه های مختلف الزامی. در این حالت موارد زیر در دسکتاپ Fly نمایش داده می شود:

• زمینه اجباری جلسه کاربر در ناحیه اعلان در نوار وظیفه؛
• سطح اجباری محرمانه بودن و یکپارچگی هر پنجره؛
• سطح حریم خصوصی پنجره برای محلی و از راه دور برنامه در حال اجرا(قاب رنگی - قاب پنجره برنامه);
• سطح اجباری و یکپارچگی همه برنامه های موجود در دسکتاپ Fly.

2.3. کاربردهای OSSN

ویژگی های معماری در نظر گرفته شده OSSN، مانند اجرای EPP بر اساس زیرساخت شبکه دامنه ALD، و مجموعه DSS ادغام شده در کیت توزیع OSSN، حوزه های اصلی کاربرد آن را تعیین می کند، که در حالت کلی توسط توسعه دهنده تنظیم می شود. در حوزه های زیر مجموعه های نرم افزاری و سخت افزاری و مجموعه ابزارهای اتوماسیون؛

• شبکه های کامپیوتری محلی (شرکتی)؛
• سخنرانان با توزیع جغرافیایی

در حال حاضر، بر اساس کیت توزیع OSSN، تعدادی از پروژه های ASZI در وزارتخانه ها و بخش ها اجرا شده است: FSB روسیه، FSO روسیه، وزارت دفاع روسیه، SVR روسیه، داروی فدرال. سرویس کنترل روسیه، سرویس مجازات فدرال روسیه، سرویس مالیات فدرال روسیه، اداره واحد دولتی فدراسیون روسیه، وزارت بهداشت روسیه، وزارت آموزش و پرورش و علوم روسیه، نیروهای داخلی وزارتخانه امور داخلی روسیه؛ شرکت ها و آژانس های دولتی: Rosatom، Roskosmos، Rostekhnologii، تعدادی از شرکت های مجتمع نظامی-صنعتی؛ در داخل بین بخشی سیستم اطلاعاتسیستم خودکار دولتی نظم دفاع دولتی (GAS GOZ).

در شکل 2.3 نوعی از اجرای یک شبکه محلی امن شرکتی (ZLAN) را ارائه می دهد که از یک سیستم ارتباطی چند سرویس پشتیبانی می کند که اجرای خدمات ایمن را ارائه می دهد:

• کنفرانس ویدیویی؛
• تلفن IP;
• یک پورتال اطلاعاتی مبتنی بر وب سرور؛
• سرور پایگاه داده؛
• سرور پست الکترونیکی

این خدمات بر اساس سیستم عامل های سرور اجرا می شوند که در نسخه سرور نصب نسخه OSSN "Smolensk" عمل می کنند. مانند کامپیوترهای مشتریچنین ZLVS عبارتند از:

• رایانه های ثابت یا تلفن همراه با معماری پردازنده Intel x86-64 که در نسخه مشتری نصب OSSN نسخه Smolensk کار می کنند.
• رایانه های لوحی با معماری پردازنده ARM که در نسخه مشتری نصب OSSN نسخه Novorossiysk کار می کنند.

در شکل 2.3 نشان می دهد که برای مشترکین یک ZLAN شرکتی، یک EPP بر اساس دامنه زیرساخت شبکه ALD با یک کنترل کننده دامنه اختصاصی که در نسخه سرور نصب OSSN نسخه Smolensk کار می کند، سازماندهی شده است. علاوه بر این، در چارچوب چنین ZLVS، یک سرویس ابر خصوصی (Private Cloud) می تواند مستقر شود که با استفاده از فناوری های مجازی سازی OSSN نسخه Smolensk (شکل 2.4) پیاده سازی شود.

در زمینه دسترسی از راه دور به منابع مورد بحث در شکل. 2.3 ZLVS از طریق کانال های ارتباطی اجاره شده از یک ارائه دهنده خدمات مخابراتی، AWP های تلفن همراه مشترکین ZLVS راه دور می توانند با استفاده از مکانیسم های VPN / MPLS به سرورهای ZLVS متصل شوند. در همان زمان، در مرز بخش شرکتی ZLAN، یک کریپتو روتر مرزی نصب شده است - یک فایروال، که می تواند بر اساس نسخه OSSN "Tula" کار کند. نمونه ای از طرحی برای چنین پیاده سازی دسترسی از راه دور به ZLVS در شکل نشان داده شده است. 2.5.

بنابراین، مجموعه ای از نسخه های OSSN توانایی ایجاد ASZI بر روی پلتفرم های مختلف نرم افزاری و سخت افزاری و پیکربندی های مختلف محافظت شده را فراهم می کند. شبکه های کامپیوتراز جمله فناوری های ابری و مکانیسم های دسترسی از راه دور ایمن.

معرفی

اتاق عمل سیستم لینوکسسیستم امنیتی یونیکس را به ارث برد که در دهه 70 توسعه یافت، در زمان ایجاد پیشرفته، اما امروزه به وضوح کافی نیست. هر کاربر از آزادی عمل کامل در محدوده اختیارات خود بر اساس همه یا هیچ برخوردار است. این منجر به این واقعیت می شود که برای انجام برخی کارها، اغلب به کاربر حقوق بسیار بیشتری از آنچه واقعاً ضروری است اعطا می شود. بنابراین، کاربری که با حقوق حساب سیستمی دسترسی پیدا کرده است، عملاً می تواند به آن دست یابد کنترل کاملبر روی سیستم

در جریان عملکرد هر برنامه، انحرافات مختلفی ممکن است رخ دهد که در نتیجه منجر به اجرای غیرعادی آن می شود. اینها می توانند هم خرابی سیستم، هم خطاهای برنامه نویسی و هم موقعیت های ایجاد شده مصنوعی باشند. یک هکر با کشف اینکه تحت شرایط خاصی امکان تأثیرگذاری بر اجرای برنامه وجود دارد، طبیعتاً سعی خواهد کرد از این مزیت استفاده کند. پیش بینی رفتار یک برنامه در حالت آزاد تقریبا غیرممکن است. نمونه‌ای از این آنتی‌ویروس‌ها هستند که همیشه با ریتم «پیش‌گیری» کار می‌کنند و در برابر حملات به اصطلاح روز صفر محافظت نمی‌کنند. با این حال، رفتار عادی یک برنامه را می توان با استفاده از قوانین نسبتا ساده توصیف کرد. در نتیجه، چندین پروژه پدید آمده است که مفهوم حفاظت فعال را اجرا می کند.

هدف از این مقاله ترممطالعه محصولات نرم افزاری با هدف تقویت امنیت سیستم عامل است، تحلیل مقایسه ایویژگی های اصلی آنها و همچنین جمع بندی نتایج کار انجام شده و توجیه کاربرد عملی آنها.

تعریف یک سیستم عامل محافظت شده. SELINUX

مفهوم سیستم عامل محافظت شده

سیستم عامل- بسته نرم افزاری که کنترل سخت افزار کامپیوتر را فراهم می کند، کار با فایل ها و اجرای برنامه های کاربردی را سازماندهی می کند و ورودی و خروجی داده ها را فراهم می کند.

محاسبه "ایمن ترین سیستم عامل" آنقدرها هم که در نگاه اول به نظر می رسد آسان نیست. معیار اصلیتعداد آسیب‌پذیری‌های شناسایی‌شده، تعداد آسیب‌پذیری‌هایی است که کاربرانی که با استانداردهای امنیتی آشنایی ندارند، توسط آن‌ها راهنمایی می‌شوند. با این حال، حداقل حفره های موجود در سیستم هنوز دلیلی برای در نظر گرفتن محافظت قابل اعتماد آن نیست. هنگام صحبت در مورد ایمنی باید چندین فاکتور را در نظر گرفت، از جمله:

- آیا کیفیت کد منبع سیستم عامل بررسی شده است یا خیر.

- آنچه داده شده است تنظیمات استانداردامنیت؛

- چقدر سریع و کارآمد رفع می شود.

- نحوه عملکرد سیستم توزیع قدرت و موارد دیگر.

هنگام انتخاب یک سیستم عامل امن، قطعاً باید لینوکس را در نظر گرفت.

اولاً، سیستم عامل ویندوز هرگز مستقیماً برای اطمینان از امنیت سیستم طراحی نشده بود، همیشه از چشمان بیرونی بسته بود - تمام کدهای ویندوز رمزگذاری شده است. در تئوری، ویندوز را می توان برای استفاده ایمن آماده کرد، اما این کار هنوز انجام نشده است زیرا زمان زیادی را می طلبد. لینوکس، به دلیل باز بودن، به شما امکان می دهد با کد منبع سیستم عامل کار کنید. نسخه های ویژه لینوکس قبلاً منتشر شده است که کاملاً ایمن هستند.

ثانیاً، فناوری Live CD - لینوکس "می تواند" خیلی سریع بدون نصب روی آن راه اندازی و استقرار یابد HDD... چنین سیستم عامل امنی را می توان روی یک دیسک نوری یا درایو USB نوشت و همیشه همراه خود داشته باشید. "در یک چشم به هم زدن"، بدون توجه به سیستم عامل اصلی نصب شده در رایانه مورد استفاده، می توان یک سیستم عامل با دسکتاپ آماده و برنامه های کاربردی مرتبط برای کار در اینترنت دریافت کرد.

هسته جزء مرکزی سیستم عامل است. مسئولیت مدیریت منابع سیستم، ارتباط بین سخت افزار و نرم افزار و امنیت را بر عهده دارد. هسته نقش مهمی در حفظ امنیت در سطوح بالاتر دارد.

همانطور که قبلاً اشاره شد، تعدادی وصله مهم هسته لینوکس وجود دارد که به حفظ امنیت سیستم شما کمک می کند. تفاوت های قابل توجه آنها عمدتاً در نحوه مدیریت و نحوه ادغام آنها در یک سیستم موجود است. همچنین، وصله ها کنترل دسترسی بین فرآیندها و اشیاء، فرآیندها و سایر فرآیندها، اشیاء و اشیاء دیگر را فراهم می کنند.

سیستم عامل نامیده می شود حفاظت شده،اگر وسیله ای برای محافظت در برابر طبقات اصلی تهدیدات فراهم کند. یک سیستم‌عامل محافظت‌شده لزوماً باید شامل ابزارهایی برای محدود کردن دسترسی کاربر به منابع آنها، و همچنین ابزارهایی برای احراز هویت کاربری باشد که شروع به کار با سیستم‌عامل می‌کند. علاوه بر این، سیستم‌عامل محافظت‌شده باید دارای ابزارهایی برای مقابله با غیرفعال کردن تصادفی یا عمدی سیستم‌عامل باشد.

اگر سیستم‌عامل نه در برابر همه کلاس‌های اصلی تهدیدها، بلکه فقط از برخی از آنها محافظت کند، چنین سیستم‌عاملی نامیده می‌شود تا حدی محافظت شده است .

رویکردهای ساخت سیستم عامل های ایمن

دو رویکرد اصلی برای ایجاد سیستم عامل های ایمن وجود دارد - تکه تکه و پیچیده. در تکه تکهرویکرد، ابتدا حفاظت در برابر یک تهدید، سپس در برابر تهدید دیگر و غیره سازماندهی می شود.

هنگام استفاده از رویکرد تکه تکه، زیرسیستم حفاظت از سیستم عامل مجموعه ای از محصولات نرم افزاری متفاوت است، به عنوان یک قاعده، از تولید کنندگان مختلف. این ابزارهای نرم افزاری مستقل از یکدیگر کار می کنند، در حالی که سازماندهی تعامل نزدیک آنها تقریبا غیرممکن است. علاوه بر این، عناصر فردی چنین زیرسیستم حفاظتی ممکن است در حضور یکدیگر به درستی کار نکنند، که منجر به کاهش شدید قابلیت اطمینان سیستم می شود.

در یکپارچهبا رویکرد، توابع حفاظتی در مرحله طراحی معماری سیستم عامل وارد سیستم عامل می شوند و جزء لاینفک آن هستند. عناصر فردی زیرسیستم حفاظت، که بر اساس یک رویکرد یکپارچه ایجاد شده اند، در حل مشکلات مختلف مربوط به سازماندهی حفاظت اطلاعات از نزدیک با یکدیگر تعامل دارند، بنابراین تعارض بین اجزای فردی آن عملا غیرممکن است. زیرسیستم حفاظت که بر اساس یک رویکرد یکپارچه ایجاد شده است، می تواند به گونه ای طراحی شود که در صورت خرابی های مرگبار در عملکرد عناصر کلیدی آن، باعث از کار افتادن سیستم عامل شود که به مهاجم اجازه غیرفعال کردن را نمی دهد. عملکردهای حفاظتی سیستم با یک رویکرد پراکنده، چنین سازماندهی زیرسیستم حفاظت غیرممکن است.

به عنوان یک قاعده، زیرسیستم حفاظت از سیستم عامل، که بر اساس یک رویکرد یکپارچه ایجاد شده است، به گونه ای طراحی شده است که عناصر فردی آن قابل تعویض باشند. ماژول های نرم افزار مربوطه را می توان با ماژول های دیگر جایگزین کرد.

پادمان های اداری

سخت افزار و نرم افزار حفاظت از سیستم عامل باید با اقدامات حفاظتی اداری تکمیل شود. حتی حفاظت سخت افزاری و نرم افزاری قابل اعتماد نیز بدون پشتیبانی مستمر واجد شرایط از سوی سرپرست ممکن است با شکست مواجه شود. بیایید اقدامات اصلی حفاظت اداری را فهرست کنیم.

• 1. نظارت مستمر بر عملکرد صحیح سیستم عامل،به خصوص زیر سیستم حفاظتی آن. اگر سیستم عامل بیشترین پشتیبانی را از ثبت خودکار داشته باشد، سازماندهی چنین کنترلی راحت است رویدادهای مهم (ثبت رویدادها)در یک مجله ویژه
• 2. سازماندهی و حفظ یک سیاست امنیتی مناسب.خط مشی امنیتی سیستم عامل باید دائماً تنظیم شود و به سرعت به تلاش های مزاحمان برای غلبه بر محافظت سیستم عامل و همچنین تغییرات در پیکربندی سیستم عامل، نصب و حذف برنامه های کاربردی پاسخ دهد.
• 3. آموزش کاربران سیستم عامل در موردنیاز به رعایت اقدامات امنیتی هنگام کار با سیستم عامل و نظارت بر انطباق با این اقدامات.
• 4. ایجاد و به روز رسانی منظم نسخه های پشتیبانبرنامه ها و داده های سیستم عامل
• 5. نظارت مستمر بر تغییرات در داده های پیکربندی و سیاست امنیتی سیستم عامل.توصیه می شود اطلاعات مربوط به این تغییرات را در رسانه های ذخیره سازی غیر الکترونیکی ذخیره کنید، به طوری که برای مهاجمی که بر محافظت از سیستم عامل غلبه کرده است، پنهان کردن اقدامات غیرمجاز خود دشوارتر است.

سیستم عامل های خاص ممکن است به اقدامات اداری دیگری برای محافظت از اطلاعات نیاز داشته باشند.

سیاست امنیتی کافی

انتخاب و حفظ یک خط مشی امنیتی مناسب یکی از مهمترین وظایف یک مدیر سیستم عامل است. اگر سیاست امنیتی اتخاذ شده در سیستم عامل ناکافی باشد، این امر می تواند منجر به دسترسی غیرمجاز یک مزاحم به منابع سیستم و کاهش قابلیت اطمینان سیستم عامل شود.

این یک جمله معروف است: هر چه سیستم عامل بهتر محافظت شود، کار با آن برای کاربران و مدیران دشوارتر است. این به دلیل عوامل زیر است:

• سیستم امنیتی همیشه قادر به تشخیص مخرب بودن برخی از اقدامات کاربر نیست. بنابراین، سیستم حفاظتی یا برخی از انواع حملات غیرمجاز را سرکوب نمی کند و یا برخی از اقدامات کاملاً قانونی کاربران را ممنوع می کند. هرچه امنیت سیستم بالاتر باشد، طبقه بندی آن دسته از اقدامات حقوقی کاربران که توسط زیرسیستم حفاظت غیرمجاز تلقی می شوند، بیشتر می شود.
• هر سیستمی که در آن توابع امنیت اطلاعات ارائه می شود، نیازمند تلاش های مشخصی از سوی مدیران برای حفظ یک خط مشی امنیتی مناسب است. هرچه عملکردهای محافظتی بیشتری در سیستم عامل داشته باشید، زمان و هزینه بیشتری برای حفظ حفاظت باید صرف کنید.
• زیرسیستم حفاظت از سیستم عامل، مانند هر بسته نرم افزاری دیگری، منابع سخت افزاری کامپیوتر را مصرف می کند. هرچه عملکردهای حفاظتی سیستم عامل پیچیده تر باشد، منابع کامپیوتری (زمان پردازنده، رم و غیره) بیشتر برای حفظ زیرسیستم حفاظتی صرف می شود و منابع کمتری برای برنامه های کاربردی باقی می ماند.
• حفظ یک خط مشی امنیتی بسیار سخت می تواند بر قابلیت اطمینان سیستم عامل تأثیر منفی بگذارد. یک سیاست امنیتی بیش از حد سخت می تواند منجر به خطاها و خرابی های سخت در فرآیند کارکرد سیستم عامل و حتی سقوط آن شود.

سیاست امنیتی مناسب و بهینه -این یک سیاست امنیتی است که نه تنها مزاحمان را از انجام اقدامات غیرمجاز جلوگیری می کند، بلکه منجر به اثرات منفی توصیف شده در بالا نیز نمی شود.

یک خط مشی امنیتی کافی نه تنها توسط معماری سیستم عامل تعیین می شود، بلکه توسط پیکربندی، برنامه های کاربردی نصب شده و غیره نیز تعیین می شود.

• 1. تحلیل تهدیدمدیر سیستم عامل تهدیدات امنیتی احتمالی را برای این نمونه سیستم عامل در نظر می گیرد. در میان تهدیدات احتمالی، خطرناک ترین آنها برجسته می شود، محافظتی که باید از آن حداکثر بودجه را اختصاص دهید.
• 2. تشکیل الزامات برای سیاست امنیتی.مدیر تعیین می کند که از چه ابزارها و روش هایی برای محافظت در برابر تهدیدات خاص استفاده شود. به عنوان مثال، محافظت در برابر دستکاری یک شیء سیستم عامل خاص را می توان با استفاده از کنترل دسترسی یا با ابزارهای رمزنگاری یا با استفاده از ترکیبی از این ابزارها حل کرد.
• 3. تعریف رسمی سیاست امنیتیمدیر تعیین می کند که دقیقاً چگونه الزامات فرموله شده در مرحله قبل باید برآورده شود. الزامات لازم برای پیکربندی سیستم عامل و همچنین الزامات برای پیکربندی بسته های حفاظتی اضافی، در صورت لزوم نصب چنین بسته هایی، فرموله شده است. نتیجه این مرحله یک لیست دقیق از تنظیمات پیکربندی سیستم عامل و بسته های حفاظتی اضافی است که نشان می دهد در چه شرایطی، چه تنظیماتی باید نصب شوند.
• 4. اجرای سیاست امنیتیوظیفه این مرحله این است که پیکربندی سیستم عامل و بسته های حفاظتی اضافی را مطابق با خط مشی امنیتی که به طور رسمی در مرحله قبل تعریف شده است، قرار دهد.
• 5. حفظ و اصلاح سیاست امنیتی.وظیفه مدیر در این مرحله کنترل انطباق با خط مشی امنیتی و ایجاد تغییرات لازم در آن با ظاهر شدن تغییرات در عملکرد سیستم عامل است.

هیچ استاندارد امنیتی سیستم عامل خاصی وجود ندارد. برای ارزیابی امنیت یک سیستم عامل، استانداردهای توسعه یافته برای سیستم های کامپیوتری به طور کلی استفاده می شود. به عنوان یک قاعده، گواهی یک سیستم عامل برای کلاس خاصی از حفاظت با تهیه الزامات برای یک سیاست امنیتی کافی همراه است که با اجرای بی قید و شرط آن امنیت یک نمونه خاصسیستم عامل الزامات کلاس حفاظت مربوطه را برآورده می کند.

هنگام تعریف یک خط مشی امنیتی کافی، مدیر سیستم عامل باید در درجه اول بر محافظت از سیستم عامل در برابر تهدیدات خاص برای امنیت آن تمرکز کند.