دانلود رایگان ترجمه مقاله فیلتر ابر، کنترل کاربردی انتشار اطلاعات حساس به ابر – ACM 2012

مقاله انگلیسی رایگان

ترجمه فارسی رایگان 

فهرست مقاله:

3-طراحی فیلتر ابر
3.1 تعیین خط مشی انتشار داده ها
3.1.1 برچسب ها
3-1-2 قواعد ECA
رویداد ها
شروط
عملیات3.1.3 خط مشی انتشار داده های توزیعی
3-2 اجرای خط مشی انتشار داده ها
3-2-1 نمونه سازی برچسب
3-2-2 انتشار برچسب

بخشی از ترجمه فارسی مقاله:

3-طراحی فیلتر ابر
هدف فیلتر ابر ارایه یک راه حل آسان و کاربردی برای کنترل انتشار داده ها بین یک شرکت و سرویس های ابر است. ما بر ارایه دهندگان فضای ذخیره ابری تاکید می کنیم که بیانگر داده های ذخیره شده نظیر فایل ها می باشند. یک لازمه مهم برای سیستم، قابلیت کاربرد آسان سیستم در ارایه دهندگان فضای ذخیره ابری مختلف با حداقل پیکر بندی است. در عین حال، بایستی قادر به سازگاری با API سرویس های فضای ابری ویژه می باشد. برای مثال، فیلتر ابر بایستی قادر به اجرای خطی مشی های انتشار داده هایی باشد که مانع از بارگذاری فایل ها توسط کاربران به پوشه های خاص می شوند: این اطلاعات در روش های HTTP وجود دارند.
نیاز به پشتیبانی از ارایه دهندگان فضای ذخیره ابری موجود، موجب شده است تا یک سری از قوانین و ملزومات در خصوص شیوه انتشار برچسب ها با داده ها ایجاد شوند.اولا، برچسب ها بایستی در ارتباط با فایل های ذخیره شده توسط ارایه دهنده فضای ذخیره ابری باشند. بسیاری از سرویس های ابر، امکان عملیات فایل از راه دور نظیر کپی، جا به جایی و دسترسی به نسخه های قبلی را می دهند. این عملیات بایستی برچسب های مربوط به فایل ها را مستقل از شیوه اجرای عملیات حفظ کنند. این مستلزم یک طرحی است که در آن برچسب ها درون فایل ها جاسازی می شوند. دوما، در صورتی که یک فایل در یک دستگاه کاربر دانلود شود، برچسب ها بایستی در ارتباط با فایل ها باقی بمانند.برچسب های ذخیره شده محلی نشان می دهند که چگونه فایل توسط ابر فیلتر در گذشته مدیریت شده است و اگر فایل دوباره بارگذاری شود، این اطلاعات را می توان برای کاهش نیاز به ورودی کاربر مورد استفاده قرار داد. به منظور بیشینه سازی پتانسیل پذیرش، مکانیسم ذخیره برچسب ها بایستی پلتفرم آگنوستیک باشد. این مانع از استفاده از ویژگی های مختص سیستم های فایل( برای مثال مشخصه های فایل توسعه یافته در لینوکس یا جریان جایگزین داده در NTFS) می شود که نیازمند ترجمه برچسب ها بین الگو های مختلف بوده و ممکن است توسط سرویس های ذخیره ابری پشتیبانی نشود. ما یک رویکرد جا سازی برچسب ها در فایل ها را در بخش 3.2 توصیف می کنیم.
فیلتر ابر متشکل از اجزای زیر است( شکل 1):
پروکسی کلاینت وسرویس: دو پروکسی فیلتر ابر، کلاینت و سرویس، ترافیک HTTP بین سازمان و ارایه دهنده ابر را قطع می کند. هر پروکسی، داده های در حال انتقال را از طرف دامینی که بخشی از آن است بازرسی می کند. به علاوه، پروکسی سرویس می تواند خطی مشی تعیین شده توسط کلاینت های ارایه دهنده را اجرا کند. پروکسی ها مسئول برچسب زنی داده ها می باشند.
حافظه خط مشی: هر پروکسی یک حافظه خط مشی را دارد. حافظه خط مشی،مجموعه ای از قوانین رویداد-شرایط –عملکرد را انباشته می کند.
قوانین ECA، وقتی که انتقال فایل اتفاق می افتد، خط مشی انتشار داده ها را تعیین می کنند و از این روی، فعالیت های پروکسی ها را کنترل می کنند. درک فرمت ECA آسان بوده و موجب تسهیل پیاده سازی آن هنگام برقراری ارتباط با پروکسی می شود( رجوع شود به 3.1.3).
افزونه های مرور گر: یک افزونه مرور گر، اطلاعات مورد استفاده برای برچسب زنی فایل های بار گذاری شده را جمع آوری می کند. این افزونه با پروکسی کلاینت ارتباط برقرار کرده و می تواند صریحا کاربر را ترغیب به تایید آن در زمان شناسایی یک بارگذاری فایل توسط پروکسی کند.
شکل 1 نشان می دهد که چگونه آپلود فایل بین یک سازمان و یک ارایه دهنده ابر اتفاق می افتد. در گام 1، کاربر، فایل را از طریق یک فرم وب تحویل می دهد. پلاگین مرور گر، به درخواست HTTP خروجی، مجموعه ای از اطلاعات شناسایی را برای کاربر فعلی همراه با متادیتا در مورد فایل نظیر محلی که فایل به طور محلی ذخیره شده است الحاق می کند. در گام دوم،پروکسی کلاینت موجب قطع درخواست شده، محتوی درون آن را بازرسی می کند و اطلاعات شناسایی کاربر را بازیابی می کند. سپس درخواست را با قواعد ECA در حافظه خط مشی آن مطابقت می دهد.
وقتی که قاعده ECA مطابق با یک درخواست باشد، پروکسی، یک عمل را اجرا می کند. در گام سوم، در مورد محرمانگی فایل در حال بارگذاری از کاربر پرس و جو می کند. پاسخ کاربر منجر به برچسبی می شود که به فایل الحاق شده است. بعد از ثبت درخواست برای حسابرسی آینده، به سرویس ابر هدایت می شود.
در گام پنجم، پروکسی سرویس، درخواست ها را همراه با برچسب های آن ها بازرسی می کند. حافظه خط مشی محلی، خط مشی بیان شده به صورت قواعد ECA را ذخیره می کند که ارایه دهنده ابر این قواعد را بر روی داده های کلاینت اجرا می کند. برای مثال، یک ارایه دهنده ابر می تواند از میزبانی فایل های حساس مربوط به یک سازمان خاص برای اجتناب از مشکلات حقوقی آینده، انصراف دهد. در صورتی که بارگذاری فایل پذیرفته شود، درخواست به یک سرویس ذخیره ای ارسال می شود.
در گام پنجم، یک درخواست HTTP بعدی، فایل بارگذاری شده در مراحل 1-4 را بازیابی می کند. پروکسی سرویس، پاسخ سرویس ذخیره سازی را را قطع کرده و از برچسب متصل به داده ها برای تصمیم گیری در مورد شیوه پاسخ به درخواست استفاده می کند. پروکسی سرویس می تواند با پروکسی کلاینت برای بدست آوردن یک خط مشی برای اجرا از طرف آن تماس برقرار کند برای مثال برای اجتناب از آزاد سازی داده ها به یک کاربری که در شبکه سازمانی نیست.

بخشی از مقاله انگلیسی:

3. CLOUDFILTER DESIGN

The goal of CLOUDFILTER is to provide an easy-to-use and practical solution for controlling data propagation between an enterprise and cloud services. We focus on cloud storage providers, which represent stored data as files. An important requirement is for the system to be easily applicable across different cloud storage providers with minimal configuration. At the same time, it should be able to adapt to the API of specific cloud storage services. For example, CLOUDFILTER should be able to enforce data propagation policies that prevent users from uploading files to particular folders; such information exists in the HTTP methods invoked. The need to support existing cloud storage providers imposes a set of requirements on how labels propagate with the data. First, the labels should remain associated with files while stored by the cloud storage provider. Many cloud services allow remote file operations such as copy, move and access to previous versions. Such operations should preserve the labels associated with the files independently of how the operations are implemented. This favours a design, in which labels are embedded inside files. Second, labels should remain associated with files if a file is downloaded at an employee’s machine. Labels stored locally capture how the file was handled by CLOUDFILTER in the past and such information can be used to reduce the need for user input if the file is uploaded again. In order to maximise the potential for adoption, the mechanism of storing labels should be platform-agnostic. This precludes the use of features specific to file systems (e.g. Extended File Attributes in Linux or Alternate Data Streams in NTFS) that would require translating labels between different representations and may not be supported by cloud storage services. We describe an approach to embed labels in files in §3.2. CLOUDFILTER consists of the following components (Figure 1): Client and Service Proxy. Two CLOUDFILTER proxies, the client and the service, intercept HTTP traffic between the enterprise and the cloud provider. Each proxy inspects the data being transferred on behalf of the domain that it is part of. In addition, the service proxy may enforce policy specified by the provider’s clients. Proxies are responsible for labelling data. Policy store. Each proxy maintains a policy store. The policy store accumulates a set of Event-Condition-Action (ECA) rules. ECA rules specify data propagation policy when a file transfer occurs and therefore control the actions of the proxies. The ECA format is easy to understand and facilitates enforcement when proxies communicate (c.f. §3.1.3). Browser extension. A browser extension collects information used to label uploaded files. It communicates with the client proxy and may explicitly prompt the user for confirmation when the proxy detects a file upload. Figure 1 illustrates how a file upload occurs between an enterprise and a cloud provider. In step 1, the user submits the file via a web form. The browser plugin attaches to the outgoing HTTP request a set of identification information for the current user along with meta-data about the file, such as the location where the file is stored locally. In step 2, the client proxy intercepts the request, inspects its content and retrieves the user-identifying information. It then matches the request against the ECA rules in its policy store. When an ECA rule matches a request, the proxy executes an action. In step 3, the action queries the user about the confidentiality of the file being uploaded. The user’s reply results in a label that is attached to the file. After the request is logged for future audit, it is forwarded to the cloud service. In step 4, the service proxy inspects the request along with its labels. The local policy store maintains policy expressed as ECA rules that the cloud provider enforces on client data. For example, a cloud provider may deny hosting sensitive files originating from a particular enterprise to avoid future legal disputes. If the file upload is accepted, the request is forwarded to the storage service. In step 5, a subsequent HTTP request retrieves the file uploaded in steps 1–4. The service proxy intercepts the response of the storage service and uses the label attached to the data to decide how it should respond to the request. The service proxy may also contact the client proxy to obtain a policy to enforce on its behalf, e.g. to avoid releasing the data to a user who is not located inside the enterprise network.