Accessing objects in hosted storage

- Google

A first access control list method is stored in a hosted storage system and in association with a storage structure. The first access control list is designed to grant permission to write data objects to the storage structure but not designed to grant permission to read objects from the storage structure. The first access control list grants a first user permission to write data objects to the storage structure. A second access control list is stored in the hosted storage system and in association with a first data object stored in the storage structure. The second access control list is designed to grant permission to read the first data object. The second access control list grants a second user permission to read the first data object.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority from U.S. Provisional Application Ser. No. 61/346,005 filed May 18, 2010. The contents of the prior application are incorporated herein by reference in their entirety.

TECHNICAL FIELD

This document relates to hosted storage.

BACKGROUND

Hosted, or cloud-based storage, refers to off-site or remote data storage that is typically provided by a third party. The third party may implement the hosted storage in a data center, and provide access to the hosted storage over a network, such as the Internet.

SUMMARY

In general, a first access control list method is stored in a hosted storage system and in association with a storage structure. The first access control list is designed to grant permission to write data objects to the storage structure but not designed to grant permission to read objects from the storage structure. The first access control list grants a first user permission to write data objects to the storage structure. A second access control list is stored in the hosted storage system and in association with a first data object stored in the storage structure. The second access control list is designed to grant permission to read the first data object. The second access control list grants a second user permission to read the first data object. A write request is received from the first user to write a second data object to the storage structure. In response to receiving the write request and based on the first access list, it is determined that the first user is permitted to write data objects to the storage structure. The second data object is stored in the storage structure in response to determining the first user is permitted to write data objects to the storage structure. A read request is received from the second user to read the first data object from the storage structure. In response to receiving the read request and based on the second access list, it is determined that the second user is permitted to read the first data object. The first data object is provided to the second user in response to determining the second user is permitted to read the first data object.

Implementations may include one or more of the following features. The first access control list may grant the first user permission to list the data objects in the storage structure. A list request may be received from the first user to list the first data object from the storage structure. In response to receiving the list request and based on the first access list, it may be determined that the first user is permitted to list the first data object. List information of the first data object is provided to the first user in response to determining the first user is permitted to read the first data object.

The first access control list may grant the first user permission to modify the first access control list. An access control list modification request may be received from the first user to modify the first access control list. In response to receiving the access control list modification request and based on the first access list, it may be determined that the first user is permitted to modify the first access control list. The first access control may be modified in response to determining the first user is permitted to modify the first access control list.

A read request may be received from the first user to read the first data object from the storage structure. In response to receiving the read request and based on the second access list, it may be determined that the first user is not permitted to read the first data object. A permission denied message may be provided to the first user in response to determining the first user is not permitted to read the first data.

The first user may be an administrator of an application and the second user may be a consumer of the application. Encryption keys for the first data object and the second data object may be stored in encrypted form. In response to determining that the second user is permitted to read the first object, the encryption key for the first data object may be decrypted. Before providing the first data object to the second user, the second data object may be decrypted.

Implementations of the described techniques may include a computer system, hardware, a method or process, or computer software on a computer-accessible medium.

The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

Various implementations of the subject matter described here may provide one or more of the following advantages. In one or more implementations, giving limited permissions to application administrators may allow the administrators to operate on a system without exposing user data to the administrators. In one or more implementations, using access control lists for buckets different access control lists for objects can permit fine grain control of permissions.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram showing an example of a system for providing hosted storage and accessing the hosted storage from a client device.

FIG. 2 is a flow chart showing an example of a process for storing data in a hosted storage service.

FIG. 3 is a flow chart showing an example of a process for providing data in a hosted storage service.

FIG. 4 is a flow chart showing an example lifecycle of an access control list.

FIG. 5 shows an example of a computing device and a mobile computing device.

 DETAILED DESCRIPTION

A hosted storage system can receive, store, and serve data objects to clients. The data objects can be organized into buckets in the hosted storage system, for example to organize, track, and reference the data objects. Each data bucket can include permissions that identify a first user or group of users that may write data objects to that bucket. Each object can have permissions that identify a second user or group of users that may read the object. In some cases, the first user or group of users may be separate from the second user or group of users.

FIG. 1 is a block diagram showing an example of a system 100 for providing hosted storage and accessing the hosted storage from a client device 102. In some implementations, a hosted storage services 120 can provide access to stored data by applications running on computing devices geographically separate from each other, provide offsite data backup and restore functionality, provide data storage to a computing device with limited storage capabilities, and/or provide storage functionality not implemented on a computing device.

The system 100 can provide scalable stores for storing data objects. The client device 102 can upload data objects to the hosted storage service 120 and control access to the uploaded data objects. Access control can include a range of security levels, from keeping data securely confidential to publishing it without restrictions. Data stored in hosted storage service 120 can be secured from unauthorized access. The hosted storage service 120 can use a simple and consistent application programming interface, or API, which can allow arbitrary quantities of structured or unstructured data to be kept private or shared between individuals, organizations, or with the world at large. The client device 102 can store data in the hosted storage service 120 for mutual business reasons (e.g., submission of work product ordered by the owner of the hosted storage service 120), or for use in data processing by other services (e.g., images uploaded are used to automatically and dynamically create a photo gallery web page.)

The client device 102 can be implemented using a computing device, such as the computing device 600 or the mobile device 650 described with respect to FIG. 6. The client device 102 can communicate with the hosted storage service 120 via a network 104, such as the Internet. The client device 102 can communicate across the network using communication protocols such as, for example, one or more of Transmission Control Protocol/Internet Protocol (TCP/IP), Hypertext Transfer Protocol (HTTP), Secure Shell Remote Protocol (SSH), or Application Program Interfaces (API). While only a single client device 102 is shown, there can be multiple client devices communicating across the network 104 with the hosted storage service 120 and/or other services and devices.

The hosted storage service 120 can be implemented such that client applications such as a client application 103 can store, retrieve, or otherwise manipulate data objects in the hosted storage service 120. The hosted storage service 120 can be implemented by one or more server devices, which can be implemented using a computing device, such as the computing device 600 or mobile device 650 described with respect to FIG. 6. For example, the hosted storage service 120 can be implemented by multiple server devices operating in the same, or different, data centers.

The hosted storage service 120 generally includes an interface frontend 106, an interface backend 108, a storage backend 110, metadata 116 for objects stored in the storage backend 110, and a keystore 109. In general, the interface frontend 106 may receive requests from and send responses to the client device 102. For instance, the hosted storage service 120 can be implemented as a Web Service with a corresponding set of Web Service Application Programming Interfaces (APIs). The Web Service APIs may be implemented, for example, as a Representational State Transfer (REST)-based HTTP interface or a Simple Object Access Protocol (SOAP)-based interface.

An interface frontend 106 can receive messages from the client 102 and parse the request into a format usable by the hosted storage service 120, such as a remote procedure call (RPC) to an interface backend 108. The interface frontend 106 writes responses generated by the hosted storage service 120 for transmission to the client 102. In some implementations, multiple interface frontends 106 are implemented, for example to support multiple access protocols.

The interface frontend 106 can include a graphical front end, for example to display on a web browser for data access. The interface frontend 106 can include a sub-system to enable managed uploads and downloads of large files (e.g., for functionality such as pause, resume, and recover from time-out). The interface frontend 106 can monitor load information and update logs, for example to track and protect against denial of service (DOS) attacks.

As described above, the Web Service API may be a REST-based HTTP interface. In a REST-based interface, a data object is accessed as a resource, uniquely named using a URI, and the client application 103 and service 120 exchange representations of resource state using a defined set of operations. For example, requested actions can be represented as verbs, such as by HTTP GET, PUT, POST, HEAD, and DELETE verbs. The GET verb may be used to retrieve an object, while the HEAD verb may be used to retrieve information about an object without retrieving the object itself. The DELETE verb may be used to delete an object from the hosted storage service 120. The PUT and POST verbs may be used to upload an object to the service 120. PUT requests can come from the client 102 and contain authentication and authorization credentials and object metadata in a header, such as an HTTP header. POST requests can be received when a client 102 wants to upload from a web browser form. The form POST upload protocol for the hosted storage service 120 can involve multiple required form fields to provide authentication, authorization and object metadata. More generally, any of the API requests may include credentials for authentication and authorization, for example, in a header of the request. For example, an authorization header may be included in the REST requests, which includes an access key to identify the entity sending the request.

Alternatively, or additionally, a user can be authenticated based on credentials stored in a browser cookie, which gets appended to the API requests. If no valid cookie is present, a redirect to an authentication frontend can be generated, and the authentication frontend can be used to generate the browser cookie. The authentication frontend can be used by systems and services in addition to the hosted storage service 120 (e.g., if the organization operating the hosted storage service 120 also operates other web services such as email service.) A user can also or alternatively be authenticated based on authentication credentials from an external credentialing service or an external service that includes credentialing functionally. User or group identifier information can be calculated from the external service's credential information. Requests sent by the client 102 to the interface frontend 106 can be translated and forwarded to the external service for authentication.

In general, objects stored in the hosted storage service 120 can be referenced by object identifiers. The hosted storage service 120 can define namespaces to which a valid object identifier must conform. For example, the namespace may require that object identifiers be a sequence of Unicode characters whose UTF-8 encoding is at most 1024 bytes long. As another example, the namespace may require that object identifiers be globally unique identifiers (GUIDs), which may be 128-bit integers.

Objects can be stored in hosted storage service 120 in data structures such as buckets. In some examples, each bucket is uniquely named in the hosted storage service 120, each object is uniquely named in a bucket, and every bucket and object combination is unique. Objects may be uniquely identified by a URI that includes the bucket name and the object name, and identifies the hosted storage service 120. For example, an object named “long/song.mp3” in a bucket named “music” could be specified using a URI pattern such as http://s.hostedstoragesystem.com/music/long/song.mp3 or http://music.s.hostedstoragesystem.com/long/song.mp3. Alternatively, the user of the client 102 can create a bucket named www.music.org, publish a CNAME alias redirecting that to http://music.s.hostedstoragesystem.com, and address the object as http://www.music.org/long/song.mp3. In some examples, buckets do not nest.

The interface backend 108 can handle request authentication and authorization, can manage data and metadata, and can track activity such as for billing. The interface backend 108 can provide functionality for independent frontend/backend scaling for resource utilization and responsiveness under localized heavy loads. Data management can be encapsulated in the interface backend 108 while communication serving can be encapsulated in the interface frontend 106. The interface backend 108 can isolate security mechanisms from the client-facing interface frontend 106.

The interface backend 108 can expose an interface usable by both the interface frontend 106 and other systems. In some examples, some features of the interface backend 108 are accessible only by an interface frontend (not shown) used by the owners of the hosted storage service 120 (internal users). Such features can include those needed for administrative tasks (e.g., resolving an object reference to a low level disk address.) The interface backend 108 can handle request authentication (e.g., ensuring a user's credentials are valid) and authorization (e.g., verifying that a requested operation is permitted.) The interface backend can also provide encryption and decryption services to prevent unauthorized access to data, even by internal users.

A keystore 109 can store encryption keys for data objects, where the encryption keys have themselves been encrypted by the interface backend 108. The encrypted keys can carry associated metadata that is cryptographically bound to the key itself, and are referred here to as wrapped keys. From the point of view of the interface backend 108, the wrapped keys can be opaque objects. To obtain the cleartext key of a wrapped key for use (e.g., to encrypt or decrypt a data object) the interface backend 108 can provide the wrapped key and client authentication credentials to the keystore 109. The keystore 109 can verify, based in part on the wrapped key's metadata, that the provided authentication credential is sufficient to authorize release of the key, and if so, can return the unwrapped key to the interface backend 108. The interface backend 108 can use the key to encrypt or decrypt the data object and then can discard the key.

In some examples, the encryption key is a symmetric key that can be used to both encrypt and decrypt an object. In some examples, a wrapped key can have associated metadata indicating multiple users or groups authorized to access the cleartext key. In some examples, the keystore 109 can copy a wrapped key and rewrap the key for a different principle (e.g., containing different metadata).

The interface backend 108 can manage metadata 116 associated with data objects, for example in a structured data format such as a database (e.g., MySQL or BigTable). User-specified names labeling the buckets can be completely defined within the metadata 116, and object metadata 116 can map a resource name to one or more data shares 112 storing the resource. The metadata 116 can also contain bucket and object creation times, object sizes, hashes, and access control lists 118 (ACL 118) for both buckets and objects. The interface backend 108 can log activity and track storage consumption to support accounting for billing and chargebacks. In some examples, this includes quota monitoring in each dimension in which customers are charged (e.g., reads, writes, network transfers, total storage in use.)

The ACLs 118 define who is authorized to perform actions on corresponding buckets or objects, and the nature of the permitted actions. The ACLs 118 can be an unordered list of {scope, role} pairs, plus Boolean flags. The scope may define a user or group of users, and the role may define the access permissions for the user or group. In some examples, the union of all {scope, role} pairs can define access rights. In some examples, more specific {scope, role} pairs override more general ones.

Table 1: Bucket Roles below shows a list of example roles that can be included in ACLs 118 for buckets. Table 2: Object Roles below shows a list of example roles that can be included in ACLs 118 for data objects. As illustrated by these examples, in some implementations the role for a bucket may be used to control who can list the buckets objects, create or delete objects in a bucket, and/or read or write the bucket ACL, but not to control who can read the objects within the bucket. Instead, the role for the object itself controls who can read the object and/or who can read or write the object's ACL. As described below, such a scheme may allow certain users to have some administrative control over buckets, without being able to have direct access to the objects in the buckets.

TABLE 1 Bucket Roles Role Capabilities READ Can list the bucket's contents. Cannot create or delete objects. WRITE READ capabilities plus ability to create and delete objects in the bucket. FULL_CONTROL WRITE capabilities plus ability to read and write the bucket ACL.

TABLE 2 Object Roles Role Capabilities READ Can read the object. FULL_CONTROL READER capabilities plus ability to read and write the object ACL.

Scopes can be defined to a single user or a group of users. In one implementation, those users with a FULL_CONTROL role (and therefore able to modify the ACL for a given bucket or object) may define a group of users, and then provide a role for the group. For example, a group of users may be managed by the hosted storage service 120 (or, more generally, by the service provider that provides the hosted storage service 120) for reasons other than storage permissions (for example, for a message board or other service that employs groups) and those groups may be identified by a single username or other identifier associated with the group of users, an e-mail address associated with the group of users (which may or may not also correspond to an identifier of the group), or a domain name associated with a group. This may allow a user to specify a preexisting group managed by the service provider that is already defined by the identifier, e-mail address, or domain name. Similarly, users may be able to specify a group of users (for example, by user id or e-mail address) and associate an access key with the group. This may allow for the formation of ad-hoc groups for the management of storage permissions, rather than groups already managed by the service provider.

In this way, a group of users can be given a particular role simply by managing the role of the group. Similarly, if the ACL is associated with a bucket containing a number of objects, or the ACL is otherwise associated with multiple objects, the role with respect to those objects can be easily changed by simply changing the role of the group.

Table 3: Scopes below shows a list of example scopes that can be included in ACLs 118 for buckets and/or data objects.

TABLE 3 Scopes Name Description Service ID A single authenticated user specified by username. Email Address A single user specified by an email address. Service Group ID A group of users managed by the hosted storage service 120 and specified by an associated identifier. Invite Token One or more users with access to a one time use digital token. Group-Restricted One or more users with access to a permanent use Key digital key. All Service Users All authenticated users of the hosted storage service 120. All Users All users, no authentication. Can be anonymous or semi-anonymous.

The FULL_CONTROL role can represent all possible capabilities, such as those assigned to an object or bucket owner connected to a financially responsible party. The bucket owner can be configured to always have FULL_CONTROL for the bucket. In general, the bucket and/or object owner can create or modify scopes and roles in the corresponding ACLs, but in some implementations the pair {bucket owner, FULL_CONTROL} may be prevented from being removed from the bucket ACL 118 (or the object ACL). To create an object, a user can have write permission on the bucket, which can be granted by WRITE and FULL_CONTROL. WRITE permission on the bucket can imply permission to delete or overwrite an object in the bucket. Additional constraints can disallow certain modifications to ACLs 118. In some examples, it is possible to create an object that the bucket owner cannot read.

For example, in some implementations, a user such as a system administrator may be given the FULL_CONTROL role for a group of buckets, but not given any roles for any of the objects in those bucket. Such a user may be, for example, responsible for the maintenance of systems using the bucket to store data, but not responsible for the data itself. For example, an email administrator user may need to write to a bucket, list the contents of the bucket, and modify the bucket's ACL, but the email administrator should not have permission, by default, to read the email of the system's users.

In some implementations (such as those using the example roles described above), the FULL_CONTROL role provides permission for three operations on any object within the bucket. First, a user with FULL_CONTROL may list the objects in the bucket. This list can include administrative information about the objects without exposing the contents of the objects. For example, a listing in some hosted storage systems 220 may include a file name and path for the object in the datastore 112. This file name and path may be lower level than a bucket or object URI and may depend on the implementation of the datastore 112. For example, the datastore 112 may be organized as a relational database, and the file name and path may include a table name and row number. The listing may also include information such as the size, timestamp of last modifications, and access log for each object in the bucket.

Second, a user with FULL_CONTROL may create and delete objects in bucket. This permission can be used to, for example, seed a new bucket with default objects for a new user. For example, for a new employee, a company's human resource administrator may create a bucket for that employee with a timesheet template, training materials, or handbook.

Third, FULL_CONTROL includes permission to modify a bucket's ACL. In the example of the new employee, the human resource administrator may create an entry in the bucket's ACL to give the employee the WRITE role for the bucket.

In this implementation, the hosted storage system 220 can be configured so that each object in the buckets may have ACLs that specify READ and FULL_CONTROL only for users that do not have FULL_CONTROL for the bucket containing the object. In the email example, where the administrator has FULL_CONTROL for email storage buckets but no role for any of the objects in those buckets, a customer of the email system may have the WRITE role for a bucket and the READ role for every object in that bucket. In this example, the email application could read, write and delete objects in the customer's bucket when the customer is logged in, but only list and write the contents of the bucket and read and write the contents of the bucket's ACL when the administrator is logged in.

The following is an example use of the hosted storage system 220 with bucket based ACLs for object writes and object based ACLs for object reads. In this example, the hosted storage system 220 is used to store email data, with objects for email files, attachments, and contacts.

An email system can store, in the hosted storage system 220, an archive of user's email object. An email bucket can contain the email objects, an attachments bucket contains attachment objects, and a contacts bucket contains contacts. Each of these three buckets can have an ACL that specifies that the email system and administrator group have FULL_CONTROL, which can designate at permissions to write data objects to the bucket, but does not designate permission to read objects from the bucket. Each email object, attachment object, and contact object can have associated an ACL that specifies that an associated user has READ permissions for the object, which specifies permission to read the objects.

The email system can receive an email message, and can parse it into an email object. The email system can send to the hosted storage system 220 a request to write the email object to the email bucket and to assign to the email object READ permission for the associated user. The hosted storage system 220 can determine that the email system is permitted to write the email object to the email bucket by examining the email bucket's ACL. Once permission is verified, the hosted storage system 220 can store the email object in the email bucket, and can create an ACL for the email object designation the user with READ permission.

Later, when the user logs into the email system, the user may request the email object from the hosted storage system 220. The hosted storage system 220 can determine that the user is permitted to read the email object by examining the email object's ACL. Once permission is verified, the hosted storage system 220 can provide the email object to the user.

The email system may perform regular maintenance and indexing of the email, attachments, and contacts bucket. For example, asynchronous processes and users of the email system may modify the contents of the buckets, and the email system may use spare cycles to scan the contents of the buckets and update search indexes of the buckets. The email system can generate a list request for a bucket that request, for example, the fully qualified name of each data object in a bucket and metadata associated with each data object. The email system can send the list request to the hosted storage system 220, and the hosted storage system 220 can determine that the email system is permitted to list the contents of the bucket, based on the email system's 220 FULL_CONTROL role for the bucket. The hosted storage system 220 can generate list information for the data objects in the bucket (the fully qualified name of a data object and the data object's metadata) and return the list information to the email system. The email system may then compare the received list information with the search index and update the search index as appropriate.

The email system may also modify the ACLs for the buckets. For example, the email system may merge with another hosted application, and all permissions that are associated with the email system can be given, by the email system, to the other hosted applications. The email system can generate an access control list modification request specifying that the other hosted application should be given the FULL_CONTROL role for the email, attachments, and contacts bucket. The email system can send the access control list modification request to the hosted storage system 220, and the hosted storage system 220 can determine that the email system is permitted to modify the ACL for the bucket, based on the email system's 220 FULL_CONTROL role for the bucket. The hosted storage system can modify the ACL for the bucket, adding the other hosted application with the FULL_CONTROL role, and return a message to the email system indicating that the modification has been made.

The email system may also generate and send messages to read the contents of the bucket, an activity the email system in this example does not have. For example, the email system may include a software bug, be misconfigured, operate under malicious code execution, or generate and send the message at the request of a human user. The email system can generate a read request for the data objects in the email bucket and send the read request to the hosted storage system 220. The hosted storage system 220 can receive the request and determine that the email system is not permitted to read the data objects in the email bucket, due to the lack of an entry for the email system in the data object's ACLs. The hosted storage system 220 can generate a permission denied message specifying that the email system is not permitted to read the data objects and can return the message to the email system.

The storage backend 110 can contain multiple datastores 112a-112c. Although three datastores 112 are shown, more or fewer are possible. Each of the datastores 112a-112c can store data objects 114a-114c in a particular format. For example, data store 112a can store a data object 114a as a Binary Large Object (BLOB), data store 112b can store a data object 114b in a distributed file system (e.g., Network File System), and data store 112c can store a data object 114c in a structured data format such as a database (e.g., MySQL).

FIG. 2 is a flow chart showing an example of a process 200 for storing data in a hosted storage service. The process 200 can be performed by, for example, the interface frontend 106 and the interface backend 110, and for clarity of presentation, the description that follows uses the system 100 as the basis for describing the process. However, another system, or combination of systems, may be used to perform the process 200.

A request is received by the interface frontend 106 from the client application 103 to store an object (202). The request can include a HTTP PUT or POST request, an authentication credential that authenticates the principal (entity) making the request, a data object, and a target for the object consisting of a bucket and data object name. In some examples, the authentication credentials can include an interoperable authentication header, token, or cookie. The interface frontend can make a RPC to the backend 108 including the request headers.

The interface backend 108 can examine and validate the authentication credentials (204). For example, native credentials (e.g., user ID, token) can be validated using internal validation features of the hosted storage service 120. External credentials (e.g., user names and passwords for another system) can be sent to the associated external system for validation.

The interface backend 108 can query the request's target bucket's ACL 118 to determine if the authenticated principal is permitted to create an object in the bucket (206). For example, the principal or a group the principal is a member of can have the WRITE or FULL_CONTROL role assigned in the bucket's ACL 118, which would allow the principal to create an object in the bucket. If the principal is not authorized to create an object, the request is denied.

Otherwise, the interface backend 108 uploads the object to the target bucket with the target data object name to a datastore 112 (208). In some examples, each bucket is associated with only a single datastore 112, and specifying a target bucket specifies a datastore 112. In some examples, the interface backend 108 can examine the data object or use a parameter in the RPC from the interface frontend 106 to determine which datastore 112 to store the object in, with associated metadata 116 indicating the location of the object (that is, the particular datastore the object is stored in and the object's location in that datastore).

The interface backend 108 re-validates the principal's authentication and authorization (210). To support long-running uploads, expiry times of authentication credentials can be temporarily ignored.

The interface backend 108 generates a new document key request to the keystore 109 for a wrapped key for the newly-uploaded object (212). The new wrapped key is tied to the authentication credentials of the principal of the request. The keystore 109 can also supply an encryption key to encrypt the wrapped key. The interface backend 108 encrypts the wrapped key (214).

The interface backend 108 creates an ACL 118 representing the access control list for the newly created object (216). In some example, a default ACL 118 is used or an ACL 118 can be specified by the request from the client 102.

The interface backend 108 generates a new document key request to the keystore 109 for a wrapped key for every principal (user or group) in the ACL 118 with permissions to read the object or modify the object's ACL 118. Each new wrapped key is tied to a single principal. The keystore 109 can also supply an encryption key to encrypt the wrapped keys, or the interface backend 108 can reuse the encryption key from the step 108.

The interface backend 108 stores the object's ACL 118 and wrapped keys in the object's metadata 116. The encryption key or keys can be discarded by the interface backend 108.

FIG. 3 is a flow chart showing an example of a process for providing data in a hosted storage service. The process 300 can be performed by, for example, the interface frontend 106 and the interface backend 110, and for clarity of presentation, the description that follows uses the system 100 as the basis for describing the process. However, another system, or combination of systems, may be used to perform the process 300.

A request is received by the interface frontend 106 from the client application 103 to download an object (302). The request can include a HTTP GET request, an authentication credential that authenticates the principal (entity) making the request, and a target consisting of a bucket (and optionally data object) name. In some examples, the authentication credentials can include an interoperable authentication header, token, or cookie. The interface frontend can make a RPC to the backend 108 including the request headers.

The interface backend 108 examines and validates the authentication credentials included in the request (304). For example, native credentials (e.g., user ID, token) can be validated using internal validation features of the hosted storage service 120. External credentials (e.g., user names and passwords for another system) can be sent to the associated external system for validation.

The interface backend 108 queries the request's bucket or object ACL 118 to determine if the authenticated principal is permitted to read the target (306). For example, the principal or a group the principal is a member of can have the READ, WRITE or FULL_CONTROL role assigned, which would allow the principal to read or otherwise access the target. If the principal is not authorized to read or access the object, the request is denied.

Otherwise, the interface backend 108 determines if the request is for a bucket or for an object (308). If the request is for a bucket, the interface backend 108 queries for a list of the bucket's contents (310) and the listing is returned to the client application 103 (312).

If the request is for an object, the interface backend 108 looks up the appropriate wrapped key for the given authenticated requestor from the object's metadata 116 (314). The interface backend 108 sends the wrapped key and the authentication credentials to the keystore 109, which can return the decrypted object encryption key to the interface backend 108 (316). The interface backend 108 can fetch and decrypt the target object (318) to be returned to the client application 103 (320).

FIG. 4 is a flow chart showing an example lifecycle 400 of an ACL 118. Although the steps of the lifecycle 400 show an order of steps, it is not implied that each step leads directly to another. The steps shown are a listing of possible steps that may be performed on an ACL 118 in roughly chronological order. The actual order, number, and kind of steps will be dependent on implementation details and usage of the hosted storage system 120.

A bucket or object is created by the backend interface 108 based on requests from the client application 103 (402). The client request can include a bucket name, an object name, and/or an ACL 118. The principal requesting the new bucket or object is authenticated and made the owner of the bucket or object.

If an ACL 118 is specified in the request (404), the specified ACL 118 is associated with the bucket or object (406). If the specified ACL 118 does not include a {scope, role} pair specifying the principal having FULL_CONTROL, one such {scope, role} pair can be added to the ACL 118. In one implementation, an ACL may be specified in a request by enumerating each scope and role pair to be included in the ACL, or may be specified by reference to the name of a pre-specified or “canned” ACL. A list of pre-specified or ‘canned’ ACLs 118 is shown in Table 4 Canned ACLs below. The canned ACLs 118 can be cataloged by the hosted storage system 120 and referenced by the client application 103 by name, rather than requiring the request enumerate each scope and role pair.

TABLE 4 Canned ACLs Canned ACL Name {scope, permission} private {creating user or bucket owner, FULL_CONTROL} public-read {all users, READ} {bucket owner, FULL_CONTROL} public-read-write {all users, WRITE} {bucket owner, FULL_CONTROL} authenticated-read {all authenticated users, READ} {bucket owner, FULL_CONTROL} bucket-owner-read {bucket owner, READ} [for objects only] {object owner, FULL_CONTROL} bucket-owner- {bucket owner, FULL_CONTROL} full-control {object owner, FULL_CONTROL} [for objects only]

If an ACL 118 is not specified in the request (404), a default ACL 118 can be used (408). For example, bucket and object creation can default to the “private” canned ACL 118 for authenticated users. For object creation by unauthenticated users, such as for new objects created in a “public-read-write” bucket, a default of “bucket-owner-full-control” can be used.

An ACL 118 can be served, for example, to a principal with READ, WRITE, or FULL_CONTROL of the associated bucket or object (410). For example, a client application 103 can perform a HTTP GET to a target's URI with the query string ?acl to retrieve the ACL associated with the target. The ACL 118 can be serialized and returned to the client application 103.

The serialization may be defined, for example, by the following extended Backus-Naur form. Nonterminals appear in sans serif italics, terminals appear in Courier Bold, { } denote zero or more repetitions, [ ] enclose optional entities, |separates alternatives, and ( ) denote grouping. The terminal symbols canonical-id, email-address, and domain are defined in English below:

access-control-list: <AccessControlList> owner entries </AccessControlList>

owner: <Owner> id </Owner>

entries: <Entries> entry {entry} </Entries>

entry: <Entry> (permission scope|scope permission)</Entry>

permission: <Permission> (READ|WRITE|FULL_CONTROL)</Permission>

scope: <Scope type=UserById> id </Scope>

|<Scope type=UserByEmail> email </Scope>

|<Scope type=GroupById> id </Scope>

|<Scope type=GroupByEmail> email </Scope>

|<Scope type=GroupByDomain> <Domain> domain </Domain> </Scope>

|<Scope type=AllUsers/>

|<Scope type=AllAuthenticatedUsers/>

id: <ID> canonical-id </ID> [<Name> text </Name>]

|[<Name> text </Name>]<ID> canonical-id </ID>

email: <EmailAddress> email-address </EmailAddress> [<Name> text </Name>]

|[<Name> text </Name> ]<EmailAddress> canonical-id </EmailAddress>

text: {printable character excluding <and >}

canonical-id: 64 hex digits

email-address: standard RFC 822 email address

domain: standard RFC 822 domain specification

A canonical-id or an email-address can identify a user or a group. A canonical-id is the encrypted service id for the user or group. Email addresses are a convenience for specifying canonical ids. In some implementations, the ACLs returned from the system always contain canonical ids. The <Name> text</Name> element may be used for information purposes only such that it is otherwise ignored by the system, and the system does not return it if there is no public name associated with the user or group.

An example serialized ACL 118 is shown below.

<AccessControlList>

<Owner>

<ID> a9a7b886d6fd24a52fe8ca5bef65f89a64e0193f23000e241bf9b1c61be666e9</ID>

<Name> chriscustomer</Name>

</Owner>

<Entries>

<Entry> <Permission> FULL_CONTROL</Permission>

<Scope type=UserById>

<ID>a9a7b886d6fd24a52fe8ca5bef65f89a64e0193f23000e241bf9b1c61be666e9</ID>

<Name> chriscustomer</Name>

</Scope>

</Entry>

<Entry> <Permission>FULL_CONTROL</Permission>

<Scope type=UserById>

<ID>79a59d1900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be</ID>

<Name> Frank</Name>

</Scope>

</Entry>

<Entry> <Permission> FULL_CONTROL</Permission>

<Scope type=UserById>

<ID>de019164ebb0724ff67188e243eae9 ccbebdde523717 cc312255d9a82498e394a</ID>

<Name> Jose</Name>

</Scope>

</Entry>

<Entry> <Permission> READ</Permission> <Scope type=AllUsers> </Entry>

</Entries>

</AccessControlList>

An ACL 118 can be updated, for example by a principal with WRITE or FULL_CONTROL of the associated bucket or object (412). In some examples, a client must read, modify, and write an ACL 118 in order to update an ACL 118. In this example, the ACL 118 is served (410) as part of modification (412). In some implementations, a client application 103 can send ACL update requests to the hosted storage system 120.

FIG. 5 shows an example of a computing device 500 and a mobile computing device 550 that can be used to implement the techniques described here. The computing device 500 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The mobile computing device 550 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart-phones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to be limiting.

The computing device 500 includes a processor 502, a memory 504, a storage device 506, a high-speed interface 508 connecting to the memory 504 and multiple high-speed expansion ports 510, and a low-speed interface 512 connecting to a low-speed expansion port 514 and the storage device 506. Each of the processor 502, the memory 504, the storage device 506, the high-speed interface 508, the high-speed expansion ports 510, and the low-speed interface 512, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. The processor 502 can process instructions for execution within the computing device 500, including instructions stored in the memory 504 or on the storage device 506 to display graphical information for a GUI on an external input/output device, such as a display 516 coupled to the high-speed interface 508. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

The memory 504 stores information within the computing device 500. In some implementations, the memory 504 is a volatile memory unit or units. In some implementations, the memory 504 is a non-volatile memory unit or units. The memory 504 may also be another form of computer-readable medium, such as a magnetic or optical disk.

The storage device 506 is capable of providing mass storage for the computing device 500. In some implementations, the storage device 506 may be or contain a computer-readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. Instructions can be stored in an information carrier. The instructions, when executed by one or more processing devices (for example, processor 502), perform one or more methods, such as those described above. The instructions can also be stored by one or more storage devices such as computer- or machine-readable mediums (for example, the memory 504, the storage device 506, or memory on the processor 502).

The high-speed interface 508 manages bandwidth-intensive operations for the computing device 500, while the low-speed interface 512 manages lower bandwidth-intensive operations. Such allocation of functions is an example only. In some implementations, the high-speed interface 508 is coupled to the memory 504, the display 516 (e.g., through a graphics processor or accelerator), and to the high-speed expansion ports 510, which may accept various expansion cards (not shown). In the implementation, the low-speed interface 512 is coupled to the storage device 506 and the low-speed expansion port 514. The low-speed expansion port 514, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

The computing device 500 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server 520, or multiple times in a group of such servers. In addition, it may be implemented in a personal computer such as a laptop computer 522. It may also be implemented as part of a rack server system 524. Alternatively, components from the computing device 500 may be combined with other components in a mobile device (not shown), such as a mobile computing device 550. Each of such devices may contain one or more of the computing device 500 and the mobile computing device 550, and an entire system may be made up of multiple computing devices communicating with each other.

The mobile computing device 550 includes a processor 552, a memory 564, an input/output device such as a display 554, a communication interface 566, and a transceiver 568, among other components. The mobile computing device 550 may also be provided with a storage device, such as a micro-drive or other device, to provide additional storage. Each of the processor 552, the memory 564, the display 554, the communication interface 566, and the transceiver 568, are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate.

The processor 552 can execute instructions within the mobile computing device 550, including instructions stored in the memory 564. The processor 552 may be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor 552 may provide, for example, for coordination of the other components of the mobile computing device 550, such as control of user interfaces, applications run by the mobile computing device 550, and wireless communication by the mobile computing device 550.

The processor 552 may communicate with a user through a control interface 558 and a display interface 556 coupled to the display 554. The display 554 may be, for example, a TFT (Thin-Film-Transistor Liquid Crystal Display) display or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display interface 556 may comprise appropriate circuitry for driving the display 554 to present graphical and other information to a user. The control interface 558 may receive commands from a user and convert them for submission to the processor 552. In addition, an external interface 562 may provide communication with the processor 552, so as to enable near area communication of the mobile computing device 550 with other devices. The external interface 562 may provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces may also be used.

The memory 564 stores information within the mobile computing device 550. The memory 564 can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. An expansion memory 574 may also be provided and connected to the mobile computing device 550 through an expansion interface 572, which may include, for example, a SIMM (Single In Line Memory Module) card interface. The expansion memory 574 may provide extra storage space for the mobile computing device 550, or may also store applications or other information for the mobile computing device 550. Specifically, the expansion memory 574 may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example, the expansion memory 574 may be provide as a security module for the mobile computing device 550, and may be programmed with instructions that permit secure use of the mobile computing device 550. In addition, secure applications may be provided via the SIMM cards, along with additional information, such as placing identifying information on the SIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory (non-volatile random access memory), as discussed below. In some implementations, instructions are stored in an information carrier. that the instructions, when executed by one or more processing devices (for example, processor 552), perform one or more methods, such as those described above. The instructions can also be stored by one or more storage devices, such as one or more computer- or machine-readable mediums (for example, the memory 564, the expansion memory 574, or memory on the processor 552). In some implementations, the instructions can be received in a propagated signal, for example, over the transceiver 568 or the external interface 562.

The mobile computing device 550 may communicate wirelessly through the communication interface 566, which may include digital signal processing circuitry where necessary. The communication interface 566 may provide for communications under various modes or protocols, such as GSM voice calls (Global System for Mobile communications), SMS (Short Message Service), EMS (Enhanced Messaging Service), or MMS messaging (Multimedia Messaging Service), CDMA (code division multiple access), TDMA (time division multiple access), PDC (Personal Digital Cellular), WCDMA (Wideband Code Division Multiple Access), CDMA2000, or GPRS (General Packet Radio Service), among others. Such communication may occur, for example, through the transceiver 568 using a radio-frequency. In addition, short-range communication may occur, such as using a Bluetooth, WiFi, or other such transceiver (not shown). In addition, a GPS (Global Positioning System) receiver module 570 may provide additional navigation- and location-related wireless data to the mobile computing device 550, which may be used as appropriate by applications running on the mobile computing device 550.

The mobile computing device 550 may also communicate audibly using an audio codec 560, which may receive spoken information from a user and convert it to usable digital information. The audio codec 560 may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of the mobile computing device 550. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating on the mobile computing device 550.

The mobile computing device 550 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a cellular telephone 580. It may also be implemented as part of a smart-phone 582, personal digital assistant, or other similar mobile device.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms machine-readable medium and computer-readable medium refer to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term machine-readable signal refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Although a few implementations have been described in detail above, other modifications are possible. For example, while a client application is described as accessing the delegate(s), in other implementations the delegate(s) may be employed by other applications implemented by one or more processors, such as an application executing on one or more servers. In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other actions may be provided, or actions may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.

Claims

1. A method performed by one or more processors, the method comprising:

storing, in a hosted storage system and in association with a storage structure, a first access control list, the first access control list designed to include (i) a control for granting permission to write data objects, each data object including respective metadata and contents, to the storage structure and (ii) a control for granting permission to read metadata of data objects from the storage structure, but designed not to include a control for granting permission to read contents of data objects from the storage structure, wherein the first access control list grants a first user permission to write data objects to the storage structure, and wherein a write operation to write a data object does not include reading contents of the data object stored at the storage structure before writing the data object;
storing, in the hosted storage system and in association with a first data object stored in the storage structure, a second access control list, the second access control list designed to include a control for granting permission to read contents of the first data object, wherein the second access control list grants a second user permission to read the contents of the first data object;
receiving, at the hosted storage system, a write request associated with the first user to write a second data object to the storage structure;
determining, in response to receiving the write request and based on the first access control list, that the first user is permitted to write data objects to the storage structure;
storing the second data object in the storage structure in response to determining the first user is permitted to write data objects to the storage structure;
receiving, at the hosted storage system, a read request from the second user to read the contents of the first data object from the storage structure;
determining, in response to receiving the read request and based on the second access control list, that the second user is permitted to read the contents of the first data object; and
providing the contents of the first data object to the second user in response to determining the second user is permitted to read the contents of the first data object.

2. The method of claim 1, wherein the first access control list grants the first user permission to list the data objects in the storage structure, the method further comprising:

receiving a list request from the first user to list the first data object from the storage structure;
determining, in response to receiving the list request and based on the first access control list, that the first user is permitted to list the first data object; and
providing metadata of the first data object to the first user in response to determining the first user is permitted to list the first data object.

3. The method of claim 1, wherein the first access control list grants the first user permission to modify the first access control list, the method further comprising:

receiving an access control list modification request from the first user to modify the first access control list;
determining, in response to receiving the access control list modification request and based on the first access control list, that the first user is permitted to modify the first access control list; and
modifying the first access control list in response to determining the first user is permitted to modify the first access control list.

4. The method of claim 1, the method further comprising:

receiving a read request from the first user to read the contents of the first data object from the storage structure;
determining, in response to receiving the read request and based on the second access control list, that the first user is not on the second access control list and is not permitted to read the contents of the first data object; and
providing a permission denied message to the first user in response to determining the first user is not permitted to read the contents of the first data object.

5. The method of claim 1, wherein the first user is an administrator of an application and the second user is a consumer of the application.

6. The method of claim 1, the method further comprising:

storing encryption keys for the first data object and the second data object in encrypted form;
in response to determining that the second user is permitted to read the contents of the first object, decrypting the encryption key for the first data object; and
before providing the contents of the first data object to the second user, decrypting the first data object.

7. A computer system comprising:

a hosted storage system configured to: store, in the hosted storage system and in association with a storage structure, a first access control list, the first access control list designed to include (i) a control for granting permission to write data objects, each data object including respective metadata and contents, to the storage structure and (ii) a control for granting permission to read metadata of data objects from the storage structure, but designed not to include a control for granting permission to read contents of data objects from the storage structure, wherein the first access control list grants permission a first user permission to write data objects to the storage structure, and wherein a write operation to write a data object does not include reading contents of the data object stored at the storage structure before writing the data object; store, in the hosted storage system and in association with a first data object stored in the storage structure, a second access control list, the second access control list designed to include a control for granting permission to read contents of the first data object, wherein the second access control list grants a second user permission to read the contents of the first data object; receive, at the hosted storage system, a write request associated with the first user to write a second data object to the storage structure; determine, in response to receiving the write request and based on the first access control list, that the first user is permitted to write data objects to the storage structure; store the second data object in the storage structure in response to determining the first user is permitted to write data objects to the storage structure; receive, at the hosted storage system, a read request from the second user to read the contents of the first data object from the storage structure; determine, in response to receiving the read request and based on the second access control list, that the second user is permitted to read the contents of the first data object; and provide the contents of the first data object to the second user in response to determining the second user is permitted to read the contents of the first data object.

8. The system of claim 7, wherein the first access control list indicates permission to list the data objects in the storage structure; the hosted storage system is further configured to:

receive a list request from the first user to list the first data object from the storage structure;
determine, in response to receiving the list request and based on the first access control list, that the first user is permitted to list the first data object; and
provide metadata of the first data object to the first user in response to determining the first user is permitted to list the first data object.

9. The system of claim 7, wherein the first access control list grants the first user permission to modify the first access control list, the hosted storage system is further configured to:

receive an access control list modification request from the first user to modify the first access control list;
determine, in response to receiving the access control list modification request and based on the first access control list, that the first user is permitted to modify the first access control list; and
modify the first access control list in response to determining the first user is permitted to modify the first access control list.

10. The system of claim 7, the hosted storage system is further configured to:

receive a read request from the first user to read the contents of the first data object from the storage structure;
determine, in response to receiving the read request and based on the second access control list, that the first user is not on the second access control list and is not permitted to read the contents of the second data object; and
provide a permission denied message to the first user in response to determining the first user is not permitted to read the contents of the second data object.

11. The system of claim 7, wherein the first user is an administrator of an application and the second user is a consumer of the application.

12. The system of claim 7, wherein the hosted storage system is further configured to:

store encryption keys for the first data object and the second data object in encrypted form;
in response to determining that the second user is permitted to read the contents of the first object, decrypt the encryption key for the first data object; and
before providing the contents of the first data object to the second user, decrypt the first data object.

13. A non-transitory computer readable medium storing instructions that, when executed by one or more processing devices, cause the one or more processing devices to perform operations including:

storing, in a hosted storage system and in association with a storage structure, a first access control list, the first access control list designed to include (i) a control for granting permission to write data objects, each data object including respective metadata and contents, to the storage structure and (ii) a control for granting permission to read metadata of data objects from the storage structure, but designed not to include a control for granting permission to read contents of data objects from the storage structure, wherein the first access control list grants a first user permission to write data objects to the storage structure, and wherein a write operation to write a data object does not include reading contents of the data object stored at the storage structure before writing the data object;
storing, in the hosted storage system and in association with a first data object stored in the storage structure, a second access control list, the second access control list designed to include a control for granting permission to read contents of the first data object, wherein the second access control list grants a second user permission to read the contents of the first data object;
receiving, at the hosted storage system, a write request from the first user to write a second data object to the storage structure;
determining, in response to receiving the write request and based on the first access control list, that the first user is permitted to write data objects to the storage structure;
storing the second data object in the storage structure in response to determining the first user is permitted to write data objects to the storage structure;
receiving, at the hosted storage system, a read request from the second user to read the contents of the first data object from the storage structure;
determining, in response to receiving the read request and based on the second access control list, that the second user is permitted to read the contents of the first data object; and
providing the contents of the first data object to the second user in response to determining the second user is permitted to read the contents of the first data object.

14. The medium of claim 13, wherein the first access control list grants the first user permission to list the data objects in the storage structure, the operations further include:

receiving a list request from the first user to list the first data object from the storage structure;
determining, in response to receiving the list request and based on the first access control list, that the first user is permitted to list the first data object; and
providing metadata of the first data object to the first user in response to determining the first user is permitted to list the first data object.

15. The medium of claim 13, wherein the first access control list grants the first user permission to modify the first access control list, the operations further include:

receiving an access control list modification request from the first user to modify the first access control list;
determining, in response to receiving the access control list modification request and based on the first access control list, that the first user is permitted to modify the first access control list; and
modifying the first access control list in response to determining the first user is permitted to modify the first access control list.

16. The medium of claim 13, the operations further include:

receiving a read request from the first user to read the contents of the first data object from the storage structure;
determining, in response to receiving the read request and based on the second access control list, that the first user is not on the second access control list and is not permitted to read the contents of the first data object; and
providing a permission denied message to the first user in response to determining the first user is not permitted to read the contents of the first data object.

17. The medium of claim 13, wherein the first user is an administrator of an application and the second user is a consumer of the application.

18. The medium of claim 13, the operations further include:

storing encryption keys for the first data object and the second data object in encrypted form;
in response to determining that the second user is permitted to read the contents of the first object, decrypting the encryption key for the first data object; and
before providing the contents of the first data object to the second user, decrypting the first data object.

19. The method of claim 1, wherein metadata of an object includes a name of the storage structure storing the object, a name of the object, a creation time of the object, an object size, a hash value associated with the object, and an access control list for the storage structure, or an access control list for the object.

20. The system of claim 7, wherein metadata of an object includes a name of the storage structure storing the object, a name of the object, a creation time of the object, an object size, a hash value associated with the object, and an access control list for the storage structure, or an access control list for the object.

21. The medium of claim 13, wherein metadata of an object includes a name of the storage structure storing the object, a name of the object, a creation time of the object, an object size, a hash value associated with the object, and an access control list for the storage structure, or an access control list for the object.

Referenced Cited
U.S. Patent Documents
5335346 August 2, 1994 Fabbio
5778222 July 7, 1998 Herrick et al.
6119230 September 12, 2000 Carter
6529885 March 4, 2003 Johnson
6577734 June 10, 2003 Etzel et al.
6751735 June 15, 2004 Schell et al.
6865555 March 8, 2005 Novak
6947556 September 20, 2005 Matyas et al.
6950819 September 27, 2005 Behera
7136840 November 14, 2006 Pinkas et al.
7319759 January 15, 2008 Peinado et al.
7373517 May 13, 2008 Riggins
7512810 March 31, 2009 Ryan
7600134 October 6, 2009 Catherman et al.
7797399 September 14, 2010 Svendsen
7836080 November 16, 2010 DeBie
7913300 March 22, 2011 Flank et al.
7984066 July 19, 2011 Kilday et al.
8024559 September 20, 2011 Jung et al.
8046509 October 25, 2011 Bondurant
8086637 December 27, 2011 Tsai et al.
8295490 October 23, 2012 McCoy et al.
8307067 November 6, 2012 Ryan
8307455 November 6, 2012 Takahashi et al.
8370388 February 5, 2013 Kilday et al.
8555403 October 8, 2013 Kilday
8719903 May 6, 2014 Kilday
20020073113 June 13, 2002 Caraher et al.
20020138843 September 26, 2002 Samaan et al.
20030088786 May 8, 2003 Moran et al.
20040107342 June 3, 2004 Pham et al.
20050081066 April 14, 2005 Lahdensivu et al.
20060005261 January 5, 2006 Sukigara et al.
20060026425 February 2, 2006 Douceur et al.
20070005595 January 4, 2007 Gafter
20070156842 July 5, 2007 Vermeulen et al.
20070255743 November 1, 2007 Gaucas
20080148339 June 19, 2008 Hill et al.
20080155652 June 26, 2008 DeBie
20080301783 December 4, 2008 Abrutyn et al.
20090049120 February 19, 2009 Sakairi et al.
20090055397 February 26, 2009 Man et al.
20090240907 September 24, 2009 Crandell
20090327706 December 31, 2009 Ikeda et al.
20100017596 January 21, 2010 Schertzinger
20110191858 August 4, 2011 Shapiro et al.
20110270833 November 3, 2011 von Kaenel et al.
20110271353 November 3, 2011 Li et al.
20110302211 December 8, 2011 Kilday et al.
20140075573 March 13, 2014 Kilday
Other references
  • Office Action for U.S. Appl. No. 13/110,361 dated Dec. 20, 2012, 15 pages.
  • Office Action for U.S. Appl. No. 13/245,393dated Jan. 25, 2012, 16 pages.
  • Office Action for U.S. Appl. No. 13/245,393 dated May 29, 2012, 20 pages.
  • Office Action for U.S. Appl. No. 13/110,306, dated Mar. 15, 2013, 18 pages.
  • Office Action for U.S. Appl. No. 13/110,323, dated Mar. 20, 2013, 18 pages.
  • Office Action for U.S. Appl. No. 13/110,336, dated Mar. 18, 2013, 17 pages.
  • Seitz et al., “Key Management for Encrypted Data Storage in Distributed Systems,” in Proceedings of the 2nd Security in Storage Workshop (SISW), 2003, 11 pages.
  • Kher and Kim, “Securing distributed storage: challenges, techniques, and systems,” Proceedings of the 2005 ACM workshop on Storage security and survivability, Nov. 11-11, 2005, 17 pages.
  • Shankar, “Security and Data Integrity in Google Health,” Powerpoint, May 2010, 30 pages.
  • Office Action for U.S. Appl. No. 13/245,393 dated Apr. 25, 2014, 38 pages.
Patent History
Patent number: 8886907
Type: Grant
Filed: May 18, 2011
Date of Patent: Nov 11, 2014
Assignee: Google Inc. (Mountain View, CA)
Inventors: Michael F. Schwartz (Seattle, WA), David R. Hanson (Redmond, WA), Brian N. Bershad (Seattle, WA), David Erb (Seattle, WA)
Primary Examiner: Sheng-Jen Tsai
Application Number: 13/110,297
Classifications
Current U.S. Class: Access Limiting (711/163)
International Classification: G06F 12/00 (20060101); G06F 13/00 (20060101); G06F 13/28 (20060101);