اصول طراحی ایمن از دیرباز پایه و اساس ساخت سیستم های ایمن بوده است. و آنها جنبه مهمی از امنیت سایبری مدرن باقی می مانند.

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

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

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

بیایید با تشریح این اصول طراحی ایمن قبل از تحلیل عمیق تر در هر یک شروع کنیم.

اصول کلیدی طراحی ایمن:

اقتصاد مکانیزم: طرح ها را ساده و مینیمال نگه دارید.

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

میانجیگری کامل: هر درخواست دسترسی برای مرجع را تحلیل کنید.

طراحی باز: اسرار در داده ها نهفته است، نه طراحی.

تفکیک امتیاز: برای تصمیم گیری های حیاتی دو طرف لازم است، امن تر است.

حداقل امتیاز: با حداقل مجوزهای لازم کار کنید.

کمترین مکانیسم رایج: زیرسیستم های مشترک بین کاربران را محدود کنید.

مقبولیت روانی: اطمینان از قابلیت استفاده برای انسان.

اصول اضافی:

عامل کار: هزینه نقض امنیت را در برابر منابع مهاجم بسنجید.

ضبط مصالحه: موارد نقض گزارش زمانی که رخ می دهد.

هشت اصل اصلی طراحی امن

اقتصاد مکانیزم

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

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

اما به یاد داشته باشید که سادگی فقط مترادف کوتاهی نیست. به عنوان مثال، این کد C را در نظر بگیرید:

 // Example A if (a = b) // Example B a = b; if (a != 0 )

در اینجا، شخصی که به این کد نگاه می کند ممکن است فکر کند که توسعه دهنده به جای "="" "==" را در نظر گرفته است. مثال اول می تواند منجر به سردرگمی شود، در حالی که نمونه دوم به وضوح قصد توسعه دهنده را نشان می دهد. این ممکن است بی اهمیت به نظر برسد، اما این سردرگمی کلیدی بود در تلاش برای پشتیبانی هسته لینوکس در سال 2003 !

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

پیش‌فرض‌های بی‌خطر

شما باید تصمیمات دسترسی را بر اساس مجوز قرار دهید تا حذف. اشتباهات در سیستم های مبتنی بر مجوز معمولاً منجر به انکار تصادفی می شود - یعنی دسترسی کاربران به اطلاعات ضروری ممنوع می شود. اینها را می توان به سرعت شناسایی کرد.

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

در اصل، شما باید فهرست ‌های مجاز را بر فهرست‌های رد اولویت دهید – نه فقط در کنترل دسترسی، بلکه در اعتبارسنجی ورودی.

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

میانجیگری کامل

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

این نیاز به یک روش قابل اعتماد برای شناسایی منبع هر درخواست دارد و هر گونه تغییر در مرجع باید به سرعت به روز شود. این اصل در مورد اعتبارسنجی ورودی نیز صدق می کند.

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

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

خوشبختانه، میانجی‌گری کامل تضمین می‌کند که دستگاه خودپرداز قبل از پرداخت پول نقد، دوباره موجودی شما را تأیید می‌کند و به طور مؤثر از چنین سوءاستفاده‌هایی جلوگیری می‌کند.

طراحی را باز کنید

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

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

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

تفکیک امتیاز

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

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

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

این اصل همچنین بر لزوم ایجاد کاربرانی با نقش ها و امتیازات تخصصی به جای تکیه بر ابرکاربرانی که می توانند به همه چیز دسترسی داشته باشند، دلالت دارد.

کمترین امتیاز

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

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

کمترین مکانیسم رایج

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

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

داده های مشترک خطرات مشابهی دارند. اگر دو فرآیند به فایل‌های موقت یکسان دسترسی داشته باشند، به خطر افتادن یکی از فرآیندها می‌تواند روی دیگری تأثیر بگذارد. جداسازی و جداسازی فرآیند و همچنین استفاده از تکنیک هایی مانند کانتینرها و مجازی سازی می تواند به جلوگیری از اثر دومینو کمک کند.

مقبولیت روانی

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

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

دو اصل اضافی

فاکتور کار

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

شما باید با در نظر گرفتن انگیزه های مهاجم و ارزش دارایی های خود، تعادل بین هزینه های امنیتی و ضررهای احتمالی را هدف قرار دهید.

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

برای مثال عملی، الگوریتم‌های ذخیره‌سازی رمز عبور - مانند Argon2، bcrypt و scrypt - دارای یک پارامتر "work factor" هستند که میزان منابع مورد استفاده را تعیین می‌کند. این می تواند مقیاس شود تا الگوریتم را برای استفاده منظم به اندازه کافی سریع نگه دارد، اما به شدت گران است.

ضبط سازش

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

بسته بندی

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

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

آخرین OWASP Top 10 با ارائه "طراحی ناامن" برای اولین بار بر نقش حیاتی طراحی تاکید می کند. برای رسیدگی به این موضوع، برای تیم های توسعه دهنده ضروری است که بهترین شیوه ها را به طور کامل درک کنند.

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

خبرکاو