فیلتر ابر: کنترل عملی انتقال اطلاعات حساس به ابر CloudFilter: Practical Control of Sensitive Data Propagation to the Cloud

۳٫ 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 §۳٫۲٫ 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. §۳٫۱٫۳). 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–۴٫ 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.