امنیت در معماری نرم‌افزار

1. مقدمه

امنیت در مهندسی نرم‌افزار یک موضوع مهم و اجتناب‌ناپذیر برای محفوظ ماندن از حملات و مخاطراتی است که در کمین نرم‌افزار هستند. می‌توان گفت در حوزه مهندسی نرم‌افزار، امنیت دارای دو جنبه متفاوت است. اولین جنبه مربوط به ساخت یک نرم‌افزار ایمن است. ساخت یک نرم‌افزار ایمن شامل طراحی امن نرم‌افزار، اطمینان از ایمن بودن آن و آموزش توسعه‌دهندگان، معماران و کاربران در مورد چگونگی امن سازی می‌باشد. دومین جنبه امنیت در مورد محافظت از نرم‌افزار و سیستم‌هایی است که نرم‌افزار به صورت پس‌رخداد (post facto) پس از تکمیل توسعه اجرا می‌کند. مسائل حیاتی در این جنبه شامل سندباکس (sandboxing) کد، محافظت در برابر کدهای مخرب، مبهم کردن کد، قفل کردن فایل‌های اجرایی، نظارت بر برنامه‌ها در حین اجرا (به ویژه ورودی‌های نرم‌افزار) و اجرای خط‌مشی استفاده از نرم‌افزار می‌باشد. براین اساس، نرم‌افزار باید طراحی قدرتمندی داشته باشد تا بتواند از خود محافظت کند و در حالت مطلوب هیچ آسیب‌پذیری نداشته باشد [1].

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

بهترین شیوه امنیت نرم‌افزار شامل درنظر گرفتن امنیت در اوایل چرخه حیات نرم‌افزار (software lifecycle)، آشنایی و درک تهدیدهای رایج، طراحی امنیت، امکان تجزیه و تحلیل بخش‌های مختلف نرم‌افزار به‌صورت دقیق و عینی و آزمایش نرم‌افزار است [1]. بر این اساس هدف این مقاله ارتقاء امنیت سیستم‌های نرم‌افزاری است به‌طوریکه امنیت در هر جنبه‌ای از طراحی در نظر گرفته شود و از ابتدا طراحی شود، چراکه اعمال امنیت بعد از طراحی کاری بسیار دشوار است [2].

2. امنیت در معماری نرم‌افزار

درمورد معماری نرم‌افزار تعاریف گوناگونی از دیدگاه‌های مختلف وجود دارد. از دیدگاه اشنایدر معماری به صورت زیر تعریف می‌شود:

«ساختاری که از طریق آن می‌توان یک سیستم بزرگ یا پیچیده را فهمید و درباره آن استدلال کرد و می‌توان نقاط ضعف را قبل از ساختن سیستم شناسایی کرد [3].»

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

امنیت نرم‌افزار یک مسئله در سطح سیستم است که هم سازوکار‌های امنیتی (مانند کنترل دسترسی) و هم طراحی برای امنیت (مانند طراحی قوی که حملات نرم‌افزاری را دشوار می‌کند) را در نظر می‌گیرد [3]. در ادامه به بررسی و تحلیل این موارد پرداخته می‌شود.

2-1. ویژگی‌های امنیتی

داده‌های مهم و حساس توسط توابع مرتبط با امنیت مدیریت می‌شوند، بنابراین امنیت باید در هر جنبه‌ای از طراحی در نظر گرفته شود. در دیدگاه سالتزر و شرودر توصیه شده‌است که معماری امنیتی باید شامل ویژگی‌های زیر باشد [4]:

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

2-2. امنیت در طراحی و مدل‌سازی

زبان مدلسازی یکپارچه (UML) زبان استانداردی برای تعیین، تجسم، ساخت و مستندسازی سیستم‌های نرم‌افزاری است که پیچیدگی طراحی نرم‌افزار را ساده کرده و یک طرح برای ساخت و ساز ایجاد می‌کند [5]. UMLsec روشی برای توسعه سیستم امنیتی است که با ادغام تجزیه و تحلیل الزامات امنیتی با فرآیند توسعه استاندارد و مدل‌سازی، برای ویژگی‌های مرتبط با امنیت (مانند محرمانگی، کنترل دسترسی و غیره) بهبودهایی را پیشنهاد می‌کند. دلیل انتخاب UML برای گسترش، توسعه‌دهندگانی است که در زمینه امنیت تخصص نداشته اما تجربه مدل‌سازی نرم‌افزار با UML را دارند.

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

مدل UMLsec از نمودارهای استاندارد UML شامل نمودارهای مورد کاربری، نمودارهای فعالیت، نمودارهای کلاس، نمودارهای توالی سیستم، نمودارهای حالت، و نمودارهای استقرار تشکیل شده است. به‌عنوان نمونه، نمودارهای توالی سیستم برای تعیین پروتکل‌های امنیتی مفید هستند، نمودارهای حالت برای مدل‌سازی رفتار پویا سیستم و رویداد محور که در آن رویدادهایی که شرایط خاص سیستم را برآورده می‌کنند و نمودارهای استقرار برای توصیف لایه فیزیکی استفاده می‌شود و به توسعه‌دهندگان کمک می‌کند تا اطمینان حاصل کنند که الزامات امنیتی در ارتباطات توسط لایه فیزیکی برآورده می‌شود [6].

2-3. سازوکار‌های امنیتی

سازوکار‌های کنترل دسترسی معمولا در قالب یک ماتریس کنترل دسترسی مشاهده می‌شوند که موضوعات (subjects) فعال (کاربران سیستم) را در ردیف‌های ماتریس و اشیا (objects) غیرفعال (فایل‌ها و سایر منابع سیستم) را در ستون‌ها دسته‌بندی می‌کند. سیستم‌های واقعی از سطرها یا ستون‌های ماتریس برای تصمیم‌گیری‌های کنترل دسترسی استفاده می‌کنند. سیستم‌هایی که از پیاده‌سازی مبتنی بر ردیف استفاده می‌کنند، با پیوست کردن فهرستی از اشیا قابل دسترس به موضوع، که معمولا با استفاده از قابلیت‌ها پیاده‌سازی می‌شوند، کار می‌کنند. سیستم‌هایی که از پیاده‌سازی مبتنی بر ستون استفاده می‌کنند، با پیوست کردن فهرستی از موضوعات مجاز به شیء، که معمولا با استفاده از لیست‌های کنترل دسترسی (Access Control Lists - ACL)، بیت‌های حفاظتی یا بخشی از لیست کنترل دسترسی پیاده‌سازی می‌شوند، کار می‌کنند [2].

سیستم‌های مبتنی بر قابلیت (Capability-based systems)، قابلیت‌ها یا برچسب‌هایی را برای موضوعاتی صادر می‌کنند که حاوی حقوق دسترسی مانند خواندن، نوشتن یا اجرا هستند و برای نشان دادن حق دسترسی به یک شیء از آن استفاده می‌شود. قابلیت‌ها می‌توانند به راحتی به موضوعات دیگر منتقل شوند و می‌توانند تعداد اشیا قابل دسترس را به حداقل مورد نیاز برای انجام یک کار خاص محدود کنند. برای مثال، می‌توان برچسبی صادر کرد که به موضوع اجازه می‌دهد فقط به اشیا مورد نیاز برای کار خاص در دست دسترسی داشته باشد. سهولت انتقال قابلیت‌ها می‌تواند یک مزیت باشد اما یک نقطه ضعف نیز محسوب می‌شود زیرا توانایی انتقال آن‌ها را نمی‌توان به راحتی کنترل کرد. این امر منجر به الزامی می‌شود که موضوعات کنترل بسیار دقیقی بر هر قابلیت داشته و ابطال و بررسی دسترسی را بسیار دشوار می‌کند [2]. سیستم های مبتنی بر لیست‌های کنترل دسترسی به هر موضوعی اجازه دسترسی به یک شیء خاص را می‌دهند یا نمی‌دهند.

نمای مبتنی بر جریان اطلاعات تغییری از نمای امنیتی مبتنی بر کنترل دسترسی است که سطوح امنیتی را به اشیا اختصاص می‌دهد و فقط اجازه می‌دهد تا جریان اطلاعات به شیء مقصد با سطح امنیتی برابر یا بالاتر از شیء منبع باشد [7]. همچنین، تعدادی سازوکار ترکیبی نیز وجود دارد که برخی از بهترین ویژگی‌های قابلیت‌ها و لیست‌های کنترل دسترسی را ترکیب می‌کند یا سعی می‌کند کاستی‌های یکی از این دو را برطرف کنند. برخی از این رویکردها شامل استفاده از نتیجه ذخیره‌شده جستجوی لیست‌های کنترل دسترسی به‌عنوان یک قابلیت [8]، ارائه فهرست‌های استثنا برای هر شیء که امکان لغو قابلیت‌ها را فراهم می‌کند [9]، با استفاده از فهرست‌های محدودیت موضوع (Subject Restriction Lists - SRLs) که برای موضوع اعمال می‌شود، لیست‌های کنترل دسترسی که در مورد شیء اعمال می شوند [10]، یا دامنه یکی از دو رویکرد را برای ترکیب بخشی از رویکرد دیگر گسترش می‌دهند.

مانیتور مرجع سازوکاری است که برای کنترل دسترسی مجموعه‌ای از موضوعات به مجموعه‌ای از اشیا استفاده می شود. مانیتور زیرسیستمی است که وظیفه بررسی مشروعیت تلاش‌های موضوع برای دسترسی به اشیا را بر عهده دارد و انتزاعی را برای کنترل روابط بین موضوعات و اشیا نشان می‌دهد.

2-4. سیاست‌ها و مدل‌های امنیتی

به طور کلی، تمرکز امنیت بر روی حفاظت متعادل از محرمانگی، یکپارچگی داده‌ها و در دسترس بودن است که این سه اصل به عنوان سه‌گانه "CIA" شناخته می‌شوند. محرمانه بودن مجموعه‌ای از قوانین سطح بالا است که دسترسی به انواع داده‌ها و اطلاعات را محدود می‌کند و فقط افراد یا سیستم‌های مجاز می‌توانند اطلاعات حساس یا طبقه‌بندی شده را مشاهده کنند. یکپارچگی به معنای اطمینان و دقیق بودن داده‌ها است و باید اقداماتی انجام شود تا اطمینان حاصل شود که نمی‌توان داده‌ها را توسط افراد غیرمجاز تغییر داد. در دسترس بودن یک شکل از مدیریت ریسک برای تضمین دسترسی قابل اعتماد به اطلاعات توسط افراد مجاز است و داده‌ها باید به طور مداوم و به راحتی برای افراد یا سیستم‌های مجاز در دسترس باشد [11].

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

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

2-4-1. مدل بل-لاپادولا

مدل بل-لاپادولا (Bell–LaPadula) [12] [13] برای حفظ محرمانه بودن استفاده می‌شود. در این مدل، موضوعات و اشیا با توجه به لایه‌های مختلف محرمانگی به روشی غیراختیاری سازمان‌دهی می‌شوند [14]. این مدل به یک مانیتور مرجع نیاز دارد که دو ویژگی امنیتی، ویژگی امنیتی ساده (Simple Security Property - Simple Confidentiality Rule) و ویژگی ستاره (Star Property - Star Confidentiality Rule) را با استفاده از یک ماتریس کنترل دسترسی به عنوان پایگاه‌داده مانیتور مرجع اعمال می‌کند. این مدل یک سطح امنیتی ثابت را به هر موضوع و شیء اختصاص می‌دهد و فقط در صورتی اجازه دسترسی خواندن به یک شیء را می‌دهد که سطح امنیتی موضوع بزرگتر یا مساوی با سطح امنیتی شیء باشد. به عبارتی دیگر، موضوع فقط می‌تواند فایل‌های موجود در همان لایه محرمانه و لایه پایین را بخواند (ویژگی امنیتی ساده، "NO READ-UP") و فقط در صورتی اجازه دسترسی نوشتن به یک شیء را می‌دهد که سطح امنیتی موضوع کمتر یا مساوی با سطح امنیتی شیء باشد. به عبارت دیگر موضوع فقط می تواند فایل‌ها را در همان لایه محرمانه و لایه بالایی بنویسد، (ویژگی ستاره، "NO WRITE-DOWN") [2]. اثر ویژگی امنیتی ساده این است که از خواندن یک شیء با سطح امنیتی بالا توسط یک موضوع با سطح امنیتی پایین جلوگیری می‌کند و اثر ویژگی ستاره جلوگیری از نوشتن یک موضوع با سطح امنیتی بالا بر روی یک شیء با سطح امنیتی پایین است. همچنین در این مدل یک سطح امنیتی بسیار قوی وجود دارد که براساس آن، موضوع فقط می‌تواند فایل ها را در همان لایه محرمانه بخواند و بنویسد و نه در لایه بالایی یا لایه پایین (ویژگی ستاره قوی ((Strong Star Property - Strong Star Confidentiality Rule))، "NO READ WRITE UP DOWN") [14].

2-4-2. مدل بیبا

مدل بیبا (Biba) [15] برای حفظ یکپارچگی استفاده می‌شود. در این مدل، موضوعات و اشیا با توجه به لایه‌های مختلف محرمانگی به روشی غیراختیاری سازمان‌دهی می‌شوند که دقیقا برعکس مدل بل-لاپادولا عمل می‌کند [14]. براساس آن به یک موضوع اجازه داده می‌شود روی یک شیء با سطح یکپارچگی برابر یا پایین‌تر بنویسد (قانون یکپارچگی ستاره (Star Integrity Rule)، "NO WRITE-UP") و از یک شیء با سطح یکپارچگی برابر یا بالاتر بخواند (قانون یکپارچگی ساده (Simple Integrity Rule)، "NO READ DOWN") [14] [15].

ویژگی ستاره در مدل بل-لاپادولا، در واقع تأثیر منفی بر یکپارچگی دارد زیرا منجر به نوشتن کور می‌شود که در آن نتایج یک عملیات نوشتن زمانی که شیء در سطح بالاتری از موضوع قرار دارد قابل مشاهده نیست [16]. مشکل مدل بیبا این است که اکثر مدیران سیستم آشنایی کمی از آن دارند و مستندات کمی درمورد آن وجود دارد و می‌توان گفت که ترکیب آن با سایر سیاست‌های یکپارچگی مدیریت آن را سخت می‌کند.

2-4-3. مدل کلارک-ویلسون

مدل کلارک-ویلسون (Clark–Wilson) [17] که هدف اصلی آن یکپارچگی به جای محرمانگی است. این مدل بجای موضوعات و اشیا، با اقلام داده‌های محدود (Constrained Data Items - CDI) کار می‌کند که براساس آن موضوع قابل دسترسی مستقیم نیست و فقط از طریق مدل امنیتی کلارک-ویلسون قابل دسترسی می‌باشد. اقلام داده‌های محدود توسط دو نوع رویه پردازش می‌شوند: رویه‌های تبدیل (Transformation Procedures - TPs) و رویه‌های تایید یکپارچگی (Integrity Verification Procedures - IVPs). درواقع درخواست موضوع برای دسترسی به اقلام داده‌های محدود شده توسط فرآیند تبدیل انجام می‌شود که آن را به مجوز تبدیل کرده و سپس به رویه تایید یکپارچگی ارسال می‌کند. رویه تایید یکپارچگی، احراز هویت و مجوز را انجام می‌دهد. اگر موفقیت آمیز بود، به موضوع دسترسی به اقلام داده‌های محدود، داده می‌شود [14]. به عبارت دیگر، رویه‌های تبدیل، مجموعه اقلام داده‌های محدود را از یک حالت معتبر به حالت دیگر تبدیل می‌کند و رویه‌های تایید یکپارچگی بررسی می‌کند که همه اقلام داده‌های محدود با خط مشی یکپارچگی سیستم مطابقت داشته باشند [17].

2-4-4. مدل برو- نش

مدل برو-نش (Brewer and Nash) که به آن مدل دیوار چین [18] نیز گفته می‌شود، برای محرمانگی و کنترل دسترسی اطلاعات ساخته شده است. این مدل، سرمایه‌گذاران را به گونه‌ای تقسیم می‌کند که تضاد منافع در یک طرف دیوار رخ ندهد. همچنین، به کاربران فقط اجازه دسترسی به داده‌هایی داده می‌شود که با سایر داده‌هایی که در اختیار دارند، در تضاد نباشد [19]. به عبارتی، این مدل کنترل‌هایی را ارائه می‌دهد که تضاد منافع در سازمان های تجاری را کاهش می‌دهد [2]. بنابراین، این مدل در درجه اول در فضاهای تجاری استفاده می‌شود.

2-4-5. مقایسه

چهار مدل امنیتی بیان شده را می‌توان به‌صورت جدول زیر مقایسه کرد:

2-5. راهکار پیاده‌سازی معماری امنیتی

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

معماری امنیتی cryptlib یک ابزار امنیتی قدرتمند است که امکان اضافه کردن قابلیت‌های امنیتی (مانند رمزگذاری یا احراز هویت) را برای برنامه‌نویسان بدون نیاز به دانستن جزئیات سطح پایین که باعث کارکرد رمزگذاری یا احراز هویت می‌شود را فراهم می‌کند. به همین دلیل، cryptlib به طور چشمگیری باعث کاهش هزینه‌های مربوط به امنیت در برنامه‌ها می‌شود [21].

معماری امنیتی از یک هسته امنیتی برای پیاده‌سازی سازوکار‌های امنیتی جهت فراهم کردن امنیت درون یک شیء و بین اشیا مختلف استفاده می‌کند. معماری امنیتی cryptlib از سازوکار‌های تخصصی مختلفی تشکیل شده است که در طول سه دهه گذشته تکامل یافته‌اند [2].

نوع هسته خاصی که در cryptlib استفاده می‌شود، هسته جداسازی است که برای اولین بار در سال 1981 رسمیت یافت [22]. در هسته جداسازی همه اشیا از یکدیگر مجزا هستند. اصولی که در هسته جداسازی گنجانده شده است به اوایل دهه 1960 با مفهوم سیستم‌های تجزیه‌پذیر برمی‌گردد، جایی که اجزای سیستم هیچ تعامل مستقیمی ندارند یا فقط با اجزای مشابه تعامل دارند [23]. یک سیستم تجزیه‌پذیر را می‌توان به دو سیستم کوچک‌تر با اجزای غیرمتقابل تجزیه کرد، که به نوبه خود می‌توانند به صورت بازگشتی به سیستم‌های کوچک و کوچک‌تر تجزیه شوند تا زمانی که دیگر تجزیه نشوند. بر این اساس سیستم های امن را می‌توان به عنوان مجموعه ای از سیستم‌های توزیع شده فردی (individual distributed systems) یا سیستم کاملا تجزیه شده (completely decomposed system) مدل‌سازی کرد که در آن امنیت وجود دارد. هسته جداسازی این امکان را فراهم می‌کند که چنین سیستم تقریبا توزیع شده‌ای در یک سیستم فیزیکی واحد اجرا شود و توانایی ایجاد یک سیستم امن واحد از واحدهای جداگانه را فراهم می‌کند که لزوما نیازی به ایمن بودن سیستم به عنوان یک کل نیست [24] [25].

3. نتیجه­‌گیری

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

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

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

مراجع

[1] McGraw, Gary. "Software security." IEEE Security & Privacy 2.2 (2004): 80-83.

[2] Gutmann, Peter. The Security Architecture. Springer New York, 2004.

[3] Schneider, Edward A. "Security architecture-based system design." Proceedings of the 1999 workshop on New Security Paradigms. 1999.

[4] Saltzer, Jerome H., and Michael D. Schroeder. "The protection of information in computer systems." Proceedings of the IEEE 63.9 (1975): 1278-1308.

[5] UML Resource Center, (November 30, 2003) http://www.rational.com/uml/index.jsp.

[6] Jürjens, Jan. "Using UMLsec and goal trees for secure systems development." Proceedings of the 2002 ACM symposium on Applied computing. 2002.

[7] Denning, Dorothy E. "A lattice model of secure information flow." Communications of the ACM 19.5 (1976): 236-243.

[8] Karger, Paul Ashley. Improving security and performance for capability systems. No. UCAM-CL-TR-149. University of Cambridge, Computer Laboratory, 1988.

[9] Gong, Li. "A Secure Identity-Based Capability System." IEEE symposium on security and privacy. 1989.

[10] Kühnhauser, Winfried E., et al. "Mechanisms for Persistence and Security in BirliX." Security and Persistence: Proceedings of the International Workshop on Computer Architectures to Support Security and Persistence of Information 8–11 May 1990, Bremen, West Germany. London: Springer London, 1990.

[11] Samonas, Spyridon, and David Coss. "The CIA strikes back: Redefining confidentiality, integrity and availability in security." Journal of Information System Security 10.3 (2014).

[12] Bell, D. Elliott, and Leonard J. LaPadula. Secure computer systems: Mathematical foundations. National Technical Information Service, 1989.

[13] Bell, David E., and Leonard J. La Padula. "Secure computer system: Unified exposition and multics interpretation." (1976).

[14] “Introduction to Classic Security Models” https://www.geeksforgeeks.org/introduction-to-classic-security-models

[15] Biba, K. J. Integrity Considerations for Secure Computer Systems, TR-76-372, USAF Electronic Systems Division, April 1977.

[16] Amoroso, Edward G. Fundamentals of computer security technology. Prentice-Hall, Inc., 1994.

[17] Clark, David D., and David R. Wilson. "A comparison of commercial and military computer security policies." 1987 IEEE Symposium on Security and Privacy. IEEE, 1987.

[18] Brewer, David FC, and Michael J. Nash. "The Chinese Wall Security Policy." IEEE symposium on security and privacy. Vol. 1989.

[19] Cankaya, Ebru Celikel. "Chinese Wall Model." (2011): 203-205.

[20] Ames, Gasser, and Schell. "Security kernel design and implementation: An introduction." Computer 16.7 (1983): 14-22.

[21] “Introduction to cryptlib” https://cryptlib.com

[22] Ames Jr, Stanley R. "Security kernels: A solution or a problem?." 1981 IEEE Symposium on Security and Privacy. IEEE, 1981.

[23] Simon, Herbert A. "The architecture of complexity." Proceedings of the American philosophical society 106.6 (1962): 467-482.

[24] Rushby, John M. "Design and verification of secure systems." ACM SIGOPS Operating Systems Review 15.5 (1981): 12-21.

[25] Shi, Qi, J. A. McDermid, and J. D. Moffett. "Developing secure systems in a modular way." COMPASS'93: Proceedings of the Eighth Annual Conference on Computer. IEEE, 1993.

Software Architecture @ SBU