API ACCESS TO SECURITY-SENSITIVE COMPUTING SYSTEM

Controlling an (API) access action in a security-sensitive computing system includes, for an action to be performed, selecting from an operator account database an available operator account, generating a unique action tag which encompasses an identifier for the API access action and a unique API access key for executing the API access action; maintaining a dynamic access list having a mapping of the identifier of the API access action and the unique API access key and a selected operator account; granting, via the dynamic access list and the unique action tag, to the selected operator account an authorization for the API access to the security-sensitive computing system limited to performing the mapped API access; and revoking a further API access based on the unique action tag after the operator has performed the API access.

BACKGROUND

The present invention relates generally to the field of a secured access action to a computing system, and more specifically, to a method for controlling an application programming interface (API) access action in a security-sensitive computing system.

SUMMARY

According to one aspect of the present invention, a method for controlling an application programming interface (API) access action in a security-sensitive computing system is provided. Operations of the method may comprise for an action to be performed, selecting from an operator account database an available operator account, generating a unique action tag which encompasses an identifier for the API access action and a unique API access key for executing the API access action, and maintaining a dynamic access list, which has a mapping of the identifier of the API access action and the unique API access key and a selected operator account. Furthermore, the method may comprise granting, via the dynamic access list and the unique action tag, to the selected operator account an authorization for the API access action to the security-sensitive computing system limited to performing the mapped API access action, and revoking a further API access action based on the unique action tag, after the operator has performed the API access action.

According to another aspect of the present invention, an access control system for controlling an application programming interface (API) access action in a security-sensitive computing system is provided. The access control system may comprise a memory communicatively coupled to a processor, wherein the memory stores program code portions to enable the processor, for an API access action to be performed, to select from an operator account database an available operator account, to generate a unique action tag which encompasses an identifier for the API access action and a unique API access key for executing the API access action. The stored program code may enable the processor additionally to maintain a dynamic access list which has a mapping of the identifier of the API access action and the unique API access key and a selected operator account, to grant, via the dynamic access list and the unique action tag, to the selected operator account an authorization for the API access action to the security-sensitive computing system limited to performing the mapped API access action, and to revoke a further API access action based on the unique action tag, after the operator has performed the API access action.

DETAILED DESCRIPTION

The term ‘application programming interface access action’—in short, API access action—may denote a call to an application programming interface of any kind. Examples may comprise APIs of operating systems, databases, configuration files, middleware components and/or application programs. The access to a component underlying the API may be performed by another program or directly by a user interface to the API. The access action may comprise any sort of influence to the component underlying the API including but not limited to a read access a write access, a change access and/or a delete access. Basically, every access action shall be understood as an access to a component underlying the API, wherein the access can change setting of the component.

The term ‘security-sensitive computing system’ may denote a highly secured computing system with a strict control of access to it. Often, such systems are implemented as a secure enclave in form of a portion of a complete so-called mainframe computing system, like an IBM Z system complex.

The term ‘operator account’ may denote a user ID (identifier) dedicated to an operator of the security-sensitive computing system. The access authorization for an operator user may go far beyond access rights of application users of the security-sensitive computing system. Up to now (i.e., in traditional systems) operator access rights may be a security threat to the security-sensitive computing system. The proposed concept may be instrumental to close that gap.

The term ‘unique action tag’ may denote a one-time-identifier and potentially also time-dependent—i.e., valid only for a predefined time period—for enabling a selected operator to perform a one-time API access action. Once the one-time API access action has been performed, the unique action tag may lose its validity. I.e., a second API access action of the same sort may be revoked.

The term ‘unique API access key’ may denote a digital code for enabling an access to a specific API.

The term ‘dynamic access list’ may denote a database or table mapping unique action tags and operators for a one-time API access action to a specific API.

The term ‘selected operator account’ may denote a user ID which has been selected to be authorized for the one-time API access action in order to perform an error correction or another required or recommended maintenance task.

The term ‘authorization for the API access action’ may denote that a selected operator may have a time-limited access right to the respective API.

The term ‘revoking a further API access action’ may denote that a revocation may happen after the unique API access key may have been used and that the potential problem may have been resolved or the maintenance task has been executed. There is no way to reuse the unique API access key in combination with the unique access tag a second time. This may increase the system security of the highly-secure computing system even more.

The term ‘secure appliance’ may denote a portion of our complete highly secured computing system, e.g., implemented as a secure enclave. Often, such systems are implemented in the form of a so-called mainframe computer system.

The term ‘secure enclave’ may denote a highly secured and often private computing environment as part of a larger computing complex. All accesses and accounts are typically secured by security key mechanisms.

The term ‘system log file’ may denote a list of activities that have occurred on a computer system. The list of activity may be time-tagged. Additionally, also users or sub-components involved may be listed as well, in combination with the performed activity.

The proposed method for controlling an application programming interface (API) access action in a security-sensitive computing system may offer multiple advantages, contributions and technical effects:

A core of the proposed concept may lie in the selective one-time actions and assignments to a selective group of system administrators who may perform a required action once, based on a dynamically generated access control list which may be determined based on a resolved action-tag. Once the authorization is given to a specific operator and the task at hand—i.e., access action to an API—has been finished, a second access to the API may be revoked.

Thus, the proposed concept may eventually be used to serve in IT environments with highly secured systems in which the operations teams shall have no direct—i.e., uncontrolled—access—i.e., in the form of ssh (secure shell) accesses—no direct access to operating system interfaces (only through pre-defined APIs), only highly controlled access to actions for a dedicated operator and wherein all API invocations should be audited and executed in a controlled and monitorable environment.

In a nutshell, the authorization given to the operation's team may be further restricted such that the highly secured computing environment may be even better self-controlled by its inherent self-monitoring subsystems.

The usage of a unique action tag for a given API access action which may become invalid after the given API access action has been performed may provide a sort of self-locking after the API access action has been performed. It may also be guaranteed that the intention of the API access action by the operator was successful.

If this was not the case, the access to APIs may also be automatically be extended—based on predefined rules and procedures (configurable)—in order to resolve a given system problem as quickly as possible.

In the following paragraphs, additional embodiments—applicable to the method as well as to the related system—will be described:

According to one embodiment of the method, the selected operator account may be a group of operator accounts. Thus, the selection of an appropriate operator for performing an access action to an API may be made based on an actual availability (e.g., “on duty”, not on vacation), based on skills or any other group definition characteristic. In a cloud computing environment, the selection of an operator or a group of operators may also be based on the client using a specific cloud computing system.

According to another embodiment of the method, the API access action may be a group of API access actions. This includes access action of different types to the same API and also API access actions to different APIs with the same or different access action(s). This may be advantageous for the following reason: If a malfunctioning system function may not be able to be repaired by a single API access action the authorization to perform additional API access actions may be triggered based on a predefined setting (or configuration) of the access control system. Thus, it is not required to restart the complete selection and assignment process of an API access action to an operator completely from the beginning. Hence, and according to another embodiment of the method the group of API access actions may refer to different APIs.

According to one embodiment of the method, the security sensitive system may be implemented as a secure appliance in form of a secure enclave. Such appliances or systems may be designed from ground up as highly protected systems preventing an open access to any components or its related APIs. Only highly secured and controlled users or other systems may be allowed or authorized to access such a secure appliance. However, typically operators may still be allowed to access the system APIs. In order to close this hole, the security system the proposed here may be instrumental.

According to another embodiment, the method also includes monitoring and analyzing a system log file—or a plurality thereof—for determining a requirement of an API access action. This may be performed by a logging and analysis system which may trigger a dynamic access control and action resolver ones a requirement for an access to an API of the secure appliance may have been determined.

According to an embodiment of the method, the API access action may be at least one selected out of the group comprising a modification to a configuration of the security-sensitive computing system—i.e., at least one resource or component of it—and an enablement of another component of the security-sensitive computing system. This may also comprise making available sleeping—i.e. inactive—components of the security-sensitive computing system, like, e.g., an additional processor core, more memory of more storage capacity or, higher memory bandwidth.

According to an embodiment of the method, the revoking the further API access action may also comprise monitoring a completion of the API access action before revoking the further API access action. Therefore, the authorized API access action may only be performed once. Based on the same access token now second API action may be possible once the specific access action has been completed. Hence, it is not possible—or better, it does not make sense—that an operator may store the access tag secretly for a later—in particular, unauthorized—usage. The later—i.e., second—usage would be revoked anyway.

According to an embodiment of the present invention, the method may also comprise extending an access controlled by the unique action key to an additional set of APIs if a previous access action did not arrive at a working solution. This may be especially useful if the problem to be solved or task to be performed cannot be completed with only one single API access action. Hence, a completion mark for a successful API access action should not be set. Consequently, and based on predefined rules and procedures an expansion of the APIs and potential actions required to solve the task at hand may be allowed automatically.

According to one embodiment of the present invention, the method may also comprise sending a notification to the selected operator account. Thereby, the notification may comprise a detail—in general more details—about a required API access action. The details may comprise additional background information, specific instructions, additionally required resources, actions to be performed upfront (worst-case shutdown of the computing system or a warning to active users) or backup activities.

In the following paragraphs, a detailed description of the figures will be given. All instructions in the figures are schematic. Firstly, a block diagram of an embodiment of the present invention for controlling an API access action in a security-sensitive computing system is given. Afterwards, further embodiments, as well as embodiments of the access control system for controlling an API access action in a security-sensitive computing system, will be described.

FIG. 1shows a block diagram of an embodiment of the method100for controlling an application programming interface (API) access action in a security-sensitive computing system. The method100comprises for an action to be performed selecting,102, from an operator account database an available operator account, generating,104, a unique action tag which encompasses an identifier for the API access action and a unique API access key for executing the API access action.

The method100comprises additionally maintaining,106, a dynamic access list, which has a mapping of the identifier of the API access action and the unique API access key and a selected operator account. It may be noted that the unique API access key is different to the unique action tag.

Additionally, the method100also comprises granting,108, via the dynamic access list and the unique action tag, to the selected operator account an authorization for the API access action to the security-sensitive computing system limited to performing the mapped API access action only. Thereby, it may be noted that the mapping may be known from the dynamic access control list.

Finally, the method100comprises revoking,110, a further API access action based on the unique action tag the operator has performed. Hence, the selected operator may perform the assigned task—i.e., the dedicated API access action identified by the unique action tag—only once.

FIG. 2shows a block diagram200of components and relevant information flows of an embodiment of the present invention. The flow starts from the log208which may be generated by the operation of the secure appliance202, e.g., running on a mainframe (MF) computer system. The log file(s)208can be retrieved,210, continuously and it/they also can be analyzed in a logging and analysis system212. Upon an error or a maintenance requirement being determined, a notification is sent,214, to the dynamic access control and action resolver216.

The dynamic access control and action resolver216can access,218, a list of available operators (220, list of operators on duty and/or skilled or generally authorized to perform the task at hand) and grant,224, access to at least one of the selected operator(s)222. At least one of the available operators222is registered as being on duty in the list220of operators on duty. The dynamic access control and action resolver216also notifies,228, the selected operator to execute,232, the permitted action (s) via the API(s)204to resolve the potential error or complete a required maintenance task. The access to the API is controlled by the APIs access management component206which receives,230, a grant for an API access action for the selected operator222.

Once the API access action is completed—which may be signaled,234, by the API access management component206, to the dynamic access control and action resolver216—a further access to the API204is revoked,236,238, via the dynamic access list226(and the related controlling component) and the API access management component206. It may be noted that the dynamic access control and action resolver216may actively check the secure appliance202or one of its components (e.g., the API access management component206or one of the log files208) for the API access action completion.

It should be noted that the API(s)204, the log files208and the API access management component206are all part of the secure appliance202. Furthermore, the logging and analysis system212can—besides analyzing the log files for errors or required maintenance actions—decide or determine, based on the determined error or required maintenance action, that a specific API access action shall be performed.

Furthermore, the dynamic access control and action resolver216performs a list of instrumental activities supporting the hereby proposed concept: listen to the notifications from the logging and analysis system212, extracting actions required per notification, determining a potential assignee (i.e., operator) on duty, create an action tag, register the action tag with the operator222to the dynamic access list226, assigning the action tag and notifying the selected operator222, resolving the action to be performed, verifying whether the API access action is initiated and/or completed and, invalidating the API action tag in the dynamic access list226so that a further API access is no longer possible (i.e., revoked).

FIG. 3shows a block diagram300of a first part of components involved in the information flow of an embodiment of the inventive concept. In the top portion of the figure involved components are listed: an administrator's front-end component302, the dynamic access list304(compare dynamic access list226fromFIG. 2) and the dynamic access control and action resolver306(compare the dynamic access control and action resolver216fromFIG. 2).

On the right side ofFIG. 3are flowchart connectors A, B, C, D, E shown which connect to respective continuation connectors onFIG. 4. For comprehensibility reasons, the total information flow had to be split betweenFIG. 3andFIG. 4.

The actor, i.e., the selected operator222(compareFIG. 2) is shown on the left side ofFIG. 3. The administrator's front-end308is permanently listening to notifications (228,FIG. 2) for a selected operator222. A respective trigger signal is generated by the notifier310. It may be related to the dynamic access control list304. This may also apply for the activities of getting,312, a notification from the dynamic access control and action resolver306so that a request,314, for the access token for the assignee to the secure appliance is generated.

The dynamic access control and action resolver306comprises a notification listener component316which triggers an extraction,318, of the access action(s) and determine the selected operator. Then a unique action tag for the operator is created,320. Furthermore, the dynamic access control and action server316monitors,322, and determines whether the API access action is performed in a predefined time. If this is not already the case, the process waits,324, for a predefined period of time before the monitoring322is carried out again.

Referring now toFIG. 4, it can be seen that that there are some information bubbles indicating process flow connection exists between the dynamic access control and actually server306and the logging and monitoring component402; these continuation connections are denotes as A, B, C, D, E.FIG. 4shows a block diagram400of a second part of components involved in the information flow of the embodiment—jointly represented inFIG. 3andFIG. 4—of embodiments of the present invention.

One can also see the connection—via A—from the triggering the extraction of the action (318and the list406of operators on duty (equivalent to220,FIG. 2). The notification listener process316is triggered—via B—after a determination,408, which API access action(s) regarding potential error corrections of required maintenance tasks shall be performed. This is based on an analysis410of the log(s)412of the secure appliance404. Here, it may also be mentioned that the reference numerals ofFIG. 2have been added toFIGS. 3 and 4in brackets where appropriate.

One may also see—via C—the connection between the request,314, the access token for the assignee—i.e., the selected operator—for the secure appliance and the API access management component414accessing information from the dynamic access list416(e.g., a database, compare226,FIG. 2), as well as the logical connection between the operator222and the access to the API(s)418of the secure appliance404. Furthermore—via D—a connection to a continuous health check420of the system is shown. Moreover, if the API access action is not carried out in the predefined period of time—via D—the API access management414is also informed that the potential API access action should be revoked.

For completeness reasons,FIG. 5shows an embodiment of the access control system500for controlling an API access action in a security-sensitive computing system. The system500comprises a memory502communicatively coupled to a processor504, wherein the memory502stores program code portions (not shown) to enable the processor504for an API access action to select—in particular by a selection unit506—from an operator account database an available operator account, generate—in particular by a generation module508—a unique action tag which encompasses an identifier for the API access action and a unique API access key for executing the API access action, maintain—in particular by a maintenance module510—a dynamic access list which has a mapping of the identifier of the API access action and the unique API access key and a selected operator account, grant—via an access granting unit512—via the dynamic access list and the unique action tag, to the selected operator account an authorization for the API access action to the security-sensitive computing system limited to performing the mapped API access action, and revoke—in particular by a revocation module514—a further API access action based on the unique action tag, after the operator has performed the API access action.

It may be noted that the activities of the access control system500may also be implemented completely as hardware components being in data exchange with the memory502and the processor504. Consequently, the memory502, the processor504, the selection unit506, the generation module508, the maintenance module510, the access granting unit512and their revocation module514may be connected among each other for data and information exchange. Alternatively, the active units and modules may be linked for data and signal exchange via the access control system internal bus system516. This may make a complete hardware implementation elegantly implementable

Embodiments of the invention may be implemented together with virtually any type of computer, regardless of the platform being suitable for storing and/or executing program code.FIG. 6shows, as an example, a computing system600suitable for executing program code related to the proposed method.

As shown in the figure, computer system/server600is shown in the form of a general-purpose computing device. The components of computer system/server600may include, but are not limited to, one or more processors or processing units602, a system memory604, and a bus606that couple various system components including system memory604to the processor602. Bus606represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limiting, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus. Computer system/server600typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server600, and it includes both, volatile and non-volatile media, removable and non-removable media.

The program/utility, having a set (at least one) of program modules616, may be stored in memory604by way of example, and not limiting, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating systems, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules616generally carry out the functions and/or methodologies of embodiments of the invention, as described herein.

The computer system/server600may also communicate with one or more external devices618such as a keyboard, a pointing device, a display620, etc.; one or more devices that enable a user to interact with computer system/server600; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server600to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces614. Still yet, computer system/server600may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter622. As depicted, network adapter622may communicate with the other components of the computer system/server600via bus606. It should be understood that, although not shown, other hardware and/or software components could be used in conjunction with computer system/server600. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

Additionally, access control system500for controlling the API access action in the security-sensitive computing system may be attached to the bus system606.

Some additional definitions are provided below:

Data communication: any sort of data communication scheme now known or to be developed in the future, including wireless communication, wired communication and communication routes that have wireless and wired portions; data communication is not necessarily limited to: (i) direct data communication; (ii) indirect data communication; and/or (iii) data communication where the format, packetization status, medium, encryption status and/or protocol remains constant over the entire course of the data communication.

Receive/provide/send/input/output/report: unless otherwise explicitly specified, these words should not be taken to imply: (i) any particular degree of directness with respect to the relationship between their objects and subjects; and/or (ii) absence of intermediate components, actions and/or things interposed between their objects and subjects.

Without substantial human intervention: a process that occurs automatically (often by operation of machine logic, such as software) with little or no human input; some examples that involve “no substantial human intervention” include: (i) computer is performing complex processing and a human switches the computer to an alternative power supply due to an outage of grid power so that processing continues uninterrupted; (ii) computer is about to perform resource intensive processing, and human confirms that the resource-intensive processing should indeed be undertaken (in this case, the process of confirmation, considered in isolation, is with substantial human intervention, but the resource intensive processing does not include any substantial human intervention, notwithstanding the simple yes-no style confirmation required to be made by a human); and (iii) using machine logic, a computer has made a weighty decision (for example, a decision to ground all airplanes in anticipation of bad weather), but, before implementing the weighty decision the computer must obtain simple yes-no style confirmation from a human source.

Automatically: without any human intervention.

Comprise/comprises/comprising: As used in the specification (specifically outside of the claims section), this term is intended to be perfectly synonymous with the term “include” and its various conjugated forms (as defined herein in this specification). The term “comprise” (and its various conjugated forms) as used in the claims is to be given its ordinary interpretation that is consistent with patent claim interpretation.