Low Trust Privileged Access Management

Abstract

A method for coordinating access management processes, an access management control orchestrator, and a computer program product. One embodiment may include receiving a request to access a managed resource of an information system, querying permission to access the resource from an access manager, and, in response to the query for permission, requesting an access control policy update to grant access privileges to the managed resource. Receiving the request, querying permission, and requesting an access control policy update may include generating a transaction record and adding the transaction record to a distributed ledger, which simultaneously maintains the transaction record at multiple nodes across a network.

Description

[Technical field]

[0001] This disclosure relates to computer security, and more particularly, to coordinating access to privileged and administrative functions on critical IT systems that store / process sensitive data. [Background technology]

[0002] The development of the EDVAC (Electronic Discrete Variable Automatic Computer) system in 1948 is often cited as the beginning of the computer age. Since that time, computer systems have evolved into extremely complex devices. Modern computer systems typically include a combination of sophisticated hardware and software components, application programs, operating systems, processors, buses, memory, input / output devices, etc. As advances in semiconductor processing and computer architectures have increased computer performance, ever more advanced computer software has been developed to take advantage of the more powerful hardware, resulting in today's computer systems that are far more powerful than those of just a few years ago.

[0003] Modern computer systems are essential to technological advances and have become an important part of everyday life. As a result, the technical issue of security of these computing systems has increased in importance. An important aspect of computer security is privileged access management and privileged account management. Privileged users are users who have higher levels of access authority within a computing system (e.g., the system's administrator or "root" superuser) and / or special levels of access authority (e.g., the ability to read and write files containing sensitive information). Furthermore, privileged access management and privileged account management generally involve managing and auditing the accounts that provide system and data access authority to those privileged users. Summary of the Invention

[0004] An access management process orchestration method according to an embodiment of the present disclosure may include receiving a request to access a managed resource of an information system, querying authorization to access the resource from an access manager, and requesting an access control policy update in response to the authorization query to grant access privileges to the managed resource. Receiving the request, querying authorization, and requesting an access control policy update may include generating a transaction record and adding the transaction record to a distributed ledger, where the distributed ledger simultaneously maintains the transaction record at multiple nodes across a network.

[0005] According to an embodiment of the present disclosure, the access management control orchestrator includes a peer node associated with a blockchain network, the blockchain network including a plurality of nodes associated with at least one of an asset owner function, an administrator function, and an auditor function. The peer node may be adapted to: record an access permission request record from a user of the information system in the distributed ledger; record an owner authorization record from the asset owner function, the owner authorization record responding to the access permission request record in the distributed ledger; execute a smart contract in response to the access permission request record and the owner authorization record to grant access permission to the information system, the smart contract modifying the authorization policy to grant the user's access permission to the information system; and record the execution record of the smart contract in the distributed ledger.

[0006] According to an embodiment of the present disclosure, a computer program product comprises a non-transitory computer-readable storage medium having a plurality of instructions stored thereon. The instructions, when executed by a processor, may cause the processor to receive a request to access a managed resource of an information system, query permission to access the resource from an access manager, and, in response to the query for permission, request an update of an access control policy to grant access privileges to the managed resource. Receiving the request, querying permission, and requesting an update of the access control policy may include generating a transaction record and adding the transaction record to a distributed ledger.

[0007] The above summary is not intended to describe each example embodiment or every implementation of the present disclosure.

[0008] The drawings contained in this application are incorporated in and form a part of this specification. The drawings, together with the description, illustrate embodiments of the present disclosure and serve to explain the principles of the present disclosure. The drawings are merely examples of specific embodiments and are not limiting of the disclosure. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 illustrates a cloud computing environment, consistent with some embodiments. [Diagram 2] FIG. 1 illustrates an abstract model layer, consistent with some embodiments. [Diagram 3] FIG. 1 illustrates a data processing system, consistent with some embodiments. [Figure 4] 1 is a schematic diagram of a privilege orchestrator, consistent with some embodiments. [Figure 5A] FIG. 1 illustrates an example blockchain architecture configuration consistent with some embodiments. [Figure 5B] FIG. 1 illustrates a block chain transaction flow, consistent with some embodiments. [Figure 6A] FIG. 1 illustrates a flow diagram, consistent with some embodiments. [Figure 6B] FIG. 13 illustrates a further flow diagram, consistent with some embodiments. [Figure 6C] FIG. 1 illustrates an example system configured to perform one or more operations described herein, consistent with some embodiments. [Figure 6D] FIG. 1 illustrates another example system configured to perform one or more operations described herein, consistent with some embodiments. [Figure 6E] FIG. 1 illustrates a further example system configured to utilize smart contracts, consistent with some embodiments. [Figure 6F] FIG. 1 illustrates a system including a blockchain, consistent with some embodiments. [Figure 7A]FIG. 1 illustrates a process for a new block being added to a distributed ledger according to an example embodiment. [Figure 7B] 11 illustrates the contents of a new data block according to an example embodiment. [Figure 7C] FIG. 1 illustrates a block chain for digital content, according to an example embodiment. [Figure 7D] FIG. 2 illustrates a block diagram that may represent the structure of a block in a blockchain, according to an example embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] While the invention is susceptible to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that it is not intended to limit the invention to the particular embodiments described. On the contrary, it is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

[0011] Aspects of the present disclosure relate to computer security, and more particularly to coordinating access to privileged and administrative functions on critical IT systems that store / process sensitive data. Although the present disclosure is not necessarily limited to such applications, various aspects of the present disclosure may be understood through the description of various embodiments using this context.

[0012] One important aspect of IT security is managing the access of privileged users, such as users who can perform administrative operations on critical IT systems that store / process sensitive data. Privileged users' access rights to IT systems can be granted or denied by an access control system based on authentication and authorization policies. These policies are typically set by the highest level of management of the IT system.

[0013] An effective access control system may attempt to control changes to security policies to ensure that only authorized changes are made (e.g., when a new operator is hired, they need access to IT systems to perform their job), and these changes to security policies may be managed by the access management control process via an access management control orchestrator.

[0014] Further, some access management control processes for managing access permissions to an IT system may consist of one or more of the following actions: (i) requesting access permissions, (ii) approving access permissions, (iii) granting access permissions, (iv) reviewing access permissions, (v) revoking access permissions, and (vi) allowing access permissions. Some access management control processes may include one or more of the following entities: (i) an IT system owner, (ii) a privileged user who requires access permissions to the IT system, (iii) an IT system security administrator who controls the access policy to the IT system, who grants or denies access permissions to the privileged user, (iv) a third-party auditor, and (v) an access management process orchestrator. In some embodiments, the process may include the following workflow: 1. A user requesting authorization to a managed asset within an IT system submits a request for access privileges, typically providing justification, to an access management process orchestrator. 2. The process orchestrator determines who the owner of the managed asset and / or IT system is and routes the request to that owner. 3. The asset and / or IT system owner receives the access permission request, reviews the justification, decides to approve or deny the request, and returns the approved / denied request to the process orchestrator. 4. If the request is approved, the process orchestrator submits an access authorization request to an administrator and / or local control system associated with the managed asset and / or IT system. 5. An administrator and / or local control system receives the request and grants access to the requesting user by applying changes to the system's authorization policies that allow the privileged user to log in and access the system. 6. The request action, approval / denial action, and access authorization action are recorded in an audit log by the process orchestrator. 7. Third-party auditors require audit logs from the process orchestrator to review that access permissions were granted in accordance with regulations (corporate, government, industry, etc.) and that all policies were correctly applied. When a privileged user completes their work and no longer requires the access privileges, the process orchestrator may submit an access privilege revocation to an administrator and / or local control system, which removes the access privileges by applying changes to the security of the system. The process orchestrator may trigger a revocation request when it receives a request to remove the access privileges from a privileged user, when the maximum time allocated to the access privileges expires, after a periodic review performed by the IT system owner of the privileged user as to whether a privileged user who currently has access privileges to the IT system still has a valid justification to continue accessing the IT system, after a third-party auditor review (which may identify a violation of security policy, causing a security incident requiring the revocation of the access privileges), etc.

[0015] In some embodiments, an access management control orchestrator may be a system that receives and processes these requests. In these embodiments, the access management control orchestrator forwards the requests to the appropriate owner, administrator, etc. The person or organization that manages the system of interest may be different from the person or organization that owns the system of interest: for example, a bank that owns a database system and manages the process using an external security organization. The administrator of the IT system may be an automated system that runs without judgment or further validation of the access authorization requests forwarded to the administrator by the process orchestrator organization.

[0016] In some embodiments, the access management control orchestrator may advantageously include a distributed ledger (e.g., blockchain) that maintains transaction records simultaneously at multiple locations across the network, thereby decentralizing authority and ensuring full transparency regarding operations by all involved parties. In particular, some embodiments may provide an access management control process to coordinate how changes to authorization policies are requested, approved, granted, revoked, verified, etc., including the access management control orchestrator interfacing with each of the local IT systems' access control systems to request changes to authorization policies. In this way, some embodiments may provide an alternative to full trust between participants, since each participant knows that the other parties cannot circumvent the access management process, nor can they force / trick employees into granting / revokeing access privileges even if approval was not issued by the data owner, etc.

[0017] One advantage of some access management control orchestrator embodiments using blockchain is that it may reduce vulnerability to attacks (e.g., employee misconduct) coming from within the access management system. For example, without this feature, employees within the organization and / or employees at external organizations managing IT assets may have sufficient power to tamper with the process and violate security policies. A rogue employee in such an environment could send “access authorization” requests to an IT system (i.e., without approval from the system owner) and tamper with the audit logs to hide or change the authorization of that access. Even log signing and other tamper-proofing techniques could theoretically be circumvented by a rogue employee with sufficient authority, for example, by hacking the code / configuration of a centralized system that is entirely owned by the centralized system, stopping it from revoking the access authorization of rogue users, providing a tampered audit log to a third-party auditor that does not show a security policy violation, etc. In contrast, an access management control orchestrator using blockchain may provide IT system owners, administrators of those IT systems, and / or data managers with confidence that access to systems and / or data cannot be granted without the owner explicitly and transparently approving the access. Embodiments using blockchain may further help reassure auditors and regulators that documented processes cannot be circumvented. These features and advantages may be of particular use in situations involving sensitive personal information, regulated data, confidential information, trade secrets, and the like.

[0018] Additionally, some embodiments may ensure that no one can forge “AccessApproved” and “GrantAccess” transactions and add those transactions to the blockchain ledger. If someone hacks a node, forges transactions, and inserts those transactions into the ledger, these embodiments may not have to reach a consensus to accept the transactions. And this may be desirable in some embodiments because the “Access Manager” no longer needs to be a privileged role or even trusted. That is, IT owners can be confident that the transactions they accepted into the distributed ledger have been validated by multiple nodes controlled by different parties, and therefore that none of the approvals have been forged. To further protect against code hacks that can present forged transactions, some embodiments may allow owners and IT administrators to optionally deploy and add their own private nodes (i.e., nodes where they have full control over the implementation and configuration of the code) to the blockchain network. In this way, some embodiments may provide improved trust between participants since each participant knows that no person or entity can circumvent the access control process or coerce / trick anyone into granting / revokeing access privileges even if approval was not issued by the data owner.

[0019] Some embodiments may allow an IT administrator to check the validity of transactions such as GrantAccess and related AccessApproved transactions by the owner of the system in question. If the transactions are inconsistent with the information the IT administrator has, the IT administrator can block the authorization. In this way, if the IT administrator suspects a hacking activity that is trying to destroy the consistency of the ledger, the IT administrator can simply disconnect the source of the crime from the network, or ask the network to ban the associated access manager (this access manager may even be removed from the blockchain network if the blockchain network reaches consensus).

[0020] Some embodiments may provide better auditability with blockchain systems, since an audit of a set of transactions may be cryptographically guaranteed. In these embodiments, the distributed ledger may be immutable, and therefore accepted transactions cannot be altered, hacked, etc. Additionally, it may be guaranteed that transactions are accepted into the distributed ledger if and only if the network reaches a consensus that the transactions are valid. An attacker attempting to inject fake transactions into the ledger, even with code modifications, protocol spoofing / forging, etc., would need to hack enough nodes of the network to force consensus on the forged transactions. The probability of success for this possibility is very low, and can be further reduced by ensuring that multiple (independent) auditors participate in the network and that consensus cannot be reached without a majority of those auditors agreeing. In these embodiments, auditing organizations participating in the network to verify the validity of transactions may also deploy and add private nodes (nodes that have full control over the code implementation and configuration) to the blockchain network to further protect against code hacks that could present forged transactions to the auditing organizations.

[0021] Some embodiments may further provide high availability of the distributed system that monitors the security process. In these embodiments, the failure of one or more nodes does not affect the availability of the global blockchain, and clients can still connect to other nodes.

[0022] Cloud Computing 1 illustrates a cloud environment consistent with some embodiments. Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings presented herein is not limited to a cloud computing environment. Rather, embodiments of the present invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0023] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computational resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) and for rapidly provisioning and releasing these resources with minimal administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0024] The features are as follows: On-Demand Self-Service: Cloud customers can automatically provision server time, network storage, and other computing power as they need it, without any unilateral, human interaction with the service provider. Broad network access: Cloud capabilities are available over the network and can be accessed using standard mechanisms, facilitating usage by heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs). Resource Pool: The provider's computing resources are pooled and offered to multiple consumers using a multi-tenant model. Different physical and virtual resources are dynamically allocated and reallocated according to demand. There is a sense of location independence, consumers usually have no control or knowledge regarding the exact location of the resources offered, although at a higher level of abstraction they may be able to specify a location (e.g. country, state, or data center). Rapid Elasticity: Cloud capacity can be provisioned quickly and elastically, in some cases automatically, to scale out quickly, and quickly released to scale in quickly. Capacity available for provisioning often appears to the consumer as unlimited, and any amount can be purchased at any time. Metered Services: Cloud systems leverage metering capabilities to automatically control and optimize resource usage at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active customer accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services utilized.

[0025] The service model is as follows: SaaS (Software as a Service): The capability offered to the consumer is the use of the provider's applications running on a cloud infrastructure. Those applications can be accessed from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functionality, except for the possibility of limited customer-specific application configuration settings. · PaaS (Platform as a Service): The capability provided to a consumer is to deploy applications that the consumer creates or acquires, written 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 networks, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the application hosting environment. Infrastructure as a Service (IaaS): The capability provided to a customer is the provisioning of processing, storage, network, and other basic computing resources over 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 has control over the operating systems, storage, and deployed applications, and in some cases has limited control over selected network components (e.g., host firewalls).

[0026] The deployment model is as follows: Private Cloud: This cloud infrastructure is operated solely for one organization. It can be managed by this organization or a third party and can exist on-premise or off-premise. Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It can be managed by these organizations or a third party and can reside on-premise or off-premise. Public Cloud: This cloud infrastructure is available for use by the general public or large industry entities and is owned by an organization that sells cloud services. Hybrid Cloud: This cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique but are bound together by standardized or proprietary technologies that allow for the portability of data and applications (e.g., cloud bursting to balance the load between clouds).

[0027] A cloud computing environment is a service-oriented environment with an emphasis on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0028] Referring now to FIG. 1, an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers (e.g., a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N) can communicate. The nodes 10 may communicate with each other. The nodes 10 may be physically or virtually grouped in one or more networks (not shown), such as in a private cloud, community cloud, public cloud, or hybrid cloud, or combination thereof, as previously described herein. This allows the cloud computing environment 50 to provide an infrastructure, platform, and / or SaaS that does not require the cloud consumer to maintain resources on a local computing device. The types of computing devices 54A-N illustrated in FIG. 1 are intended as examples only, and it will be understood that the computing node 10 and cloud computing environment 50 may communicate with any type of computer-controlled device via any type of network and / or network-addressable connection (e.g., a connection using a web browser).

[0029] 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 that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0030] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes 61, Reduced Instruction Set Computer (RISC) architecture based servers 62, servers 63, blade servers 64, storage devices 65, and networks and network components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0031] The virtualization layer 70 provides an abstraction layer that can provide virtual entities 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 .

[0032] By way of example, the management layer 80 may provide the following functions: Resource provisioning 81 provides dynamic procurement of computational and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking and billing or invoicing for the utilization of resources within the cloud computing environment. By way of example, the resources may include application software licenses. Security provides identity verification of cloud users and tasks, as well as protection of data and other resources. Customer portal 83 provides access to the cloud computing environment to users and system administrators. Service level management 84 provides allocation and management of cloud computational resources to meet required service levels. Service level agreement (SLA) planning and execution 85 provides pre-provisioning and procurement of cloud computational resources in anticipation of upcoming demands, in accordance with SLAs.

[0033] The Workload Layer 90 illustrates examples of functionality available in a cloud computing environment. Examples of workloads and functionality that may be 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 access management control orchestrator 96.

[0034] Data Processing System FIG. 3 illustrates an embodiment of a data processing system (DPS) 300 suitable for use as a cloud computing node 10 in a cloud computing environment 50, consistent with some embodiments. In some embodiments, the DPS 300 is implemented as a processor integrated into a larger device, such as a personal computer, a server computer, a laptop or notebook computer, a portable computer, such as a PDA (personal digital assistant), a tablet computer, or a smartphone, an automobile, an aircraft, a videoconferencing system, an appliance, a smart device, or any other suitable type of electronic device. Additionally, components other than or in addition to those illustrated in FIG. 3 may be presented, and the number, type, and configuration of such components may vary. Additionally, FIG. 3 illustrates only representative major components of the DPS 300, and individual components may have greater complexity than those depicted in FIG. 3.

[0035] The data processing system 300 of FIG. 3 includes multiple central processing units 310a-310d (collectively referred to herein as processors 310 or CPUs 310) connected to memory 312, mass storage interface 314, terminal / display interface 316, network interface 318, and input / output (I / O) interface 320 by a system bus 322. In this embodiment, mass storage interface 314 connects the system bus 322 to one or more mass storage devices, such as a direct access storage device 340, a universal serial bus (USB) storage device 341, or a readable / writeable optical disk drive 342. Network interface 318 enables the DPS 300 to communicate with other DPSs 300 via communication medium 306. Memory 312 also includes an operating system 324, multiple application programs 326, and program data 328.

[0036] The embodiment of the data processing system 300 of FIG. 3 is a general-purpose computing device. Thus, the processor 310 may be any device capable of executing program instructions stored in the memory 312, and the processor 310 itself may be constructed from one or more microprocessors and / or integrated circuits. In this embodiment, the DPS 300 includes multiple processors and / or processing cores, as is typical in larger and more powerful computer systems, but in other embodiments, the computing system 300 may include a single processor system designed to emulate a multiprocessor system or a single processor or / and. Additionally, the processor 310 may be implemented using multiple heterogeneous data processing systems 300, where a main processor exists along with secondary processors on a single chip. As another example, the processor 310 may be a symmetric multiprocessor system that includes multiple processors of the same type.

[0037] When a data processing system 300 boots, an associated processor 310 initially executes program instructions that make up an operating system 324, which manages the physical and logical resources of the DPS 300. These resources include memory 312, mass storage interface 314, terminal / display interface 316, network interface 318, and system bus 322. As with the processor 310, some DPS 300 embodiments may utilize multiple system interfaces 314, 316, 318, 320, and bus 322, each of which may include its own separate, fully programmed microprocessor.

[0038] The instructions for the operating system, applications, and / or programs (collectively referred to as "program code," "computer usable program code," or "computer readable program code") may be initially located in mass storage devices 340, 341, 342, which communicate with the processor 310 via the system bus 322. The program code in various embodiments may be embodied on different physical or tangible computer readable media, such as the system memory 312 or the mass storage devices 340, 341, 342. In the example of FIG. 3, the instructions are stored in a functional form of persistent storage on the direct access storage device 340. These instructions are then loaded into the memory 312 for execution by the processor 310. However, the program code may also be located in a functional form on a selectively removable computer readable medium 342 and loaded or transferred to the DPS 300 for execution by the processor 310.

[0039] The system bus 322 may be any device that facilitates communication between the processor 310, the memory 312, and the interfaces 314, 316, 318, 320. Additionally, although the system bus 322 in this embodiment is a relatively simple single bus structure providing a direct communication path within the system bus 322, other bus structures are consistent with this disclosure, including, but not limited to, point-to-point links, multiple hierarchical buses, redundant parallel paths, in a hierarchical, star, or web configuration, etc.

[0040] Memory 312 and mass storage devices 340, 341, 342 work together to store operating system 324, application programs 326, and program data 328. In this embodiment, memory 312 is a random access semiconductor device capable of storing data and programs. While FIG. 3 conceptually illustrates this device as a single monolithic entity, in some embodiments memory 312 may be a more complex configuration, such as a hierarchy of caches and other memory devices. For example, memory 312 may exist in multiple levels of caches, and these caches may be further divided by function, such that some caches hold instructions while other caches hold non-instruction data used by one or more processors. Memory 312 may be further distributed and associated with different processors 310 or sets of processors 310, as known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures. Additionally, some embodiments may utilize a virtual addressing mechanism that allows the DPS 300 to act as if it has access to a large, single storage entity instead of accessing multiple smaller storage entities, such as memory 312 and mass storage devices 340, 341, 342.

[0041] Although the operating system 324, application programs 326, and program data 328 are shown as being contained within memory 312, in some embodiments, some or all of these may be physically located on different computer systems and may be accessed remotely, such as via communications medium 306. Thus, while the operating system 324, application programs 326, and program data 328 are shown as being contained within memory 312, these elements are not necessarily all contained entirely on the same physical device at the same time and may reside in the virtual memory of another DPS 300.

[0042] System interfaces 314, 316, 318, 320 support communication with various storage and I / O devices. Mass storage interface 314 supports the connection of one or more mass storage devices 340, 341, 342, which are typically rotating magnetic disk drive storage devices, solid-state storage devices (SSDs) that use integrated circuit assemblies as memory (usually using flash memory) to persistently store data, or a combination of the two. However, mass storage devices 340, 341, 342 may comprise other devices including an array of disk drives configured to appear to the host as a single large storage device (commonly referred to as a RAID array), or hard disk drives, tapes (e.g., miniDV), writable compact disks (e.g., CD-R and CD-RW), digital versatile disks (e.g., DVD, DVD-R, DVD+R, DVD+RW, DVD-RAM), holographic storage systems, blue laser disks, and / or archival storage media such as IBM® Millipede devices.

[0043] The terminal / display interface 316 is used to connect one or more display units, such as a monitor 380, directly to the data processing system 300. These display units 380 may be non-intelligent (i.e., non-data processing capable) terminals, such as LED monitors, or may themselves be fully programmable workstations used to enable IT administrators and customers to communicate with the DPS 300. It is noted, however, that while the display interface 316 is provided to support communication with one or more display units 380, the computer system 300 does not necessarily require a display unit 380, as all necessary customer interaction and other processes may occur via the network interface 318.

[0044] The communications medium 306 may be any suitable network or combination of networks and may support any suitable protocol for communicating data and / or code between multiple DPSs 300. Thus, whether the network connections are made using current analog and / or digital technologies, or via some future networking mechanism, the network interface 318 may be any device that facilitates such communications. Suitable communication media 306 include, but are not limited to, networks implemented using one or more of the "InfiniBand" or IEEE (Institute of Electrical and Electronics Engineers) 802.3x "Ethernet" specifications, cellular transmission networks, wireless networks implemented using one of the IEEE 802.11x, IEEE 802.16, General Packet Radio Service (GPRS), Family Radio Service (FRS), or Bluetooth (R) specifications, Ultra-Wide Band (UWB) technology as described in FCC 02-48, and the like. Those skilled in the art will appreciate that many different network and transport protocols can be used to implement communication medium 306. The Transmission Control Protocol / Internet Protocol (TCP / IP) suite includes suitable network and transport protocols.

[0045] Access Management Control Orchestrator FIG. 4 is a schematic diagram of an access management control orchestrator 400 consistent with some embodiments. This embodiment of the access management control orchestrator 400 is described with reference to a system owner function 450, an auditor function 455, a system privilege requesting user function 460, and a system administrator function 465, which communicate via a blockchain 470. In an exemplary transaction, a user requests additional privileges 405 from the access management control orchestrator 400, and the owner function 450 may approve or deny the request 415. After the owner function 450 approves the request, the system administrator function 465 may grant the corresponding access rights 425, 430 to the physical IT system. The auditor 455 may verify 410 that the owner approved the new privileges. In some embodiments, the system owner function 450, the auditor function 455, the system privilege requesting user 460, and the system administrator function 465 may all be part of different legal entities and therefore may use different internal technical systems to manage the access rights. In these use cases, different functions may interface with the access management control orchestrator 400 via standard application programming interfaces (APIs), etc.

[0046] In this embodiment, blockchain 470 may be a network of nodes 471A, 471B, 471C, 471D (collectively, nodes 471) at different logical, physical, and entity locations (geographic locations, organizational locations, hosting locations, etc.). Nodes 471 may be connected to each other via encrypted network communication channels 472. In some embodiments, a node 471 may be added to blockchain 470 if and only if the addition of node 471 is approved by other existing nodes 471 in blockchain 470 according to a consensus protocol.

[0047] In this embodiment, each node 471 may maintain a copy of the distributed ledger 473 (for clarity, only one copy is shown in FIG. 4 ) that lists all transactions that have been submitted to the blockchain 470 and accepted. In this embodiment, a transaction may be accepted if and only if there is agreement between the nodes 471 in the blockchain 470 according to a consensus protocol. In this embodiment, a transaction may be added to the distributed ledger 473 only when all past transactions in the distributed ledger 473 are immutable and cannot be changed. Additionally, the distributed ledger 473 may be cryptographically signed to ensure that it is virtually impossible to tamper with the records.

[0048] In some embodiments, nodes 471 may execute smart contracts (i.e., computer programs submitted by clients that process transactions in the ledger 473, such as to digitally facilitate, verify, or enforce the execution of the transactions). The responsibilities of a smart contract may include, but are not limited to, (i) validating transactions (i.e., participating in a consensus protocol to accept new transactions into the ledger), (ii) proposing new transactions into the ledger, which may or may not be accepted, and (iii) performing operations to process one or more transactions with external clients. A smart contract may be executed in parallel on all nodes 471 of the blockchain 470, and the outcome of the smart contract may be accepted by the blockchain 470 if and only if there is agreement among the nodes 471 in the network according to the consensus protocol.

[0049] In some embodiments, the blockchain 470 may be a permissioned blockchain. In these embodiments, a client (e.g., a user, a software application) may connect to the blockchain 470 only through nodes 471A, 471B, 471C, 471D that authenticate and authorize the client. In these embodiments, a client may call the blockchain network APIs to submit transactions, query transaction states and attributes, etc. These transactions may include, but are not limited to, (i) a client proposing a new transaction that is added to the ledger and then accepted into the distributed ledger through a consensus protocol, (ii) a client checking that the client is authorized to process a new transaction that is accepted by the distributed ledger, and (iii) a client submitting a smart contract to the blockchain 470.

[0050] In some embodiments, an access management system may be implemented by using the blockchain 470 to allow for association of identities to entities that have been granted access to connect / invoke services provided by the blockchain 470. These entities may have the authority to connect to existing nodes 471A, 471B, 471C, 471D or to add additional nodes (not shown) to which these entities can connect. These entities may have the authority to submit and interact with smart contracts from the nodes 471A, 471B, 471C, 471D to which they are connected. These entities, and the smart contracts they submit, may have the authority to obtain / submit transactions that include attributes that match the access policy criteria.

[0051] Blockchain Network API Some embodiments may support the following types of transactions with the following attributes: RequestAccess(UID, ITSystemID, Privilege, Reason) AccessApproved(UID, ITSystemID, Privilege, UIDOwner, ApprovalDescription, RequestTID) AccessDenied(UID, ITSystemID, Privilege, UIDOwner, DenialExplanation, RequestTID) GrantAccess(UID, ITSystemID, Privilege, UIDAdmin, Reason, ApprovalDescription, ApprovalTID) AccessGranted(UID, ITSystemID, Privilege, UIDAdmin, Reason, ApprovalDescription, ApprovalTID) RevokeAccess(UID,ITSystemID,UIDAM / UIDAuditor,reason) AccessRevoked(UID,ITSystemID,UIDAM / UIDAuditor,reason) RequestValidationP() 1. With a new RequestAccess(UID, ITSystemID, Privilege, Reason) transaction 2. Find the UID Owner of the system ITSystemID 3. Submit transaction RequestApproveAccess(UID, ITSystemID, Privilege, UIDOWNER, Reason.RequestTID) OwnerApprovalP(ITSystemID) 1. With ITSystemID == ITSystemID, execute a new RequestAccess(UID, ITSystemID, Privilege, UIDOWNER) transaction. 2. Validate that the reason provided by the UID to request access to the privileged ITSystemID is valid 3. If the reason is valid 1. Submit transaction ApprovalTID = AccessApproved(UID, ITSystemID, Privilege, UIDOWNER, ApprovalDescription, RequestTID) 2. Submit transaction GrantAccess(UID, ITSystemID, Privilege, UIDOWNER, ApprovalDescription, ApprovalTID) 4. Otherwise, submit transaction AccessDenied(UID, ITSystemID, Privilege, UIDOWNER, Explanation of denial, RequestTID). GrantAccessP(ITSystemID) 1. In a new AccessGranted(UID, ITSystemID, Privilege, UIDOWNER, AuthorizationDescription, RequestTID) transaction, with ITSystemID == ITSystemID. 2. Double check that the UID Owner is the owner of the ITSystemID, then send a message to the ITSystemID access control (authorization) system to perform the authorization action with the parameters UID, ITSystemID, privilege, UID Owner, authorization description, and RequestTID. The authorization policy is modified so that the authorization action grants access rights for user UID to system ITSystemID. LogAccess(ITSystemID) 1. Wait for a request from Bob to perform a grant or revoke action by passing the parameters UID, ITSystemID, UIDAdmin, Description, RequestTID 2. If the action is Allow, update the access privileges for the UID and submit the transaction AccessGranted(UID, ITSystemID, Privilege, UIDAdmin, Description, ApprovalTID). 3. If the action is revoke, revoke the access privileges for the UID and submit the transaction AccessRevoked(UID, ITSystemID, UIDOwner, Description, ApprovalTID). RevokeAccessP(ITSystemID) 1. With ITSystemID == ITSystemID, use a new RevokeAccess(UID, ITSystemID, UIDowner, Reason, RequestTID) transaction. 2. Double check that the UID Owner is valid, then send a message to the ITSystemID access control (authorization) system to perform the revoke operation with the parameters UID, ITSystemID, UID Owner, revoke description, and RequestTID. The authorization policy is modified so that the revoke action denies access rights for user UID to system ITSystemID. AuditActionsP (List of ITSystemIDs) 1. In a new transaction that includes the ITSystemID in the list of ITSystemIDs 2. Validate that transaction and security policies are being adhered to, e.g. · RequestApproved: RequestTID is a RequestAccess for UID, UIDOWNER is the owner of ITSystemID, and the reason is valid GrantAccess: ApprovalTID is an AccessApproved transaction for the UID / SystemID, UIDOWNER is the owner of the ITSystemID, and the approval reason is valid ·AccessGranted: ApprovalTID is an AccessApproved transaction for UID / SystemID, UIDOWNER is the owner of ITSystemID, UIDAdmin is an administrator of SystemID, and the approval reason is valid Initiate a security incident if policies are not followed

[0052] example In the example, if the following entities with the following specified identities exist within a particular privilege coordination system: Eve: Owner organization of system ITSystemID1 Eve: Ownership organization of system ITSystemID2 Bob (real person or automation): Administrator of systems ITSystemID1, ITSystemID2 Auditor: Audit organization of ITSystemID1 and ITSystemID2 Alice: Privileged User The following access policy is defined: Eve: Read the RequestAccess transaction with attributes ITSystemID=ITSystemID1, ITSystemID2 Eve: Submit AccessApproved, AccessDenied, GrantAccess, and RevokeAccess transactions with attributes ITSystemID=ITSystemID1, ITSystemID2. Bob: Read GrantAccess, RevokeAccess, Request transactions with attributes ITSystemID=ITSystemID1, ITSystemID2 Bob: ITSystemID1, ITSystemID2: Submit AccessGranted and AccessRevoked transactions with attributes ITSystemID = ITSystemID1 and ITSystemID2 Auditor: Read all types of transactions with any attribute The following nodes have been added to blockchain 470: Node1: Hosted by the access rights management organization Node2: System ITSystemID1, hosted by the owner organization of system ITSystemID2 Node3: Hosted by administrator of systems ITSystemID1 and ITSystemID2 Node 4: Hosted by the audit organization for ITSystemID1 and ITSystemID2 Next, in this example, the following operations may be performed by the client during operation by calling the blockchain network API: Alice connects to Node1 and submits an access permission request for ITSystemID1 Eve connects to Node2 and runs the OwnerApprovalP(ITSystemID1) program. Eve connects to Node2 and runs the OwnerApprovalSP(ITSystemID2) program. Bob connects to Node3 and runs the GrantAccessP(ITSystemID1) program. Bob connects to Node3 and runs the GrantAccessP(ITSystemID2) program. Bob connects to Node3 and runs the RevokeAccessP(ITSystemID1) program. Bob connects to Node3 and runs the RevokeAccessP(ITSystemID2) program. ITSystemID1 and ITSystemID2 connect to Node3 and run the LogAccessP() program. The auditor connects to Node4 and executes AuditActionsP(ITSystemID1, ITSystemID2) for execution.

[0053] Blockchain Architecture FIG. 5A illustrates a blockchain architecture configuration 500 consistent with some embodiments. In these embodiments, the blockchain architecture 500 may include a particular blockchain element (e.g., a group of blockchain nodes 502). The group of blockchain nodes 502 may then include one or more member nodes 504-510 (four of these nodes are shown merely by way of example). These member nodes 504-510 may participate in a number of activities, such as adding and validating blockchain transactions (agreements). One or more of the member nodes 504-510 may sign transactions based on a signature policy and provide ordering services to all blockchain nodes in the architecture 500. The member nodes 504-510 may initiate blockchain authentication and attempt to write to the blockchain's immutable ledger stored in the blockchain layer 516, a copy of which may also be stored in the underlying physical infrastructure 514.

[0054] In some embodiments, the blockchain architecture 500 may include one or more applications 524 linked to an application programming interface (API) 522 to access and execute stored program / application code 520 (e.g., chaincode, smart contracts, etc.). The stored program / application code 520 can then be created according to customized configurations required by the participants, and can maintain its own state, control the participants' assets, and receive external information. The stored program / application code 520 can be deployed as a transaction and installed on all blockchain nodes 504-510 by adding it to the distributed ledger.

[0055] The blockchain base or platform 512 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors seeking access to data entries. The blockchain layer 516 may expose interfaces that provide access to the virtual execution environments necessary to process program code and enlist the physical infrastructure 514. The cryptographic trust services 518 may be used to verify transactions, such as asset exchange transactions, and keep information private.

[0056] The blockchain architecture of FIG. 5A may process and execute program / application code 520 through one or more interfaces and services exposed by the blockchain platform 512. The program / application code 520 may control assets of the blockchain. For example, the code 520 may store and transfer data and may be executed by the member nodes 504-510 in the form of associated chaincode including smart contracts and conditions or other code elements subject to execution. As a non-limiting example, smart contracts may be created to perform reminders, updates, or changes, other notifications subject to updates, or combinations thereof. The smart contracts themselves may be used to identify permission and access requirements and rules associated with the use of the ledger. For example, the document attribute information 526 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 516. The results 528 may include multiple linked shared documents. The physical infrastructure 514 may be utilized to retrieve any of the data or information described herein.

[0057] In some embodiments, smart contracts may be created using high-level application and programming languages ​​and then written into blocks in the blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated in the blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that may be executed in response to a condition associated with the smart contract being satisfied. Execution of a smart contract may trigger a trusted change to the state of the digital blockchain ledger. Changes to the blockchain ledger caused by the execution of a smart contract may, in some embodiments, be automatically replicated across a distributed network of blockchain peers via one or more consensus protocols.

[0058] A smart contract may write data to the blockchain in the form of key-value pairs. In some embodiments, the smart contract code may also read values ​​stored in the blockchain and use them in the operation of the application. In these embodiments, the smart contract code may write the output of various logical operations to the blockchain. In some embodiments, the smart contract code may be used to create temporary data structures in a virtual machine or other computing platform. In these embodiments, the data written to the blockchain may be public or may be kept encrypted as private. The temporary data used / generated by the smart contract may be kept in memory by the provided execution environment and then deleted after the data required for the blockchain has been identified.

[0059] In some embodiments, the chaincode may include a code interpretation of the smart contract along with additional functionality. In some embodiments, the chaincode may be implemented as program code deployed on a computing network and executed together and validated by chain validators during the consensus process. The chaincode may receive a hash and may retrieve a hash from the blockchain associated with a data template created by use of a previously stored feature extractor. If the hash of the hashed identifier and the hash created from the stored identifier template data match, the chaincode may send an authorization key to the requested service. The chaincode may write data associated with the cryptographic details to the blockchain.

[0060] FIG. 5B illustrates an example of a blockchain transaction flow 550 between nodes of a blockchain according to some embodiments. The transaction flow in these embodiments may include a transaction proposal 591 sent by an application client node 560 to a signing peer node 581. The signing peer 581 may verify the client's signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of versions of the keys / values ​​that were read into the chaincode (the read set), and a set of keys / values ​​that were written into the chaincode (the write set). A proposal response 592 may then be sent back to the client 560, along with the signature if approved.

[0061] In response, the client 560 may package the signatures into a transaction payload 593 and broadcast it to the ordering service node 584. The ordering service node 584 may then distribute the ordered transaction as a block on the channel to all peers 581-583. Before committing it to the blockchain, each peer 581-583 may verify the validity of the transaction. For example, a peer may, in some embodiments, check a signature policy to ensure that the correct allocation of the designated peer has signed the result and authenticated the signature on the transaction payload 593.

[0062] Continuing to refer to FIG. 5B, in some embodiments, a client node 560 may initiate a transaction 591 by constructing and sending a request to a peer node 581, which may act as a signer. The client 560 may include an application utilizing a supported software development kit (SDK), which may utilize available APIs to generate a transaction proposal. The transaction proposal may be a request to invoke a chaincode function so that data can be read from and / or written to the distributed ledger (i.e., writing a new key-value pair for an asset). The SDK may act as a shim to package the transaction proposal into a suitably designed format (e.g., protocol buffers over a remote procedure call (RPC)), receive the client's cryptographic credentials, and generate a unique signature for the transaction proposal.

[0063] In response, the signing peer node 581 may verify that (a) the transaction proposal is properly formed, (b) the transaction has not already been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example embodiment, client 560) is properly authorized to perform the proposed operation on the channel. The signing peer node 581 may receive the transaction proposal input as an argument to a chaincode function that is called. The chaincode may then be executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set. In some embodiments, no updates are made to the ledger at this point. Instead, the set of values, along with the signing peer node 581 signature, may be returned as a proposal response 592 to the client 560's SDK, which parses the payload for the application to use.

[0064] In response, the client 560 application may check / verify the signing peer's signature and compare the proposal response to determine if the proposal response is the same. If the chaincode simply queried the ledger, the application may check the query response and typically would not submit the transaction to the ordering node service 584. If the client application is going to submit a transaction to the ordering node service 584 to update the ledger, the application may determine if the specified signature policy is satisfied (i.e., if all required peer nodes for the transaction have signed the transaction) before submitting. Here, the client may include only one of multiple parties of the transaction. In this case, each client may include its own signing node, and each signing node must sign the transaction. The architecture ensures that the signature policy is still enforced by the peers and maintained in the commit validation phase, even if the application chooses not to check the response or otherwise forwards an unsigned transaction.

[0065] After successful validation, at operation 593, the client 560 may package the signatures into a transaction and broadcast the transaction proposal and transaction response in a transaction message to the ordering node 584. The transaction may include the read / write set, the signing peer signatures, and the channel ID. The ordering node 584 does not need to validate the entire contents of the transaction to perform its operation; instead, the ordering node 584 may simply receive transactions from all channels in the network, order them chronologically by channel, and create a block of transactions for each channel.

[0066] The block of transactions may be distributed from the ordering node 584 to all peer nodes 581-583 on the channel. The transactions 594 in the block may be validated to ensure that any signature policies are satisfied and to ensure that there have been no changes to the ledger state with respect to the variables in the read set since the read set was generated by the execution of the transaction. The transactions in the block may be tagged as valid or invalid. Further, in operation 595, each peer node 581-583 may add the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events may be published to notify the client application that the transaction (invocation) has been immutably added to the chain, and to notify whether the transaction has been validated or invalidated.

[0067] Permissioned Blockchain FIG. 6A illustrates an example of a permissioned blockchain network consistent with some embodiments, characterized by a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 602 may initiate a transaction to a permissioned blockchain 604. In this example, the transaction may be a deployment, an invocation, or a query, and may be issued via a client-side application utilizing an SDK, directly via an API, etc. The network may provide access to regulators 606, such as auditors. A blockchain network operator 608 manages member permissions, such as registering regulators 606 as “auditors” and blockchain users 602 as “clients.” Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain types of chaincode.

[0068] A blockchain developer 610 may write the chaincode and client-side applications in some embodiments. The blockchain developer 610 may deploy the chaincode directly to the network through an interface in these embodiments. To include authentication information from traditional data sources 612 in the chaincode, the developer 610 may use an out-of-band connection to access the data. In this example, a blockchain user 602 may connect to the permissioned blockchain 604 through a peer node 614. Before initiating any transactions, the peer node 614 may obtain a user registration and transaction certificate from a certificate authority 616 that manages user roles and permissions. In some embodiments, blockchain users must possess their digital certificates to perform transactions on the permissioned blockchain 604. In other embodiments, blockchain users may be authenticated using other techniques, such as by a distributed chain of trust. On the other hand, users seeking to utilize chaincode may need to verify their user's authentication information on traditional data sources 612. To verify the user's authorization, the chaincode may use an out-of-band connection to this data through a traditional processing platform 618.

[0069] FIG. 6B illustrates another example of a permissioned blockchain network consistent with some embodiments, characterized by a decentralized, decentralized peer-to-peer architecture. In this example, a blockchain user 622 may submit a transaction to a permissioned blockchain 624. In this example, the transaction may be a deploy, invoke, or query and may be issued via a client-side application utilizing an SDK, directly via an API, etc. The network may provide access to regulators 626, such as auditors. A blockchain network operator 628 manages member permissions, such as registering regulators 626 as “auditors” and blockchain users 622 as “clients.” Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain types of chaincode.

[0070] A blockchain developer 631 may write the chaincode and client-side applications in these embodiments. The blockchain developer 631 may deploy the chaincode directly to the network through an interface. To include authentication information from traditional data sources 632 in the chaincode, the developer 631 may use an out-of-band connection to access the data. In this example, a blockchain user 622 connects to the network through a peer node 634. The peer node 634 obtains a user's registration and transaction certificate from a certificate authority 636 before initiating any transactions. In some embodiments, blockchain users must possess their digital certificates to execute transactions on the permissioned blockchain 624. In other embodiments, blockchain users may be authenticated using other techniques, such as by a distributed chain of trust. On the other hand, users seeking to utilize the chaincode may need to verify their user's authentication information on traditional data sources 632. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 638.

[0071] FIG. 6C illustrates an example system including a physical infrastructure 611 configured to perform various operations consistent with some embodiments. With reference to FIG. 6C, the physical infrastructure 611 includes a module 688 and a module 689. The module 619 includes a blockchain 620 and a smart contract 630 (which may reside in the blockchain 620) that may perform any of the operational steps 678 (in module 612) included in any of the example embodiments. The steps / operations 678 may include one or more of the embodiments described or illustrated in the figures and may represent information written or read, outputted, or written from one or more smart contracts 630 and / or the blockchain 620. The physical infrastructure 611, the module 688, and the module 689 may include one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof. Additionally, the module 688 and the module 689 may be the same module.

[0072] FIG. 6D illustrates another example system configured to perform various operations consistent with some embodiments. With reference to FIG. 6D, the system includes modules 612 and 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside in the blockchain 620) that may perform any of the operational steps 678 (in module 612) included in any of the example embodiments. The steps / operations 678 may include one or more of the embodiments described or illustrated in the figures and may represent information written or read, outputted, or written from one or more smart contracts 630 and / or blockchain 620. The physical modules 612 and 614 may include one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof. Additionally, modules 612 and 614 may be the same module.

[0073] FIG. 6E illustrates an exemplary system configured to utilize an intermediary server configured to enforce the terms of a smart contract on a blockchain 620, consistent with some embodiments. With reference to FIG. 6E, this configuration may represent a communication session, an asset transfer session, or a process or procedure operated by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the execution of the smart contract may be managed by a server 654. The contents of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656 that are participants in the smart contract transaction. The results of the execution of the smart contract may be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on the blockchain 620, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0074] FIG. 6F illustrates a system 660 including a blockchain, consistent with some embodiments. Referring to the example of FIG. 6D, an application programming interface (API) gateway 662 provides a common interface for accessing the logic (e.g., smart contracts 630 or other chaincode) and data (e.g., distributed ledger, etc.) of the blockchain. In this example, the API gateway 662 is a common interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., servers 654). Here, the servers 654 are peer components of the blockchain network that hold copies of the world state and the distributed ledger, which allow clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, which executes the smart contracts 630 according to the smart contracts 630 and signing policies.

[0075] Processing Blocks Figure 7A illustrates a process 700 of a new block being added to a distributed ledger 720, consistent with some embodiments, and Figure 7B illustrates the contents of a blockchain new data block structure 730, consistent with some embodiments. The new data block 730 may include documents that link data.

[0076] With reference to FIG. 7A, a client (not shown) may submit a transaction to blockchain nodes 711, 712, or 713, or a combination thereof. A client may be an instruction received from any source to specify an activity on the blockchain 722. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, proposing a blockchain transaction. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain a copy of the blockchain network state and the distributed ledger 720. Various types of blockchain nodes / peers may exist in a blockchain network, including signing peers that simulate and sign transactions proposed by clients, and commit peers that verify signatures, validate transactions, and commit transactions to the distributed ledger 720. In some embodiments, blockchain nodes 711, 712, and 713 may perform the role of signer nodes, committer nodes, or both.

[0077] The distributed ledger 720 may include a blockchain that stores immutable ordered records in blocks, and a state database 724 (current world state) that maintains the current state of the blockchain 722. There may be one distributed ledger 720 per channel, with each peer maintaining its own copy of the distributed ledger 720 for each channel in which it is a member. The blockchain 722 may be a transaction log structured as hash-linked blocks, with each block containing a sequence of N transactions. A block may include various components, such as those shown in FIG. 7B. Block links (illustrated by arrows in FIG. 7A) may be generated by adding a hash of the previous block's header into the block header of the current block. In this way, all transactions on the blockchain 722 may be ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of these links, the most recent block in the blockchain 722 represents all transactions that came before it. The blockchain 722 may be stored in the file system (local or attached storage) of a peer that supports additional dedicated blockchain workloads.

[0078] The current state of the blockchain 722 and distributed ledger 720 may be stored in a state database 724, where the current state data represents the latest values ​​of all keys ever included in the on-chain transaction log of the blockchain 722. Chaincode invocations execute transactions against the current state in the state database 724. To make those chaincode interactions more efficient, the latest values ​​of all keys may be stored in the state database 724. The state database 724 may contain an indexed view into the blockchain 722 transaction log and therefore can be regenerated off-chain at any time. The state database 724 may be automatically restored (or generated if necessary) at peer startup and before transactions are received.

[0079] A signing node receives transactions from clients and signs the transactions based on the simulation results. The signing node holds a smart contract that simulates the transaction proposal. When a signing node signs a transaction, it creates a signature for the transaction, which is a signed response from the signing node to the client application that indicates the signature of the simulated transaction. The way in which a transaction is signed depends on a signature policy that may be specified in the chaincode. An example of a signature policy is "a majority of the signing peers must sign the transaction." Different channels may have different signature policies. The signed transaction is forwarded by the client application to the ordering service 710.

[0080] The ordering service 710 receives signed transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 710 may start a new block when a transaction threshold is reached, a timer times out, or another condition. In the example of FIG. 7A, blockchain node 712 is a committing peer that receives a new data block 730 of new data for storage in the blockchain 722. The first block in a blockchain may be called a genesis block, which contains information about the blockchain, the members of the blockchain, the stored data, etc.

[0081] The ordering service 710 may consist of a cluster of ordering nodes. In some embodiments, the ordering service 710 may not process transactions, smart contracts, or maintain a shared ledger. Rather, in these embodiments, the ordering service 710 may receive signed transactions and specify the order in which those transactions are committed to the distributed ledger 720. The architecture of the blockchain network may be designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0082] In some embodiments, transactions may be written to the distributed ledger 720 in a consistent order. In these embodiments, the order of transactions may be established to ensure that updates to the state database 724 are valid when transactions are committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering occurs through solving cryptographic puzzles or through mining, in this example, the parties to the distributed ledger 720 may choose the ordering mechanism that best suits their network.

[0083] In some embodiments, the ordering service 710 may initialize a new data block 730, and the new data block 730 may be broadcast to the committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer may verify the validity of the transaction in the new data block 730 by checking to ensure that the read set and write set still match the current world state in the state database 724. In particular, the committing peer may determine whether the read data that existed when the signer simulated the transaction is identical to the current world state in the state database 724. If the committing peer verifies the validity of the transaction, the transaction may be written to the blockchain 722 of the distributed ledger 720, and the state database 724 may be updated with the write data from the read / write set. In some embodiments, if a transaction fails (e.g., if a commit peer detects that the read / write set does not match the current world state in state database 724), the transactions ordered in the block may still be included in the block but marked as invalid, and state database 724 is not updated.

[0084] With reference to FIG. 7B, in some embodiments, a new data block 730 (also referred to as a data block) stored in the blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750, and block metadata 760. It should be understood that the various illustrated blocks and their contents, such as the new data block 730 and its contents illustrated in FIG. 7B, are examples only and are not intended to limit the scope of example embodiments. The new data block 730 may store transaction information for N (e.g., 1, 10, 100, 200, 1000, 2000, 3000, etc.) transactions in the block data 750. The new data block 730 may include a link to a previous block (e.g., on the blockchain 722 of FIG. 7A) in the block header 740. In particular, the block header 740 may include a hash of the header of the previous block. The block header 740 may include a unique block number for the new data block 730, a hash of the block data 750, etc. The block numbers for the new data block 730 are unique and may be assigned in various orders, such as a progressive / consecutive order starting from 0.

[0085] The block data 750 may store transaction information for each transaction recorded in the new data block 730. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, distributed ledger 720 channel ID, transaction ID, epoch, payload visibility, chaincode path (deploy transaction), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identification such as public key and certificate, client signature, signer identification, signer signature, proposal hash, chaincode event, response status, namespace, read set (e.g., list of keys and versions read by the transaction), write set (e.g., list of keys and values), start key, end key, list of keys, Merkel tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0086] In some embodiments, the block data 750 may store new data 762 that adds additional information to the hash-linked chain of blocks in the blockchain 722. The additional information may include one or more of the steps, features, processes, or operations, or combinations thereof, described or illustrated herein. Accordingly, the new data 762 may be stored in an immutable log of blocks on the distributed ledger 720. Some of the advantages of storing such new data 762 are reflected in various embodiments disclosed and illustrated herein. In FIG. 7B, the new data 762 is illustrated in the block data 750, but in some embodiments, the new data 762 may be in the block header 740 or block metadata 760. The new data 762 may include a document composite key used to link documents within an organization.

[0087] The block metadata 760 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, the last persistent offset of the ordering service that ordered the block, etc. The signature, the last constituent block, and the ordering node metadata may be added by the ordering service 710. Meanwhile, the committer of the block (e.g., blockchain node 712) may add valid / invalid information based on signature policies, validation of read / write sets, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 750, and a validation code that identifies whether the transaction was valid / invalid.

[0088] FIG. 7C illustrates an embodiment of a blockchain 770 for digital content, consistent with some embodiments. Digital content may include one or more files and associated information. These files may include transaction data, media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable append-only feature of some blockchain embodiments may be desirable in serving as a safeguard to protect the integrity, validity, and authenticity of the digital content, making the use of the digital content appropriate in legal proceedings where admissibility rules apply, or in other situations where evidence is considered or the presentation and use of digital information is otherwise subject. In this case, the digital content may be referred to as digital evidence.

[0089] In these embodiments, the blockchain may be formed in a variety of ways. In one embodiment, the digital content may be contained in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of the reference information (e.g., headers, values, etc.) along with the associated digital content. The hash value and the associated digital content may then be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a basis to reference the previous block. This may be shown as follows: Block 1 Block 2 ······ Block N Hash value 1 Hash value 2 Hash value N Digital Content 1 Digital Content 2 Digital Content N

[0090] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store an encrypted hash of the contents of each block that does not contain digital content. The digital content may be stored in a separate storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or may be a different storage area or a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block in question and then searching the storage area for the hash value stored that corresponds to the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be shown as follows: Blockchain Storage Area Hash value of block 1 Hash value of block 1...Contents · · · · · · Hash value of block N Hash value of block N... contents

[0091] In the example embodiment of FIG. 7C , the blockchain 770 comprises a number of cryptographically linked blocks 778 in an ordered sequence. 1 , 778 2 , ...778 N where N>=1. Block 778 1 , 778 2 , ...778 N The encryption used to link the , ... 1 , 778 2 , ...778 N is subjected to a hash function (where n is 256 or another number) that produces an n-bit alphanumeric output from an input that is based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, the Merkle-Dangard algorithm, the HAIFA algorithm, the Merkle tree algorithm, nonce-based algorithms, and non-collision resistant PRF algorithms. In another embodiment, block 778 1 , 778 2 , ..., 778 N may be cryptographically linked by a function different from the hash function. For illustrative purposes, the following description is given with reference to a hash function (eg, SHA-2).

[0092] Block 778 in the blockchain 1 , 778 2 , ..., 778 NEach of the may include a header, a version of the file, and a value. The header and value may vary from block to block as a result of hashing in the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the version of the file may be the original file or a different version of the original file.

[0093] The first block in the blockchain: 778 1 It is called the genesis block and has header 772 1 , original file 774 1 , and the initial value 776 1 The hashing scheme used for the genesis block (and indeed for all subsequent blocks) may vary. For example, the first block, 778 1 All information in may be hashed together at the same time, or the first block 778 1 Each or part of the information in may be hashed separately and then a hash of the separately hashed parts may be performed.

[0094] Header 772 1 may include one or more initialization parameters, such as a version number, a timestamp, a nonce, route information, difficulty, agreement protocol, duration, media format, source, descriptive keywords, or the original file 774 1 or other information associated with the blockchain or both, or a combination thereof. 1 may be generated automatically (e.g., by blockchain network management software) or manually by participants in the blockchain. 2 ~778 N Unlike the header in the genesis block, the header in 1 does not need to reference the previous block, since there is simply no previous block.

[0095] Original file 774 in the genesis block 1 may be, for example, data captured by a device, with or without processing before being included in the blockchain. Original file 774 1 may be received from a device, media source, or node through an interface of the system. 1 The metadata may be associated with metadata, which may be generated, for example, by a user, a device, or a system processor, or a combination thereof, either manually or automatically. 1 In relation to the first block 778 1 may be included in

[0096] Value 776 in the genesis block 1 The original file 774 1 In one embodiment, the one or more unique attributes may be an initial value generated based on one or more unique attributes of the original file 774. 1 hash value of the original file 774 1 This may include metadata and other information associated with the file. 1 may be based on the following unique attributes: (1) The hash value calculated for the original file using SHA-2 (2) Calling device ID (3) The start timestamp of the original file (4) The initial storage location of the original file (5) The blockchain network member ID of the software that currently controls the original file and associated metadata.

[0097] 778 other blocks in the blockchain 2 ~778 N also contains a header, file, and value. However, the first block's header 772 1Unlike the header 772 in other blocks 2 ~772 N Each of the remaining blocks contains the hash value of the immediately preceding block, which may simply be a hash of the previous block's header, or may be a hash value of the entire previous block. By including the hash value of the preceding block in each of the remaining blocks, a block-by-block tracing can be performed from the Nth block to the genesis block (and associated original file), as indicated by arrow 780, establishing an auditable and immutable evidential chain of custody.

[0098] Header 772 in another block 2 ~772 N Each of the may generally include other information (e.g., version numbers, timestamps, nonce, root information, difficulty, consensus protocols) or other parameters or information associated with the corresponding file or blockchain or both, or a combination thereof.

[0099] File 774 in other blocks 2 ~774 N may be the same as the original file in the genesis block or may be a modified version of the original file, depending, for example, on the type of processing performed. The type of processing performed may vary from block to block. Processing may include any modification of the file in the preceding block, such as, for example, editing information or otherwise changing the content of information, removing information from the file, or adding information to the file.

[0100] Additionally or alternatively, processing may include simply copying a file from a previous block, changing the storage location of the file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another storage or memory location, or performing operations on the file and / or associated metadata on the blockchain. Processing that includes analyzing a file may include, for example, adding, including, or otherwise associating various analyses, statistics, or other information associated with the file.

[0101] Another block in another block 776 2 ~776 N The value contained in each of the blocks is unique and different as a result of the operations that were performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. This update is reflected in the hash of the block to which the value was assigned. Thus, the value of a block provides an indication of what operations were performed in the block, and also makes it possible to trace the blockchain back to the original file. This tracing confirms the evidential integrity of the file throughout the blockchain.

[0102] For example, consider the case where a portion of a file in a previous block is edited, blocked, or pixelated to protect the identity of a person indicated in the file. In this case, the block containing the edited file will include metadata associated with the edited file, such as, for example, how the edit was performed, who performed the edit, a timestamp of when the edit occurred, etc. This metadata may be hashed to form a value. Because the metadata of the block is different from the information hashed to form the value in the previous block, the values ​​are different from each other and may be recovered when decrypted.

[0103] In one embodiment, the value of the previous block may be updated (e.g., a new hash value may be calculated) to form the value of the current block if any one or more of the following occurs: The new hash value, in this example embodiment, may be calculated by hashing all or part of the information set forth below: (a) A new SHA-2 computed hash value whenever the file is processed in any way (e.g., when the file is edited, copied, modified, accessed, or any other action is performed on it). (b) The new storage location of the file. (c) Identified new metadata associated with the file. (d) Transfer of access to or control of a file from one blockchain participant to another blockchain participant.

[0104] FIG. 7D illustrates an embodiment of a block that may represent the structure of a block in a blockchain 790, consistent with some embodiments. i ) is header 772 i , File 774 i , and the value 776 i may include:

[0105] Header 772 i is the previous block (block i-1 ) and additional reference information (e.g., header information containing references, characteristics, parameters, etc.), which may be any type of information. In some embodiments, every block may reference a hash of the previous block, except in some embodiments the genesis block. The hash value of the previous block may simply be a hash of the header in the previous block, or it may be a hash of all or part of the information in the previous block, including files and metadata.

[0106] File 774 imay in turn contain multiple pieces of data, such as Data 1, Data 2, ..., Data N. The data are tagged with Metadata 1, Metadata 2, ..., Metadata N that describe content and / or characteristics associated with the data. For example, the metadata for each piece of data may include information to indicate a timestamp for the data, keywords indicative of the process of the data, people or other content depicted in the data, or other characteristics that may be useful in establishing the validity and content of the file as a whole, and in particular for using digital evidence, e.g., as described in connection with the embodiments described below, or a combination thereof. In addition to the metadata, each piece of data may include a reference (references) to previous pieces of data to prevent tampering, gaps in the file, and successive references throughout the file. 1 ,reference 2 ,...,reference N ) may be tagged.

[0107] In some embodiments, after metadata is assigned to data (e.g., via a smart contract), the metadata cannot be changed without changing the hash, which can be easily identified as invalid. Thus, in these embodiments, the metadata creates a data log of information that may be accessed for use by participants in the blockchain.

[0108] In some embodiments, the value 776 i may be a hash value or other value calculated based on any of the types of information previously described. For example, i ), the value of that block may be updated to reflect the operation performed on that block (e.g., a new hash value, a new storage location, new metadata for the associated file, control or access transfer, an identifier, or other operation or added information). Although the values ​​in each block are shown as being separate from the metadata of the file and header data, in alternative embodiments the values ​​may be based in part or in whole on this metadata.

[0109] In some embodiments, at any point after the blockchain 770 is formed, an immutable evidential integrity of the file may be obtained by querying the blockchain for the transaction history of values ​​across blocks. This query or tracking procedure may begin by decrypting the value of the last included block (e.g., the last (Nth) block), and then continue to decrypt the values ​​of other blocks until the genesis block is reached and the original file is recovered. Decryption may include decrypting the header and file and associated metadata at each block.

[0110] Decryption may be performed based on the type of encryption performed on each block. This decryption may involve the use of a private key, a public key, or a public and private key pair. For example, if asymmetric encryption is used, a blockchain participant or a processor in the network may generate a public and private key pair using a predefined algorithm. The public and private keys may be related to each other by some mathematical relationship. The public key may be distributed publicly to serve as an address (e.g., an IP address or a home address) for receiving messages from other users. The private key may be kept secret and may be used to digitally sign messages sent to other blockchain participants. The signature may then be included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be sure that only the sender could have sent this message.

[0111] In some embodiments, generating a key pair may be similar to creating an account on the blockchain, but without the need to actually register anywhere. In these embodiments, every transaction performed on the blockchain may be digitally signed by the sender using a private key. This signature may help ensure that only the account owner (if within the scope of permissions determined by the smart contract) can track and transact files on the blockchain.

[0112] Computer Program Products Although the present invention has been described in detail with reference to specific examples of the invention, it may be embodied in other specific forms without departing from the essential spirit or attributes of the invention. For example, the present invention may be a system, a method, or a computer program product, or a combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium that includes computer-readable program instructions for causing a processor to perform aspects of the invention. The computer-readable program instructions may be stored or executed on a single computer, or may be divided among different computers, at the same or different locations, for storage and execution.

[0113] A computer readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The 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 thereof. 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 disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridges in a groove on which instructions are recorded, and any suitable combinations of these. As used herein, computer-readable storage media should not itself be construed as being ephemeral signals 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 a fiber optic cable), or electrical signals transmitted over wires.

[0114] The computer readable program instructions described herein may be downloaded from a computer readable storage medium to each computing device / processing device or to an external computer or storage device over a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof) that may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing device / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions for storage on a computer readable storage medium within each computing device / processing device.

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

[0116] These computer readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, produce means for implementing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions may be stored on a computer readable storage medium, such that the computer readable storage medium on which the instructions are stored comprises an article of manufacture including instructions for implementing aspects of the functions / operations 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.

[0117] The computer readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device to generate a computer-implemented process and cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device, such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0118] general 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 the flowchart or block diagram may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions shown in the blocks may occur in a different order than the order shown in the figures. For example, two blocks shown in succession may in fact be realized as one step, may be executed simultaneously, substantially simultaneously, in a partially or fully overlapping manner in time, or may be executed in reverse order, depending on the functionality involved. It is also noted that each block in the block diagrams and / or flowchart illustrations, as well as combinations of blocks included in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that executes the specified functions or operations, or executes a combination of dedicated hardware and computer instructions.

[0119] Aspects of the present invention have been described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks included in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions. Moreover, 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 the flowchart or block diagrams may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur in an order different from that shown in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently or in the reverse order, depending on the functionality involved. It is also noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks included in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or operations or execute a combination of special purpose hardware and computer instructions.

[0120] The names of specific programs used in this description are merely for convenience, and thus the present invention should not be limited to use with only the specific application identified and / or implied by such names. Thus, for example, the routines executed to implement embodiments of the present invention could be referred to as a "program," an "application," a "server," or other meaningful name, whether implemented as part of an operating system or a specific application, component, program, module, object, or sequence of instructions. Indeed, other alternative hardware and / or software environments may be used without departing from the scope of the present invention.

[0121] The presently described embodiments are therefore considered in all respects to be illustrative and not restrictive, and reference should be made to the appended claims to determine the scope of the invention.

Claims

1. 1. A method for coordinating an access management process, comprising: receiving, by a computer, a request to access a controlled resource of an information system, the managed resource being one of a plurality of managed resources of a plurality of information systems, each of the plurality of information systems being associated with a local access control system; querying, by the computer, permission to access the managed resource from an access manager; in response to the query for permission, the computer requests an update of an access control policy to grant access privileges to the managed resource; in response to approval of the request to update the access control policy, the computer calls one of the local access control systems associated with an information system of the plurality of information systems to request a change to a local authorization policy; Including, Receiving the request, querying the permission, and requesting an update of the access control policy each include: said computer generating a transaction record; and The computer adds the transaction record to a distributed ledger, the distributed ledger maintaining the transaction record simultaneously at multiple nodes across a blockchain network. Including, and requesting an update to the access control policy includes executing a smart contract to process transactions in the distributed ledger. The method for adjusting the access management process.

2. 2. The method of claim 1 , wherein the transaction records are exchanged among the multiple nodes of the distributed ledger.

3. The method of claim 1 or 2, wherein the plurality of nodes are interconnected via a cryptographically secured channel.

4. 4. The method of claim 1, wherein the transaction record includes at least one management action selected from the group consisting of an access authority request action, an access authority approved action, an access authority denied action, an access authority granted action, an access authority revoked action, and an access authority revoked action.

5. The method of claim 4 , wherein the management action associated with the authorized action modifies an authorization policy to grant the user's access to the one information system.

6. The method of claim 4 or 5, wherein the management action associated with the access permission revocation action modifies an authorization policy to deny the user access permission to the one information system.

7. The computer transmitting the generated transaction records to the one information system; and said computer automatically executing said management operation on said one information system; The method of any one of claims 4 to 6, further comprising:

8. 1. An access management control orchestrator including a peer node associated with a blockchain network, the blockchain network including a plurality of nodes associated with at least one of an asset owner function, an administrator function, and an auditor function, the peer node comprising: receiving a request to access a controlled resource of an information system, the managed resource being one of a plurality of managed resources of a plurality of information systems, each of the plurality of information systems being associated with a local access control system; Recording access authority request records from users of the information system in a distributed ledger; recording an owner authorization record from the asset owner function, the owner authorization record being responsive to the access authority request record in the distributed ledger; executing a smart contract in response to the access authority request record and the owner authorization record to grant access authority to one of the plurality of information systems, the smart contract modifying an authorization policy to allow the user's access authority to the one information system; recording an execution record of the smart contract in the distributed ledger; is adapted to carry out modifying the authorization policy includes invoking one of the local access control systems to request a change to a local authorization policy in response to approval of a request to update an access control policy. The access management control orchestrator.

9. The peer node: storing one or more of the access authority request record, the owner approval record, and the execution record in a transaction block; selecting one of the plurality of nodes as a signing node for signing the transaction block according to an agreement protocol; signing the transaction block by the selected signing nodes; The access management control orchestrator of claim 8 , further adapted to execute:

10. The peer node: receiving a new peer request to add a new node to the blockchain network; sending the new peer request to the plurality of nodes in the blockchain network for approval according to a consensus protocol; 10. The access management control orchestrator of claim 8 or 9, further adapted to execute:

11. 11. The access management control orchestrator of claim 8, wherein modifying the authorization policy includes invoking a local access control system associated with the information system and requesting a change to a local authorization policy.

12. 12. The access management control orchestrator of claim 8, wherein the peer nodes are further adapted to review the distributed ledger for execution records that are not associated with an owner approval record.

13. A computer for coordinating an access management process, comprising: receiving a request to access a controlled resource of an information system, the managed resource being one of a plurality of managed resources of a plurality of information systems, each of the plurality of information systems being associated with a local access control system; Querying authorization to access the managed resource from an access manager; requesting an update of an access control policy to grant access privileges to the managed resource in response to the query for authorization; in response to approval of the request to update the access control policy, calling one of the local access control systems associated with an information system of the plurality of information systems to request a change to a local authorization policy; Run Receiving the request, querying the permission, and requesting an update of the access control policy each include: said computer generating a transaction record; and adding the transaction record to a distributed ledger, the distributed ledger maintaining the transaction record simultaneously at multiple nodes across a blockchain network; Including, and requesting an update to the access control policy includes executing a smart contract to process transactions in the distributed ledger. The computer.

14. The computer of claim 13, wherein the transaction record includes at least one management action selected from the group consisting of an access authority request action, an access authority approved action, an access authority denied action, an access authority granted action, an access authority revoked action, and an access authority revoked action.

15. The computer described in claim 14, wherein the management action associated with the access permission revocation action modifies an authorization policy to allow the user access permission to the one information system or modifies an authorization policy to deny the user access permission to the one information system.

16. A computer program product, the computer program product being configured to cause a computer to carry out the method according to any one of claims 1 to 7.

17. 17. A computer readable medium having recorded thereon the computer program of claim 16.

Images