از تولیدکنندگان هواپیما و خودرو گرفته تا شرکت های دارویی و فناوری پیشرفته، موسسات نظامی و تامین کنندگان – صنایع مختلف از جاسوسی می ترسند. در حالی که بسیاری از ما در مبارزه جهانی برای تسلط اقتصادی و فناوری بیش از حد نامربوط هستیم، برخی از شرکت ها و موسسات آرامش کمتری دارند. این یک خطر واقعی است که سرویس های مخفی خارجی اسرار تجاری آنها را بدزدند و آنها را به رقبا منتقل کنند.
آیا آنها می توانند (و باید) داده های خود را به ابر منتقل کنند؟ رمزگذاری چگونه به آنها کمک می کند؟ در ادامه، پس از توضیح سه الگوی اساسی برای یکپارچه‌سازی سرویس‌های ابری (ذخیره‌سازی) در چشم‌انداز برنامه‌های سازمانی، چهار رویکرد برای مدیریت رمزگذاری داده‌ها در حالت استراحت در فضای ابری مورد بحث قرار می‌دهیم.
سه الگوی معماری برای رمزگذاری در ابر
الگوی اول این است رمزگذاری فضای ابری (شکل 1، سمت چپ)، که در آن ابر یک هدف ساده دارد: یک راه حل ذخیره سازی قابل اعتماد، مقرون به صرفه و مقیاس پذیر. مشتریان از اجرای ماشین‌های مجازی در فضای ابری یا ساخت سرویس‌های مبتنی بر پلتفرم به‌عنوان سرویس (PaaS) مانند Azure Functions یا Amazon Textract خودداری می‌کنند. همه برنامه ها بر روی ماشین های مجازی داخلی (VM) اجرا می شوند. هنگامی که برنامه‌ها داده‌ها را در فضای ابری می‌نویسند، ماژول رمزگذاری داخلی داده‌ها را قبل از اینکه در فضای ابری به پایان برسد، رمزگذاری می‌کند.
ماژول رمزگذاری می تواند به سادگی یک کتابخانه جاوا یا از طرف دیگر، یک ماژول امنیتی سخت افزاری (HSM) باشد که برای مقاومت در برابر NSA طراحی شده است. با داده های رمزگذاری شده در حالت استراحت در ابر اما بدون کلید، مهاجمانی که به زیرساخت ابری دسترسی دارند نمی توانند به داده های مشتری ابری دسترسی داشته باشند. همه داده ها امن است.
توسط ارائه دهنده ابر مدیریت و کنترل می شود.
این بارهای کاری ابری با رمزگذاری شخصی الگوی (شکل 1، وسط) تلاش می کند تا به امنیت دنیای درون سازمانی دست یابد و در عین حال مراکز داده داخلی را کنار بگذارد. در این الگو، منطق کسب و کار روی ماشین های مجازی باقی می ماند. مشتریان از خدمات PaaS استفاده نمی کنند و همچنان به ماژول رمزگذاری خود برای انجام رمزگذاری داده در حالت استراحت قبل از نوشتن داده ها در فضای ذخیره سازی ابری تکیه می کنند.
با این حال، ماشین های مجازی و ماژول رمزگذاری در محل کار نمی کنند، بلکه در فضای ابری اجرا می شوند. مهاجمان، کارمندان جنایتکار یا سازمان های دولتی با دسترسی به زیرساخت ابری می توانند به داده های مشتری دسترسی داشته باشند، اما تنها با استخراج اطلاعات از ماشین های مجازی. این یک تعهد عملی اما از نظر فنی پیشرفته تر برای رمزگذاری داده ها در حالت استراحت است.
این cloud-workloads-with-cloud-native-encryption الگو ترکیبی از رمزگذاری و استفاده از خدمات PaaS بومی ابری است (شکل 1، سمت راست). شعار: از خدمات PaaS برای ایجاد راه حل ها سریعتر از همیشه بهره مند شوید. در نتیجه، رمزگذاری داده ها به خدمات بومی ابری متکی است. در این الگو، مشتریان ابری باید به ارائه‌دهنده ابر خود اعتماد کنند تا معقولانه عمل کند و توسط دولت‌ها یا سازمان‌های مجری قانون مجبور به اقدام علیه مشتریان خود نشوند. این یک فرض آسان برای شرکت های آمریکایی در AWS آمازون، Azure مایکروسافت، یا GCP گوگل است. برای سازمان‌های فدرال آلمان که بار کاری روی «Bundescloud» آلمانی دارند؛ یا برای شرکت‌های چینی که روی ابر علی‌بابا کار می‌کنند.
با این حال، برای بسیاری از موارد دیگر، این فرض صادق نیست. برای رسیدگی به هرگونه شک و تردیدی که ممکن است به کسب و کار آنها لطمه بزند، ارائه دهندگان ابر انواع مختلفی را برای رمزگذاری بومی ابری ارائه کردند که منعکس کننده بحرانی بودن بارهای کاری مختلف است. انواع کلیدهای مدیریت خدمات، کلیدهای مدیریت شده توسط مشتری، کلیدهای خود را بیاورید و کلیدهای خود را نگه دارید (شکل 2).
سلسله مراتب کلید و انواع مدیریت کلید اصلی برای رمزگذاری
هر چهار نوع، داده ها را در حالت استراحت در ابر با کلیدهای رمزگذاری داده خاص رمزگذاری می کنند. همه از کلیدهای مختلفی برای رمزگذاری سطل های مختلف داده استفاده می کنند تا شعاع انفجار در هنگام نشت یک کلید کاهش یابد. همه انواع این کلیدهای رمزگذاری داده را در ابر ذخیره می کنند. آنچه متفاوت است رمزگذاری کلیدهای رمزگذاری داده ها است که همه انواع آن به کلیدهای رمزگذاری اصلی متکی هستند.
چهار رویکرد برای مدیریت رمزگذاری داده در حالت استراحت در ابر
چهار نوع برای مدیریت کلیدهای رمزگذاری اصلی عبارتند از:
- کلیدهای مدیریت سرویس (SMK). سرویس رمزگذاری ابری تمام داده های کاربران (دقیقاً: کلیدهای رمزگذاری داده های آنها) را در یک سرویس با همان کلید اصلی رمزگذاری رمزگذاری می کند. بنابراین، یک کلید وجود دارد، به عنوان مثال، برای سرویس ذخیره سازی کامل یا یک پایگاه داده خاص به عنوان یک سرویس ارائه می شود. ارائه دهندگان ابر باید اطمینان حاصل کنند که کارمندان یا هکرها نمی توانند از چنین کلیدهایی سوء استفاده کنند. مشتریان به سادگی باید به آنها اعتماد کنند. اگر مقامات خواستار دسترسی به داده ها شوند، ارائه دهندگان ابری می توانند همه داده ها را رمزگشایی کنند.
- کلیدهای مدیریت شده توسط مشتری (CMK) کلیدهای رمزگذاری اصلی مشتری خاص با پیچ و تاب هستند. در این نوع، مشتریان مختلف ابری به یک کلید رمزگذاری اصلی تکیه نمی کنند، بلکه می توانند کلیدهای اختصاصی داشته باشند. همه کلیدها در فضای ابری باقی می مانند، بنابراین کارمندان یا مقامات ابر ممکن است از کلیدها برای رمزگشایی داده های ذخیره شده استفاده کنند. با این حال، امید این است که مهاجمانی که به فضای ابری نفوذ می کنند نتوانند به همه کلیدها دسترسی پیدا کنند. بعلاوه، کلیدهای خاص مشتری مکانیسم های کنترل دسترسی پیچیده تری را امکان پذیر می کنند زیرا کاربران نیاز به دسترسی به داده ها و دسترسی به کلید خاص دارند.
- این کلید خودت را بیاور (BYOK) نوع رمزگذاری تقریباً مشابه کلیدهای رمزگذاری مدیریت شده توسط مشتری با یک تغییر (تقریباً) قابل چشم پوشی است: مشتریان خود کلیدهای رمزگذاری اصلی را در زیرساخت خود ایجاد می کنند. به عنوان مثال، یک HSM در محل. سپس کلیدهای خود را در فضای ابری بارگذاری می کنند. بنابراین، مشتریان می توانند از ایجاد کلیدها بدون دستکاری یا دخالت در ساخت کلید اطمینان حاصل کنند. نقطه ضعف: مشتری باید زیرساخت ایجاد کلید خود را اجرا و ایمن کند. به عنوان مثال، با خرید، اجرا و نگهداری یک HSM. و هیچ تغییری در مورد (سوء) استفاده از کلید توسط کارمندان یا مقامات تغییر نمی کند.
- این کلید خود را نگه دارید (HYOK) نوع رمزگذاری راه حل بسیار ارزیابی شده برای محافظت از داده های شما در ابر در برابر همه نیروهای شیطانی است. کلید رمزگذاری اصلی در زیرساخت مشتری باقی می ماند. بدیهی است که جدا کردن کلید اصلی از داده‌هایتان، سطح حفاظتی بیشتری را اضافه می‌کند. اگر ابر طبق طراحی کار کند، کلیدهای اصلی 100٪ از دست مقامات و کارمندان ابر ایمن هستند. بنابراین، نوع HYOK ویژگی های فنی اضافی را اضافه می کند تا شما را به یک زیرساخت ابری که نمی توانید به مالک آن اعتماد کنید اعتماد کنید. به عنوان مثال، به دلیل CloudAct. فقط دو محدودیت وجود دارد. اول، همه ابرها چنین ویژگی HYOK را ارائه نمی دهند. به عنوان مثال، GCP در این زمینه برتری دارد، Azure نه. دوم، اگر مهاجمان (یا آژانس‌های فدرال) بتوانند رمزگذاری را دور بزنند، یک الگوریتم عالی و یک کلید رمزگذاری فوق‌العاده ذخیره‌سازی کمکی نمی‌کند، حداقل برای مواردی که ارزش تلاش بیشتری دارند. چگونه می‌توانید مطمئن باشید که ترافیک مسیریابی مجدد مشتریان ابری «بسیار جالب» به سرورها و فضای ذخیره‌سازی بدون رمزگذاری کار وجود ندارد؟
مروری بر انواع رمزگذاری ابر
در پایان، نه ساده لوحی و نه پارانویا هنگام تصمیم گیری در مورد ذخیره و پردازش داده ها در ابر کمکی نمی کند. معماران ابر ممکن است شکل 3 را در طول فرآیند طراحی مفید بدانند زیرا تمام الگوها و انواع را به صورت خطی برای امنیت و کارایی مرتب می کند. با این حال، در نهایت، زمانی که صحبت از رمزگذاری در فضای ابری به میان می‌آید، شرکت‌ها باید بین توانایی توسعه و استقرار سریع عملکردهای تجاری، نیاز به انجام تعهدات قانونی و نظارتی اجباری و تمایل به محافظت از اسرار تجاری تعادل ایجاد کنند. و این یک تصمیم همه یا هیچ نیست. شرکت ها می توانند برای داده های نه چندان مهم به رمزگذاری بومی ابری تکیه کنند و در عین حال اسرار تجاری را از فضای ابری دور نگه دارند.
درباره نویسنده
کلاوس هالر به عنوان یک معمار ارشد امنیت فناوری اطلاعات کار می کند. حوزه های تخصص او شامل ابرهای عمومی (Google Cloud Platform و Microsoft Azure) و نحوه ایمن سازی آنها، مدیریت پروژه و پروژه فنی، عملیات فناوری اطلاعات، مدیریت اطلاعات، تجزیه و تحلیل و هوش مصنوعی است. او همچنین نویسنده “مدیریت هوش مصنوعی در سازمان” است.