Principles of security
این بخش مقدمه‌ای بسیار کوتاه بر برخی مفاهیم مورد استفاده در حوزه امنیت نرم‌افزار است، چرا که این مفاهیم ممکن است برای بسیاری از توسعه‌دهندگان اپلیکیشن ناآشنا باشند. مجموعه برگه‌های تقلب OWASP توضیحات عمیق‌تری برای این اصول امنیتی ارائه می‌دهد؛ برای مطالعه بیشتر به بخش انتهایی این متن مراجعه کنید.
نمای کلی (Overview)
مفاهیم و اصطلاحات گوناگونی در حوزه امنیت وجود دارند که برای درک و بحث در مورد امنیت اپلیکیشن، اساسی هستند. مدیران امنیت و مهندسان امنیت با این اصطلاحات آشنا خواهند بود و تیم‌های توسعه نیز برای پیاده‌سازی اپلیکیشن‌های امن، به این درک نیاز دارند.
امنیت در طراحی (Security by Design)
امنیت نباید یک موضوع ثانویه یا یک افزودنی باشد. هنگام توسعه سیستم‌ها، باید با شناسایی نیازمندی‌های امنیتی مرتبط شروع کنید و آنها را به عنوان بخشی جدایی‌ناپذیر از فرآیند کلی و طراحی سیستم در نظر بگیرید. کار را با ایجاد و اتخاذ اصول و سیاست‌های مرتبط به عنوان پایه‌ای برای طراحی خود آغاز کنید، سپس امنیت را در چرخه برنامه توسعه خود بگنجانید. همچنین به خاطر داشته باشید که سیستمی که می‌سازید به نگهداری نیز نیاز خواهد داشت و اپراتورهای سیستم باید بتوانند به طور امن سیستم را مدیریت کرده و حتی آن را از کار انداخته و از رده خارج کنند. بنابراین، با توسعه اصول و رویه‌های امن برای «مدیریت عملیاتی»[^1]، به عملیات امن متعهد باشید.
امنیت در اولویت (Security by Default)
«امنیت در اولویت» به این معناست که تنظیمات، امن‌ترین تنظیمات ممکن باشند. این لزوماً به معنای کاربرپسندترین تنظیمات نیست. بر اساس تحلیل ریسک و آزمون‌های کاربردپذیری، ارزیابی کنید که این تنظیمات باید چه باشند. در نتیجه، تصمیم‌گیری در مورد معنای دقیق آن بر عهده شماست. با این وجود، سیستم را طوری پیکربندی کنید که تنها کمترین عملکرد لازم را ارائه دهد و به طور مشخص استفاده از سایر عملکردها، پورت‌ها، پروتکل‌ها و یا سرویس‌ها را ممنوع و/یا محدود کند. همچنین، تنظیمات پیش‌فرض را مطابق با بهترین شیوه‌ها تا حد امکان محدودکننده پیکربندی کنید، بدون اینکه «پذیرش روانی» (Psychological acceptability) و «کاربردپذیری و مدیریت‌پذیری» (Usability and Manageability) سیستم به خطر بیفتد.
عدم وجود تضمین امنیتی (No security guarantee)
یکی از مهم‌ترین اصول امنیت نرم‌افزار این است که هیچ اپلیکیشن یا سیستمی به طور کامل و ۱۰۰٪ در برابر همه حملات مقاوم نیست. این ممکن است نقطه شروعی غیرمعمول و بدبینانه به نظر برسد، اما کاملا واقعی است؛ با داشتن زمان و منابع کافی، هر سیستمی قابل نفوذ است. هدف از امنیت نرم‌افزار، «امنیت ۱۰۰٪» نیست، بلکه دشوار کردن نفوذ و کم‌ارزش کردن پاداش آن است، تا جایی که بازیگران مخرب برای بهره‌برداری به سراغ سیستم‌های دیگر بروند و این کار برایشان صرفه نداشته باشد.
دفاع در عمق (Defense in Depth)
دفاع در عمق که به آن دفاع لایه‌ای نیز گفته می‌شود، یک اصل امنیتی است که در آن، دفاع در برابر حمله توسط چندین کنترل امنیتی فراهم می‌شود. هدف این است که نقاط شکست کامل (single points of complete compromise) با گنجاندن یک سری یا چندین لایه از پادمان‌های امنیتی و اقدامات متقابل برای کاهش ریسک، حذف یا کاهش یابند.
اگر یک لایه دفاعی ناکافی باشد، در صورتی که استراتژی‌های دفاعی متنوعی وجود داشته باشد، لایه دیگر ممکن است از یک نفوذ کامل جلوگیری کند و اگر آن لایه نیز دور زده شود، لایه بعدی ممکن است اکسپلویت را مسدود کند.
حالت ایمن (Fail Safe)
این یک اصل امنیتی است که هدف آن حفظ محرمانگی، یکپارچگی و در دسترس بودن (confidentiality, integrity and availability) هنگام شناسایی یک وضعیت خطا است. این وضعیت‌های خطا ممکن است نتیجه یک حمله باشند یا به دلیل نقص در طراحی یا پیاده‌سازی رخ دهند؛ در هر صورت، سیستم/اپلیکیشن‌ها باید به جای یک وضعیت ناامن، به یک وضعیت امن بازگردند.
به عنوان مثال، تا زمانی که به یک موجودیت (entity) دسترسی صریح به یک شیء (object) داده نشده باشد، به طور پیش‌فرض باید دسترسی آن به آن شیء رد شود. این اغلب به عنوان «پیش‌فرض‌های حالت ایمن» (Fail Safe Defaults) یا «امنیت به صورت پیش‌فرض» (Secure by Default) توصیف می‌شود.
در زمینه امنیت نرم‌افزار، اصطلاح «fail secure» معمولاً به جای «fail safe» به کار می‌رود که از اصطلاحات امنیت فیزیکی گرفته شده است. حالت ایمن همچنین به تاب‌آوری (resiliency) نرم‌افزار کمک می‌کند، به این ترتیب که سیستم/اپلیکیشن می‌تواند به سرعت پس از نقص‌های طراحی یا پیاده‌سازی، بهبود یابد.
حداقل امتیاز (Least Privilege)
یک اصل امنیتی که در آن به یک شخص یا فرآیند فقط حداقل سطح حقوق دسترسی (دسترسی امنیتی) که برای تکمیل یک عملیات محول شده ضروری است، داده می‌شود. این حق باید فقط برای حداقل زمان لازم برای تکمیل عملیات اعطا شود.
این اصل با به حداقل رساندن توانایی یک مهاجم برای ارتقای امتیازات به صورت جانبی یا عمودی، به محدود کردن آسیب در هنگام نفوذ به سیستم کمک می‌کند. برای اعمال این اصل حداقل امتیاز، باید سطح‌بندی (granularity) مناسبی از امتیازات و مجوزها ایجاد شود.
بخش‌بندی (Compartmentalize)
اصل حداقل امتیاز زمانی بهتر عمل می‌کند که اجازه دسترسی یک مدل «همه یا هیچ» نباشد. در عوض، دسترسی به اطلاعات را بر اساس «نیاز به دانستن» (need-to-know) برای انجام وظایف خاص، بخش‌بندی کنید. اصل بخش‌بندی به به حداقل رساندن تأثیر یک رخنه امنیتی در صورت وقوع یک تلاش موفق برای نفوذ کمک می‌کند، اما باید با اعتدال استفاده شود تا از غیرقابل مدیریت شدن سیستم جلوگیری شود. بنابراین، از اصل «صرفه‌جویی در سازوکار» (Economy of Mechanism) نیز پیروی کنید.
تفکیک وظایف (Separation of Duties)
تفکیک وظایف، که به عنوان تفکیک امتیازات نیز شناخته می‌شود، یک اصل امنیتی است که نیازمند آن است که تکمیل موفقیت‌آمیز یک وظیفه واحد، به دو یا چند شرط وابسته باشد که هر یک به تنهایی برای تکمیل آن وظیفه کافی نیستند.
کاربردهای زیادی برای این اصل وجود دارد، به عنوان مثال محدود کردن آسیبی که یک کارمند ناراضی یا مخرب داخلی می‌تواند وارد کند، یا محدود کردن ارتقای امتیاز.
صرفه‌جویی در سازوکار (Economy of Mechanism)
این اصل که به «ساده نگه‌داشتن» (keep it simple) نیز معروف است، بیان می‌کند که اگر چندین پیاده‌سازی وجود دارد، باید ساده‌ترین و قابل فهم‌ترین پیاده‌سازی انتخاب شود.
احتمال وجود آسیب‌پذیری‌ها با پیچیدگی طراحی معماری و کد نرم‌افزار افزایش می‌یابد و اگر دنبال کردن یا بازبینی کد دشوار باشد، این احتمال بیشتر هم می‌شود. با ساده و قابل فهم نگه داشتن طراحی و جزئیات پیاده‌سازی نرم‌افزار، سطح حمله (attack surface) آن کاهش می‌یابد.
میانجی‌گری و بازنگری کامل (Complete Mediation)
یک اصل امنیتی که تضمین می‌کند در درخواست‌های بعدی یک فاعل (subject) برای یک شیء (object)، مرجعیت (authority) دور زده نمی‌شود، و این کار را با بررسی مجوزها (حقوق و امتیازات) در هر بار درخواست برای آن شیء انجام می‌دهد.
به عبارت دیگر، درخواست‌های دسترسی یک فاعل برای یک شیء هر بار به طور کامل میانجی‌گری می‌شوند، به طوری که تمام دسترسی‌ها به اشیاء باید بررسی شوند تا اطمینان حاصل شود که مجاز هستند.
طراحی باز (Open Design)
اصل امنیتی طراحی باز بیان می‌کند که جزئیات پیاده‌سازی یک طراحی باید مستقل از خود طراحی باشد، و به طراحی اجازه می‌دهد باز بماند در حالی که پیاده‌سازی می‌تواند مخفی نگه داشته شود. این در تضاد با «امنیت از طریق گمنامی» (security by obscurity) است که در آن امنیت نرم‌افزار به پنهان کردن خود طراحی بستگی دارد.
هنگامی که نرم‌افزار با استفاده از مفهوم طراحی باز معماری می‌شود، بازبینی خود طراحی منجر به به خطر افتادن پادمان‌های امنیتی در نرم‌افزار نخواهد شد و این مورد مهمی محسوب می‌شود.
حداقل سازوکار مشترک (Least Common Mechanism)
اصل امنیتی حداقل سازوکار مشترک، اشتراک‌گذاری سازوکارهایی که بین بیش از یک کاربر یا فرآیند مشترک هستند را در صورتی که آن کاربران یا فرآیندها در سطوح امتیازی متفاوتی قرار دارند، ممنوع می‌کند. این امر هنگام دفاع در برابر ارتقای امتیاز اهمیت دارد و اجازه نمی‌دهد مهاجم دسترسی‌های خود را بالا برده و نفوذ را عمیق کند.
پذیرش روانی (Psychological acceptability)
یک اصل امنیتی که هدف آن به حداکثر رساندن استفاده و پذیرش قابلیت‌های امنیتی در نرم‌افزار است، و این کار را با اطمینان از اینکه قابلیت‌های امنیتی برای استفاده آسان و در عین حال برای کاربر شفاف هستند، انجام می‌دهد. سهولت استفاده و شفافیت، الزامات اساسی برای مؤثر بودن این اصل امنیتی هستند.
کنترل‌های امنیتی نباید دسترسی به یک منبع را به طور قابل توجهی دشوارتر از زمانی کنند که آن کنترل امنیتی وجود نداشت. اگر یک کنترل امنیتی اصطکاک زیادی برای کاربران ایجاد کند، ممکن است آنها به دنبال راه‌هایی برای دور زدن آن کنترل بگردند و «درها را باز بگذارند».
کاربردپذیری و مدیریت‌پذیری (Usability and Manageability)
این اصلی است که با پذیرش روانی مرتبط است، اما فراتر از صرفاً پذیرش روانی درک‌شده رفته و شامل طراحی، پیاده‌سازی و عملیات کنترل‌های امنیتی نیز می‌شود. پیکربندی، مدیریت و یکپارچه‌سازی مؤلفه‌های امنیتی نباید بیش از حد پیچیده یا مبهم باشد. بنابراین، همیشه از استانداردهای باز برای قابلیت حمل و قابلیت همکاری استفاده کنید، از زبان مشترک در توسعه نیازمندی‌های امنیتی استفاده کنید، امنیت را طوری طراحی کنید که امکان پذیرش منظم فناوری جدید را فراهم کند، اطمینان حاصل کنید که یک فرآیند ارتقاء امن و منطقی وجود دارد، فعالیت‌های مدیریت امنیت را خودکار کنید و برای سهولت استفاده در عملیات تلاش کنید.
ایمن‌سازی ضعیف‌ترین حلقه (Secure the Weakest Link)
این اصل امنیتی بیان می‌کند که تاب‌آوری نرم‌افزار شما در برابر تلاش‌های هکرها، به شدت به حفاظت از ضعیف‌ترین مؤلفه‌های آن، چه کد، چه سرویس یا یک رابط کاربری، بستگی دارد. بنابراین، شناسایی ضعیف‌ترین مؤلفه و رسیدگی به جدی‌ترین ریسک در ابتدا، تا رسیدن به سطح قابل قبولی از ریسک، یک رویه امنیتی خوب محسوب می‌شود که در سطح اولیه حمله تلاش برای نفوذ را خنثی کند.
بهره‌گیری از مؤلفه‌های موجود (Leveraging Existing Components)
این یک اصل امنیتی است که بر اطمینان از عدم افزایش سطح حمله و عدم معرفی آسیب‌پذیری‌های جدید از طریق ترویج استفاده مجدد از مؤلفه‌ها، کد و قابلیت‌های نرم‌افزاری موجود تمرکز دارد.
مؤلفه‌های موجود به احتمال زیاد امتحان شده و آزمایش شده‌اند و بنابراین امن‌تر هستند و همچنین باید پچ‌های امنیتی برای آنها در دسترس باشد. علاوه بر این، مؤلفه‌هایی که در جامعه منبع‌باز (open source) توسعه یافته‌اند، از مزیت «چشمان بسیار» بهره‌مند هستند و بنابراین احتمالاً حتی امن‌تر خواهند بود و در مواردی که مجبور به نوشتن کد یا سرویس دست‌نویس نیستید از آن استفاده نفرمایید.
منابع (References)
- مجموعه Cheat Sheetهای OWASP
- Authentication Cheat Sheet
- Authorization Cheat Sheet
- Secure Product Design Cheat Sheet
- کنترل‌های پیشگیرانه ۱۰گانه برتر OWASP
- C5: Secure by Default Configurations
- سایر موارد
- Compartmentalization (information security)
- Least Functionality, (NIST)
- Security by Design, (Open Group)
- Usability and Manageability, (Open Group)
راهنمای توسعه‌دهنده OWASP یک تلاش اجتماعی است؛ اگر چیزی نیاز به تغییر دارد، لطفاً یک ایشو ثبت کنید یا در گیت‌هاب ویرایش کنید.
[^1]: Operational Management, (SAMM)