ترجمه مقاله امنیت در رایانش ابری

امنیت در رایانش ابری

Security in Cloud Computing

چکیده:

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

 

سفارش ترجمه تخصصی مهندسی کامپیوتر

 

1. مقدمه

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

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

طراحی ساختمان با نام SecureDBaaS برای مراحل سیستم ابری، سفارشی سازی شده و هیچ سرور واسطه میانجی متناوب بین مشتری و عرضه کننده سیستم ابری وجود ندارد. خارج کردن هر گونه میانجی قابل اعتماد از سرور مسیر به SecureDBaaS مجوز رسیدن به همان درجات دسترسی، قابلیت اعتماد و انعطاف پذیریِ یک DBaaS ابری را می دهد. توصیه های دیگر (به عنوان مثال، [8]، [9] و [10]، [11]) مبتنی بر میانه سرور‌ مسیر ، برای یک آرایش مبتنی بر ابر غیر عملی توصیف شده اند، که در آن هر واسطه یا میانجی از اهداف انفرادی ناامیدکننده و چارچوبی که در آن مزیت‌های اصلی (به عنوان مثال، سازگاری، قابلیت دسترسی، و انعطاف پذیری) یک مدیر پایگاه داده بر روی یک مرحله ابری منتقل شده است، حرف می زند. در همه SecureDBaaS، معماری وابسته به میانه قابل اعتماد از رابط مسیر، به پیش‌پاافتاده‌ترین وضعیت ابری کمکی نمی کند. وضعیتی که در آن مشتریان پراکنده توپوگرافیکی به طور همزمان می توانند عملیات خواندن/نوشتن را درخواست کنند و ساختار اطلاعات به یک پایگاه داده ابری تغییر می کند. مجموعه ای قابل توجه از امتحانات، حول مراحل واقعی سیستم ابر تمر کز دارند که نشان می دهد که SecureDBaaS به سرعت به هر DBMS مرتبط است، که باعث عدم تغییر برای مدیریت پایگاه داده ابری می شود. طراحی ساختار پیشنهادی شده مسئول معیار استاندارد TPC-C برای مقادیر مختلف از مشتریان است و تأخیر سیستم نشان می دهد که اجرای همزمان عملیات خواندن و نوشتن، در ساختار پایگاه داده SecureDBaaS تغییر ایجاد نمی کند، و عملا برای آن پایگاه‌های داده ابری رمزگشایی شده یکسان است. حجم کار، از جمله تغییرات در ساختار بانک اطلاعاتی نیز توسط SecureDBaaS پشتیبانی می شود، حتی در هزینه های سربار که به نظر برای به انجام رساندن سطح خیالی حریم خصوصی اطلاعات رضایت بخش به نظر می رسد.

 

شکل1: طرح کلی SecureDBaaS

2. کار مرتبط

SecureDBaaS همه آثار و کارهایی که از رمزگذاری استفاده می کنند برای اطمینان از اطلاعات نظارت توسط پایگاه‌های داده غیر قابل اطمینان، به هم مربوط می کند. در این صورت، یک مسئله اساسی خاطرنشان کردن این است که سیستمهای رمزنگاری نمی توانند ساده لوحانه به DBaaS استاندارد ارتباط پیدا کنند چون DBMS تنها میتوانید عملیات SQL بر اطلاعات متنی اجرا کند. چند موتور DBMS احتمال کدگذاری اطلاعات در سطح سیستم فایلی را از طریق ویژگی تظاهر به رمزگذاری اطلاعات شفاف [16]، [17] ارائه می دهند. این حیله ساخت یک DBMS مورد اعتماد روی ذخیره‌سازی غیر قابل اطمینان، قابل تصور می سازد. سپس دوباره، DBMS مورد اعتماد می شود و اطلاعات را در برخی از زمان‌های نزدیک به  استفاده از آنها، رمزگشایی می کند. پس، این روش مربوط به اتصال DBaaS توسط SecureDBaas در نظر گرفته نمی شود، بر این اساس که ما می پذیریم که منبع ابری غیر قابل اطمینان است.

یک ابر در واقع چارچوبی در مقیاس بزرگ است که در آن هر یک بیت از اطلاعات بر روی سرور‌های مختلف توزیع شده، برای رسیدن به قابلیت دسترسی بالا تکثیر شده است. در این روش، ابتدا در چارچوب اختصاصی مدل منسجم. مرجع [10] به عنوان راهکار، دو کلاس از مدل منسجم را ارائه می دهد: منسجم از دید اطلاعاتی و همچنین منسجم از دید مشتری. مدل منسجم اطلاعات محور، شرایط داخلی از یک چارچوب ذخیره سازی را در نظر می گیرد، به عنوان مثال، چگونه طراحی دوباره در چارچوب اثر می گذارد و چه چیزی تضمین می کند که چارچوب بتواند طراحی دوباره را تحسین کند. سپس دوباره، به یک مشتری، این واقعا تفاوتی در اینکه یک چارچوب ذخیره سازی داخلی شامل هیچ تکرار اطلاعات کهنه باشد، ایجاد نمی کند. طول هیچ اطلاعات کهنه‌ای از دیدگاه مشتری دیده نمی شود. در امتداد این خطوط، مدل منسجم مشتری محور دربر اینکه مشتریان خاص چه چیزی نیاز دارند متمرکز می شود، به عنوان مثال، مشتریان بازبینی اطلاعات را چگونه مشاهده می کنند. کار آنها به همین ترتیب سطوح مختلف سازگاری در چارچوب‌های گردشی را به تصویر می کشد، از سازگاری سخت تا سازگاری ضعیف. سازگاری بالا همراه است با هزینه های بالا و کاهش دسترسی. مرجع [11] بیان می کند که سازگاری سخت هرگز در عمل مورد نیاز نیست، و در واقع مخرب در نظر گرفته می شود. در واقع، به دستور کنوانسیون CAP [3]، [4]، چارچوب‌های هدایتی متعدد، سازگاری سخت برای دسترسی بالا را فراهم می کنند.

در این جا، ما کار بر روی دستیابی به سطوح مختلف سازگاری و هماهنگی در یک ابر را بررسی می کنیم. مرجع [12]  خواص سازگاری ارائه شده با ابهامات بیزینس کشف کرده و چند برداشت مفید انجام می دهد. ابهامات بیزینسی موجود به طور معمول گواهی نامه‌های سازگاری را به مجموعه داده های کوچک محدود می کنند (سرویس اطلاعاتی مگااستورِ گوگل و SQL مایکروسافت)، و یا فقط سازگاری پایانی را ارائه می دهند (Simpledb آمازون و یا Bigtable گوگل ). مرجع [13] چند پاسخ برای به انجام رساندن سازگاری در سطوح مختلف به هنگام ارسال برنامه های کاربردی پایگاه داده در Amanzon S3 را به تصویر کشیده است. در مرجع [14]، ضرورت سازگاری در مورد تکیه بر قابلیت دسترسی واقعی از اطلاعات را بررسی می کند، و همچنین استراتژی سازندگان که چارچوب را با چک کردن وضعیت اطلاعات  قادر به ایجاد سازگاری می سازد. مرجع [15] یک سازگاری جدید را نشان می دهد که به طور طبیعی اجازه هماهنگی سطوح سازگاری مختلف برای اطلاعات معنایی متمایز را می دهد. در گذشته، ما کاری را بر روی چک کردن سطوح سازگاری با CSP ها از دید هدف مشتریان، بررسی کردیم. آرایش های موجود را می توان برای بررسی‌های مبتنی بر پیگیری [7]، [9] و تأیید‌های مبتنی بر معیار [16] - [19] مرتب‌سازی کرد. بررسی های پیگیری‌محور در پرتو سه معناشناسی سازگاری تمرکز می کنند: امنیت، سازگاری و ظرفیت اتمی، که توسط Lamport [20] و توسط Aiyer و همکاران مطرح شده است. یک رجیستری ایمن می ماند اگر یک عمل خواندن که با هیچ ترکیبی همزمان نیست، تخمینی از آخرین ترکیب را برگرداند، و عمل خواندنی که با یک ترکیب همزمان است بتواند هر مقداری را برگرداند. یک رجیستری استاندارد است اگر عمل خواندنی که به با هیچ ترکیبی توام نیست یک بازپرداخت متناسب از آخرین عمل نوشتن و خواندن فراهم کند. یک رجیستری هسته ای است اگر هر عمل خواندن برگشتی داشته باشد. میسرا [22] اولین و مهمترین ارائه یک محاسبه برای چک کردن اینکه آیا پیروی رد رجیستری خواندن/نوشتن هسته ای است یا نه،  می باشد. با توجه به ادامه این کار، مرجع [7] رایانش خروجی را برای چک کردن اینکه آیا یک چارچوب کلیدی ویژگی های  امنیت، نرمالی، و ظرفیت اتمی را با توسعه یک نمودار هدف توسعه می دهد. مرجع [9] یک رایانش چک‌کردن آنلاین با استفاده رایانش GK مطرح می کند و از اندازه گیری‌های متنوع برای ارزیابی جدی نقض استفاده می کند.

ضعف اساسی تأیید اعتبار مبتنی بر پیگیری جریان این است که در میان تمام مشتریان در سراسر جهان یک ساعت جهانی مورد نیاز است. پاسخ ما دارای یک محل با تأیید مبتنی بر  پیگیری است. با این حال، ما در معناشناسی سازگاری های متنوع در چارچوب ابری کسب و کار تمرکز می کنیم، که در آن یک ساعت تقریبا هماهنگ مناسب برای پاسخ ما است. تأیید معیار ساخته شده در پرتو تعیین معیار، در چارچوب ذخیره سازی متمرکز می شود. هر دو [16] و [17] سازگاری در S3 آمازون را ارزیابی می کنند، با این حال نتایج متنوعی نشان می دهند. مرجع [16] از تنها یک مشتری برای مطالعه اطلاعات در سنجش‌ها استفاده می کند، و نشان داده که چند تناقض در S3 وجود دارد. مرجع [17] از مشتریان مختلف پراکنده از نظر توپوگرافیکی برای مطالعه کردن اطلاعات استفاده کرد، و کشف کرد که S3 اغلب موارد سازگاری خواندن یکنواخت را نقض می کند. عواقب [17]  به ساختار بررسی دو سطحی ما مشروعیت می دهد. مرجع [18] یک روش تعیین معیار مشتری محور برای هماهنگی اجتناب ناپذیر در درک چارچوب‌های ظرفیت پراکنده ارائه می دهد.

3: معماری طراحی

SecureDBaaS در نظر گرفته شده تا به مشتریان مختلف و مستقل اجازه برقراری رابط خاص به DBaaS ابری غیر قابل اطمینان بدون هیچ سرور نیم‌راه، را بدهد. شکل1 مدل سازی ساخت و ساز را به طور کلی به تصویر می کشد. ما قبول می کنیم که یک مجموعه اشغال کننده، پایگاه داده‌ای ابری از یک منبع DBaaS غیر قابل اطمینان به دست می آورد. سپس ساکنان سپس یک یا چند ماشین می فرستند (مشتری 1 تا N) و یک مشتری SecureDBaaS در هر یک از آنها معرفی می کند. این مشتری اجازه می دهد تا یک مشتری با DBaaS ابری برای کنترل آن رابطه برقرار کند، تا اطلاعات را بخواند و بنویسد، و در واقع جداول پایگاه داده را تغییر دهد.

 

شکل2: ساختار یک متادیتای جدولی

ما قبول داریم که همان امنیت نشان می دهد که به طور معمول به وسیله نوشتن در این زمینه در بر گرفته شده (به عنوان مثال، [8]، [9])، که در آن مشتریان ساکن باور شده اند، سیستم غیر قابل اطمینان است، و تامین کننده ابر  نسبتا بی ابر مانده، که این یعنی عملیات مدیریت ابر به طور موثر اجرا شده. از این رو، اطلاعات مستاجر، ساز و کارهای اطلاعات، و ابرداده‌ها (متادیتا) باید قبل از خروج مشتری کد گذاری شود. یک ارائه فشرده از مدل امنیتی دریافتی در این مقاله در ضمیمه An آمده است.

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

SecureDBaaS  از معماریهای موجود متفاوت است چراکه تنها اطلاعات را در پایگاه داده سرنشینان ابر ذخیره می کند، و ابرداده‌های ریکاوری را بین  پایگاه داده و یک واسطه ابری مورد اعتماد [8] و در دستگاه مشتری [9] ذخیره می کند. با توجه به شرایطی که در آن مشتریان مختلف می توانند به طور همزمان به پایگاه داده یکسان دسیابی داشته باشند، این ترتیبات بسیار بی فایده هستند. به عنوان مثال، مقدار کمی از ابرداده در مشتریان ممکن است نیاز به سیستم های دست و پا گیر برای هماهنگ سازی ابرداده‌ها داشته باشند.

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

مشتریان SecureDBaaS می توانند ابرداده‌های اساسی را از پایگاه داده های غیر قابل اطمینان، از طریق مفصل SQL ریکاوری کنند، به طوری که ظهور های مختلف از مشتری SecureDBaaS بتوانند به پایگاه داده های غیر قابل اطمینان ابری خود همزمان با اطمینان از همان ویژگی های دسترسی و سازگاری ابر میانی ​​DBaaS، دسترسی پیدا کنند. تکنیک های رمزنگاری برای اطلاعات ساکن و پاسخ های خلاقانه برای مدیریت ابرداده در دو بخش به تصویر کشیده شده است.

سفارش ترجمه تخصصی مهندسی کامپیوتر

سفارش ترجمه تخصصی مهندسی کامپیوتر

سفارش ترجمه تخصصی مهندسی کامپیوتر

سفارش ترجمه تخصصی مهندسی کامپیوتر

 

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

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

 

شکل3: سازماندهی پایگاه داده ابرداده‌ها

 

4. عملیات

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

در مراحل همراهی، DBA جداول پایگاه داده های کد گذاری شده را میسازد. این باید سه زمینه حریم خصوصی (COL، MCOL و DBC) ارائه شده در پایان بخش 3 را در نظر بگیرد. فرصتی به ما دهید تا این مرحله را با اشاره به یک مورد گویای عمومی نشان داده شده در شکل 4 را به تصویر بکشیم، که در آن ما سه جدول امن به نام ST1، ST2، ST3 داریم. هر یک جداول STi دارای یک جدول کد گذاری Ti هستند که حاوی اطلاعات درهم ساکنین است، و یک جدول فراداده‌های Mi .

عملیات متوالی SQL

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

 

شکل4: مدیریت کلید رمزنگاری طبق پارامتر قابلیت اطمینان

 

3. عملیات همزمان SQL

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

عملیات SQL بر تغییرات در ساختار پایگاه داده، به عنوان مثال، خواندن، نوشتن، و تعمیرات آورده نمی شوند؛ عملیاتی از جمله تغییرات ساختار بانک اطلاعاتی در طی ایجاد، تخلیه و تغییر جداول پایگاه داده.

 

نتیجه گیری

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