https://virgool.io/feed/@FatemehSepahdoost Master's Student in Software Engineering fa 2026-06-17 21:59:20 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@FatemehSepahdoost https://virgool.io/@FatemehSepahdoost/%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%AF%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-r1b0rduzqohj 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].شکل1. ماتریس کنترل دسترسیسیستم‌های مبتنی بر قابلیت (Capability-based systems)، قابلیت‌ها یا برچسب‌هایی را برای موضوعاتی صادر می‌کنند که حاوی حقوق دسترسی مانند خواندن، نوشتن یا اجرا هستند و برای نشان دادن حق دسترسی به یک شیء از آن استفاده می‌شود. قابلیت‌ها می‌توانند به راحتی به موضوعات دیگر منتقل شوند و می‌توانند تعداد اشیا قابل دسترس را به حداقل مورد نیاز برای انجام یک کار خاص محدود کنند. برای مثال، می‌توان برچسبی صادر کرد که به موضوع اجازه می‌دهد فقط به اشیا مورد نیاز برای کار خاص در دست دسترسی داشته باشد. سهولت انتقال قابلیت‌ها می‌تواند یک مزیت باشد اما یک نقطه ضعف نیز محسوب می‌شود زیرا توانایی انتقال آن‌ها را نمی‌توان به راحتی کنترل کرد. این امر منجر به الزامی می‌شود که موضوعات کنترل بسیار دقیقی بر هر قابلیت داشته و ابطال و بررسی دسترسی را بسیار دشوار می‌کند [2]. سیستم های مبتنی بر لیست‌های کنترل دسترسی به هر موضوعی اجازه دسترسی به یک شیء خاص را می‌دهند یا نمی‌دهند.نمای مبتنی بر جریان اطلاعات تغییری از نمای امنیتی مبتنی بر کنترل دسترسی است که سطوح امنیتی را به اشیا اختصاص می‌دهد و فقط اجازه می‌دهد تا جریان اطلاعات به شیء مقصد با سطح امنیتی برابر یا بالاتر از شیء منبع باشد [7]. همچنین، تعدادی سازوکار ترکیبی نیز وجود دارد که برخی از بهترین ویژگی‌های قابلیت‌ها و لیست‌های کنترل دسترسی را ترکیب می‌کند یا سعی می‌کند کاستی‌های یکی از این دو را برطرف کنند. برخی از این رویکردها شامل استفاده از نتیجه ذخیره‌شده جستجوی لیست‌های کنترل دسترسی به‌عنوان یک قابلیت [8]، ارائه فهرست‌های استثنا برای هر شیء که امکان لغو قابلیت‌ها را فراهم می‌کند [9]، با استفاده از فهرست‌های محدودیت موضوع (Subject Restriction Lists - SRLs) که برای موضوع اعمال می‌شود، لیست‌های کنترل دسترسی که در مورد شیء اعمال می شوند [10]، یا دامنه یکی از دو رویکرد را برای ترکیب بخشی از رویکرد دیگر گسترش می‌دهند.مانیتور مرجع سازوکاری است که برای کنترل دسترسی مجموعه‌ای از موضوعات به مجموعه‌ای از اشیا استفاده می شود. مانیتور زیرسیستمی است که وظیفه بررسی مشروعیت تلاش‌های موضوع برای دسترسی به اشیا را بر عهده دارد و انتزاعی را برای کنترل روابط بین موضوعات و اشیا نشان می‌دهد.شکل2. مانیتور مرجع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].شکل3. مدل بل-لاپادولا2-4-2. مدل بیبامدل بیبا (Biba) [15] برای حفظ یکپارچگی استفاده می‌شود. در این مدل، موضوعات و اشیا با توجه به لایه‌های مختلف محرمانگی به روشی غیراختیاری سازمان‌دهی می‌شوند که دقیقا برعکس مدل بل-لاپادولا عمل می‌کند [14]. براساس آن به یک موضوع اجازه داده می‌شود روی یک شیء با سطح یکپارچگی برابر یا پایین‌تر بنویسد (قانون یکپارچگی ستاره (Star Integrity Rule)، "NO WRITE-UP") و از یک شیء با سطح یکپارچگی برابر یا بالاتر بخواند (قانون یکپارچگی ساده (Simple Integrity Rule)، "NO READ DOWN") [14] [15].ویژگی ستاره در مدل بل-لاپادولا، در واقع تأثیر منفی بر یکپارچگی دارد زیرا منجر به نوشتن کور می‌شود که در آن نتایج یک عملیات نوشتن زمانی که شیء در سطح بالاتری از موضوع قرار دارد قابل مشاهده نیست [16]. مشکل مدل بیبا این است که اکثر مدیران سیستم آشنایی کمی از آن دارند و مستندات کمی درمورد آن وجود دارد و می‌توان گفت که ترکیب آن با سایر سیاست‌های یکپارچگی مدیریت آن را سخت می‌کند.شکل4. مدل بیبا2-4-3. مدل کلارک-ویلسونمدل کلارک-ویلسون (Clark–Wilson) [17] که هدف اصلی آن یکپارچگی به جای محرمانگی است. این مدل بجای موضوعات و اشیا، با اقلام داده‌های محدود (Constrained Data Items - CDI) کار می‌کند که براساس آن موضوع قابل دسترسی مستقیم نیست و فقط از طریق مدل امنیتی کلارک-ویلسون قابل دسترسی می‌باشد. اقلام داده‌های محدود توسط دو نوع رویه پردازش می‌شوند: رویه‌های تبدیل (Transformation Procedures - TPs) و رویه‌های تایید یکپارچگی (Integrity Verification Procedures - IVPs). درواقع درخواست موضوع برای دسترسی به اقلام داده‌های محدود شده توسط فرآیند تبدیل انجام می‌شود که آن را به مجوز تبدیل کرده و سپس به رویه تایید یکپارچگی ارسال می‌کند. رویه تایید یکپارچگی، احراز هویت و مجوز را انجام می‌دهد. اگر موفقیت آمیز بود، به موضوع دسترسی به اقلام داده‌های محدود، داده می‌شود [14]. به عبارت دیگر، رویه‌های تبدیل، مجموعه اقلام داده‌های محدود را از یک حالت معتبر به حالت دیگر تبدیل می‌کند و رویه‌های تایید یکپارچگی بررسی می‌کند که همه اقلام داده‌های محدود با خط مشی یکپارچگی سیستم مطابقت داشته باشند [17].شکل5. مدل کلارک-ویلسون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 Fatemeh Sepahdoost Fatemeh Sepahdoost Tue, 30 Jan 2024 21:31:24 +0330 https://virgool.io/CE-SHAHED-publication/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-15-%D9%85%D9%88%D8%B6%D9%88%D8%B9-%D9%85%D8%AA%D9%86%D9%88%D8%B9-%D9%88-%D9%85%D9%81%DB%8C%D8%AF-%D8%AF%D8%B1-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-flvttyaymdui 1. یکپارچه مدولار (Modular Monolithic)یکپارچه مدولار یک معماری نرم‌افزار است که براساس آن سیستم به مجموعه‌ای از ماژول‌های مستقل تقسیم می‌شود؛ هر ماژول وابستگی زیادی به ماژول‌های دیگر ندارد و بدون تاثیر ماژول‌های دیگر قابل توسعه، اصلاح یا تست می‌باشد. در این معماری تغییرات سریع‌تر و آسان‌تر انجام می‌شود. همچنین توسعه مستقل ماژول‌ها باعث آسان‌تر شدن طراحی، استقرار و مدیریت می‌شود. هر ماژول از معماری لایه‌ای پیروی می‌کند بنابراین در هر ماژول، ساخت یا تغییر هر لایه بدون تاثیر بر لایه دیگر انجام می‌شود. معماری یکپارچه مدولار(منبع)2. خدمات وب آمازون (Amazon Web Services)خدمات وب آمازون یا AWS، یک شرکت تابع آمازون است که پلتفرم محاسبات ابری را برای افراد و سازمان‌ها به منظور استفاده از خدمات ابری ارائه می‌دهد. این خدمات شامل محاسبات، ذخیره‌سازی، پایگاه‌داده، ابزارهای نرم‌افزاری و غیره می‌باشد که از طریق شبکه‌ای از سرورها در سراسر جهان به مشتریان ارائه می‌شود. درواقع AWS با ارائه یک زیرساخت ابری مقیاس‌پذیر، برای کاربران این امکان را فراهم می‌کند تا بدون نیاز به استفاده از منابع فیزیکی گران قیمت، براساس نیازهای خود از خدمات ابری استفاده کنند. مشتریان می‌توانند با استفاده از امکان اندازه‌گیری خودکار برآورد هزینه و پرداخت را انجام دهند. (منبع)3. رویکرد API-firstرویکرد API-first، یک رویکرد آینده نگرانه برای توسعه نرم‌افزار توسط شرکت‌ها است. این رویکرد به این موضوع اشاره دارد که درمقابل درنظر گرفتن APIها پس از توسعه برنامه، APIها را به عنوان بلوک‌های اصلی نرم‌افزار در ابتدای توسعه اولویت بندی کرده و درنظر بگیریم. براین اساس، پیش از نوشتن کد برنامه، APIها را اولویت بندی می‌کنیم و نقش آن‌ها و شرکا را در سازمان تشخیص دهیم. این رویکرد باعث می‌شود که با برنامه‌های داخلی و خارجی به صورت یکپارچه ارتباط برقرار کرده و برای کاربران نهایی قابل دسترس باشد.از مزایای این رویکرد می‌توان به موارد زیر اشاره کرد:بهره‌وری: در این رویکرد، به دلیل اینکه فضای کاری برای توسعه‌دهندگان شناخته شده‌است و APIها متمرکز هستند، همکاری سریع‌تر بوده و بهره‌وری افزایش می‌یابد.کیفیت: استفاده از این رویکرد باعث می‌شود که اشکالات پیش از تولید رفع شوند، بنابراین توسعه‌دهندگان می‌توانند نرم‌افزاری بهتر و انعطاف‌پذیرتر در زمان کوتاه تولید کنند که این موضوع به‌طور مستقیم باعث افزایش کیفیت می‌شود.ساده‌سازی و انطباق: در این رویکرد، معماران می‌توانند قوانین طراحی و راهبری را در مرحله طراحی و توسعه پیاده‌سازی کنند. (منبع)4. پایگاه‌داده‌‌های NoSQLساختار سنتی موجود در پایگاه‌داده‌های رابطه‌ای (ساختار جدولی) به مرور زمان نیاز به انعطاف پذیری بیشتری پیدا کرد تا بتواند مجموعه داده‌های بزرگ و بدون ساختار را مدیریت کرده و مقیاس‌پذیر باشد. از این رو، NoSQL (که به‌عنوان not only SQL و non-SQL نیز شناخته می‌شود) به‌عنوان رویکردی برای طراحی پایگاه‌داده که امکان ذخیره‌سازی و بازیابی داده‌ها را در قالب ساختار داده فراهم می‌کند، پدید آمد. گسترش میکروسرویس‌ها و محدودیت استفاده از پایگاه‌داده‌های رابطه‌ای برای هر کامپوننت، باعث رشد NoSQL شده‌است.از مزایای پایگاه‌داده‌‌های NoSQL می‌توان به موارد زیر اشاره کرد:انعطاف‌پذیری: مدل داده انعطاف‌پذیر بوده و همچنین حجم زیادی از داده‌های درحال تغییر را می‌تواند مدیریت کند.قابلیت اطمینان: داده‌ها در چندین سرور ذخیره‌ شده بنابراین دربرابر از دست رفتن محافظت می‌شوند. همچنین در زمان‌های از کار افتادگی اطمینان از دسترسی وجود دارد.سرعت: امکان ذخیره‌سازی و پردازش سریع را برای استفاده کاربران فراهم می‌کند.هزینه: NoSQL باعث کاهش منابع و به حداقل رساندن هزینه‌ها می‌شود.(منبع)5. معماری بدون سرور (Serverless Architecture)معماری بدون سرور یک رویکرد طراحی نرم‌افزار است که با انتقال مسئولیت مدیریت سرورها به ارائه‌دهندگان سرور ابری (مانند AWS)، تیم توسعه به‌جای نگرانی درمورد سرورها، بر روی توسعه و استقرار کد تمرکز دارد.از مزایای این معماری می‌توان به موارد زیر اشاره کرد:هزینه: هزینه سرور ابری براساس سرورها و ماشین‌های مجازی استفاده شده درخواست می‌شود. بنابراین می‌تواند باعث کاهش هزینه شود.مقیاس‌پذیری: سرورهای ابری در مقابل تغییرات به صورت خودکار مقیاس پذیر هستند.بهره‌وری: با انتقال مسئولیت مدیریت سرورها و کاهش مسئولیت توسعه‌دهندگان، سرعت تحویل و به طورکلی بهره‌وری افزایش می‌یابد.این مزایا باعث افزایش قابل توجه استفاده شرکت‌ها کوچک و بزرگ از معماری بدون سرور شده‌است. از معایب این رویکرد می‌توان به مسائل امنیتی، عدم کنترل بر مشکلات سرور و وابستگی به ارائه‌دهنده و مشکلات مربوط به تست اشاره کرد.(منبع)6. طراحی دامنه محور (Domain Driven Design)طراحی دامنه محور یک رویکرد طراحی نرم‌افزار است که براساس آن، تمرکز اصلی بر روی دامنه و منطق تعیین شده توسط کارشناسان برنامه است. از آنجایی که نرم‌افزار براساس ویژگی‌های یک مشکل و برای حل آن طراحی شده‌است، بنابراین اجزای مختلف برنامه مانند ساختار و زبان کد نرم‌افزار باید با دامنه کسب‌وکار مطابقت داشته باشد.مفاهیم اصلی در طراحی دامنه محور به صورت زیر است:منطق دامنه: منطق دامنه، به بخشی از دامنه گفته می‌شود که نحوه دسترسی، ذخیره‌سازی و تغییر داده‌ها را مشخص می‌کند.مدل دامنه: مدل دامنه به جزئیات مشکل و راه حل آن اشاره دارد.زیر دامنه: به دلیل جزئیات زیاد دامنه و پیچیدگی آن، زیر دامنه به‌وجود آمد. سه زیر دامنه اصلی، پشتیبان و عمومی در طراحی دامنه محور وجود دارد.(منبع)7. معماری شش‌ضلعی (Hexagonal architecture)معماری شش‌ضلعی، که به آن معماری پورت‌ها و آداپتورها نیز گفته می‌شود، یک الگوی معماری برای طراحی نرم‌افزار و جایگزین معماری لایه‌ای سنتی است. هدف این معماری، ایجاد کامپوننت‌های آزاد قابل تعویض است که به سادگی با استفاده از پورت‌ها و آداپتورها به محیط نرم‌افزاری متصل شوند. این کامپوننت‌های آزاد شامل هسته برنامه، پایگاه‌داده، اسکریپت‌های تست، رابط کاربری و غیره می‌باشند. در این معماری اتصال کامپوننت‌ها از طریق پورت‌ها و باتوجه به اهداف پروتکل‌های تعریف شده انجام می‌پذیرد. معماری تمیز پیشنهاد شده توسط رابرت مارتین ترکیبی از اصول معماری شش ضلعی معماری لایه‌ای و چند معماری دیگر است.معماری شش‌ضلعی(منبع)8. منبع‌یابی رویداد (Event Sourcing)منبع‌یابی رویداد روشی برای ذخیره‌سازی وضعیت برنامه براساس تاریخچه رویدادهایی است که در گذشته اتفاق افتاده است. در روش‌های سنتی، برای ذخیره‌سازی وضعیت برنامه، فقط وضعیت فعلی ذخیره می‌شد، درصورتی‌که مسیرهای مختلفی برای رسیدن به این وضعیت وجود داشت. همچنین استفاده از یک مدل جداگانه برای ذخیره تاریخ اقدامات منجر به وضعیت فعلی، باعث بروز پیچیدگی می‌شود. در منبع‌یابی رویداد، هر رویداد نشان دهنده یک تغییر در برنامه است و به عبارت دیگر منبعی از آنچه که در برنامه اتفاق افتاده، می‌باشد.از مزایای منبع‌یابی رویداد می‌توان به موارد زیر اشاره کرد:حسابرسیآنالیزانعطاف‌پذیری طراحیگزارش‌های زمانی(منبع)9. پلتفرم‌های کم کد (Low code platforms)پلتفرم‌های کم کد، یک رویکرد توسعه نرم‌افزار است که وابستگی به رویکردهای برنامه‌نویسی سنتی را کاهش داده و با استفاده از کمترین کد برنامه‌نویسی، امکان تحویل سریع برنامه را فراهم می‌کند. در پلتفرم کم کد، خودکارسازی فرآیند توسعه با استفاده از رابط‌های کاربری گرافیکی و ویژگی کشیدن و رها کردن، به بهبود فرآیند توسعه کمک می‌کند. همچنین قابلیت‌های ابزارهای کم کد باعث بهبود فرآیند DevOps و تخصیص زمان بیشتر برای نوآوری می‌شود.در کنار پلتفرم‌های کم کد، پلتفرم‌های بدون کد نیز وجود دارد. در پلتفرم‌های بدون کد که کاربران می‌توانند بدون نیاز به مهارت‌های برنامه‌نویسی و توسعه، برنامه‌های کسب و کار خود ایجاد کنند.(منبع)10. سیستم مدیریت فرایند کسب و کار (Business Process Management Systems)سیستم مدیریت فرایند کسب و کار یا BPMS، سیستمی برای کمک به کسب و کار و بهینه‌سازی فرآیندها است. این سیستم امکان مدل سازی، طراحی، اجرا و نگهداری فعالیت‌های تجاری و کارکنان در بخش‌های مختلف را فراهم می‌کند. نحوه عملکرد این سیستم به این صورت است که امکان ایجاد فرآیند کسب و کار را در بخش‌های مختلف، نظارت برای اطمینان از کارایی فرآیند و تغییر و بهبود فرآیندهای موجود را فراهم می‌کند.(منبع)11. صف پیام (Message Queue)صف پیام امکان ذخیره‌سازی موقت پیام را در زمانی که برنامه مشغول است، برای برنامه کاربردی فراهم می‌کند. درواقع، زمانی که پیام‌ها توسط تولید کننده ایجاد می‌شوند، به صف پیام ارسال می‌شوند و تا زمانی که توسط مصرف کننده مورد استفاده قرار گیرند، نگهداری می‌شوند. انتقال پیام‌ها بین فرآیندها یا سیستم‌ها، با اضافه کردن کارگزار پیام مانند RabbitMQ، Kafka یا LavinMQ انجام می‌شود.از مزایای صف پیام می‌توان به موارد زیر اشاره کرد:افزایش قابلیت اطمینان، مقیاس‌پذیری و اطمینان‌پذیری سیستماستقلال تولید کننده و مصرف کنندهبرای محاسبات توزیع شده، زمان‌بندی وظیفه و مدیریت گردش‌کار می‌تواند مورد استفاده قرار گیرد(منبع)12. ارکستراسیون کانتینر (Container orchestration)ارکستراسیون کانتینر به طور خودکار استقرار، مدیریت، مقیاس‌بندی و راه‌اندازی شبکه برای تعداد زیادی از کانتینرها را امکان‌پذیر می‌کند. کانتینرها کامپوننت‌های سبک و اجرایی هستند که امکان اجرای برنامه‌ها در محیط‌های مختلف بدون نیاز به طراحی و ساخت مجدد را فراهم می‌کنند. از محبوب‌ترین ارکستراتورهای کانتینری می‌توان به Kubernetes ،Docker Swarm و OpenShift اشاره کرد.نحوه کار ارکستراسیون کانتینر به این صورت است که توسعه دهنده یک فایل پیکربندی که یک حالت پیکربندی مطلوب مورد نظر را تعریف می‌کند، می‌نویسد؛ سپس ارکستراتور به طور مداوم از هوش و منابع خود برای رسیدن به حالت مورد نظر استفاده می‌کند.از مهم‌ترین مزایای ارکستراسیون کانتینر می‌توان به خودکارسازی اشاره کرد. خودکارسازی، پیچیدگی و تلاش مدیریت یک برنامه بزرگ کانتینری را کاهش داده و از رویکرد چابک برای توسعه و استقرار در چرخه‌های سریع و تکراری پشتیبانی می‌کند.(منبع)13. ابزارهای مدیریت لاگ (Log Management Tools)ابزارهای مدیریت لاگ، نحوه تعامل کاربران با برنامه‌ها و سیستم‌ها را به‌صورت زمان واقعی مجسم می‌کنند. این ابزارها با جمع‌آوری، تجزیه و تحلیل و حفظ داده‌ها می‌تواند قابلیت اطمینان و امنیت را افزایش داده و قادر به نظارت و بهبود عملکرد و پیدا کردن مشکلات و نقص‌ها می‌باشند. ابزارهای مدیریت لاگ داده‌های جمع‌آوری شده را فیلتر کرده و آن‌ها را به اطلاعات قابل کنترل تبدیل می‌کند و برای درک فعالیت‌های سازمان، با استفاده از نمودارها و خلاصه‌های ساده‌ و غیره یک نمایش واضح و بصری از نحوه عملکرد سیستم را به‌صورت زمان واقعی ایجاد می‌کنند.(منبع)14. ابزارهای پایش (Monitoring tools)ابزارهای پایش برای ارزیابی و نظارت بر برنامه‌ها و سیستم‌ها و بررسی وضعیت، سلامت، عملکرد محیط و زیرساخت‌ها مورد استفاده قرار می‌گیرند. نظارت مداوم بر سیستم به مدیریت عملکرد، قابلیت اطمینان و صرفه‌جویی در زمان برای تفسیر رویدادها کمک می‌کند که در نهایت باعث رضایت مشتریان از عملکرد سیستم می‌شود.یکی از ابزارهای منبع باز برای پایش و ارزیابی برنامه‌ها، ابزار Prometheus است. این ابزار داده‌ها را در بازه‌های زمانی به عنوان معیار، جمع‌آوری و ذخیره کرد و این اطلاعات را از طریق داشبورد نمایش می‌دهد. این اطلاعات شامل آمار حجم کار، اطلاعات بحرانی، وضعیت درحال اجرا و غیره می‌باشند.جمع‌آوری این داده‌ها می‌تواند به دلایل زیر مفید باشد:هشدار و رسیدگی به مشکلات پیش از رخدادنظارت و تجزیه و تحلیل فرآیندمقایسه داده‌های پیشین(منبع)15. تجزیه و تحلیل ایستا کد (Static Code Analysis)تجزیه و تحلیل ایستا کد یک رویکرد محبوب در توسعه نرم‌افزار است که براساس آن توسعه‌دهندگان کد منبع را پیش از اجرا و در اوایل فرایند توسعه، برای شناسایی آسیب‌پذیری‌های پنهان و خطاها و رعایت دستورالعمل‌ها و استانداردهای برنامه‌نویسی، بررسی می‌کنند.از مزایای تجزیه و تحلیل ایستا می‌توان به موارد زیر اشاره کرد:سازگاری کد با استانداردهای برنامه‌نویسیامنیت بالاتر با یافتن نقص‌های امنیتی در ابتدای کارقابلیت نگهداری بهتر با رفع سریع مشکلاتصرفه‌جویی در هزینه‌هادر کنار تجزیه و تحلیل ایستا، تجزیه و تحلیل پویا قرار دارد. تجزیه و تحلیل ایستا مشکلات را پیش از اجرای برنامه شناسایی می‌کند اما در تجزیه و تحلیل پویا شناسایی مشکلات پس از اجرای برنامه انجام می‌شود.(منبع) Fatemeh Sepahdoost Fatemeh Sepahdoost Thu, 23 Nov 2023 00:11:36 +0330 https://virgool.io/CE-SHAHED-publication/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2-dei0y8semgta معماری معمار نرم افزار از بهترین برنامه نویسانی است در کنار برنامه نویسی، اعضای تیم را به سمت طراحی دعوت می‌کند. به شکل یا چهارچوبی که معماران نرم افزار به یک سیستم نرم افزاری می‌دهند، معماری گفته می‌شود؛ بطوریکه شامل تقسیم آن سیستم به اجزا، نحوه چیدمان و راه‌های ارتباط آن‌ها می‌باشد. معماری یک سیستم تاثیر بسیار کمی بر روی کارکرد آن سیستم دارد، در واقع هدف اصلی معماری ساده سازی توسعه، استقرار و نگهداری سیستم نرم افزاری می‌باشد. یک معماری خوب باید از موارد زیر پشتیبانی کند:توسعه: معماری یک سیستم باید توسعه را برای تیم توسعه دهنده آسان کند، در غیر اینصورت سیستم نرم افزاری عمر طولانی نخواهد داشت. به عنوان مثال، سیستمی متشکل از چند تیم توسعه که هرکدام شامل چند توسعه دهنده می‌باشد، باید به اجزای تعریف شده و ارتباطات معین و قابل اعتماد تقسیم شود. این موضوع برای یک تیم کوچک شامل چند توسعه دهنده شاید به عنوان یک مانع به نظر می‌رسد؛ به همین دلیل بسیاری از سیستم‌ها فاقد معماری خوب است.استقرار: معماری یک سیستم باید قابل استقرار باشد؛ هرچه هزینه استقرار بیشتر باشد، سیستم کمتر مفید است. به عنوان مثال، اگر در توسعه اولیه یک سیستم براساس تصمیم توسعه دهندگان معماری میکرو سرویس انتخاب شود، اما در زمان استقرار متوجه این موضوع می‌شوند که تعداد سرویس‌های کوچک بسیار زیاد و اتصالات بین آن‌ها سخت و پر خطا شده است. از این رو، عدم توجه به استقرار منجر به معماری‌هایی با توسعه آسان و استقرار سخت می‌شود.نگهداری: نگهداری پر هزینه‌ترین جنبه یک سیستم نرم افزاری می‌باشد، چراکه نرم افزار شامل حجم زیادی از نقص‌ها، اصلاحات و اضافه کردن ویژگی‌های جدید است که نیازمند منابع انسانی بسیاری است. از این رو، معماری خوب با جداسازی سیستم به اجزای مختلف می‌تواند باعث کاهش این هزینه‌ها شود.عملکرد: تاثیر معماری سیستم بر روی عملکرد نسبت به توسعه، استقرار و نگهداری کمتر است، چراکه معماری‌هایی که مانع عملکرد می‌شوند به نسبت کم هزینه‌تر از معماری‌هایی هستند که مانع توسعه، استقرار یا نگهداری می‌شوند.باز نگه داشتن گزینه‌ها: انعطاف پذیر بودن و امکان تغییر سریع و آسان نرم افزار با باز گذاشتن گزینه‌ها حاصل می‌شود. در واقع جزئیات نباید به سیاست‌های اصلی ارتباط داشته باشند تا تصمیم‌گیری در مورد جزئیات ممکن باشد.عدم وابستگی اولین دغدغه معمار این است که معماری باید از هدف سیستم پشتیبانی کند که این به معنای پشتیبانی از موارد کاربری برنامه هدف است. همانطور که پیش از این بیان شد، معماری تاثیر زیادی بر روی عملکرد برنامه ندارد، اما مهم‌ترین کاری که معماری خوب برای عملکرد برنامه انجام می‌دهد، شفاف سازی رفتار است تا هدف سیستم در سطح معماری قابل مشاهده باشد. از آنجایی که موارد کاربری در ساختار و سطح بالای سیستم قابل مشاهده است، بنابراین توسعه دهندگان نیازی به توصیف رفتار سیستم ندارند.جداسازی لایه‌هابراساس اصول SRP و CCP، معمار باید عناصری را که به دلایل مختلف تغییر می‌کنند جدا کرده و عناصری را که به دلایل مشابه تغییر می‌کنند، باتوجه به هدف سیستم جمع آوری کند. از این رو، سیستم‌ها را براساس مواردی که به طور جدا تغییر می‌کنند، به لایه‌های افقی تقسیم می‌کنیم. در عین حال، موارد کاربری برش‌های عمودی هستند که این لایه‌های افقی را تقسیم می‌کنند. در نتیجه، با استفاده از این شیوه جداسازی، می‌توان موارد جدید را بدون تداخل با موارد قبلی به سیستم اضافه کرد. همچنین این روش باعث می‌شود مواردی که توان عملیاتی بالایی دارند، پیش از مواردی که توان عملیاتی پایینی دارند، اجرا شوند. علاوه بر موارد مذکور، این روش باعث کاهش تداخل تیم‌ها، امکان توسعه مستقل و سبب انعطاف پذیری در استقرار می‌شود. باید به این نکته توجه داشت که جداسازی یک سیستم با گذشت زمان تغییر کرده و معمار باید این تغییرات را تسهیل کند.حالت‌های جداسازی را می‌توان در سه سطح تقسیم بندی کرد:سطح منبع: در این سطح وابستگی بین ماژول‌های کد منبع به صورتی است که تغییر در یک ماژول باعث تغییر یا کامپایل مجدد ماژول‌های دیگر نمی‌شود. در این حالت همه اجزاء در فضای آدرس یکسان اجرا می‌شوند و از طریق فراخوانی توابع ارتباط برقرار می‌کنند.سطح استقرار: در این سطح وابستگی بین قسمت‌های قابل استقرار به صورتی است که تغییر در کد منبع یک ماژول باعث استقرار مجدد دیگران نشود. بسیاری از اجزاء در فضای آدرس یکسان هستند اما سایر اجزاء در فرآیندهای دیگر در همان پردازنده بوده و از طریق ارتباطات بین فرآیندی، سوکت‌ها یا حافظه مشترک ارتباط برقرار می‌کنند.سطح سرویس: در این سطح وابستگی به صورتی است که هر واحد اجرایی مستقل از تغییرات دیگران است و ارتباط فقط از طریق بسته‌های شبکه انجام می‌شود.مرزها مرزها برای جداسازی عناصر نرم افزار به کار می‌روند، به طوریکه یک طرف درمورد طرف دیگر نباید اطلاعی داشته باشد. در یک معماری خوب بین چیزهایی که اهمیت دارند و چیزهایی که اهمیت ندارند یک مرز یا خط وجود دارد تا موارد فرعی قابل تعویض باشد.به عنوان مثال در تصویر زیر، رابط کاربری گرافیکی و پایگاه داد برای قوانین تجاری اهمیت ندارد، بنابراین بین آن‌ها یک خط وجود دارد. جهت خط نیز بسیار اهمیت دارد به این معنا که پایگاه داده و رابط کاربری گرافیکی برای قوانین تجاری اهمیت ندارند اما این دو بدون قوانین تجاری وجود ندارند. باتوجه به اینکه پایگاه داده و رابط کاربری گرافیکی در اینجا به صورت پلاگین درنظر گرفته شدند، بنابراین قابل تغییر و جایگزینی هستند.عبور از مرز تابعی در یک طرف مرز است که تابعی در طرف دیگر را در زمان اجرا فراخوانی می‌کند که ایجاد آن نیازمند مدیریت وابستگی‌های کد منبع است.شکل‌های مختلف مرزها به صورت زیر است:یکپارچه: ساده‌ترین مرزهای معماری هیچ نمایش فیزیکی دقیقی ندارند. توابع و داده‌ها به صورت منظم در یک پردازنده و فضای آدرس واحد است (حالت جداسازی سطح منبع). اینکه در حالت استقرار یکپارچه، مرزها قابل مشاهده نیستند به این معنا نیست که مرزها وجود ندارند. ساده‌ترین عبور از مرز، فراخوانی تابع از سطح پایین به سطح بالا است که در این حالت وابستگی زمان اجرا و کامپایل به سمت مولفه سطح بالاتر است.فرآیندهای محلی: یک مرز معماریِ قوی‌تر است که از خط فرمان یا فراخوان سیستمی ایجاد می‌شود. فرآیندهای محلی در یک یا چند پردازنده یکسان اما در فضاهای آدرس جدا اجرا می‌شوند. بیشتر فرآیندهای محلی با استفاده از سوکت‌ها یا امکانات ارتباطی سیستم عامل بایکدیگر ارتباط برقرار می‌کنند.سرویس‌ها: قوی‌ترین مرز معماری، سرویس است که عموما از خط فرمان یا فراخوان سیستم ایجاد می‌شود و به موقعیت فیزیکی آن‌ها بستگی ندارد. می‌توان گفت یک سرویس، مجموعه‌ای از فرآیندهای محلی در حال تعامل است.سیاست و سطح سیستم‌های نرم افزاری مجموعه‌ای کامل از سیاست‌ها است که براساس آن ورودی به خروجی تبدیل می‌شود. در بیشتر سیستم‌ها، می‌توان سیاست‌ها را به عبارات کوچک‌تر تقسیم کرد. یک معمار نرم افزار خوب باید بتواند این سیاست‌ها را به صورت دقیق جدا کرده و براساس تغییراتشان، آن‌ها را در یک گراف غیر چرخه‌ای جهت‌دار، گروه بندی کند؛ بطوریکه جهت وابستگی‌ها از اجزای سطح پایین به سمت اجزای سطح بالا است. به فاصله از ورودی‌ها و خروجی‌ها، سطح می‌گویند. هرچقدر سیاست از ورودی و خروجی سیستم دورتر باشد، سطح بالاتری دارد.قوانین کسب و کار قوانین کسب و کار، قوانین یا دستورالعمل‌هایی هستند که فارغ از نحوه پیاده سازی، موجب صرفه جویی در هزینه‌ها می‌شوند. در سیستم‌های کامپیوتری، موجودیت یک شیء است که شامل مجموعه‌ای از قوانین تجاری مهم است. موارد کاربری از قوانینی تشکیل شده که نحوه و زمان استفاده از قوانین تجاری مهم در موجودیت‌ها را تعیین می‌کند. درواقع موارد کاربری نحوه نمایش سیستم برای کاربر را بیان نمی‌کند، بلکه قوانین برنامه که برروی تعامل کاربران و نهادها حاکم است را توصیف می‌کند.معماری فریاد معماری نرم افزار ساختارهایی است از موارد کاربری سیستم پشتیبانی می‌کنند، بنابراین معماری باید درمورد موارد کاربری برنامه فریاد بزند! به عنوان مثال وقتی به معماری یک کتابخانه نگاه می‌کنیم، با نگاه به قفسه‌های کتاب، میزهای مطالعه و غیره کاملا واضح است که این ساختمان کتابخانه است. معماری‌ها نباید براساس فریمورک‌ها باشند، درغیر اینصورت نمی‌توانند براساس موارد کاربری عمل کنند. معماری‌های خوب بر روی موارد کاربری متمرکز شده‌اند تا معماران بتوانند ساختارهایی را که از آن‌ها پشتیبانی می‌کنند را بدون تعهد به فریمورک‌ها، ابزارها و محیط‌ها توصیف کنند. به این ترتیب، اگر این موضوع را رعایت کنیم، می‌توانیم موارد کاربری را بدون فریمورک‌ها به صورت واحد تست کنیم.معماری تمیز در چند دهه گذشته ایده‌های مختلفی درمورد معماری سیستم‌ها مطرح شد که هدف مشترک آن‌ها تقسیم نرم افزار به لایه‌های مختلف برای جداسازی دغدغه‌ها است. این معماری‌ها دارای ویژگی‌هایی همچون عدم وابستگی به فریمورک‌ها، طراحی رابط کاربری و پایگاه داده بوده و بدون وابستگی قوانین کسب و کار به آن‌ها قابل تست هستند.لایه‌های مختلف نرم افزار به صورت دایره‌های متحدالمرکز در شکل زیر نمایش داده شده است. حلقه‌های داخلی سیاست و بیرونی مکانیزم‌ها هستند، بطوریکه وابستگی‌های کد منبع به سمت داخل و سیاست‌های سطح بالاتر است. دایره‌های درونی درمورد دایره‌های بیرونی چیزی نمی‌دانند.تعریف این لایه‌های به صورت زیر است:موجودیت‌ها: لایه موجودیت‌ها شامل قوانین حیاتی کسب و کار در سطح سازمان است که می‌توانند شیء با متد یا مجموعه‌ای از ساختار داده‌ها و توابع باشند.موارد کاربری: لایه موارد کاربری شامل قوانین تجاری خاص برنامه است که جریان داده‌های موجودیت‌ها را کنترل می‌کنند. تغییرات در این لایه نباید بر روی موجودیت‌ها اثر بگذارد یا اینکه تحت تاثیر لایه‌های خارجی قرار گیرد.آداپتورهای رابط: این لایه شامل مجموعه‌ای از آداپتورها است که فرمت موجودیت‌ها و موارد کاربری را به فرمت مناسب برای برخی عاملیت‌های خارجی مانند پایگاه داده یا وب تبدیل می‌کنند. هیچ کدی در این لایه نباید از عاملیت‌های خارجی چیزی بداند.فریمورک‌ها و درایورها: این لایه شامل فریمورک‌ها و ابزارهایی مانند پایگاه داده و وب فریمورک است.تعداد این لایه‌ها ممکن است متغییر باشد اما قانون وابستگی همواره باید اعمال شود.ترجمه و خلاصه فصل‌هایی از کتاب معماری تمیز از رابرت مارتین Fatemeh Sepahdoost Fatemeh Sepahdoost Thu, 19 Oct 2023 17:24:47 +0330 https://virgool.io/CE-SHAHED-publication/%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-on2db2arozpm امنیت نرم افزار فراتر از آن است که از فایروال (Firewall) رمز گذاری قوی، تبدیل اطلاعات به کد (Encryption) و... استفاده کنیم؛ در واقع بحث درمورد این است که نرم افزار را به صورتی توسعه دهیم که از همان ابتدا ایمن‌تر باشد.در ادامه مدل‌ها و تكنیک‌هایی که به دستیابی امنیت نرم افزار کمک می‌کنند را بررسی می‌کنیم.مدل‌های چرخه حیات امنیتچرخه حیات توسعه امنیت (SDL-Security Development Lifecycle) یک فرآیند امنیتی نرم افزاری پیشرو در صنعت است. در سال ۲۰۰۴ مایکروسافت مجموعه اصولی را طراحی کرد تا امنیت و حریم خصوصی را در نرم افزارهای خود تعبیه کند. چرخه حیات توسعه امنیت این امکان را برای مایکروسافت فراهم کرد تا امنیت و حریم خصوصی را در مراحل اولیه و در تمام مراحل توسعه نرم افزار فراهم کند.اصول چرخه حیات توسعه امنیت:- ایمن با طراحی (Secure by Design) معماری، طراحی و ساختار ایمن: برنامه نویسان باید یکسری ملاحظات و نکات امنیتی را در معماری اولیه و توسعه نرم افزار در نظر بگیرند.مدل سازی و کاهش تهدید: مدل سازی تهدید و روش‌های مقابله و کاهش تهدیدات طراحی می‌شود.از بین بردن آسیب پذیری‌ها: هیچ آسیب پذیری امنیتی شناخته شده‌ای که بتواند خطر قابل توجهی برای نرم افزار ایجاد کند، بعد از بررسی نباید در کد باقی بماند.بهبود در امنیت: پروتکل‌ها و کدهای قدیمی که ایمنی کمتری دارند در صورت امکان باید جایگزین شوند.- ایمن به صورت پیش فرض (Secure by Default)کمترین امتیاز: همه اجزا باید با حداقل امتیاز ممکن اجرا شوند.دفاع در عمق: در مقابله با تهدیدات نباید فقط به یک راه حل تکیه کنیم تا اگر یک سد دفاعی شکسته شد، سد دفاعی دیگری داشته باشیم.تنظیمات پیشفرض محافظه کارانه: از آنجایی که تیم توسعه از سطح حمله برای محصول آگاه است، باید با یک سری روش‌ها احتمال حمله را در پیکره بندی پیشفرض به حداقل برساند.اجتناب از تغییرات مخاطره آمیز پیشفرض: برنامه‌ها نباید هیچ تغییر پیشفرضی در سیستم عامل یا تنظیمات امنیتی ایجاد کنند تا امنیت میزبان کاهش پیدا کند.خدماتی که کمتر مورد استفاده قرار می‌گیرند به صورت پیشفرض خاموش شوند: اگر کمتر از ۸۰% کاربران یک برنامه از یک ویژگی استفاده می‌کنند، آن ویژگی نباید به صورت پیشفرض فعال باشد.- ایمن در استقرار (Secure in Deployment)راهنماهای استقرار: این راهنماها نحوه توسعه امن هر ویژگی را بیان می‌کنند تا کاربران بتوانند ارزیابی ریسک امنیتی داشته باشند.ابزارهای تحلیل و مدیریت: تجزیه و تحلیل امنیتی و ابزارهای مدیریت، برای مدیران این امکان را فراهم می‌کند تا سطح امنیتی را برای انتشار نرم افزار تعیین کنند.- ارتباطات (Communications)پاسخ امنیتی: زمانی که حمله رخ می‌دهد، تیم توسعه باید بتواند پاسخگو باشد و اطلاعات مربوط به بروزرسانی‌های امنیتی را ارسال کند.مشارکت جوامع: تیم‌های توسعه باید به صورت فعال با کاربران در ارتباط باشند تا به سوالات مربوط به آسیب پذیری‌، بروزرسانی‌ یا تغییرات امنیتی پاسخگو باشند.مهندسی الزامات امنیتیهرچند الزامات امنیتی بخش مهمی از توسعه ایمن نرم افزار هستند ولی در عمل اغلب نادیده گرفته می‌شوند. علاوه بر مدل‌های چرخه حیات امنیتی مدل‌های زیادی وجود دارد که مختص نیازمندی‌های امنیتی است که یکی از آنها مدل SQUARE است.مدل SQUARE:این مدل استخراج، طبقه بندی و اولویت بندی الزامات امنیتی برای سیستم‌های نرم افزاری متمرکز را فراهم می‌کند و تمرکز آن ایجاد مفاهیم امنیتی در مراحل اول توسعه است. به علاوه، از این مدل مدل می‌توان برای سیستم‌هایی که درحال بهبود و اصلاح هستند هم استفاده کرد.مراحل مدل SQUARE:توافق درمورد تعاریفشناسایی دارایی‌ها و اهداف امنیتیتوسعه مصنوعاتارزیابی ریسکانتخاب تکنیک استخراجاستخراج الزامات امنیتیطبقه بندی الزاماتاولویت بندی الزاماتبازرسی الزاماتموارد سوء استفاده و الگوهای حملهروش‌هایی که مهاجم برای سوء استفاده از نرم افزار استفاده می‌کند را باید بررسی کنیم. به عبارت دیگر سناریوهای مختلف حمله را طراحی می‌کنیم تا بتوان از قبل درمورد واکنش به حملات احتمالی تصمیم گیری شود. همچنین از این روش می‌توان برای تجزیه و تحلیل تهدیدات نیز استفاده کرد.مثال: نحوه حمله بدافزار DroidCleaner به تلفن همراه با استفاده از برنامه ایمیل K-9.تجزیه و تحلیل ریسک امنیتیروش‌های مختلفی برای ارزیابی ریسک امنیتی وجود دارد که یکی از آن‌ها روش چارچوب مدیریت ریسک (RMF-Risk Management Framework) است.مراحل روش RMF:سیستم اطلاعاتی و اطلاعات پردازش، ذخیره و ارسال شده توسط آن سیستم را براساس تجزیه و تحلیل طبقه بندی کنیم.مجموعه اولیه‌ای از کنترل‌های امنیتی پایه برای سیستم اطلاعات را براساس طبقه بندی امنیتی انتخاب کنیم.کنترل‌های امنیتی را پیاده سازی کنیم.کنترل‌های امنیتی را با استفاده از روش‌های امنیتی مناسب ارزیابی کنیم.مجوز عملیات سیستم اطلاعاتی را براساس یک سری معیارها صادر کنیم.روی کنترل‌های امنیتی به صورت مستمر نظارت داشته باشیم.مدل سازی، اولویت بندی و کاهش تهدیداتمدل سازی تهدید (TMM-Threat Modeling Method) روشی است که هدف آن شناسایی توانایی و اهداف مهاجمان است تا از آن برای فهرست نویسی تهدیدات احتمالی استفاده شود.استراید (STRIDE) یکسری روش‌های مدل سازی تهدید است که نحوه کار آن به این صورت است که یک سیستم را به عناصرش تقسیم می‌کند و هر عنصر را از جهت آسیب پذیر بودن نسبت به تهدیدات بررسی می‌کند.سطح حملههمه نقاطی که یک مهاجم از طریق آن می‌تواند به سیستم وارد شود (تا به سیستم دسترسی پیدا کند یا داده‌ها را خارج کند) را سطح حمله می‌گویند.سطح حمله یک برنامه کاربردی:مجموعه تمام مسیرها برای داده‌ها و دستورات ورودی خروجی برنامه.کدی که از این مسیرها محافظت می‌کند. (از جمله احراز هویت، مجوزها، اعتبار سنجی داده و ...)داده‌های ارزشمند در برنامه.کدی که از این داده‌ها محافظت می‌کند. ( از جمله رمزگذاری، کنترل‌های امنیتی و ...)پروژه امنیت نرم‌افزاری تحت وب (OWASP)یک متدولوژی است که معیارهایی را برای افزایش امنیت نرم افزار (برای توسعه دهندگان جهت درک و مدیریت ریسک‌های امنیتی برنامه حین طراحی و همچنین توسط متخصص امنیت برنامه که ارزیابی ریسک امنیتی را انجام می‌دهند) شرح داده است.خلاصه و ترجمه شده از کتاب مهندسی نرم افزار پرسمن ویرایش نهم Fatemeh Sepahdoost Fatemeh Sepahdoost Sun, 26 Dec 2021 00:42:02 +0330 https://virgool.io/CE-SHAHED-publication/%D9%BE%D8%B1%D9%88%D8%AA%DA%A9%D9%84-%D9%87%D8%A7%DB%8C-%D9%84%D8%A7%DB%8C%D9%87-%D9%BE%DB%8C%D9%88%D9%86%D8%AF-%D8%AF%D8%A7%D8%AF%D9%87-%D9%85%D8%AF%D9%84-osi-ikcrcqt9ouce پروتكل ٨٠٢.١١ برای Wi-Fi:۸۰۲.۱۱ مجموعه‌ای از پروتکل‌های استاندارد برای شبکه‌های محلی بی‌سیم (Wireless LAN) است كه در سال ١٩٩٧ توسط موسسه IEEE پايه گذاری شد. هر استاندارد IEEE با نام منحصربفردی شناخته می‌شود؛ پیشوند ۸۰۲ نشان دهنده تمام پروتکل‌ها و اصلاحیه‌های مربوط به شبکه‌های یک محدوده است. به عنوان مثال استانداردهای شبکه محلی اترنت با ۸۰۲.۳ و شبکه شخصی بی‌سیم (Wireless PAN) با ۸۰۲.۱۵ نامگذاری شده است، به همین ترتیب Wi-Fi یا شبکه محلی بی‌سیم با ۸۰۲.۱۱ شناخته می‌شود.۸۰۲.۱۱ در شبکه‌های خانگی و اداری برای اتصال لپ‌تاپ، چاپگر، تلفن هوشمند و سایر دستگاه‌ها به یکدیگر استفاده می‌شود. قبل از ابداع این پروتکل، برای داشتن شبکه محلی با سرعت بالا، از اتصال فیزیکی با کابل استفاده می‌شد.پروتکل ۸۰۲.۱۱ استانداردهای مختلفی دارد که تاریخچه مشهورترین اصلاحیات آن به صورت زیر است:استاندارد ۸۰۲.۱۱a: در سال ۱۹۹۹ منتشر شد که با نام Wi-Fi A نیز شناخته می‌شود. اولین استاندارد Wi-Fi بود که دو سال بعد از کامل شدن استاندارد اولیه از راه رسید. این اصلاحیه باند ۵ گیگاهرتز را هم اضافه کرد تا Wi-Fi منعطف‌تر از قبل باشد.(فضای ۲.۴ گیگاهرتز با تلفن‌های خانگی، ماکروویوها و... پُر شده بود)استاندارد ۸۰۲.۱۱b: اوایل سال ۲۰۰۰ منتشر شد که Wi-Fi B نیز نام گرفت. اولین پروتکل فراگیر بود و توانست بُرد و سرعت انتقال اطلاعات را تا ۱۱ مگابیت بر ثانیه افزایش دهد.استاندارد ۸۰۲.۱۱g: در سال ۲۰۰۳ یعنی ۳ سال بعد از Wi-Fi B و با سرعتی ۵ برابر بالاتر عرضه شد.استاندارد ۸۰۲.۱۱n: در سال ۲۰۰۹ منتشر شد که با نام Wi-Fi N نیز شناخته می‌شود. نرخ انتقال اطلاعات را به ۴۵۰-۳۰۰ مگابیت بر ثانیه رساند.استاندارد ۸۰۲.۱۱ac: در سال ۲۰۱۳ یعنی ۴ سال بعد از Wi-Fi N منتشر شد. به عنوان اولین قدم در مسیر Wi-Fi گیگابیتی معرفی شد که تقریبا سرعت ۱ گیگابیت بر ثانیه یا ۸۰۰ مگابیت بر ثانیه را فراهم می‌کرد.استاندارد ۸۰۲.۱۱ah: در سال ۲۰۱۷ معرفی شد. دارای فرکانس ۹۰۰ مگاهرتز است، به همین دلیل مصرف انرژی کم و بُرد بیشتری دارد.استاندارد ۸۰۲.۱۱ax: در ۹ فوریه ۲۰۲۱ تایید شد. جانشین ۸۰۲.۱۱ac است و به عنوان Wi-Fi با کارایی بالا و بهبود عملکرد برای مصرف کنندگان شناخته می‌شود.پروتکل اترنت (Ethernet):اترنت مجموعه‌ای از استانداردهای مختلف برای شبکه‌های کامپیوتری است که در سال ۱۹۸۰ به صورت تجاری معرفی و اولین بار در سال ۱۹۸۳ با نام ۸۰۲.۳ IEEE استاندارد شد.یکی از ویژگی‌های خوب اترنت این است هرچند که استانداردهای مختلفی دارد ولی ساختار فریم اترنت در همه آن‌ها یکسان است و از زمان معرفی تاکنون تغییرات زیادی نداشته است.ساختار فریم اترنت:فریم اترنت مقدمه فریم(Preamble): الگویی ۷ بایتی از ۰ و ۱ است که برای همگام سازی (Synchronization) بکار می‌رود.حائل (SFD-Start Frame Delimiter): پایان مقدمه را مشخص می‌کند و به گیرنده فریم می‌گوید که فیلد بعدی، خود فریم اترنت است که با فیلد مقصد شروع می‌شود.آدرس مقصد (Destination Address): آدرس مک گره مقصد یا گیرنده فریم را نشان می‌دهد.آدرس مبداء (Source Address): آدرس مک گره مبداء یا فرستنده فریم را نشان می‌دهد.نوع (Type): نوع محتوی فریم را نشان می‌دهد.(IPv4 و IPv6)داده (Data): محتوی فریم (به عنوان مثال می‌تواند بسته‌ای با فرمت IPv4 باشد) که طول آن می‌تواند ۱۵۰۰-۶۴ بایت باشد.ترتیب بررسی فریم (FCS-Frame Check Sequence): به گره گیرنده کمک می‌کند تا متوجه شود فریم صحیح است یا مخدوش شده است.پروتکل Point-to-Point:یک پروتکل نقطه به نقطه مبتنی بر بایت (Byte-Oriented) است که وظیفه انتقال داده‌ها را در لایه پیوند داده به صورت نقطه به نقطه برعهده دارد. به عبارت دیگر، می‌تواند دو روتر را مستقیما بدون هیچ میزبان یا دستگاه شبکه‌ای در وسط وصل کند.پروتکل HDLC (High level Data Link Control) هم یک پروتکل لایه پیوند داده سنکرون مبتنی بر بیت (Bit-Oriented) است.سوال: PPP بهتر است یا HDLC؟ این سوال نمی‌تواند درست باشد، چراکه باتوجه به شرایطی که قرار است ارتباطات ایجاد شود، باید به همان شکل عمل کنیم.یکی از تفاوت‌های این دو پروتکل این است که HDLC برای دستگاه‌هایی که سیسکو نیستند نمی‌تواند استفاده شود ولی PPP می‌تواند برای دستگاه‌های غیر سیسکو استفاده شود. بنابراین اگر در قسمتی از یک سازمان یک روتر سیسکو و در قسمت دیگر یک روتر میکروتیک قرار داشته باشد (یعنی دستگاه‌های دو طرف با یکدیگر متفاوت باشند)، از پروتکلی استفاده می‌کنیم که از هردوی آن‌ها پشتیبانی کند یعنی PPP.ساختار فریم PPP:فریم PPPپرچم (Flag): وظیفه تعیین آغاز و پایان یک فریم را برعهده دارد.آدرس (Address): در صورتی که Broadcast باشد، روی ۱۱۱۱۱۱۱۱ قرار می‌گیرد.کنترل (Control): به صورت پیشفرض روی ۱۱۰۰۰۰۰۰ قرار دارد.پروتکل (Protocol): وظیفه تعیین نوع داده‌ها را برعهده دارد.داده (Data): حاوی داده‌ها از لایه شبکه است.ترتیب بررسی فریم (FCS-Frame Check Sequence): وظیفه چک کردن سالم بودن بسته و خطاهایی که ممکن است به وجود آمده باشد را برعهده دارد.پروتکل Point-to-Point Over Ethernet:شاخه‌ای از پروتکل Point-to-Point است که Over Ethernet در آن به معنای استفاده از اترنت است. همانطور که قبل‌تر گفته شد، PPP امکان تبادل داده بین دو نقطه را برعهده دارد ولی در PPPoE داخل فریم اترنت قرار می‌گیرد (Encapsulate). Fatemeh Sepahdoost Fatemeh Sepahdoost Thu, 23 Dec 2021 23:24:44 +0330