امنیت سخت است و آسان تر نخواهد شد

سیستم های نرم افزاری پیچیده هستند و تیم های توسعه دارای اهداف متناقضی هستند. اوه، و مردم ناقص هستند.

امنیت یکی از معدود چیزهایی است که در صورت فرو رفتن جهان در رکود، از تبر بودجه جان سالم به در می‌برد، اما به طور فزاینده‌ای واضح است که نمی‌توانیم به سادگی راه خود را خرج کنیم به آینده ای مطمئن در واقع، SLSA (سطوح زنجیره تامین برای مصنوعات نرم‌افزاری)، Tekton، و راه‌حل‌های دیگر می‌توانند زنجیره‌های تامین منبع باز را ایمن کنند، اما واقعیت این است که ما همچنان بیشتر به توسعه‌دهندگان متکی هستیم تا عملکرد بهتری داشته باشند و «هوشیار باشند. ” به عنوان بنیانگذار Modal Labs اریک برنهاردسون اشاره می‌کند. جای تعجب نیست که این غیر استراتژی همچنان با شکست مواجه می شود.

این امر نشان می‌دهد که سوال اصلی برناردسون بسیار سخت است در سال ۲۰۲۲؟” یک پاسخ این است که سیستم‌ها همچنان پیچیده‌تر می‌شوند و حفره‌هایی باقی می‌مانند که هکرها می‌توانند از آنها سوء استفاده کنند. با در نظر گرفتن این موضوع، آیا امیدی به بهتر شدن اوضاع وجود دارد؟

بدون دارو

یکی از دلایل اصلی سخت بودن امنیت این است که ایمن کردن یک سیستم بدون درک کامل سیستم دشوار است. همانطور که منبع باز سایمون ویلیسون بیان می‌کند، “نوشتن نرم‌افزار ایمن نیاز به دانش عمیق از نحوه همه چیز دارد. کار می کند.” او ادامه می‌دهد که بدون این درک اساسی، توسعه‌دهندگان ممکن است به اصطلاح «بهترین شیوه‌ها» را بدون درک چرا آن‌ها دنبال کنند، که «یک دستور العمل برای اشتباهات تصادفی است که حفره‌های امنیتی جدیدی ایجاد می‌کند. p>

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

نه. «فکر نمی‌کنم ابزارها بتوانند ما را نجات دهند» ویلیسون استدلال می‌کند. چرا؟ زیرا «مهم نیست که ابزار پیش‌فرض چقدر خوب باشد، اگر مهندسان متوجه نشوند که چگونه آن‌ها را ایمن نگه می‌دارد، آن را زیر و رو می‌کنند – حتی بدون اینکه بدانند چرا کاری که انجام می‌دهند بد است.» علاوه بر این، مهم نیست که ابزار چقدر خوب باشد، اگر به طور یکپارچه با فرآیندهای امنیتی سازگار نباشد، هرگز کافی نخواهد بود. در نهایت، امنیت (مانند بسیاری از چیزها) به مردم بازمی گردد: شما می توانید نرم افزار را تعمیر کنید، اما تا زمانی که افراد پشت نرم افزار را تعمیر نکنید، واقعاً چیزی را اصلاح نکرده اید.

با وجود این، زبان‌های برنامه‌نویسی و سایر ابزارهای نرم‌افزاری می‌توانند مکانیسم‌هایی را برای گرفتن کد توسعه‌دهنده غیرایمن معرفی کنند. ما مدیران کلیدی از HashiCorp داریم که از طریق مواردی مانند AuthO و غیره احراز هویت بهتری دارند، که همه آنها به طور کلی امنیت را بهبود بخشیده اند. با این حال، چنین پیش‌فرض‌هایی برای راه‌حل‌های «بازار انبوه» ممکن است برای شکاف‌های امنیتی یک شرکت اعمال نشود. همانطور که یکی از توسعه‌دهندگان می‌افزاید، “تاثیرگذارترین مشکلات امنیتی نیز برای هر شرکت و پایگاه مشتریان آنها منحصر به فرد است. ” به عبارت دیگر، همان‌قدر که یک وضعیت امنیتی اجباری ممکن است برای یک برنامه معتبر باشد، نقض‌های امنیتی به معماری یک شرکت خاص‌تر هستند.

این درست است، اما آنطور که برخی پیشنهاد می کنند کاملاً متقاعدکننده نیست. به هر حال، پیش‌فرض‌های قوی و امنیتی‌محور در ORM‌ها (نقشه‌نگاری رابطه‌ای شی) تا حد زیادی تزریق SQL را که زمانی یک نقض امنیتی رایج بود، حذف کرده‌اند. “nofollow”>Octavian Costache فرا می خواند.

امنیت مردم است

مشکل همیشگی ویژگی‌ها اینجاست: «امنیت و نوآوری توسط افراد مختلف با اهداف متضاد هدایت می‌شود،» یادداشت‌ها لارس آلبرتسون از اسکلینگ. “امنیت و مدیریت ریسک همیشه در دراز مدت در برابر نیازهای مستقیم تجاری ضرر خواهد کرد.” یا همانطور که گوردون شاتول از Socure بیان می کند، «امنیت تقریباً همیشه هزینه بهره وری دارد. توجیه این هزینه اغلب بسیار دشوار است زیرا امنیت دارای مزایای بلندمدت تا حدودی نظری است در حالی که هزینه بهره وری واقعی و فوری است.”

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

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

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

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