توسط اد مویل1 اکتبر 2020
طی چند سال گذشته ، مفهوم معماری “اعتماد صفر” مراحل مختلف تکاملی را طی کرده است. این مدل از یک مد جدید داغ ، به متانت (تا حد زیادی به دلیل هجوم بازاریابی از سوی کسانی که به دنبال پول گرفتن در این روند هستند) ، به یک مدل مقبول تبدیل شده است ، و در نهایت به همان چیزی رسیده است که احتمالاً همیشه باید وجود داشته باشد .
along یک گزینه امنیتی محکم و اپلیکیشن با مزایا و معایب قابل مشاهده است که می تواند در رویکرد امنیتی سازمان ما مورد استفاده واقع شود.
اعتماد صفر ، همانطور که از نامش پیداست ، یک مدل امنیتی است که در آن فرض بر این است که تمام دارایی ها – حتی نقاط پایانی مدیریت شده که شما تهیه می کنید و شبکه های پیش فرض که توسط شما پیکربندی شده اند – توسط دشمنان ، بصورت غیرقابل اعتماد و به طور بالقوه در معرض خطر قرار می گیرند. به جای مدل های امنیتی قدیمی که فضای داخلی “قابل اعتماد” را از یک خارجی غیر قابل اعتماد متمایز می کند ، بر اساس اعتماد صفر فرض می کند که همه شبکه ها و میزبان ها به همان اندازه غیرقابل اعتماد هستند.
هنگامی که این تغییر اساسی در پیش فرض ها را انجام دادید ، تصمیمات متفاوتی را درباره اینکه چه کسی و چه زمانی باید اعتماد کنید که روش های تأیید اعتبار قابل قبول برای درخواست ها یا معاملات مجاز است ، و آنگاه شروع می کنید.
مزایا و معایب به عنوان یک ذهنیت امنیتی
یک مزیت این است که به شما امکان می دهد در مورد منابع امنیتی که بیشتر به آنها نیاز دارید ، به صورت استراتژیک اعمال کنید. و مقاومت در برابر حرکت جانبی مهاجم را افزایش می دهد .
معایبی نیز وجود دارد. به عنوان مثال ، اجرای این سیاست در هر سیستم و برنامه ای مورد نیاز است ، و اجزای قدیمی ساخته شده با فرضیات امنیتی مختلف ممکن است به خوبی سازگار نباشند ، به عنوان مثال این که شبکه داخلی قابل اعتماد است.
یکی از مهمترین نکات منفی ممکن است مربوط به اعتبار سنجی وضعیت امنیتی باشد ، یعنی در شرایطی که مدل امنیتی نیاز به بازبینی توسط سازمانهای قدیمی تر و تمرکز بر سوابق دارد. این زمان است که پویایی مایه تاسف است بدین معنی که همان سازمانهایی که به نظر می رسد جذاب ترین مدل را پیدا می کنند همان سازمانهایی هستند که با اتخاذ آن ، احتمالاً خود را برای چالشهای بررسی آماده می کنند.
برای درک پویایی منظور ما در اینجا ، مفید است که در صورت پذیرش اعتماد صفر ، مرحله منطقی بعدی را بررسی کنید. به طور خاص ، اگر تصور کنید که تمام نقاط انتهایی به طور بالقوه به خطر بیفتند و همه شبکه ها احتمالاً مورد هجوم باشند ، نتیجه طبیعی و منطقی این فرض این است که داده های حساس را به حداقل برسانید.
به عنوان مثال ، ممکن است تصمیم بگیرید که بعضی از محیط ها به اندازه کافی از کانال های کاملاً مشخص ، مانند دسترسی معتبر HTTPS به یک برنامه وب ، برای ذخیره ، پردازش یا انتقال داده های حساس ، محافظت نشده باشند.
در مواردی که از خدمات ابری زیاد استفاده می شود ، کاملاً منطقی است که تصمیم بگیریم داده های حساس در ابر ذخیره شوند – البته موضوع این است که مکانیزم های کنترل دسترسی که به طور صریح برای این منظور ساخته شده اند و دارای اقدامات امنیتی و عملیاتی هستند ولی کارکنانی که توانایی استفاده یا نگهداری از آنها را فقط برای استفاده از آنها را ندارید.
به عنوان نمونه ، بگویید که شما یک سازمان فرضی جوان تر در بازار متوسط دارید. منظور ما از “جوان تر” این است که شاید فقط چند سال از تأسیس سازمان می گذرد. بگویید این سازمان “بومی ابر” است ، یعنی 100٪ همه برنامه های تجاری اش خارجی است و کاملاً برای استفاده از فضای ابر طراحی شده است.
برای سازمانی مانند این ، اعتماد صفر قانع کننده است. از آنجا که 100٪ خارجی است ، هیچ مرکز داده یا سرور داخلی ندارد و تنها کمترین ردپای فناوری پیش فرض را حفظ می کند. این سازمان ممکن است به صراحت نیاز داشته باشد که هیچگونه داده حساسی نمی تواند در نقاط انتهایی یا داخل شبکه دفتر آنها “وجود داشته و به اصطلاح زندگی ” کند. در عوض ، همه این داده ها باید در زیر مجموعه سرویس های ابر شناخته شده و تعریف شده بوده و قرار داشته باشند که صریحاً برای آن منظور تأیید شده اند.
انجام این کار به این معنی است که نهاد می تواند تمام منابع خود را بر روی زیرساخت های ابر متمرکز کند ، خدمات دروازه ای را به گونه ای فراهم کند که از همه دسترسی ها (صرف نظر از منبع) به روشی محکم محافظت شود و مواردی مانند امنیت فیزیکی برای شبکه داخلی را کناربگذارد و استفاده از کنترل های نظارت داخلی و غیره ، آنگاه با فرض اینکه یک فرایند سخت کوشانه برای اطمینان از استفاده از اجزای ابر دنبال شود ، چنین رویکردی می تواند به تمرکز بر منابع محدود کمک کند.
با این حال ، سازمان مثال فوق در خلا کار نمی کند یعنی هیچ سازمانی این کار را نمی کند. مدل با مشتریان کار می کند و منجر به ارتباطات فروش ، شرکای تجاری و بسیاری دیگر می شود. از آنجا که این سازمان سازمان کوچکتری است ، ممکن است بسیاری از مشتریان آن سازمان های بزرگتری باشند – مشتریانی که بالقوه با نیازهای شدید در مورد تأمین خدمات خارجی و تأیید امنیت آنها روبرو هستند که شاید بسته به اینکه در کدام صنعت فعالیت می کند یک وظیفه نظارتی داشته باشد. اکنون برخی از این مشتریان ممکن است کاملاً خارجی شده باشند اما اکثریت آنها چنین نخواهند شد . آنها از برنامه های قدیمی ، محدودیت های منحصر به فرد ، شرایط خاص و ارتباط با سایر کسب و کار ها برخوردار خواهند بود. دلایلی که چرا آنها نمی توانند از یک مدل کاملاً خارجی پشتیبانی کنند.
آنچه که نتیجه می گیریم ، غالباً یک بحث کاملاً قابل درک ، اما معکوس برای اهداف متقابل بین سازمانی است که ارزیابی را انجام می دهد (مشتری بالقوه) و شخصی که ارزیابی می شود (ارائه دهنده خدمات). به عنوان مثال ، یک ارائه دهنده خدمات ، بسیار منطقی استدلال می کند که کنترل های امنیتی فیزیکی (برای انتخاب فقط یک مثال) از اهداف ارزیابی نیستند. آنها ممکن است بر این اساس استدلال کنند که تنها کنترلهای امنیتی فیزیکی مهمترین مواردی است که در ارائه دهندگان خدمات ابری که آنها به کار می گیرند وجود دارد ، زیرا بالاخره این تنها مکانی است که داده ها اجازه حضور دارند.
از طرف دیگر مشتری نیز ممکن است نگران جنبه هایی از امنیت فیزیکی باشد که مربوط به محیط ارائه دهنده خدمات است. به عنوان مثال ، دسترسی بازدید کننده به امکاناتی که ممکن است داده های مشتری در صفحه مشاهده شود ، حتی اگر داده ها در آنجا ذخیره نشده باشد. آنها ممکن است یک سناریو را پیش بینی کنند ، به عنوان مثال ، یک بازدید کننده غیر مجاز از دفتر ممکن است هنگام ورود به صفحه توسط یک کاربر قانونی داده ها را در معرض دید قرار دهد.
مکالمه ای مانند گفتگوی بالا ، حتی وقتی بحث برانگیز نشود ، همچنان برای هر دو طرف یک درگیری بهینه نیست. از دیدگاه ارائه دهنده خدمات ، روند فروش را کند می کند و از مهندسانی که در غیر این صورت متمرکز بر تولید محصول هستند ، فاصله می گیرد. هرچند از نظر مشتری بالقوه ، آنها را از داشتن منابع بالقوه خطر بی کنترل رنج می دهد – ضمن اینکه باعث ایجاد احساس بد با شرکای تجاری داخلی که مایل به استفاده از خدمات هستند و می خواهند سریع بررسی انجام شود ، می شود.
استراتژی های اصلی
بنابراین ، این سوال مطرح می شود: اگر بخواهیم از این طریق از یک مدل استفاده کنیم ، چگونه ما یک مدل اعتماد صفر را به طور موثر برقرار کنیم؟ اگر ما چنین رویکردی را تأیید می کنیم ، چگونه به سوالات پاسخ صحیح می دهیم تا بتوانیم به سرعت به تصمیمی برسیم و (در حالت ایده آل) استفاده تجاری از خدمات را فعال کنیم؟ به نظر می رسد چند روش وجود دارد که می توانیم از آنها استفاده کنیم. هیچ یک از آنها جهشی نیستند ، اما برای حمایت نیاز به همدلی – و انجام برخی کارها – دارند.
از دیدگاه ارائه دهنده خدمات ، سه اصل مفید وجود دارد که باید به خاطر بسپارید: 1) آینده ، 2) اثبات اعتبار مفروضات خود ، و 3) پشتیبان گیری از موارد ادعایی خود با مستندات.
با “آینده” به تمایل برای به اشتراک گذاشتن اطلاعات فراتر از آنچه مشتری ممکن است بخواهد ، اشاره می کنم. اگر SaaS ابری مانند مثال بالا را ارائه دهید ، این امر ممکن است به این معنی باشد که مایل هستید اطلاعاتی فراتر از مجموعه خاصی از موارد درخواست شده توسط مشتری را به اشتراک بگذارید. این به شما امکان می دهد اطلاعات را “حتی” تا حد استفاده از کالاهای قابل تحویل استاندارد “عمومی” کنید. به عنوان مثال ، ممکن است شرکت در رجیستری CSA STAR را در نظر بگیرید ، مصنوعات استاندارد جمع آوری اطلاعات مانند CSA CAIQ ، SIG ارزیابی استاندارد های مشترک ، یا برنامه ارزیابی شخص ثالث HITRUST را در فضای بهداشت و درمان تهیه کنید.
اصل دوم ، نشان دادن اعتبار سنجی ، به این معنی است که شما فرضیاتی را که در مدل امنیتی شما وارد شده اند ، تأیید کرده اید. در مثال بالا ، این بدان معناست که ما می توانیم با اعتبار سنجی از آن ، از فرض “هیچ داده ای در داخل ذخیره نمی شود” نسخه پشتیبان تهیه کنیم. اگر از کنترلی مانند DLP برای تأیید اعتبار استفاده شود ، یک ارزیاب از مشتری احتمالاً این گفته را باور می کند.
آخرین نکته در داشتن مستندات به معنای مستند سازی مدلی است که از آن استفاده می کنید. به عنوان مثال ، اگر می توانید یک سند معماری اطلاعات را ارائه دهید که روش شما را توصیف کندبدین صورت که چرا آن را به کار می گیرید ، تجزیه و تحلیل ریسکی که قبلاً انجام داده اید ، کنترل های موجود برای اعتبار سنجی ، و غیره. با یک سیاست مشخص تهیه کنید که اصول و انتظارات امنیتی را ارائه دهد .
از طرف ارزیاب ، در واقع فقط یک اصل وجود دارد ، این است که در هر جایی که می توانید از انعطاف پذیری استفاده کنید. اگر هدف و میزان دقت کنترل هایی را که انتظار دارید درک کنید و اتفاقاً یک ارائه دهنده خدمات در همان سطح سختگیری اما با روشی متفاوت از آنچه شما انتظار دارید ، همان هدف را برآورده می کند . در این صورت گزینه هایی برای ارائه دهنده خدمات (غیر از نیاز آنها برای خرید و نصب کنترلهایی که نیازی به آنها نیستند) مفید است.
باز هم ، البته هیچکدام از این توصیه ها علم موشکی نیست. اما فقط بدیهی بودن این بدان معنا نیست که همه این کار را می کنند. با انجام مقدماتی پیش از موعد و نگرش سازگارانه ، می توانید روند ارزیابی را در شرایطی مانند این ساده کنید.
