۶ بهترین روش امنیتی برای برنامه های کاربردی ابری

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

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

این چالش‌ها اغلب از چالش‌های مرتبط با برنامه‌های سنتی و یکپارچه متفاوت است. درک این تفاوت‌ها برای توسعه‌دهندگان بسیار مهم است، به‌ویژه به این دلیل که برنامه‌های کاربردی مدرن مبتنی بر ابر ترکیبی از چالش‌های امنیتی قدیمی و جدید هستند که باید به طور جامع مورد توجه قرار گیرند.

این مقاله شش روش کدگذاری ایمن را که برای ساخت برنامه‌های کاربردی ابری امن، انعطاف‌پذیر و مقیاس‌پذیر ضروری هستند، تشریح می‌کند. این شیوه‌ها صرفاً «خوب داشتن» نیستند، بلکه اصول اساسی هستند که به وضعیت امنیتی کلی هر برنامه‌ای که در فضای ابری است کمک می‌کند.

۶ بهترین روش امنیتی برای cloud-native

• معماری اعتماد صفر
• اعتبار سنجی ورودی
• کنترل قرار گرفتن در معرض اینترنت
• ذخیره‌سازی امن فایل
• اصل کمترین امتیاز
• پوشش داده‌های گزارش

معماری اعتماد صفر

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

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

Micro-segmentation شامل تقسیم برنامه شما به اجزای کوچکتر و قابل مدیریت تر (سرویس های میکرو) و تنظیم کنترل های امنیتی مستقل برای هر کدام است. این تضمین می کند که حتی اگر یک جزء در معرض خطر باشد، سطح حمله محدود می شود. مثال: در یک برنامه تجارت الکترونیک بومی ابری، موجودی، پرداخت، و احراز هویت کاربر را به میکروسرویس‌های مختلف جدا می‌کنید که هر کدام پروتکل‌های امنیتی خاص خود را دارند.

به جای تکیه بر احراز هویت کاربر، احراز هویت سرویس به سرویس تضمین می کند که سرویس ها قبل از تبادل اطلاعات یکدیگر را احراز هویت می کنند. این را می توان با استفاده از تکنیک هایی مانند TLS متقابل (mTLS) انجام داد. مثال: وقتی ریزسرویس موجودی در یک پلتفرم تجارت الکترونیک جزئیات پرداخت را از ریزسرویس پرداخت درخواست می‌کند، می‌توان از TLS متقابل برای تأیید هویت هر دو سرویس استفاده کرد.

تأیید اعتبار ورودی

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

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

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

فهرست سفید شامل حفظ فهرستی از ورودی‌های پذیرفته شده یا محدوده‌های مقدار است. فقط ورودی هایی که این معیارهای از پیش تعریف شده را دارند باید پذیرفته شوند. مثال: برای یک API که ورودی‌های رنگی را برای یک ویژگی سفارشی‌سازی می‌پذیرد، از یک لیست سفید استفاده کنید تا فقط کدهای رنگ خاصی مانند #FF0000 برای قرمز مجاز باشد.

کنترل قرار گرفتن در معرض اینترنت

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

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

یک VPC را برای جداسازی بخش‌های مختلف برنامه خود پیاده‌سازی کنید. این باید شامل زیرشبکه های جداگانه برای هر نوع سرویس و شبکه ACL باشد تا ترافیک بین آنها محدود شود. مثال: برنامه تجارت الکترونیک خود را برای احراز هویت کاربر، کاتالوگ محصول و پردازش پرداخت به VPCهای جداگانه تقسیم کنید.

پیش‌رفت پیکربندی در سرویس‌های خود را نظارت کنید. اغلب اوقات، سرویس‌های داخلی ممکن است به دلیل تغییرات در جاهای دیگر، مانند تغییراتی که برای پاسخگویی به یک درخواست API نامرتبط انجام می‌شود، به طور ناخواسته در معرض دید عموم قرار گیرند. هشدارهایی را برای هرگونه تغییر پیکربندی ناخواسته ایجاد کنید و سریعاً هرگونه تغییر شکل را برطرف کنید.

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

ذخیره‌سازی امن فایل

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

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

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

از مکانیزم کنترل دسترسی مبتنی بر نقش (RBAC) برای مدیریت دسترسی به فایل های ذخیره شده استفاده کنید. ثبت همه دسترسی ها برای ایجاد یک مسیر حسابرسی. مثال: در یک برنامه مراقبت های بهداشتی، فقط به کادر پزشکی خاصی اجازه دسترسی به سوابق بیمار را بدهید.

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

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

اصل حداقل امتیاز

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

تنظیمات مجوز خود را برای هماهنگی با مسئولیت‌های خاص هر جزء تنظیم کنید. این از بسیاری از منظرها مهم است و اغلب دیدگاه API نادیده گرفته می شود. آیا API شما نیاز به خواندن و نوشتن دارد؟ اگر چنین است، آنها را دو API مجزا بسازید و حداقل امتیاز لازم را در هر کدام به آنها بدهید.

مثال: یک سرویس ثبت نام کاربر (که احتمالاً تغییراتی ایجاد می کند) باید دارای یک مجموعه مجوز با دامنه متفاوت نسبت به سرویس فقط خواندنی باشد که داده ها را گزارش می دهد.

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

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

پوشاندن داده‌های گزارش

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

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

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

یک خط مشی سختگیرانه برای مدت زمان نگهداری فایل های گزارش ایجاد کنید. این خط‌مشی را با هرگونه الزامات انطباق مطابقت دهید، و حذف گزارش‌هایی را که بیش از این دوره هستند، خودکار کنید. مثال: مطابق با GDPR، گزارش‌های حاوی داده‌های شخصی را تنظیم کنید تا پس از ۳۰ روز به‌طور خودکار حذف شوند، مگر اینکه به دلایل ممیزی یا قانونی لازم باشد.

گام به سوی اقدامات امنیتی بهتر

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

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

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

یوسی پیک یکی از بنیانگذاران و مدیر ارشد فناوری در Backslash Security.

—

New Tech Forum مکانی را برای رهبران فناوری – از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی – فراهم می‌کند تا فناوری سازمانی نوظهور را در عمق و وسعت بی‌سابقه بررسی و بحث کنند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه پرس و جوها را به doug_dineley@foundryco.com.