Patent Description:
Cloud computing is a computing framework that enables ubiquitous and on-demand network access to a shared pool of computing resources that are configurable and capable of being rapidly provisioned and released with minimal inputs from the service provider's point of view. Cloud computing can be deployed in several formats, including, public cloud platforms, private cloud platforms, hybrid cloud platforms, and community cloud platforms. Three of these formats facilitate the sharing of cloud-computing resources among different organizations/tenants. While sharing of such resources is helpful to alleviate the costs associated with operating and maintaining the resources, sharing also presents several challenges. In particular, sharing of cloud-computing resources makes it difficult to accurately maintain usage audit logs for the resources.

Most audit functions aim to provide the following requirements: (<NUM>) non-repudiation; (<NUM>) sequence integrity and checking; (<NUM>) proof of reliable audit; (<NUM>) performance, scalability and cost; (<NUM>) isolation of tenant audit; (<NUM>) security of audit; and (<NUM>) durability of logs. It is incredibly difficult to meet all of the above requirements in a cloud-computing environment where the computing resources are shared among a plurality of organizations/tenants.

Not only do audit functions aim to meet the above requirements, but most audit functions will not be desirable unless they can also maintain an adequate durability, are properly scalable, and highly available. Thus, what is needed is an audit function that can meet all of the above requirements and preferences, while operating on shared cloud-computing resources.

Further relevant prior art is disclosed in <CIT>,.

It is with respect to the above that embodiments of the present disclosure were contemplated. In particular, embodiments of the present disclosure contemplate a method for maintaining a log of events in a shared computing environment.

In particular it is provided a method defined in claim <NUM> and a system defined in claim <NUM>. Further preferred embodiments are described in the dependent claims.

The phrases "at least one," "one or more," and "and/or" are open-ended expressions that are both conjunctive and disjunctive in operation. For example, each of the expressions "at least one of A, B and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C" and "A, B, and/or C" means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together. When each one of A, B, and C in the above expressions refers to an element, such as X, Y, and Z, or class of elements, such as X<NUM>-XN, Y<NUM>-Ym, and Z<NUM>-Zo, the phrase is intended to refer to a single element selected from X, Y, and Z, a combination of elements selected from the same class (e.g., X<NUM> and X<NUM>) as well as a combination of elements selected from two or more classes (e.g., Y<NUM> and Zo).

The term "a" or "an" entity may refer to one or more of that entity.

The present disclosure is described in conjunction with the appended figures, which are not necessarily drawn to scale:.

The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyrights whatsoever.

Before any embodiments of the disclosure are explained in detail, it is to be understood that the disclosure is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings.

With reference to <FIG>, an illustrative computing system <NUM> will be described in accordance with at least some embodiments of the present disclosure. The system <NUM> is shown to include a communication network <NUM> that facilitates machine-to-machine communications between one or more client devices <NUM> and one or more client service resources <NUM>. An audit system <NUM> is also shown as being connected to the communication network <NUM>.

In some embodiments, the various client devices <NUM> and client service resources <NUM> may be configured to communicate using various nodes or components of the communication network <NUM>. The communication network <NUM> may comprise any type of known communication medium or collection of communication media and may use any type of protocols to transport messages between endpoints. The communication network <NUM> may include wired and/or wireless communication technologies. The Internet is an example of the communication network <NUM> that constitutes an Internet Protocol (IP) network consisting of many computers, computing networks, and other communication devices located all over the world, which are connected through many telephone systems and other means. Other examples of the communication network <NUM> include, without limitation, a standard Plain Old Telephone System (POTS), an Integrated Services Digital Network (ISDN), the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Session Initiation Protocol (SIP) network, a Voice over Internet Protocol (VoIP) network, a cellular network, and any other type of packet-switched or circuit-switched network known in the art. In addition, it can be appreciated that the communication network <NUM> need not be limited to any one network type, and instead may be comprised of a number of different networks and/or network types. Moreover, the communication network <NUM> may comprise a number of different communication media such as coaxial cable, copper cable/wire, fiber-optic cable, antennas for transmitting/receiving wireless messages, and combinations thereof.

The client devices <NUM> may correspond to any type of computing resource that includes a processor, computer memory, and a user interface. The client devices <NUM> may also include one or more network interfaces that connect the client device <NUM> to the communication network <NUM> and enable the client device <NUM> to send/receive packets via the communication network <NUM>. Non-limiting examples of client devices <NUM> include personal computers, laptops, mobile phones, smart phones, tablets, etc. In some embodiments, the client devices <NUM> may be configured to access or utilize the client service resources <NUM> with one or several applications stored in memory of the client device <NUM>. As an example, a client device <NUM> may access the client service resource(s) <NUM> with assistance from a browser application running on the client device <NUM>. Other types of applications such as transaction applications, communication applications, voicemail applications, word processing applications, etc. may also be used on the client device <NUM> to access the client service resource(s) <NUM>.

In some embodiments, the client devices <NUM> may be owned, operated and/or administered by different entities 112a, 112b. As a non-limiting example, some of the client devices <NUM> may be owned, operated and/or administered by a first entity 112a whereas other client devices <NUM> may be owned, operated and/or administered by a second entity 112b. It should be appreciated that other client devices <NUM> may not necessarily be grouped and belong to an entity. For instance, a single client device may be associated with an entity without departing from the scope of the present disclosure. Additionally, although <FIG> only depicts two entities 112a, 112b sharing the client service resources <NUM>, it should be appreciated that many more than two entities may share the client service resources <NUM> without departing from the scope of the present disclosure.

The client service resource(s) <NUM> are depicted as belonging to a shared computing environment <NUM>. As a more specific reference, the client service resource(s) <NUM> may be referred to as cloud-computing resources in that the resource(s) <NUM> are part of a cloud platform, which is connected to a communication network <NUM> and is made available to a plurality of different client devices <NUM> being owned, operated and/or administered by different entities 112a, 112b. The shared computing environment <NUM> may be configured as one or more of a public cloud platform, a hybrid cloud platform, or a community cloud platform. As an example, the shared computing environment <NUM> may be a cloud computing platform such as the Amazon Web Services platform, Microsoft Azure platform, Google cloud platform, or IBM cloud platform. The configuration of the shared computing environment <NUM> facilitates the sharing of resources <NUM> among different entities 112a, 112b, which may also be referred to as different organizations or different tenants. While sharing of such resources <NUM> is helpful to alleviate the costs associated with operating and maintaining the resources <NUM>, sharing of the resources <NUM> makes it difficult to maintain tamper resistant usage audit logs for the resources <NUM>. As will be discussed in further detail herein, the audit system <NUM> may be provided with one or several components that enable an accurate and secure tracking of the usage of resources <NUM> by the various client devices <NUM> owned, operated and/or administered by different entities/tenants 112a, 112b. The client service resource(s) <NUM> may be provided as one or more servers (or virtualized servers) operating in a cloud platform. As such, the client service resources <NUM> may include one or multiple processors, one or multiple computer memory devices, and one or more network interfaces that enable the server to communicate via the communication network <NUM>.

<FIG> also shows that the audit system <NUM> may be configured to communicate directly with the one or more client service resources <NUM>. As an example, the resource(s) <NUM> may be configured to send a data stream or multiple data streams to the audit system <NUM>. Whether received directly from the resource(s) <NUM> or via the communication network <NUM>, the audit system <NUM> may be configured to process the multiple data streams received from the shared computing environment <NUM>. In some embodiments, the audit system <NUM> may include auditing components <NUM> that enable the audit system <NUM> to generate audit logs for the usage of resource(s) <NUM> by the different entities/tenants 112a, 112b. Audit logs or information related to audit logs may be stored, temporarily or permanently, in an audit log database <NUM>. As will be discussed in further detail herein, the audit system <NUM> may utilize the auditing components <NUM> to enable the various entities/tenants 112a, 112b to access their audit log data from the audit log database <NUM> without exposing audit log data for other entities that are also using the resource(s) <NUM> and having their usage information stored in the audit log database <NUM>.

In addition to the auditing components <NUM>, the audit system <NUM> may include reporting components <NUM> that enable the audit system <NUM> to generate reports for the entities/tenants 112a, 112b and/or allow the entities/tenants 112a, 112b to search within the audit log database <NUM>. Alternatively or additionally, the reporting components <NUM> may be configured to generate usage reports for entities other than the entities/tenants 112a, 112b that are using the resources <NUM>. For instance, the reporting components <NUM> may be used to provide audit logs or historical usage information for the resources <NUM> to independent third parties, such as financial auditors, compliance auditors, governmental entities, or any other entity that has a legitimate interest in the usage information for the resource(s) <NUM> but does not otherwise utilize the resource(s) <NUM> themselves.

<FIG> also shows that the audit system <NUM> and audit log database <NUM> may be provided within the shared computing environment <NUM>. This configuration of system elements may be an alternative arrangement to having the audit system <NUM> and audit log database <NUM> positioned outside the shared computing environment <NUM>. Thus, in some embodiments, the entirety of the audit log solution may be completely self-contained within the shared computing environment <NUM> rather than being provided as a system or service outside the shared computing environment. As a more specific, but non-limiting example, the functionality of the audit system <NUM> may be provided on top of one of the client service resource <NUM>, although such a configuration is not a requirement.

With reference now to <FIG> and <FIG>, additional details of an audit system <NUM> will be described in accordance with at least some embodiments of the present disclosure. A first possible configuration of system <NUM> is shown in <FIG>. The system <NUM> may be similar or identical to the audit system <NUM> depicted in <FIG>. It should further be noted that some or all of the components of system <NUM> may be provided as part of a client device <NUM>. Moreover, one, some, or all of the components depicted in system <NUM> may be provided in any type of configuration and not all of the components may be required to provide the desired functionality of the system <NUM> described herein.

With reference initially to <FIG>, the system <NUM> is shown to include a plurality of tenant inputs 204a, 204b, 204c that are fed to a load balancer <NUM>. The plurality of tenant inputs 204a, 204b, 204c may be received as raw data streams from the client service resources <NUM>. In some embodiments, the inputs may include information that describe transactions conducted in the shared computing environment <NUM> on behalf of the various entities/tenants that are logging in/out, accessing, using, and sharing the resources <NUM> within the environment <NUM>. The tenant inputs 204a, 204b, 204c may optionally be provided to the load balancer <NUM> in an encrypted or unencrypted format, depending upon the sensitivity of the usage data and whether or not the system <NUM> is contained within the shared computing environment <NUM> and is directly accessing the resources <NUM> or if the tenant inputs 204a, 204b, 204c are being communicated over an untrusted communication network <NUM>. As a non-limiting example, the tenant inputs 204a, 204b, 204c may each correspond to streams of data that describe transactions executed by clients of entities/tenants within the resources <NUM>. The data contained in the streams 204a, 204b, 204c may include: a relative time that a transaction occurred; an actual time that a transaction occurred; an identification of an entity/tenant that conducted the transaction; an identification of a particular resource <NUM> that conducted the transaction; an identification of transaction type; an identification of a client <NUM> that requested the transaction; an identification of other parties to the transaction; and combinations thereof.

The load balancer <NUM> may be implemented as a simple data switch or a more intelligent switch/server that is able to analyze the various inputs 204a, 204b, 204c and redirect those inputs to an appropriate audit server <NUM>. In some embodiments, the load balancer <NUM> attempts to ensure that particular tenant inputs are only provided to a subset of the audit servers <NUM>. In some embodiments, the load balancer <NUM> may utilize one or more load balancing techniques (e.g., round robin, weighted round robin, least connection, chained failover, weighted response time, source IP hash, etc.) to determine which of the audit servers <NUM> are to receive a particular tenant input 204a, 204b, 204c. It should be appreciated that the load balancer <NUM> may not be required in instances where a single audit server <NUM> is used to process all of the tenant inputs 204a, 204b, 204c. In a system <NUM> having two or more audit servers <NUM>, the load balancer <NUM> is useful to ensure that no single audit server <NUM> becomes overloaded or underloaded as compared to other audit servers <NUM> in the group of audit servers <NUM>.

In the depicted embodiment, each audit server <NUM> is provided with an audit trail adapter <NUM>, which may correspond to instructions stored in memory of the audit server <NUM> that are executed by a processor of the audit server <NUM> in connection with creating and maintaining audit logs for the various tenant inputs 204a, 204b, 204c. Each audit trail adapter <NUM> may be similar or identical to other audit trail adapters <NUM> in the various audit servers <NUM>. In some embodiments, each audit trail adapter <NUM> is configured to receive the data stream inputs from the load balancer <NUM> and then create, based on the one or more data streams, blockchain entries for transactions conducted in the shared computing environment <NUM>. As the audit trail adapters <NUM> may be configured to generate multiple blockchain entries, each subsequently-generated blockchain entry may be created to include a signature that points back to a blockchain entry previously generated by the audit trail adapter <NUM>. In this way, a plurality of blockchain entries can be created and linked together for writing to a blockchain data structure <NUM>.

The example of <FIG> shows one instance of an audit server <NUM> receiving data from the first tenant's data stream 204a and the third tenant's data stream 204c, another instance of an audit server <NUM> receiving data from the second tenant's data stream 204b and the third tenant's data stream 204c, and another instance of an audit server <NUM> receiving data from the second tenant's data stream 204b. In some embodiments, each audit trail adapter <NUM> of each audit server <NUM> is configured to capture the data streams originating from various sources 204a, 204b, 204c and record them in individual blockchain entries. Audit trail records may then be combined at an Application Programming Interface (API) gateway <NUM>, which is hosted by a RESTful service <NUM>. The API gateway <NUM> is configured to combine and coordinate the writing of the blockchain entries generated by the various audit servers <NUM> into a common blockchain data structure <NUM>, which can be stored in a database <NUM>. Each blockchain entry generated at the audit trail adapters <NUM> may be represented by a PlatformID (e.g., identifying an originating application) and/or a TenantID (e.g., identifying an individual entity/tenant). The originating audit trail adapter <NUM> can, but does not have to, provide a sequence number for individual audit trail records or entries being written to the audit trail records. As an example, the audit trail adapters <NUM> may generate sequence numbers or the API gateway <NUM> may generate the sequence numbers on behalf of each audit trail adapter <NUM>; however, in a multi-node configuration, distributed application flows of the audit trail records must happen asynchronously to fulfill scalability requirements, which could affect the real chronological order. To minimize this negative effect, either the client service resource(s) <NUM> or the audit trail adapters <NUM> can generate the sequence numbers or timestamps. If sequence numbers or timestamps are not generated in this way, then the analytics engine <NUM> and/or reporting engine <NUM> may be left to judge/determine the chronological order of the audit log entries maintained in the blockchain data structure <NUM> based on the generated sequence number (which could be misleading) and/or the timestamps (which could be also misleading).

In some embodiments, the various servers that are responsible for generating timestamps for a transaction may have their clocks synchronized with one another. As a more specific example, all applications nodes may be synchronized within an auto-scaling group. To achieve this it may be desirable to utilize the Network Time Protocol (NTP) and a time-synchronization service. Such synchronization helps to ensure each audit server <NUM>, for example, is operating with clocks that are substantially or at least nearly synchronized (e.g., within an acceptable tolerance, such as <NUM>-<NUM>, of each other).

As can be appreciated, the database <NUM> may be configured to store some or all of the blockchain data structure <NUM> and the blockchain data structure <NUM> may be made available to some or all of the entities/tenants that are utilizing the shared computing environment <NUM> and having their resource utilizations logged and audited. In some embodiments, the blockchain data structure <NUM> may be replicated across one or more databases <NUM>. For example, databases <NUM> may be hosted within separate cloud platforms or maintained on servers owned, operated and/or administered by different entities. Access to the database <NUM> may be made via database lookup requests that identify a particular blockchain entry to be retrieved. In this situation, the blockchain entry may be retrieved from the blockchain data structure with reference to a particular blockchain entry identifier. Alternatively or additionally, access to the database <NUM> may be made via a lookup request that identifies a tenant identifier, platform ID, or the like, and all entries found in the blockchain data structure <NUM> can be returned to the requesting entity (assuming the requesting entity provided appropriate proof of access to those entries). It should also be noted that the database <NUM> may be accessible through the RESTful service <NUM> and/or API <NUM>.

An analytics server <NUM> may be utilized to execute an analytics engine <NUM>. In some embodiments, the analytics engine <NUM> is used to analyze entries made to the blockchain data structure <NUM> to determine if one or more entries correspond to anomalous entries. This analysis may occur as entries are written to the data structure <NUM> or offline after multiple entries have been written to the data structure <NUM>. As can be appreciated, the analytics engine <NUM> may have access to one or more usage models that describe normal or expected usage behaviors for the shared computing environment. These models of normal or expected usage behaviors may be entity/tenant specific or generic to a plurality of entities/tenants. In the event that one or more blockchain entries written to the blockchain data structure <NUM> fall outside of the models of normal or expected usage behaviors (e.g., an anomalous behavior is detected), then analytics engine <NUM> may interface with a reporting engine <NUM> operated by a reporting server <NUM> to generate a report or alert for the entity/tenant associated with the anomalous behavior.

The reporting engine <NUM> may be configured to generate reports that describe entries made to the blockchain data structure <NUM> or transactions described within those blockchain entries. As an example, the reporting engine <NUM> may be configured to generate periodic/regular reports about each entity's/tenant's usage of the resource(s) <NUM> over a predetermined amount of time (e.g., daily, weekly, monthly, etc.). Alternatively or additionally, the reporting engine <NUM> may be configured to generate special non-periodic reports in response to the analytics engine <NUM> detecting anomalous usage behaviors of any entity or tenant. These non-periodic reports may be transmitted to the same recipients of the periodic/regular reports or the non-periodic reports may be transmitted to other recipients. In some embodiments, recipients of the reports generated by the reporting engine <NUM> may include personnel within an associated entity/tenant or third parties that do not belong to the associated entity/tenant. As an example, regular reports may be generated and sent to a comptroller working within an associated entity and/or to an external auditing authority. Access to the reports for the external auditing authority may require approval from the comptroller working within the associated entity and such authority may be granted by sharing a unique tenant ID assigned to the entity or by sharing one or more decryption keys used by the entity to decrypt payloads of blockchain entries. It should be appreciated that the reporting server <NUM> and analytics server <NUM> may access the database <NUM> using any type of known blockchain or database-accessing protocols known in the art.

Although the database <NUM> is depicted as a centralized database that stores the blockchain data structure <NUM>, it should be appreciated that embodiments of the present disclosure are not so limited. For instance, the database <NUM> may actually be managed autonomously using a peer-to-peer network and the distributed timestamping servers <NUM>. Entries to the blockchain data structure <NUM> may be authenticated by mass collaboration of distributed client devices, which may or may not belong to the various entities/tenants <NUM>. As is known in blockchain technologies, the actual blockchain entries in the blockchain data structure <NUM> may be stored among a plurality of different and distributed devices that are participants to the blockchain peer-to-peer network. Because a peer-to-peer network may be used for the database <NUM>, it should be appreciated that the analytics server <NUM> and/or reporting server <NUM> may be member participants to the peer-to-peer network. In addition to accessing blockchain entries made to the data structure, the resources of the servers <NUM>, <NUM> may also be used to authenticate entries prior to allowing such entries to be written to the data structure <NUM>. Further still, in the sense of a cloud-computing environment, the database <NUM> may be automatically distributed and may not necessarily be provided as a peer-to-peer network.

<FIG> depicts a second configuration of the system <NUM> whereby the functionality of the audit server <NUM> and/or audit trail adapter <NUM> is provided behind the API gateway <NUM> and/or RESTful service <NUM>. It should be noted that the RESTful service <NUM> may correspond to an optional component to help speed up the overall operations of the system <NUM>. In this particular configuration, the audit trail adapter <NUM> is positioned behind the API gateway <NUM>, making it possible to provide the audit trail adapter <NUM> within a cloud-computing environment. Although not depicted, it should also be appreciated that the audit trail adapter <NUM> may have its own load balancer <NUM> rather than relying upon the capabilities of an external load balancer <NUM>. This particular configuration may also enable the load of an audit trail service to be moved to client devices (e.g., in an embodiment where client devices are enabled to calculate their own sequence numbers).

With reference now to <FIG>, additional details of a server <NUM> will be described in accordance with at least some embodiments of the present disclosure. The server <NUM> may correspond to an example of a client service resource <NUM>, an audit server <NUM>, an analytics server <NUM>, a reporting server <NUM>, or any other type of server/computing device depicted and described herein. Although the server <NUM> is shown as having various components to perform the functionality associated with multiple types of servers described herein, it should be appreciated that different physical servers or different virtualized servers may be used for the different server functions. For example, an instance of a server <NUM> may be used as the analytics server <NUM> whereas another instance of a server <NUM> may be used as the reporting server <NUM>. It may be possible, however, to have an instance of a server <NUM> provide multiple functions. For example, one instance of a server <NUM> may include functionality to behave as an audit server <NUM> as well as an analytics server <NUM>. The depiction of the server <NUM> as a single device is simply for ease of conversation and understanding and should not be construed as limiting embodiments of the present disclosure.

The server <NUM> is depicted to include one or more processors <NUM>, memory <NUM>, one or more network interfaces <NUM>, and a power supply <NUM>. If embodied as something other than a server, the server <NUM> may further include user input and/or output devices.

The processor <NUM> may include one or more CPUs, General Processing Units (GPUs), Integrated Circuit (IC) chips, microprocessors, etc. Alternatively or additionally, the processor <NUM> may include other hardware components that are capable of executing the instructions stored in memory <NUM>.

The memory <NUM> may be configured to store processor-executable instructions in volatile or non-volatile memory devices. The types of instructions that may be stored in memory <NUM> include, without limitation, audit adapter instructions <NUM>, analysis instructions <NUM>, reporting instructions <NUM>, and blockchain updating instructions <NUM>. The audit adapter instructions <NUM> may enable the server <NUM> to operate as or behave like the audit server <NUM>. More specifically, the audit adapter instructions <NUM> may enable functionality of the audit trail adapter <NUM>. For instance, the audit adapter instructions <NUM> may include instructions that cause the processor <NUM> to generate blockchain entries, populate those entries with appropriate information, and cause the entries to point or refer to previously-generated entries. Furthermore, the audit adapter instructions <NUM> may include instructions that enable the processor <NUM> to sequence blockchain entries and/or create sequence ID/timestamp information for inclusion with the blockchain entries.

The analysis instructions <NUM> may enable the server <NUM> to operate as or behave like the analytics server <NUM>. More specifically, the analysis instructions <NUM> may include instructions that enable the processor <NUM> to access the blockchain data structure <NUM>, analyze particular entries made to the blockchain data structure <NUM>, and determine if such entries fall within or outside of an expected behavior pattern. The analysis instructions <NUM> may be configured to analyze specific blockchain entries or a collection of blockchain entries. The analysis may be performed on contents of a blockchain entry.

The reporting instructions <NUM> may enable the server <NUM> to operate as or behave like the reporting server <NUM>. More specifically, the reporting instructions <NUM> may include instructions that enable the processor <NUM> to generate one or more reports for transmission to various concerned users/persons/entities/tenants. For instance, the reporting instructions <NUM> may include information that describes what information to include in a particular report, how to format the information for the particular report (e.g., a definition of file type to use and layout preferences), and how to transmit the particular report to a predetermined recipient (e.g., via email, text message, SMS message, etc.).

The blockchain updating instructions <NUM> may enable the server <NUM> to act as a participant in the peer-to-peer blockchain network that maintains and updates the blockchain data structure <NUM>. In some embodiments, the blockchain updating instructions <NUM> enable the processor <NUM> to authenticate or validate blockchain entries prior to allowing such entries to be written to the blockchain data structure <NUM>. For example, the blockchain updating instructions <NUM> may include instructions for analyzing a signature included in a blockchain entry, compare the signature against blockchain entries already written to the blockchain data structure <NUM>, and determine if the signature is a valid signature and refers to a valid blockchain entry. As can be appreciated, the blockchain data structure <NUM> may correspond to a distributed ledger describing transaction information for the shared computing environment <NUM>. As such, the data structure <NUM> may be immutable and entries written thereto should not be capable of being re-written or modified. Rather, modifications to the entries may only be made by writing a new entry to the blockchain data structure <NUM>.

The network interface(s) <NUM> may correspond to one or more hardware devices that connect the server <NUM> to the communication network <NUM>. For instance, the network interface(s) <NUM> may include one or more wired or wireless serial or parallel data ports. As a more specific example, the network interface(s) <NUM> may include an Ethernet port, a SCSI port, or the like. The network interface(s) <NUM> may also include drivers for the hardware components thereof.

The power supply <NUM> may correspond to internal and/or external power supply devices. For instance, the power supply <NUM> may correspond to a battery pack, capacitive charge device, or the like. Alternatively or additionally, the power supply <NUM> may correspond to a power adapter that enables the server to receive AC power from an external outlet and convert that AC power into DC power or useable power for the components of the server.

With reference now to <FIG> and <FIG>, additional details of the blockchain data structure <NUM> and entries that can be made thereto will be described in accordance with at least some embodiments of the present disclosure. With reference initially to <FIG>, it can be seen that the different audit trail adapters <NUM> are configured to write their own sets of blockchain entries 404a, 404b, 404c. As can be appreciated, the blockchain entries written by any of the audit trail adapters <NUM> may depend upon the data stream or transaction details received from the various tenant inputs 204a, 204b, 204c. In the illustrative example, one audit trail adapter <NUM> generates a first entry for a first tenant, followed by a first entry for a second tenant, followed by a second entry for the first tenant. Each entry may point to a previous entry in the set of entries 404a. Furthermore, each entry in the set of entries 404a may be ordered according to a time of occurrence or sequenced order. This effectively means that the first entry for the first tenant correspond to a transaction that occurred within the shared computing environment <NUM> prior to a transaction described in the first entry for the second tenant. As such, the first entry for the second tenant may include a signature that points to the first entry for the first tenant.

Each set of entries 404a, 404b, 404c may be provided to a blockchain server <NUM>, which is configured to write one or more entries <NUM> to an elastic cache <NUM> as well as write one or more entries to the blockchain data structure <NUM>. It should be appreciated that the blockchain data structure <NUM> may be similar or identical to blockchain data structure <NUM>.

In some embodiments, the blockchain server <NUM> may be executed within the RESTful service <NUM>, as part of the audit servers <NUM>, or in some other server connected to the various components depicted in <FIG>. The blockchain server <NUM> may be configured to process sets of entries <NUM> received from the various audit trail adapters <NUM> in batches (e.g., in batches of <NUM> entries). Alternatively or additionally, this batch processing may be performed at the audit trail adapters <NUM>, meaning that batches of entries are sent to the server <NUM> in the form of sets of entries <NUM>. After processing a batch of entries <NUM> in an audit trail adapter <NUM>, it may be desirable to leverage the shared elastic cache <NUM> to write a hash(es) of a last processed event(s) in the set of entries <NUM>. In this way other nodes (e.g., other audit trail adapters <NUM>) can still re-use previously created blockchain entries that were created by other nodes to build the common blockchain data structure <NUM>.

The blockchain server <NUM> may also provide a data integrity service by creating a chronological record of the time the entries are signed, the identity of who signed the entries, and assurance that the entries have not been changed after being signed. This can provide an auditable trail of the chain of custody. Independent verification of the integrity of entries is possible using the media published publication code and the signature to prove the integrity of the entries. The lifecycle integrity of entries can be monitored by continuously verifying the entries in near-real-time and generating alerts at the reporting engine <NUM> in the event of a failure.

To achieve these features, the blockchain server <NUM> could be configured to store hashes of blockchain entries in a separate place than the blockchain data structure <NUM> (e.g., in the elastic cache <NUM>). In some embodiments, the hashes of the blockchain entries can be calculated on timestamps and other non-encrypted data contained in the entries. Storing hashes outside the blockchain data structure <NUM> would give another confidence level that when data which has been already recorded is corrupted, tampering can still be detected.

<FIG> further shows how the various sets of blockchain entries can be linked to one another within the blockchain data structure <NUM>. This linking, as discussed above, can be ordered according to time of transaction or sequence number. Thus, the earlier entries in the blockchain data structure <NUM> may represent transactions that occurred prior to other entries in the blockchain data structure <NUM>, regardless of which entity/tenant performed the transaction and which resource <NUM> was used to perform the transaction.

<FIG> depicts further details of blockchain entries 504a, 504b, 504c that may be created and added to the blockchain data structure <NUM>. Each blockchain entry may include a block identification portion <NUM>, a publicly-available data portion <NUM>, and a payload portion <NUM>. In some embodiments, the payload portion <NUM> may undergo pseudonymization such that sensitive data (e.g., personal identifiable information) is replaced by one or more artificial identifiers or pseudonyms. In this manner, the sensitive data can be masked (less identifiable) while remaining suitable for data analysis and processing. In one embodiment, the payload portion <NUM> may be tokenized with a tokenization service. In such an embodiment, each tenant would be provided with its own tokenization dictionary grouped per the tenant's user, thereby ensuring that no sensitive information is exposed within the payload portion <NUM>.

An entry may also include a signature or pointer to the previous entry written to the blockchain data structure <NUM>. As an example, the second entry 504b is shown to have a signature that points to the first entry 504a. This signature may correspond to a signature that references the unique identifier of the previous entry in the blockchain data structure (e.g., prevuniqueidentifier - identifier0100, which is the unique identifier previously assigned to the first entry 504a).

When a transaction event is logged as an entry <NUM>, the entry may contain details that provide enough information about the transaction event to provide the necessary context of who conducted the transaction, what conducted the transaction, when the transaction was conducted, and where the transaction occurred. Specifically, the following fields may be useful in an audit log:.

Audit trails maintained in the blockchain data structure <NUM> can become a good source of information about particular transaction events in the shared computing environment <NUM>. The most basic audit logging functionality desirably has a clear understanding of which transaction events should be recorded in the audit log/data structure <NUM>. Audit trails are sometimes mixed with the event sourcing concept, which might be treated as the bigger set of events in respect to audit trail. The audit trail events are activities in the shared computing environment <NUM> triggered by users or functional users (endpoints, integrated applications, etc.), while event sourcing records all states of the application not necessarily triggered by a particular actor.

Monitoring of event sources provides another set of functions that can be extracted. One such function is governance and compliance regulations monitoring that can be checked against monitored event sources. Monitoring applied at the audit trail level gives the same type of functionality but in respect to concrete actors of the system. In order to be able to monitor and do the context analysis (e.g., correlation between individual audit trail events) or aggregation, records are desirably normalized and at least provide the possibility to extract the information mentioned above that is maintained in the publicly-available data portion <NUM> of each entry <NUM>.

With reference now to <FIG>, a first method of operating an audit and reporting system will be described in accordance with at least some embodiments of the present disclosure. The method begins by receiving data streams from a plurality of entities/tenants (step <NUM>). These data streams may correspond to streams from a plurality of different tenants 204a, 204b, 204c.

The data streams or information from the received data streams are than provided to one or a plurality of audit trail adapters (step <NUM>). The audit trail adapters are then enabled to independently create audit trail records for transaction events that occurred in the shared computing environment <NUM> on behalf of the tenant(s) (step <NUM>). In some embodiments, the audit trail records may correspond to data elements that will be written to blockchain entries of a common blockchain data structure after the data elements and the blockchain entry have been appropriately authenticated/validated by other participating nodes to the blockchain.

The method continues with an optional step of feeding one or more of the audit trail records from the audit trail adapters to a common location for processing (step <NUM>). In some embodiments, the common location may correspond to a blockchain server <NUM>, an API gateway <NUM>, or some other component operating within a RESTful service <NUM>.

The audit trail records or entries are then sequenced (step <NUM>). The audit trail records or entries may be sequenced according to time of the transaction, according to an assigned sequence number, and/or according to other considerations. The audit trail records or entries may be sequenced without concern for the entity/tenant that caused the transaction event to occur, but rather when the transaction event occurred relative to other transaction events in the shared computing environment <NUM>.

The method continues by generating a blockchain entry for each audit trail record if such blockchain entries were not already created (step <NUM>). The blockchain entries may be generated and/or processed individually or in a bulk/batch process. The method will then continue by attempting to write the blockchain entry (or batch of entries) to a common blockchain data structure (step <NUM>). In some embodiments, this step may require authentication of the blockchain entry (step <NUM>) and a securing of payload in the blockchain entry (step <NUM>). Specifically, a signature of the blockchain entry may be analyzed to ensure that the signature references a valid entry that already belongs to the common blockchain data structure. The securing of the payload in the blockchain entry may include using one or more tokens provided by a tokenization service. In some embodiments, one or more keys may be used to calculate an AES-CMAC footprint. To achieve the footprinting (e.g., computing of hash value(s)), a symmetric key may be used, and PKI could be used for validating if a particular tenant can write to the audit trail system service through the API. Specifically, a tenant may validate the integrity of a blockchain entry by calculating a block AES-CMAC (e.g., hash value) using the tenant's symmetric key and then comparing the calculated hash value to a hash value received from the blockchain entry that is being validated. If the hash values match, then the tenant can confirm the integrity of the blockchain entry is valid.

Assuming that steps <NUM>, <NUM>, <NUM> are completed successfully, the method continues by writing the entry or set of entries to the common blockchain data structure (step <NUM>). Once written to the common blockchain data structure, the entry or set of entries may be maintained on the peer-to-peer network and be made available for reading. In some embodiments, an entity/tenant may only be able to see, view, or know about an existence of blockchain entries that have their TenantID assigned thereto (step <NUM>). All other blockchain entries not having that particular TenantID assigned thereto will not be reported or made available to non-associated entities/tenants. However, because one entry will have a signature referring to a previous entry in the blockchain data structure, the entity/tenant associated with one entry will know about an existence of a previous blockchain entry by virtue of the fact that their associated entry points to the previous entry with its signature. However, the contents/payload of that previous entry may not be made available to the entity/tenant of the later-written blockchain entry.

With reference now to <FIG> a second method of operating an audit and reporting system will be described in accordance with at least some embodiments of the present disclosure. The method begins by collecting audit trail records or potential blockchain entries at an audit trail adapter (step <NUM>). The method continues by determining whether or not a predetermined number of records have been collected at the audit trail adapter (step <NUM>). If this query is answered negatively, then the method returns to step <NUM>. If, however, the query of step <NUM> is answered positively, then the method continues by allowing the audit trail adapter to perform a batch process on the collected audit trail records (step <NUM>). In some embodiments, the batch processing may include allowing the audit trail adapter to create a plurality of blockchain entries based on the collected records and link each entry to a previous entry based on a time or sequence in which a transaction for the entry occurred.

The method may continue by generating and writing a hash of the last processed audit trail record to an elastic cache (step <NUM>). Specifically, the hash may be generated on the blockchain entry that is created based on the last record in the collected records. The hash may be generated based on payload of the entry, a time of the transaction, a TenantID, a sequence number, or any other information that is contained in the blockchain entry. The hashing algorithm used to generate the hash may correspond to a one-way hashing algorithm. Thereafter, the batch of blockchain entries may be prepared for writing (as a batch) to the common blockchain data structure (step <NUM>).

With reference now to <FIG>, a third method of operating an audit and reporting system will be described in accordance with at least some embodiments of the present disclosure. The method begins by continuously monitoring blockchain entries that are created and/or added to a common blockchain data structure in real-time (step <NUM>). It should be appreciated that this analysis may occur in near-real-time without departing from the scope of the present disclosure.

The method continues by determining whether or not any of the analyzed entries creates a trigger to generate a report (step <NUM>). If not, then the method will return to step <NUM>. If so, then the method continues by determining if the report should contain specific information from the blockchain entry or entries that triggered the reporting action (step <NUM>). If the query is answered affirmatively, then particular blockchain content will be accessed and that information will be extracted therefrom (step <NUM>). In some embodiments, accessing particular content may require execution of a de-tokenization process, which may be conducted through an external tokenization service.

The method will continue with the generation of a report based on the information extracted from the blockchain entry or entries (step <NUM>). The report may include the extracted information itself or a summarization of the extracted information (e.g., a listing of sequence numbers from the entries, a listing of timestamps from the entries, or a reporting of a range of time over which the entries span). In some embodiments, the report may optionally include analytics information (step <NUM>). Analytics information that may be included in the report can include the types of reasons for identifying the blockchain entry or entries as a reporting trigger. For instance, if a blockchain entry was identified as anomalous, then the reason for identifying the blockchain entry as anomalous may be included in the analytics information. Any other statistical representation of information from a plurality of blockchain entries may also be included in the analytics information of a report.

The method will then continue with the transmission of the report to one or more predetermined recipients (step <NUM>). It should be appreciated that predetermined recipients may be members of the entity/tenant that is associated with the triggering blockchain entry or entries written to the blockchain data structure. Alternatively or additionally, the predetermined recipients may include third parties to the entity/tenant that is associated with the triggering blockchain entry or entries.

Referring back to step <NUM>, if the report is not to include entry-specific information, then the method will include generating a non-specific report in which analytics of the triggering blockchain entry or entries and/or other related blockchain entries are incorporated into the report (step <NUM>). Thereafter, the report is transmitted to the one or more predetermined recipients.

Claim 1:
A method for maintaining a log of events in a shared computing environment (<NUM>), the method comprising:
receiving, at an audit trail adapter (<NUM>) provided on an audit server (<NUM>), one or more raw data streams from the shared computing environment (<NUM>) that include transactions conducted in the shared computing environment by a first entity (112a, 204a) and a second entity (112b, 204b) that is different from the first entity (112b, 204b);
creating by the audit trail adapter (<NUM>), based on the received one or more raw data streams, a first blockchain entry for a first transaction conducted in the shared computing environment (<NUM>) for the first entity (112a, 204a);
creating by the audit trail adapter (<NUM>), based on the received one or more raw data streams, a second blockchain entry for a second transaction conducted in the shared computing environment (<NUM>) for the second entity (112b, 204b), wherein the second blockchain entry includes a signature that points to the first blockchain entry; and
causing the first and second blockchain entries to be written to a common blockchain data structure (<NUM>) in a database (<NUM>) that is made accessible to both the first entity (112a, 204a) and the second entity (112b, 204b),
wherein a payload of the first blockchain entry is pseudonymized with a first set of pseudonyms, wherein a payload of the second blockchain entry is pseudonymized with a second set of pseudonyms, and wherein the first set of pseudonyms is different from the second set of pseudonyms.