رویکردهای جدید رمزگذاری امنیت داده سطوح مختلفی از امنیت داده‌های چند ابری (Multi-Cloud) ارائه می‌دهد. به گفته گارتنر، ۸۱ درصد مشاغل از استراتژی ابری و ترکیب چند ابر استفاده می‌کنند. چالش‌های محافظت از داده‌ها و استفاده از رمزگذاری در فضای عمومی / خصوصی ابر، SaaS و محیط‌های داخلی، پیچیدگی، هزینه و ریسک امنیتی را افزایش می‌دهد. فناوری‌های جدید رمزگذاری امنیت داده این امکان را برای سازمان‌ها فراهم می‌کنند تا ضمن حفظ کنترل بر داده‌های حساس و خصوصی، از مزایای public cloud نیز بهره مند شوند. طیف وسیعی از رویکردهای رمزگذاری امنیت داده وجود دارد که از توابع امنیت داده ارائه دهندگان public cloud برای پرداختن به محافظت از داده‌های آن در چندین ابر استفاده می‌کند که امنیت داده چند ابری نام گذاری شده است.
رمزگذاری Cloud-Native
رمزگذاری Cloud-Native برای تأمین امنیت داده‌ها به ارائه دهنده ابر متکی است و معمولاً به عنوان طرح رمزگذاری داده به صورت پیش فرض ارائه می‌شود. بر اساس این روش، ارائه دهندگان ابر کلیدهای رمزگذاری داده‌ها را در حالت استراحت در ابر تولید و حفظ می‌کنند. این روش ساده‌ترین روش برای پیاده سازی است و از مزایای ادغام با سایر سرویس‌های Cloud-native نیز برخوردار است، اما هیچ گونه کنترل و مدیریت کلیدهای رمزگذاری را به مشتریان ارائه نمی‌دهد.
این مساله چندین جنبه ی منفی امنیتی به همراه دارد، از جمله:
- ارائه دهنده ابر به کلیدهای رمزگذاری و در نتیجه داده‌های ذخیره شده در cloud دسترسی دارد.
اگر نقصی وجود داشته باشد و برای حل آن لازم باشد دسترسی قطع شود، مشتریان قادر به حذف کلیدها و از بین بردن سریع دسترسی نیستند. - در صورت گم شدن کلید، مشتری راهی برای بازیابی کلید یا دستیابی به داده‌های خود ندارد.
- مشتریان نمی‌توانند از همان کلید برای رمزگذاری بلوک‌های مختلف داده استفاده کنند. به عنوان مثال، ممکن است لازم باشد داده‌های مختلف را با همان کلید رمزگذاری کنند تا بتوانند بر اساس آن داده‌ها به روشی ثابت عمل کنند.
- مشتریان از روش ثابتی برای تنظیم کنترل‌های دقیق بر روی سیاست‌های کلیدی مدیریت در چند ابر برخوردار نیستند.
- مشتریان پلت فرمی برای مدیریت کلید چند ابر دریافت نمی‌کنند. چارچوب سیاست و حسابرسی برای هر ابر متفاوت خواهد بود.
مدیریت کلید پلت فرم cloud
مدیریت کلید پلت فرم Cloud همچنین به ارائه دهنده ابر امکان تولید، مالکیت و مدیریت کلیدهای رمزگذاری داده را می‌دهد، اما با استفاده از سرویس مدیریت کلید cloud-native برای تولید و مدیریت کلیدهای اصلی یا کلیدهای رمزگذاری کلیدی (KEK). این کلیدهای اصلی برای رمزگذاری کلیدهای رمزگذاری داده (DEK) به منظور ایمن سازی DEK ها قبل از ذخیره شدن در cloud استفاده می‌شوند. ارائه دهنده ابر از داخل تمام DEK ها را مدیریت می‌کند و رمزگذاری داده‌ها را انجام می‌دهد. این روش سطح امنیتی و کنترل مضاعفی را ارائه می‌دهد – به عنوان مثال، مشتریان می‌توانند کلیدهای اصلی را حذف کنند تا از دسترسی سایرین به داده‌های موجود در فضای ابری جلوگیری کنند. گرچه از رمزگذاری cloud native ایمن‌تر است، اما این رویکرد نیز دارای برخی خطرات امنیت داده می‌باشد، از جمله:
اگر یک کلید اصلی حذف شود، هیچ راهی برای پس گرفتن آن کلید وجود ندارد. هر داده‌ی رمزگذاری شده در زیر آن کلید از بین می‌رود.
- ارائه دهنده ابر هنوز مالک کلید اصلی است و به داده‌های رمزگذاری شده دسترسی دارد. این امر به سطحی از اعتماد به ارائه دهنده ابر و کارمندان آن نیاز دارد که ممکن است خط مشی امنیت داخلی و / یا مقررات خارجی را نقض کند.
- استقرارهایی که داده‌ها را در چندین منطقه ابری ذخیره می‌کنند نمی‌توانند از همان کلید استفاده کنند و این امر دسترسی برای برنامه‌های مهم را پیچیده می‌کند.
کلید شخصی داشته باشید (BYOK)
کلید شخصی خود را داشته باشید (BYOK) روشی است که معمولاً برای افزایش امنیت در فضای عمومی ابر استفاده می‌شود. بر اساس این رویکرد، مشتریان کلید اصلی خود را می‌آورند یا وارد می‌کنند که ارائه دهنده ابر در سیستم مدیریت کلید (KMS) خود ذخیره می‌کند. Cloud KMS بسیاری از DEK ها را برای رمزگذاری داده‌های ابری تولید می‌کند و با تحت پوشش قرار دادن آنها با کلید اصلی مشتری از DEK ها محافظت می‌کند.
این روش به مشتریان اجازه می‌دهد تا مالکیت کلید اصلی را حفظ کنند و برخی از کاستی‌های مدیریت کلید پلت فرم ابری را برطرف کنند. اگر برای جلوگیری از نقض در حال انجام لازم است که یک کلید حذف شود، می‌توان بعداً دوباره آن را به سیستم KMS ابری وارد کرد تا داده‌ها را بازیابی کند. اگر کلید اصلی ذخیره شده گم شود، کپی آن در دسترس است تا مشتری بتواند داده‌های خود را بازیابی کند. هنگامی که داده‌های مستقر در مکان‌های مختلف توسط همان برنامه پردازش می‌شوند، می‌توان از یک کلید در چندین حساب و منطقه استفاده کرد. با این حال، این قابلیت‌ها می‌توانند پیچیدگی مدیریت را افزایش دهند. در حالی که امنیت بیشتری نسبت به مدیریت کلید پلتفرم ابری دارد. BYOK با این وجود به ارائه دهنده ابر امکان دسترسی به کلیدهای اصلی را می‌دهد، بنابراین خطرات امنیتی شخص ثالث برای دسترسی همچنان برقرار است.
KMS شخصی داشته باشید (BYOKMS)
KMS خود را داشته باشید (BYOKMS) یکی از ایمن‌ترین راه‌ها را برای محافظت از کلیدها و داده‌های ابری ارائه می‌دهد، در حالی که همچنین یکپارچه سازی قوی با سرویس‌های cloud-native را فراهم می‌کند. تحت این رویکرد، یک سرویس مدیریت کلید کاملاً خارج از پلت فرم ارائه دهنده‌ی ابر، کلیدهای اصلی استفاده شده توسط ارائه دهنده ابر را تولید و مدیریت می‌کند. کلیدهای اصلی همیشه به طور ایمن در KMS / HSM خارج از ابر خود مشتری ذخیره می‌شوند. بر خلاف BYOK، ارائه دهنده ابر هرگز به کلید اصلی دسترسی ندارد. برای رمزگذاری / رمزگشایی داده‌ها درون فضای ابر، کلیدهای رمزگذاری با کلید اصلی مشتری پیچیده/باز می‌شوند. دسترسی به کلید اصلی می‌تواند در هر زمان لغو شود، و باعث می‌شود داده‌ها بلافاصله در پلت فرم ابر غیرقابل دسترسی شوند. اگرچه این راه حل به مشتریان امکان کنترل کامل و بی درنگ کلیدهای اصلی آنها را می‌دهد، اما ارائه دهنده ابر هنوز هم به کلیدهای رمزگذاری داده دسترسی دارد.
رمزگذاری شخصی
این روش ایمن‌ترین راه برای محافظت از کلیدها و داده‌های ابری است اما ممکن است بر ادغام با سایر سرویس‌های cloud-native تأثیر بگذارد. این روش همان سطح حفاظت ارائه شده در یک مرکز داده را فراهم می‌کند، اما با سهولت کار و مقیاس پذیری ابر. مشتریان کلیه کلیدهای رمزگذاری داده‌ها را ارائه می‌دهند و رمزگذاری داده‌ها را در فضای ابری انجام می‌دهند. چالش این روش این بوده است که داده‌های رمزگذاری شده توسط کلیدهای رمزگذاری داده‌های متعلق به مشتری نمی‌توانند توسط سایر سرویس‌های cloud-native آزادانه استفاده شوند. این سرویس‌ها قادر به رمزگشایی داده‌ها نیستند زیرا به کلیدهای رمزگذاری داده دسترسی ندارند.
یک راه حل رمزگذاری موثر به چهار مولفه ی اصلی نیاز دارد:
- یک راه حل رمزگذاری و مدیریت کلید مدیریت شده توسط مشتری که در پلت فرم ابر عمومی منتخب اجرا می‌شود.
- یک سیستم مدیریت کلید انجام شده توسط مشتری که در محیط کار می‌کند تا رمزگذاری داده‌های مشتری را قبل از ارسال به ابر و ذخیره در آن جا انجام دهد.
- ادغام بین KMS ابری مشتری و KMS پیش فرض به گونه‌ای که آنها بتوانند کلیدها را به اشتراک بگذارند و داده‌هایی را که توسط KMS دیگر رمزگذاری یا رمزگشایی شده، رمزگذاری یا رمزگشایی کنند.
- ادغام بین KMS ابری مشتری و KMS اصلی پلت فرم ابر. وقتی داده‌های رمزگذاری شده توسط مشتری که در ابر ذخیره شده‌اند، باید توسط سرویس‌های cloud-native مصرف شوند، KMS مشتری باید داده‌ها را از رمزگذاری مشتری (DEK متعلق به مشتری) به رمزگذاری سرور (KEK متعلق به ارائه دهنده ابر) تبدیل کند. سپس سرویس‌های Cloud-native می‌توانند قبل از رمزگذاری مجدد داده‌ها با استفاده از کلیدهای مشتری، داده‌ها را استخراج و عملیات مورد نیاز را انجام دهند.
ایجاد یک استراتژی برای ایجاد امنیت داده چند ابری یک ضرورت است.
به احتمال زیاد، استقرار امنیت داده موجود شما برای محافظت از داده‌های موجود در محل تحت کنترل یک مرکز داده سنتی ساخته شده است. هرچه زیرساخت‌ها، حجم کار و داده‌های بیشتر به فضای ابری منتقل می‌شوند، تجدیدنظر در مورد امنیت داده‌ها به عنوان بخشی از فرآیند انتقال بسیار مهم خواهد بود. رویکردی که اکثر سازمان‌ها برای محافظت از داده‌های داخلی در پیش گرفته‌اند، به راحتی به زیرساخت‌ها و ظرفیت کاری ابر عمومی منتقل نمی‌شود. به خاطر داشته باشید که حجم کاری و طبقه بندی مختلف داده‌ها می‌تواند از رویکردهای مختلف امنیت داده (Cloud-native، BYOK، BYOKMS، BYOE) برای دستیابی به بهترین تعادل ادغام ابر و کاهش ریسک استفاده کند.