Secure policy distribution in cloud environments, methods, systems, and programs

Abstract

A method is provided for secure policy distribution to a cloud system. The method includes defining an access policy for a set of resources on a cloud computing system, the access policy including rules for enabling access to the set of resources. The method further includes creating an activation function and attribute metadata in the cloud computing system based on the access policy, the attribute metadata including a set of access attributes for each resource in the set of resources. The method also includes receiving a request to access a first resource in the set of resources, the request including a set of credentials. The method includes comparing the set of credentials with the set of access attributes by the activation function. The method further includes processing the request to access the first resource based on the comparing.

Description

[Technical Field]

[0001] The present disclosure relates to access control, and more particularly to secure policy distribution for scaling cloud services. [Background technology]

[0002] Modern cloud computing systems can be very large, very complex, and very demanding environments. Reliability and scalability are two factors that can affect the adoption and / or efficiency of cloud systems. As the number of users and / or services provided increases, the risk of breaches and / or performance issues also increases. Summary of the Invention

[0003] A computer-implemented method for secure policy distribution across a cloud system is disclosed. The method includes defining an access policy for a set of resources on a cloud computing system, the access policy including rules for enabling access to the set of resources. The method further includes creating an activation function and attribute metadata within the cloud computing system based on the access policy, the attribute metadata including a set of access attributes for each resource in the set of resources. The method also includes receiving a request to access a first resource in the set of resources, the request including a set of credentials. The method includes comparing the set of credentials with the set of access attributes via the activation function. The method further includes processing the request to access the first resource based on the comparison. Further aspects of the present disclosure are directed to systems and computer program products including functionality consistent with the above-described methods.

[0004] This summary is not intended to describe each aspect, every implementation, or every embodiment, or combination, of the present disclosure.

[0005] Various embodiments are described herein with reference to different subject matter. In particular, some embodiments may be described with reference to methods, while other embodiments may be described with reference to devices and systems. Nevertheless, those skilled in the art will know from the above and following description that, unless otherwise indicated, any combination of features belonging to one type of subject matter, as well as any combination between features relating to different subject matters, particularly between method features and device and system features, is considered to be disclosed in this document.

[0006] The above-defined aspects, and further aspects disclosed herein, will be apparent from and will be elucidated with reference to one or more example embodiments to be described hereinafter, without the invention being limited thereto. Various embodiments are described, by way of example only, and with reference to the following drawings, in which: [Brief explanation of the drawings]

[0007] [Figure 1] 1 is a diagram of a cloud computing environment in accordance with an embodiment of the present invention. [Figure 2] FIG. 2 is a diagram of abstraction model layers according to an embodiment of the present invention. [Figure 3] FIG. 1 is a block diagram of a DPS according to one or more embodiments disclosed herein. [Figure 4] FIG. 1 is a functional diagram of a computing environment suitable for secure policy distribution within a cloud system, according to some embodiments of the present disclosure. [Figure 5] 1 is a flowchart of an example method for securely distributing access policies within a cloud system, according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0008] General Cloud Computing Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings recited herein is not limited to cloud computing environments. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

[0009] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal administrative effort or interaction with the service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0010] The characteristics are as follows:

[0011] On-demand self-service: Cloud customers can unilaterally provide computing capacity, such as server time and network storage, automatically as needed, without the need for human interaction with the service provider.

[0012] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and personal digital assistants (PDAs)).

[0013] Resource Pooling: Provider computing resources are pooled to serve multiple consumers using a multi-tenant model, with various physical and virtual resources dynamically allocated and reallocated according to demand. Location independence is meant in that consumers generally have no control or knowledge of the exact location of the resources provided, but may specify location at a higher level of abstraction (e.g., country, state, or data center).

[0014] Rapid Elasticity: Capacity can be rapidly and elastically provisioned, sometimes automatically, to quickly scale out, and rapidly released to quickly scale in. To the consumer, the capacity available for provisioning often appears unlimited, and can be purchased at any time and in any quantity.

[0015] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at several levels of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource utilization can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services used.

[0016] The service model is as follows:

[0017] Software as a Service (SaaS): The consumer is provided with the ability to use the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface, such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or possibly individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0018] Platform as a Service (PaaS): The ability provided to a consumer is to deploy consumer-created or acquired applications, created using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but rather exercises control over the deployed applications and, in some cases, the application hosting environment configuration.

[0019] Infrastructure as a Service (IaaS): The capability provided to a customer is the provision of processing, storage, networking, and other basic computing resources on which the customer can deploy and run any software, which may include operating systems and applications. The customer does not manage or control the underlying cloud infrastructure, but rather exercises control over the operating systems, storage, deployed applications, and, in some cases, limited control over selected networking components (e.g., host firewalls).

[0020] The deployment model is as follows:

[0021] Private Cloud: The cloud infrastructure is operated solely for the organization. The cloud infrastructure may be managed by the organization or a third party and may be on-site or off-site.

[0022] Community Cloud: Cloud infrastructure is shared by several organizations and supports a unique community of shared concerns (e.g., mission, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by the organization or a third party and may be on-site or off-site.

[0023] Public Cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by organizations that sell cloud services.

[0024] Hybrid Cloud: A cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain unique entities but are tied together by standard or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0025] Cloud computing environments are service-oriented, with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0026] Referring now to FIG. 1, an illustrative cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud users, such as, for example, a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, may communicate. The nodes 10 may also communicate with each other. The nodes 10 may be physically or virtually grouped in one or more networks (not shown), such as a private, community, public, or hybrid cloud, or combinations thereof, as described above. This enables the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service without the cloud user having to maintain resources on their local computing device. It is understood that the types of computing devices 54A-N shown in FIG. 1 are intended to be illustrative only, and that computing node 10 and cloud computing environment 50 can communicate with any type of computerized device over any type of network and / or network-addressable connection (e.g., using a web browser).

[0027] Referring now to Figure 2, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 1) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 2 are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0028] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (reduced instruction set computer) architecture-based servers 62, servers 63, blade servers 64, storage devices 65, and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0029] The virtualization layer 70 provides an abstraction layer in which examples of virtual entities are provided, such as virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0030] In one example, management layer 80 may provide the functions described below. Resource provisioning 81 dynamically procures computing and other resources utilized to perform tasks within the cloud computing environment. Metering and pricing 82 tracks costs as resources are utilized within the cloud computing environment and bills or invoices for the usage of these resources. In one example, these resources may include application software licenses. Security validates cloud subscribers and tasks and protects data and other resources. User portal 83 provides subscribers and system administrators with access to the cloud computing environment. Service level management 84 allocates and manages cloud computing resources to ensure required service levels are met. Service level agreement (SLA) planning and fulfillment 85 pre-provisions and procures cloud computing resources to anticipate future requirements according to SLAs.

[0031] The workload layer 90 provides examples of functions for which cloud computing environments are utilized. Examples of workloads and functions provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and object-based encryption 96.

[0032] General Data Processing System

[0033] 3 is a block diagram of an example data processing system (DPS) according to one or more embodiments. The DPS may be used as a cloud computing node 10. In this illustrative example, the DPS 100 may include a communication bus 102, which may provide communication between a processor unit 104, a memory 106, persistent storage 108, a communication unit 110, an input / output (I / O) unit 112, and a display 114.

[0034] Processor unit 104 functions to execute instructions for software loaded into memory 106. Processor unit 104 may be several processors, a multi-core processor, or some other type of processor, depending on the particular implementation. As used herein while referring to an item, a number means one or more items. Furthermore, processor unit 104 may be implemented using several heterogeneous processor systems, in which a main processor resides on a single chip along with secondary processors. As another illustrative example, processor unit 104 may be a symmetric multiprocessor system including multiple processors of the same type.

[0035] Memory 106 and persistent storage 108 are examples of storage devices 116. A storage device may be any hardware capable of storing information, such as, without limitation, data, functional program code, or other suitable information, or a combination thereof, on a temporary or permanent basis. Memory 106, in these examples, may be, for example, random access memory or any other suitable volatile or non-volatile storage device. Persistent storage 108 may take various forms depending on the particular implementation.

[0036] For example, persistent storage 108 may include one or more components or devices. For example, persistent storage 108 may be a hard drive, flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by persistent storage 108 may also be removable. For example, a removable hard drive may be used for persistent storage 108.

[0037] The communication unit 110 in these examples may provide for communication with other DPSs or devices. In these examples, the communication unit 110 is a network interface card. The communication unit 110 may communicate using either or both physical and wireless communication links.

[0038] The input / output unit 112 may allow for the input and output of data with other devices connected to the DPS 100. For example, the input / output unit 112 may provide a connection for user input through a keyboard, a mouse, or some other suitable input device, or a combination thereof. Additionally, the input / output unit 112 may send output to a printer. The display 114 may provide a mechanism for displaying information to a user.

[0039] Instructions for the operating system, applications, and / or programs may be located in storage device 116, which is in communication with processor unit 104 through communications bus 102. In these illustrative examples, the instructions are in functional form on persistent storage 108. These instructions may be loaded into memory 106 for execution by processor unit 104. The processes of the different embodiments may be performed by processor unit 104 using computer-implemented instructions located in a memory, such as memory 106.

[0040] These instructions are referred to as program code, computer usable program code, or computer readable program code, which may be read and executed by a processor in processor unit 104. The program code in the different embodiments may be embodied on different physical or tangible computer readable media, such as memory 106 or persistent storage 108.

[0041] Program code 118 may be located in a functional form on computer-readable medium 120, which is selectively removable, and may be loaded or transferred to DPS 100 for execution by processor unit 104. Program code 118 and computer-readable medium 120, in these examples, may form computer program product 122. In one example, computer-readable medium 120 may be computer-readable storage medium 124 or computer-readable signal medium 126. Computer-readable storage medium 124 may include, for example, an optical or magnetic disk inserted into or placed in a drive or other device that is part of persistent storage 108 for transfer to a storage device, such as a hard drive that is part of persistent storage 108. Computer-readable storage medium 124 may also be a form of persistent storage, such as a hard drive, thumb drive, or flash memory, connected to DPS 100. In some cases, computer-readable storage medium 124 may not be removable from DPS 100.

[0042] Alternatively, program code 118 may be transported to DPS 100 using computer-readable signal medium 126. Computer-readable signal medium 126 may be, for example, a propagated data signal containing program code 118. For example, computer-readable signal medium 126 may be an electromagnetic signal, an optical signal, or any other suitable type of signal, or a combination thereof. These signals may be transmitted over communications links, such as wireless communications links, fiber optic cable, coaxial cable, a wire, or any other suitable type of communications link, or a combination thereof. In other words, communications links and / or connections may be physical or wireless, in illustrative examples.

[0043] In some demonstrative embodiments, program code 118 may be downloaded to persistent storage 108 via computer-readable signal medium 126 from another device or DPS over a network for use within DPS 100. For example, program code stored on a computer-readable storage medium of a server DPS may be downloaded from the server over a network to DPS 100. The DPS providing program code 118 may be a server computer, a client computer, or some other device capable of storing and transmitting program code 118.

[0044] The different components illustrated for DPS 100 are not intended to provide architectural limitations to the manner in which different embodiments may be implemented. Different illustrative embodiments may be implemented in a DPS that includes components in addition to or instead of those illustrated for DPS 100. Other components are shown in FIG.

[0045] Modern cloud computing systems can be very large, very complex, and very demanding environments. Reliability and scalability are two factors that can affect the adoption and / or efficiency of cloud systems. As the number of users and / or services provided increases, so does the risk of violations and / or performance issues. For example, scaling up a service or adding a second service requires allocating additional computing resources (e.g., servers, hard drives, processors, etc.) to perform the function. Additionally, most current implementations have resource storage and authorization as separate services. To perform a cloud function, there is an additional step of sending the authorization function to an access control system (ACS) to validate access and then returning authorization to complete the function. In many systems, the ACS is remote, such as a separate cloud system. This can introduce potential bottlenecks and increase the cost of scaling and adding services. The bottleneck could be based on bandwidth between the authorization system and / or the main cloud system. To scale, not only do the main services need to be scaled, but the connections and hardware also need to authenticate the additional requests.

[0046] Additionally, the extra data transport can increase security / trust issues. In many current systems, policies defined in the ACS are not encrypted, which leaves the policy data potentially vulnerable. If a bad actor gains access to a request, the system may attribute the user to an access level equivalent, potentially subjecting a few high-access users to phishing attacks. Embodiments of the present disclosure can alleviate some of the above-mentioned problems.

[0047] Embodiments of the present disclosure include systems and / or methods for secure policy distribution within cloud services. This can include defining a new metadata structure that includes policies for granting access to data. In some embodiments, the new metadata structure includes metadata objects attached to resources, and the policies can be specific to the data definition. In some embodiments, the new metadata structure can be encrypted, allowing resource authorization functions to access assets. One method can be attribute-based encryption.

[0048] Embodiments of the present disclosure may include an authorization function that scales efficiently in proportion to the resources it commands. A system using the authorization function is persistent, secure, and can be used across various cloud systems. The authorization function can be processed by any resource access node within the cloud system.

[0049] In some embodiments, the authorization functionality can be utilized by a resource management node, such as an accessor. An accessor can be a component that manages access to data / functions in a cloud computing environment. In some embodiments, the accessor can operate in conjunction with an access control system (ACS). An ACS can be one or more policies that define rules for granting access to data and / or permissions to use / process the data.

[0050] In some embodiments, the accessor can enforce access policies. The access policies can be stored in the ACS. The access policies can define access requirements for data / functions within a cloud system / database. Policies can be defined for any level of specificity and with any number of attributes at each level. For example, for object-based storage, there can be database-level, bucket-level, and object-level attributes. In some embodiments, the access policies can be defined by the data owner.

[0051] In some embodiments, an accessor can send and receive access data to and from a cloud system / database. Access attributes (or metadata attributes) can be stored as metadata in the remote system, and the attributes are encrypted by an encryption engine. Therefore, even if part of the system is compromised, no information about the security policy can be gleaned. In some embodiments, the data owner can send / push encrypted access data to the cloud system. Therefore, the cloud provider cannot access the encrypted policy information. The cloud provider can only perform enforcement functions. This can improve the overall trustworthiness of the cloud system. In some embodiments, the access attributes can be used in a hashing function to prove possession of the attributes and eliminate the need to pass a token with this sensitive data over the client request channel.

[0052] In some embodiments, an accessor receives a request to perform a function on a cloud system / database. In some embodiments, the request includes an authorization certificate. The certificate can include one or more attributes. Attributes can be data that defines information about the request. Information can include account, user, role, time, location, action to be performed, target data / resource, and the like. In some embodiments, the accessor can compare / evaluate the attributes of the received certificate with an authorization function using policies in the source's metadata. If the authorization function is successful, access will be granted. If any attributes are missing, the authorization function fails and access to the resource is denied.

[0053] The aforementioned advantages are examples of advantages, and there are embodiments that can include all, some, or none of the aforementioned advantages while still being within the scope of this disclosure.

[0054] Referring now in more detail to various embodiments of the present disclosure, Figure 4 is a representation of a computing environment 400 capable of executing accessor / activation function / policy enforcement functionality in accordance with one or more embodiments of the present disclosure. Many modifications to the depicted environment may be made by one skilled in the art without departing from the scope of the present disclosure.

[0055] Computing environment 400 includes a host 410, a database 430, and a network 440. Network 440 can be, for example, a telecommunications network, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the three, and can include wired, wireless, or fiber optic connections. Network 440 may include one or more wired and / or wireless networks capable of receiving and transmitting data, voice, and / or video signals, including multimedia signals including voice, data, and video information. In general, network 440 may be any combination of connections and protocols that support communication between and among host 410, database 430, and other computing devices (not shown) within computing environment 400. In some embodiments, each of hosts 410 and database 430 may include one or more computer systems, such as data processing system 100 of FIG. 3.

[0056] Host 410 may be a standalone computing device, a management server, a web server, a mobile computing device, or any other electronic device or computing system capable of receiving, transmitting, and processing data. In other embodiments, host 410 may represent a server computing system that utilizes multiple computers as a server system, such as in a cloud computing environment (e.g., cloud computing environment 50). In some embodiments, host 410 includes application 412. In some embodiments, host 410 may submit a request for a cloud service that includes a certificate. The certificate may have / include one or more attributes that define data about the request. The attributes may relate to the account, the user, the account level, the time of the request, the location of the request, and the like.

[0057] Application 412 can be any combination of hardware and / or software configured to perform functions on a computing device (e.g., host 410). In some embodiments, application 412 is a web application. In some embodiments, application 412 can be configured to access / process data stored in database 430. Application 412 can be an account-based application. A user or group of users can access data using one or more accounts. Access to processes / data can be based on one or more attributes of each account. In some embodiments, application 412 can be configured to perform one or more functions on a cloud computing network (e.g., cloud computing environment 50 shown in FIG. 1). In some embodiments, application 412 can generate a request for a cloud service. The request can include a certificate that matches the certificate of host 410. There can also be a certificate based application.

[0058] Database 430 can be any combination of hardware, software, or both configured to store data. Database 430 includes ACS 420, metadata 434, accessors 431, buckets 432, objects 433(1), objects 433(2), and up to object 433(n), where n can be an integer representing the object. For application purposes, objects 433(1), objects 433(2), and up to object 433(n) can be referred to together, separately, individually, or in any combination thereof as objects 433.

[0059] In some embodiments, database 430 includes object storage or an object-based storage architecture (or object store). Object storage is a data storage architecture that manages data as objects. Object storage can allow large amounts of unstructured data to be stored as a single unit / object.

[0060] In some embodiments, database 430 includes a file system architecture. A file system architecture can manage data as a hierarchy. Each level and / or branch of the hierarchy can be assigned one or more attributes to enable access / processing of the data in that particular portion of the file system. In some embodiments, database 430 includes a block storage architecture. A block storage architecture can manage data based on where the data is stored on a storage device. The device can be separated into any number of blocks and / or sub-tiers within the blocks (e.g., tracks, extents, etc.). Each block and / or sub-tier can be correlated with one or more attributes to enable access. In some embodiments, database 430 can be a relational database. A relational database can store data in one or more tables, with each table having columns and rows. Generally, columns will contain similar types of data, and all data in a common row is related to each other column in the same row. There can also be relationships between two or more tables. In some embodiments, attributes can be correlated to tables, rows, columns, and / or partitions of a relational database to enable access to the data. In some embodiments, database 430 can include metadata that defines the attributes that enable access to the database. Attributes can be defined by ACS 420, received from ACS 420, or both.

[0061] Database 430 is one embodiment of a resource in a cloud system that can utilize the functionality of the present disclosure. In some embodiments, database 430 can be a cloud system that has resources available to remote users. The resources can be any functionality of the cloud system, including performing various API functions and other predetermined functions. Various functions can replace subcomponents of database 430. For example, bucket 432 and object 433 can be replaced with different functions / actions. In some embodiments, ACS 420, metadata 434, and accessor 431 can exist in any cloud system and be used to implement the benefits of the present disclosure.

[0062] ACS 420 can be any combination of hardware, software, or both configured to control access to applications and / or data. The application can be application 412. The data can be stored in database 430. In some embodiments, ACS 420 can be defined and / or updated by a data owner. ACS 420 can include rules to dictate how data and / or resources can be utilized. In some embodiments, ACS 420 includes accounts 421, roles 422, policies 423, and encryption engine 424. In some embodiments, ACS 420 can be fully integrated into database 430 and / or accessor 431. For example, a data owner can access database 430 to update and / or define security policies. This integration can provide many of the benefits of the present disclosure. This integration eliminates the need for access to a remote ACS, which can increase scaling costs and create potential bottlenecks and other availability and service issues.

[0063] An account 421 can be a set of credentials used to perform a function, access data, or both. There can be any number of accounts 421 with ACS 420. New accounts can be created, or old accounts can be disabled / deleted, or both. Each account in accounts 421 can be associated with a particular user, group, entity (e.g., business), department, and the like. Accounts 421 can be accessed by properly entering the credentials associated with each account. In some embodiments, accounts 421 are associated with one or more attributes. In some embodiments, information about an account / user can be used as one or more credentials.

[0064] Role 422 can be an attribute of account 421. There can be any number of roles within ACS 420. In some embodiments, each role has a defined set of attributes / credentials. The attributes enable access to one or more databases, data types, functions, applications, and the like. In some embodiments, each account can be associated with at least one role. Depending on the configuration, an account can have two or more roles associated with it or simply a single role. In some embodiments, roles are hierarchical. Each role can have at least as many permissions / attributes as lower-level roles. For example, there can be a basic user, a supervisory user, and an administrator. An administrator can perform all functions and access all data, a subset of the supervisory role, the administrator, and a smaller subset of the basic user and supervisory roles. In some embodiments, roles can be associated with actions / functions. For example, there can be a role for each type of data manipulation, or application that uses data, or both. In some embodiments, roles can be associated with categories of users of the data. For example, one role can be a data owner and a data user, where the data owner can add and remove data, and the data user can only view data.

[0065] Policy 423 can be rules / definitions for managing data. Policy 423 can include any number of attributes. The policy can control when and how data is accessed. Attributes can be based on one or more of location, account, user, title, time, date (e.g., weekends, holidays, and weekdays can have different attributes), intended usage, frequency of access, and the like. In some embodiments, policy 423 can define attributes that must be present in an access request to enable access to the cloud system.

[0066] In some embodiments, there is overlap between roles 422 and policies 423. In some embodiments, roles 422 and policies 423 can be combined into a single attribute list. The attribute list can include each condition under which an account / user can access various data. In some embodiments, attributes can be defined at any level of granularity.

[0067] The encryption engine 424 can be any combination of hardware and / or software configured to encrypt and decrypt data. In some embodiments, the encryption engine 424 can reside in the host 410 and / or database 430, along with the ACS 420. In some embodiments, the encryption engine 424 can use attribute-based encryption (ABE). ABE is a type of public key encryption in which the private key depends on attributes of the requester.

[0068] Metadata 434 can be a set of metadata configured to encapsulate access control to data in database 430. In some embodiments, each level in database 430 can include a unique set of metadata 434. For example, there can be separate metadata for database 430 as a whole, for buckets 432, and for objects 433. In some embodiments, metadata 434 can be incorporated into one or more buckets 432, objects 433, or any other level / function within database 430. In other words, each component in database 430 can include a set of metadata 434 configured specifically for the component, and the set of metadata 434 is attached to the component. The metadata can include policy attributes that define how access to the resource can be granted.

[0069] In some embodiments, metadata 434 may include one or more attributes that define access to each object / level in database 430. In some embodiments, the attributes may be received from ACS 420 and may be based on one or more of accounts 421, roles 422, and policies 423.

[0070] In some embodiments, attributes may be based on the architecture of database 430. For example, in a relational database, attributes may be table and / or column specific.

[0071] Accessor 431 can be any combination of hardware, software, or both configured to enable access to data in database 430. In some embodiments, accessor 431 can compare the credentials received along with a request for access to a set of attributes of the requested data / function to determine whether access is appropriate. The comparing can include / be performed by an authorization function. If the attributes all match the credentials, access can be granted. In some embodiments, if any of the attributes do not match, access can be denied. In some embodiments, accessor 431 includes authorization function 435. In some embodiments, accessor 431 can identify one or more target resources based on the request and identify corresponding attributes and / or authorization functions.

[0072] Authorization function 435 can be any combination of hardware, software, or both configured to determine whether a request is allowed or denied. In some embodiments, accessor 431 includes one or more authorization functions 435. There can be a unique authorization function for each unique set of attributes that defines access to any resource in database 430. Thus, more than one authorization function can be utilized to access a single object. For example, there can be a unique set of attributes required to access database 430, a second set for accessing bucket 432, and a third set for object 433. Accessor 431 can compare the certificate to a separate authorization function three times, with each set of attributes corresponding to a separate authorization function. In some embodiments, two or more resources can share the same set of attributes. For example, a first bucket and a second bucket can use the same set of attributes and authorization function. As another example, a bucket and one or more objects within the bucket can share the same set of attributes.

[0073] In some embodiments, authorization function 435 may include one or more definitions of attributes required to access database 430 and / or components within database 430. In some embodiments, attributes from a subset of the attributes defined in ACS 420 are included in the function. Authorization function may include attributes such as the account the user is using, the role assigned to the account, the location of creation, the time of creation (date and / or time), and the intended action (e.g., view, add, delete, etc.).

[0074] In some embodiments, the authorization function may include one or more definitions of attributes required to access database 430, or components within database 430, or both.

[0075] Bucket 432 can be a data organization tool. In some embodiments, database 430 can include one or more buckets 432. In some embodiments, bucket 432 can be a container for storing one or more data objects. Bucket 432 can be defined based on one or more attributes. Attributes can be used to allow / deny actions to be performed / access to objects in the bucket. This can include permissions to add and / or remove objects from bucket 432. In some embodiments, attributes are included in metadata for bucket 432. Metadata can be received from ACS 420. Metadata can be based on one or more of accounts 421, roles 422, and policies 423.

[0076] Objects 433 can be a collection of data that represents files. Each object can include a unique identifier, some amount of metadata, and the data that forms the object. An object can be any type of file (e.g., a word processing document, a spreadsheet, a photo, a video, etc.). Each object 433 can include attribute metadata. The attribute metadata can be received from ACS 420. The attribute metadata can be defined when access to the data in the object is enabled. The metadata can be based on one or more of accounts 421, roles 422, and policies 423.

[0077] 5 depicts a flowchart of an example method 500 for scalable access management of data that may be implemented in a computing environment (e.g., computing environment 400 and / or cloud computing environment 50). One or more of the above-described advantages and improvements for scalable access management may be achieved by method 500 consistent with various embodiments of the present disclosure.

[0078] Method 500 can be implemented by one or more processors, hosts 410, applications 412, ACS 420, accounts 421, roles 422, policies 423, encryption engines 424, databases 430, accessors 431, buckets 432, objects 433, metadata 434, and / or different combinations of hardware, software, or both. In various embodiments, various operations of method 500 are performed by one or more of host 410, applications 412, ACS 420, accounts 421, roles 422, policies 423, encryption engines 424, databases 430, accessors 431, buckets 432, objects 433, metadata 434. For purposes of illustration, method 500 will be described as being performed by accessor 431.

[0079] In operation 502, accessor 431 defines an access policy. In some embodiments, the access policy may be defined in ACS 420. The access policy may dictate data stored in the cloud computing system, or functions performed on the cloud computing system, or both. In some embodiments, the policy may include accounts 421, roles 422, or policies 423, or a combination thereof.

[0080] In some embodiments, an access policy defines attributes and / or credentials that must be present in a request to enable access to data / functions. Each piece of data can have any number of attributes based on the architecture. Data can be separated and have the same or different attributes at any granularity. For example, in an object-based storage architecture, attributes can be set at the database, bucket, object, or any other level in the storage hierarchy, or a combination thereof. In a relational database, attributes can be at the database, partition, table, column, or row level, or a combination thereof. Any number of attributes can be defined for any level. In some embodiments, attributes are defined by the data owner. Policies / attributes can be updated by the data owner at any time.

[0081] In some embodiments, operation 502 includes defining one or more authorization functions. There can be any number of authorization functions. In some embodiments, the number of authorization functions can be the same as the number of unique sets of attributes defined to enable access to various resources.

[0082] In operation 504, the accessor 431 stores the defined attributes / policies in a database. In some embodiments, the attributes are stored as metadata. There can be unique / separate metadata for each level / object / application in the cloud system. In some embodiments, the metadata can be stored along with the target data. For example, in object storage, metadata is already used to define the object. The attribute metadata can be added to the existing metadata. The policy / attribute metadata can include the same encryption and security standards as the object. In some embodiments, operation 504 includes attaching per-resource attributes to the resource as metadata. This can include authorization functions. In some embodiments, the attributes / policies can be encrypted. The encryption process can be performed by the encryption engine 424.

[0083] In operation 506, accessor 431 receives a request to access a resource in the cloud system. In some embodiments, the request / query is configured to utilize data in a database (e.g., database 430). In some embodiments, the request can be directed to any resource in any node of the cloud system. The data can be stored and / or located in the cloud computing system (e.g., remote from the source of the request). The utilization can be access, view, update, add, delete, or other action using the data, or a combination thereof. In some embodiments, the request can include a set of credentials. The set of credentials can include any number of attributes. The credentials (or certificate attributes) can be information about the source of the request. The information can include the account, the user, the account role, the requested time, the function to be performed, and the like. In some embodiments, the set of credentials is based on data in ACS 420.

[0084] In some embodiments, operation 506 includes identifying each requested resource. In some embodiments, operation 506 includes identifying each set of attributes that must be checked to grant access to the resource. For example, a single request may request access to a service, to a bucket, and to a function. Each of these may have a different set of attributes attached. Accessor 431 may determine that there will be three sets of attributes to check against the certificate.

[0085] In operation 508, accessor 431 determines whether each of the attributes in the authorization function is included in the certificate of the request. In some embodiments, the determination is based on comparing the certificate in the request with attributes of the data (e.g., attribute metadata). In some embodiments, the comparing includes a hash function. The certificate can be a key to the hash function, and the key identifies whether hashed with the attributes to indicate proof of possession of the correct certificate. If each of the requested attributes in the attribute metadata is included in the certificate, access can be granted. It is possible to put more certificates in the request than are required to access the data. For example, the request can include a time certificate, but the policy does not define any time for access. In some implementations, the security attributes can be set to arbitrary values, so that extra certificates do not unintentionally block access.

[0086] If it is determined that the request attribute matches the metadata attribute (508: yes), accessor 431 proceeds to operation 510. If it is determined that the request attribute does not match the metadata attribute (508: no), accessor 431 proceeds to operation 512.

[0087] In operation 510, the accessor 431 allows the request to be fulfilled. In some embodiments, operation 510 may include returning the results of the request to the source, granting access to the cloud service, or both.

[0088] In operation 512, accessor 431 denies / prevents the request from being fulfilled. In some embodiments, the denial may include returning an indication of denial, which may include an error message, a denial message, or returning nothing, or a combination thereof.

[0089] In some embodiments, method 500 can be separated into two or more separate methods. For example, operations 502 and 504 can be a first method, and the remaining operations can be a second method. Thus, a data owner can define a policy and send it to two or more different databases / cloud systems. This can be useful if the data owner uses multiple cloud providers, or if the data owner desires different security standards and processes on different databases, or both. In another example, it can be possible for the first method to be performed once, and the second method to be used several times per request. When the policy is updated / redefined, new attribute metadata can be sent to the cloud system, and the second method continues with the new data.

[0090] In some embodiments, several iterations of various operations may be performed. For example, if a request requires access to a service, bucket, and object, each having a unique set of attributes, the certificate would be checked against each set of attributes. In some embodiments, the accessor 431 starts at the top level, and if access is granted, the accessor may repeat operations 506-510 for each unique set of attributes.

[0091] Method 500 can provide several benefits. One benefit is that method 500 does not require (or eliminates) the need to contact ACS 220 when a request is received. This can provide scalability for the cloud system. If ACS 420 had to be contacted, the bandwidth and capacity for validating appropriate access at ACS 420 would also need to be scaled up as usage / services in the cloud system increased. Sending the attributes as metadata to the cloud system can improve scalability. The cost of adding metadata is essentially zero compared to upgrading the bandwidth and processing to enable appropriate access on the remote system.

[0092] Another advantage of the various embodiments described herein is that they provide improved security and reliability. Attribute metadata can be encrypted with a key controlled by the data owner. Thus, if there is any breach of the system, portions of the policy, including the request and the source of the request, can be encrypted. Having to invoke a remote ACS 420 may leave portions of the policy unencrypted. If this data is obtained fraudulently, it could be used to identify phishing targets, among other undesirable consequences.

[0093] Computer Technology and Computer-Readable Media The present invention may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0094] A computer-readable storage medium can be a tangible device capable of retaining and storing instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures having instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein should not be construed as being signals that are transitory in nature, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted through wires.

[0095] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0096] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++, or the like, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer readable program instructions by utilizing state information of the computer readable program instructions to individualize the electronic circuitry to implement aspects of the present invention.

[0097] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0098] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium such that the computer-readable storage medium comprises an article of manufacture containing instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, and may direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0099] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to perform a series of operational steps on the computer, other programmable apparatus, or other device to produce a computer-executed process, the instructions executing on the computer, other programmable apparatus, or other device to perform the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0100] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing specified logical functions. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified function or operation or executes a combination of dedicated hardware and computer instructions.

[0101] The description of various embodiments of the present disclosure has been presented for purposes of illustration and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, practical applications, or technical improvements over technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. A computer-based information processing method, the method comprising: Defining an access policy for a set of resources on a cloud computing system, the access policy including rules for enabling access to the set of resources; creating an activation function and attribute metadata within the cloud computing system based on the access policy, the attribute metadata including a set of access attributes for each resource in the set of resources; receiving a request to access a first resource of the set of resources, the request including a set of credentials; comparing said set of credentials with said set of access attributes by said activation function; processing the request to access the first resource based on the comparing; and A method comprising:

2. determining that the set of credentials matches the set of access attributes; further comprising said processing including enabling access to said resource in response to said determining that said certificate matches said access attributes. The method of claim 1.

3. determining that the set of credentials does not match the set of access attributes; further comprising said processing including denying access to said resource in response to said determining that said certificate does not match said access attributes. The method of claim 1.

4. The method of claim 1 , wherein the attribute metadata is encrypted by an encryption engine.

5. The method of claim 4 , wherein attribute-based encryption is used to encrypt the attribute metadata.

6. The method of claim 4 , wherein the resource comprises access data stored as object-based storage.

7. 7. The method of claim 6, wherein the object-based storage includes at least a bucket level having one or more buckets and an object level having one or more objects within each bucket, and the attribute metadata can include at least one attribute per bucket and at least one attribute per object.

8. 5. The method of claim 4, wherein the attribute metadata is selected from the group consisting of account type, account role, time, request location, and type of requested resource.

9. The method of claim 4 , wherein the attribute metadata includes an account type, an account role, a time, a request location, and a type of requested resource.

10. The method of claim 4 , wherein the attribute metadata includes table-level and column-level attributes.

11. The method of claim 1 , wherein each resource in the set of resources has a unique activation function.

12. A system that executes the method according to any one of claims 1 to 11 on computer hardware.

13. A computer program that causes a computer to execute the method according to any one of claims 1 to 11.

14. A storage medium on which the computer program described in claim 13 is stored in a computer-readable storage medium.

Images