Method for checking access to access information in runtime environment, and runtime environment system, computer program and data carrier

Abstract

The invention relates to a method for checking access to access information in a runtime environment (2), in which a container instance (3, 7) can be authenticated in the runtime environment (2) by means of at least one piece of access information (5), comprising: providing the at least one piece of access information (5) by means of an orchestration unit (4); -assigning an access data policy (6) to the access information (5) by means of the orchestration unit (4); -assigning the access information (5) to at least one container instance (7) by means of the orchestration unit (4); identifying an access to the access information (5) by means of an anomaly identification unit (8); checking the identified access by means of the anomaly identification unit (8) in order to determine whether the identified access is performed by the container instance (7) assigned to the access information (5); and if not: altering, by the orchestration unit (4), the access information (5) on the basis of the corresponding access data policy (6). The invention also relates to a runtime environment system (1), a computer program (14) and an electronically readable data carrier (15).

Description

Technical Field

[0001] The present invention relates to a method for checking access to access information within a runtime environment, wherein a container instance can be authenticated in the runtime environment by means of at least one access piece of information.

[0002] The present invention also relates to a runtime environment system, a computer program, and an electronically readable data carrier. Background Technology

[0003] Currently, in container-based runtime environments, container instances are generated using "images" or container images and "deployment" configurations, and these container instances are allocated resources from the underlying host or runtime environment. Resources can be specifically provided by the underlying runtime environment or host. In addition to hardware and software resources, it's common in this scenario that individual instances or objects are authenticated within or outside the runtime environment using access data such as SSH keys, private certificate keys, or passwords. This access data can be managed, restricted, or have access permissions limited by an orchestrator, a "secret-management-system," or a central secret management system. In this case, access control is typically implemented through role-based access control. Instances can authenticate with the secret management system using tokens. The secret management system authorizes requests and grants access to one or more access data. Therefore, the instance can obtain or "acquire" access data using a token. It's also conceivable that the orchestrator takes over access control and allocates access data to the instance using dynamically generated "volumes" or environment variables.

[0004] To prevent such access data leakage, this access data is primarily transmitted in an encrypted manner and / or its validity is also limited. However, one problem that cannot be solved by this is the following situation: an attacker is directly located in the runtime environment or on the underlying device and has access to the container instance, and directly intercepts unprotected access data existing within that instance for use in other contexts.

[0005] In this context, an example application would be a container-based industrial edge application, i.e., an application in a production line or manufacturing line that uses a unique password to log in to a backend system located outside the runtime environment and cannot use modern access mechanisms such as restricted access tokens for this purpose.

[0006] Therefore, in this application example, the problem is that the password cannot be restricted in time, and on the other hand, without access monitoring, it cannot be guaranteed that other applications, system users, or attackers on the device will not access the data, and thus the password may be read by unauthorized entities.

[0007] In existing technologies, such as IAM ("Identity-Access-Management-System"), access tokens or certificates can be issued with limited validity periods, and these tokens or certificates can be renewed whenever the requested system requests them from the IAM system. The challenge in this scenario is that both the requested client and the target application must support IAM system integration. This can be achieved, for example, by supporting the "OAuth" method, which is typically used or applied in web-based applications.

[0008] For example, there exist methods in which certificates or access tokens are issued in a time-limited manner, and the "sidecar-Container" performing the authentication independently requests these access tokens or certificates. A "sidecar-Container" specifically refers to a container instance that performs the "delivery work" for the actual container instance. For example, this container instance transparently performs authentication for other services for the actual container instance.

[0009] There are also solutions where certificates and associated keys are automatically rotated. In this case, the rotation is controlled only by the certificate's expiration date, but not by suspicious access to the managed private key. Summary of the Invention

[0010] The purpose of this invention is to make access to such access information more secure by more efficiently identifying unauthorized access to runtime environment access information (such as access data).

[0011] This objective is achieved by a method, a runtime environment system, a computer program, and an electronically readable data carrier as described in the independent claims. Reasonable extensions can be derived from the dependent claims.

[0012] One aspect of the present invention relates to a method for checking access to access information within a runtime environment, wherein a container instance can be authenticated in the runtime environment by means of at least one piece of access information, the method comprising: - In particular, at least one access message is provided through the orchestration unit of the runtime environment; - In particular, the orchestration unit assigns access data policies to the at least one access message; - In particular, through this orchestration unit, the at least one piece of access information is assigned to at least one container instance of the runtime environment; - In particular, the anomaly detection unit identifies at least one access to the at least one access message; - In particular, the anomaly detection unit examines the identified accesses to determine whether the identified accesses were performed by a container instance assigned to the at least one access message; and - If not: then in particular, the at least one piece of access information is modified by the orchestration unit based on the corresponding access data strategy.

[0013] The proposed method enables or creates improved checks or monitoring of access to access information. In this context, unauthorized access by an entity can be identified, and the corresponding access information can then be modified. In other words, access information targeted by unauthorized or malicious access can be altered or regenerated accordingly. This prevents or blocks access that is not permitted or is performed by an unauthorized entity.

[0014] The proposed method protects access information from unauthorized reading or access. This primarily improves or enhances IT security, particularly runtime environment IT security. In other words, using the proposed method, unauthorized access to access information both inside and outside an instance (such as a container instance) can be identified through orchestration units or components located outside the runtime environment, and based on this unauthorized access, password rotation or access information modification can be introduced and, in particular, performed, especially against the identified components.

[0015] The proposed method enables event-driven modifications to access information, such as access data, to be performed within the orchestration environment, i.e., the runtime environment.

[0016] The runtime environment, also known as the execution environment, describes the preconditions that a particular runtime system is available and specifies for the execution of a computer program.

[0017] Container instances can be virtual, isolated environments where software applications are deployed and isolated. Containers, for example, share an operating system without requiring a virtual machine. Containers typically do not run in a separate virtual machine and do not have their own complete operating system. Containerized applications can consist of multiple container images. A container instance can contain the components required by the application running within it. These components include files, environment variables, dependencies, and libraries. Container instances simplify the security, operation, management, and distribution of servers and applications. Therefore, containers simplify the handling of complex server applications and enable extensive automation of roll-out processes in data centers. This is especially important when deploying scalable, distributed applications within cloud environments.

[0018] A container instance can be, for example, an application, or a computer program. Using at least one or more access pieces of information, a container instance can be authenticated either inside or outside the runtime environment, so that, for example, it can execute application processes or functions.

[0019] A "complete application" can consist of multiple container instances, which are generated from different container images. However, in this case, mutual authentication can then be re-performed by accessing data or access information.

[0020] The at least one piece of access information, and especially this access information, can be access data, such as a certificate, password, or key. In particular, the access information can be access data consisting of a user identifier and a password. Therefore, each pair of access data constitutes an access identifier. The access information can, in particular, have multiple pieces of access data and multiple pairs of access data. The orchestration unit can be an orchestration component or an orchestrator.

[0021] Therefore, orchestration can be performed using orchestration units. Orchestration refers to the automated configuration, management, and coordination of computer systems, applications, and services. When using containers, orchestration units can distribute instances to multiple execution environments managed by that orchestration unit.

[0022] By using access data policies (which could be called "rotation policies"), you can specify which processes in which container instances are allowed to read the relevant access information, and what actions should be taken when unauthorized or illegal access is identified. For example, you can first generate or create such access data policies.

[0023] With the help of orchestration units, at least one or more access requests can be assigned to a container instance. Therefore, this is system-side dispatch. The access requests can be provided accordingly, or generated or produced by the orchestration unit. With the help of an anomaly detection unit or mechanism, the corresponding access can be checked to determine whether it is authorized or unauthorized. Here, a system-side check is performed: whether the access was executed by a container instance or even an actually authorized instance, in order to allow the use of one or more access requests associated with that access. If it is determined to be an unauthorized access, the at least one access request targeted by the unauthorized access will be modified according to the access data policy assigned to that access request. This is especially automatic. Therefore, the unauthorized access can be prevented or blocked.

[0024] The proposed method enables the rotation of access data or certificate keys after an unexpected access to the containerized runtime environment.

[0025] If an authorized instance accesses the service again, that instance can access the corresponding access information.

[0026] The proposed method can be implemented in particular by computer.

[0027] In one embodiment, the modified access information is provided to the container instances associated with the modification of the at least one piece of access information. Thus, after preventing or blocking unauthorized or prohibited access to the access information, the container instances can be provided with, and in particular, the newly adjusted or modified access information can be transmitted, keeping these container instances up-to-date and allowing them to access the information again. Therefore, it prevents authorized or permitted access to container instances from failing after the modification of the at least one piece of access information, since the access information was modified during a previous unauthorized access. Therefore, in particular, the change in access information can be notified to all container instances assigned access information that has suffered at least one unauthorized access.

[0028] In other words, when unauthorized access to access information occurs, all container instances referencing that access information can be notified that modified access information now exists, and that the modified access information can be provided to those container instances.

[0029] By adjusting access information or data, especially automating this adjustment, after identifying or determining unauthorized access, security, particularly data security, can be continuously improved. Therefore, defenses against unauthorized access can be enhanced.

[0030] In one embodiment, the following steps are specified: at least one modified access piece of information is transmitted to a container instance, and then the container instance is updated, wherein the monitoring function of the container instance checks whether the modified access piece of information has been updated within the container instance. For example, using an orchestration unit that has performed the access information modification, the modified access information can be automatically transmitted or sent to all relevant container instances.

[0031] Each container instance, or at least one container instance, can independently or individually adjust the stored, assigned access information so that the changed or modified access information is now stored. To ensure that other container instances can continue to access the access information assigned to them within the runtime environment after unauthorized access is identified and the access information is changed, monitoring or inspection can be performed. In this case, inspection, especially using monitoring functions, checks whether the at least one container instance has transmitted the changed access information and is now stored or stored within the container instance. In this case, the information can be stored or updated in a database or within the container instance's compute unit.

[0032] In one embodiment, if the update fails, the corresponding information is sent to the orchestration unit, and then the orchestration unit performs a re-modification on the already changed access information.

[0033] For example, due to errors or an erroneous state, the transmission of modified access information may fail, and errors may also occur when updating the modified access information. To address this issue and ensure continued access for container instances to the access information correspondingly assigned to them, the modified access information can be readjusted or re-modified. Therefore, for example, the monitoring function of the corresponding container instance's compute unit or orchestration unit can be used to report, for example, by using indicator signals, that the update of the modified access information failed. Then, the modified access information is readjusted so that all container instances in the runtime environment can successfully access the runtime environment. It is also possible that, due to a network attack or other malicious intervention, the re-modified access information cannot be updated. To address this again, the access information is readjusted or regenerated and reassigned to the container instances accordingly.

[0034] The modified access information can be retransmitted to the corresponding container instance by the orchestration unit.

[0035] Additionally or alternatively, regarding updates, the duration of the update can be considered in determining whether the update can be successfully executed. In this case, a specified time limit can be specified within which the update should be executed. If no positive feedback is received regarding the update of the orchestration unit after the specified time limit, the changed access information should be modified again for security reasons, and especially for IT security reasons, in order to prevent unauthorized access.

[0036] In one embodiment, the orchestration unit is used to check whether other container instances are using at least one piece of modified access information, and if so, to provide the modified access information to those container instances. For example, when assigning access information to container instances, the corresponding grouping or classification of these container instances can already be performed with respect to the assigned access information, so that when unauthorized access is identified, container instances that are also associated with the modified access information can still have that modified access information transmitted.

[0037] In one embodiment, an access data policy is used to specify what actions should be taken when unauthorized access to at least one piece of access information occurs. This allows the system to quickly identify the appropriate actions to be taken or performed when unauthorized access to access information occurs. For example, the scope or extent of changes to the access information can be specified in this case.

[0038] Similarly, access data policies can be used to specify the corresponding alarm prompts or security mechanisms to be executed or activated. In other words, using access data policies, for the corresponding access information, the system can specify or define which security measures the orchestration unit should execute or activate (especially how and when) when unauthorized access is detected.

[0039] In one embodiment, these measures are specified to execute specific instructions on the container instance involved in the unauthorized access, send specific instruction signals to the container instance involved in the unauthorized access, and / or perform reconfiguration on the container instance involved in the unauthorized access. These measures are exemplary and can be implemented or executed in a conceivable manner. In this case, at least some of these measures can be executed or caused to be executed, particularly by an orchestration unit. In this case, the corresponding signals or instructions can be transmitted by the orchestration unit to the corresponding container instance, so that the corresponding measures can be implemented by means of the computing or processing unit of the corresponding container instance. Thus, it can be ensured that the container instance related to the access information involving unauthorized access is not threatened by other risks or attacks. This particularly improves the overall security related to the runtime environment and access information. In particular, the notification to other instances is intended to inform the "client" applications running therein that the login information required to log in to the "server" application has been changed, and new access data or access information has been provided for this purpose.

[0040] In one embodiment, an access data policy is used to specify which user or process is allowed to access at least one piece of access information. For example, when allocating access information and corresponding container instances, the orchestration unit may have already reported which user or processes are allowed or not allowed to access the corresponding access information. This can be advantageously used to identify unauthorized access because, based on the entity or instance seeking access to the access information, it can be checked whether the corresponding user or process has made that access. Therefore, unauthorized access can be more easily identified. Thus, the access data policy can be considered when checking identified accesses.

[0041] In one embodiment, when examining identified accesses, the anomaly detection unit is provided with separate information relating to the container instance to which the access data was assigned. This separate information, such as container instance-specific information, allows the anomaly detection unit to examine the identified accesses more effectively or efficiently, because comprehensive information is available to estimate or determine whether the access is authorized or unauthorized.

[0042] In one embodiment, an exception rule set is generated by an orchestration unit based on at least one piece of access information and a container instance of the runtime environment, and provided to an exception identification unit. This exception rule set is considered, and in particular, additionally considered, when examining identified accesses. Therefore, additional inspection criteria can be provided to better determine whether identified accesses are illegal or unauthorized. For example, the initial creation and instantiation of the exception rule set can be performed by the orchestration unit. Specifically, the exception rule set can be generated when allocating access data policies and access information.

[0043] In one embodiment, if an inspection of an identified access reveals that the access was conducted by an unauthorized object, the anomaly detection unit generates a corresponding alarm signal and transmits it to the orchestration unit. Therefore, an immediate alarm or alert can be issued immediately upon detection of unauthorized access to an object (such as an entity). Thus, by means of the generated alarm signal, the anomaly detection unit can notify or inform the orchestration unit that unauthorized access has occurred and that appropriate measures or security precautions should be introduced or implemented, especially as quickly as possible.

[0044] In one embodiment, an orchestration unit is used to modify the adaptation of at least one piece of access information based on an alarm signal. In this case, the advantage is already apparent when corresponding measures are to be taken for the corresponding situation. In particular, by making this modification for the corresponding situation related to the identified access, appropriate security measures, especially data security technical measures, can be implemented or executed. By modifying the access information, unauthorized access can be prevented.

[0045] Another aspect of the present invention relates to a runtime environment system having: - Runtime environment; - Multiple container instances that can be authenticated within the runtime environment by accessing at least one piece of access information; - An orchestration unit used to provide at least one piece of access information; - The orchestration unit is designed to assign access data policies to the at least one access message; - The orchestration unit is designed to assign the at least one access message to at least one container instance; - Anomaly detection unit, used to identify at least one access to the at least one access message; - The anomaly detection unit is designed to: examine at least one identified access to determine whether the identified access was performed by a container instance assigned to the at least one access message; and - The orchestration unit is designed to modify the at least one access message based on the corresponding access data policy if the identified access was not performed by the container instance assigned to the at least one access message.

[0046] In particular, the above-described methods can be executed or implemented using the proposed runtime environment system.

[0047] The runtime environment can be, for example, a container runtime environment (such as Docker).

[0048] In particular, multiple container instances can use this at least one access information to authenticate each other within the runtime environment or to authenticate one another.

[0049] Another aspect of the invention relates to a computer program that can be directly loaded into the memory of a control device of a computer network system according to the preceding aspect, the computer program having program means for performing the method described according to one of the foregoing aspects or an advantageous extension thereof when the program is executed in the control device of a runtime environment system.

[0050] Another aspect of the invention relates to an electronically readable data carrier storing electronically readable control information thereon, the electronically readable control information being designed such that, when the data carrier is used in a control device of a runtime environment system according to one of the foregoing aspects, the electronically readable control information performs the method described according to one of the foregoing aspects or an advantageous extension thereof.

[0051] The runtime environment system can be, for example, a cloud-based technology. In particular, the runtime environment system can be a container runtime environment that can run on an operating system.

[0052] An advantageous embodiment of one aspect of the invention may be regarded as an advantageous embodiment of another aspect or all the other aspects. The reverse is also true.

[0053] For example, computer programs, electronically readable data carriers, and runtime environment systems may have means for implementing or performing the methods according to the present invention.

[0054] The advantageous design form of this method should be considered as an advantageous design form of another method, runtime environment system, computer program, and electronically readable data carrier. The runtime environment system, computer program, and electronically readable data carrier have specific characteristics that enable them to perform one of these methods or their advantageous design forms.

[0055] Regardless of the grammatical gender of a particular term, it includes both male and female individuals.

[0056] In various embodiments, the evaluation unit includes: one or more hardware and / or software interfaces; and / or one or more storage units.

[0057] Storage cells can be designed as: volatile data memory, such as dynamic random access memory (DRAM) or static random access memory (SRAM); or non-volatile data memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or flash EEPROM, ferroelectric random access memory (FRAM), magnetoresistive random access memory (MRAM), or phase-change random access memory (PCRAM).

[0058] Unless otherwise stated, all steps of the method, particularly the computer-implemented method, can be performed by at least one computing unit, which may also be referred to as a data processing device. In particular, the data processing device can execute the steps of the computer-implemented method and includes at least one processing circuit designed or adapted to execute the method according to the invention, particularly the computer-implemented method. For this purpose, a computer program comprising instructions, which, when executed by the data processing device, particularly the at least one processing circuit, causes the data processing device to perform the computer-implemented method.

[0059] For use cases or application scenarios that can be derived in this method but are not explicitly described herein, it may be specified that: according to this method, error messages are output, and / or requests for user feedback are output, and / or standard settings and / or predetermined initial states are set.

[0060] The features and combinations of features mentioned in the foregoing description, as well as those mentioned subsequently in the description of the drawings and / or shown separately in the drawings, can be applied not only in the corresponding described combinations but also in other combinations without departing from the scope of protection of the invention. Even if embodiments and combinations of features do not contain all the features of the initially proposed independent claims, and / or exceed or deviate from the combinations of features described in the recitations of the claims, these embodiments and combinations of features should be considered as disclosed. Attached Figure Description

[0061] The invention will now be described in more detail with reference to specific embodiments and related illustrative drawings. In these drawings, identical or functionally identical elements may be equipped with the same reference numerals. If necessary, identical or functionally identical elements are not necessarily repeated in different drawings.

[0062] In the following figures: Figure 1 A schematic diagram or overview of the components of the runtime environment system is shown; and Figure 2 An exemplary flowchart is shown regarding how unauthorized access can be identified within the runtime environment and what actions can be taken in response.

[0063] In these accompanying drawings, elements with the same function are equipped with the same reference numerals. Detailed Implementation

[0064] Figure 1A schematic diagram of runtime environment system 1 is shown. This higher-level, computer-based or data technology-based system can be used, in particular, to inspect access information within runtime environment 2. Runtime environment system 1 may, for example, have multiple container instances 3 or instance or data technology objects. With the help of container instances 3, for example, an application process or function can be executed. For this purpose, container instances 3 can be authenticated, either inside or outside runtime environment 2, by means of access information assigned to container instances 3.

[0065] Runtime environment 2 can be, in particular, a containerized runtime environment. For security reasons, especially IT security reasons, unauthorized or prohibited access to information such as access data is not permitted. Therefore, specific access control or access mechanisms must be provided. This invention advantageously begins here. With the aid of an anomaly detection mechanism, the reading of access information (such as a "secret") by an unexpected process (such as an instance) can be identified by orchestration unit 4 or an orchestrator. Container instances can, in particular, be process, task, or program instances.

[0066] For example, at least one access message 5 can be provided to orchestration unit 4. Orchestration unit 4 can then assign or dispatch at least one access data policy 6 to this access message 5. This access data policy 6 could be, for example, a "rotation policy." Using the access message 5 referenced by this at least one access data policy 6, orchestration unit 4 can assign or dispatch it to at least one container instance 7 or multiple container instances 3. With the help of access data policy 6, it can be determined which processes in which container instances 3 and 7 are allowed to read or access the at least one access message 5, and what action should be taken by orchestration unit 4 in the event of a known violation.

[0067] Using the access data policy 6, which can be individually specified for each access message 5, it is possible to define what actions to take when unauthorized access to access message 5 occurs. For this purpose, the access data policy 6 can include references to the access messages 6 managed by the orchestration unit 4.

[0068] For example, the name of the access information can be directly referenced using the label assigned to access information 6, or it can be referenced using a regular expression. Similarly, the container instance 7 can be referenced using the assigned label, direct reference, or regular expression. Furthermore, using access data policy 6, the names of prohibited or allowed processes (combined with process names if necessary) can be defined for allowed users (indicating usernames or user IDs within entity 7) and the responses or actions to be performed (such as "allow", "rotate secrete", or "alarm").

[0069] With the help of the anomaly detection unit 8, access within or from outside the runtime environment 2 can be monitored or inspected. In particular, unauthorized access can be identified. Specifically, access to access information, such as access information 5, is examined. To perform this inspection, the anomaly detection unit 8 investigates whether the identified access was made by the container instance 7 assigned to access information 5. If unauthorized access is determined, access information 5 can be modified or regenerated. This can be achieved through the orchestration unit 4.

[0070] For example, using the anomaly identification unit 8, anomalies, such as unauthorized access, can be identified based on the anomaly rule set 9.

[0071] The following section illustrates a portion of the code lines used in accessing data strategy 6.

[0072] • Secret 1: Container instance 1 / reference: process name 1: processarguments 1: allow • Secret 1: Container instance 2 / Reference: process name 2: process arguments 2: allow • any instance: any: any: alert(any instance: any: any: alert) • ### Definition of alert behavior • secret X: Container instance a / reference: rotate secret • secret X: Container instance b / reference: alarm only.

[0073] For example, access information can be assigned to container instance 3 in different ways. Furthermore, different instance types can be provided within the deployment configuration using different paths or variable names. In this case, the integrity rule set can be instantiated using the target value defined in the deployment configuration.

[0074] For example, access information can be provided by assigning dynamically generated "volumes" 10. Using such "volumes" 10 eliminates the need for environment variables. Environment variables are harder to detect because they cannot be associated with opening specific files; instead, they are assigned to processes based on environment allocation and are easily readable. Therefore, by instantiating rule sets, instantiation can be performed on a per-instance basis, assigning access information to the files allocated to that instance. Furthermore, the runtime environment system 1 can have a kernel 11 or a kernel system or operating system kernel.

[0075] It is also conceivable that the runtime environment system 1 has a corresponding control device 12. Furthermore, the control device 12 may have a memory 13 in which a computer program 14 can be loaded to execute, for example, the method according to the invention. For this purpose, the program 14 may be executed, for example, within the control device. Additionally, an electronically readable data carrier 15 may be provided, designed to store electronically readable control information. The method according to the invention can be executed particularly well when the data carrier 15 is used in the control device 12.

[0076] Once instantiation is complete, for example, access data policy 6 can be transferred to the anomaly detection unit 8, and in particular, the corresponding node of that anomaly detection unit. Whenever new data information is provided or generated, instance 3 is stopped or started, or access data policy 6 is updated, instantiation updates and anomaly monitoring policies or anomaly rule sets 9 are performed on these nodes. In other words, anomaly rule sets 9 can be generated based on access information and the type and / or number of container instances 3.

[0077] This includes at least one or more access messages, such as confidential information or confidential data.

[0078] For example, unauthorized operations can be identified by the anomaly detection unit 8 by reading the secret file or access information 6, and the orchestration unit 4 will be notified accordingly. The anomaly detection unit 8 can identify, for example, whether a specific file has been accessed by an unauthorized user or process using the system instruction "fopen" for the secret file or access information 5, and compare this with the existing rule set (especially the anomaly rule set 9). If an alarm is triggered, the actions defined in the rule set of access data policy 6 can be executed. In this case, for example, the complexity of the access information and the further actions to be taken if necessary can be defined within the "secret management" of the orchestration unit 4. In this case, a new certificate or new access information can be requested as an action.

[0079] If access to access information 5 is required from outside the area managed by orchestration unit 4, automatic rotation cannot be performed. In this case, special alarms and security mechanisms can be triggered.

[0080] For example, an alarm policy can be defined using access data policy 6. This alarm policy defines how alarms or notifications should be sent to other instances 3 if they use the relevant access information 5. If an alarm occurs, the orchestration unit 4 checks which instance is using the access information and whether that instance is referenced in the alarm policy, for example, by using a label, regular expression, or directly indicating the instance name. It also defines how the changes to access information 5 should be notified to these instances 3. Then, specific actions applied to the affected instances 3 can be defined within this policy. Possible actions include, for example, executing a specific "skripte" within instance 3; executing a specific "kill signal" on the affected instances 3; or performing a full "re-deployment."

[0081] For container instances 3 and 7, it's common to monitor whether each instance 3 and 7 is functioning correctly using a "robe-Skript" or by monitoring a "container-probe-Skript". This feature can also be used to: if the application identifies changes to access information, meaning "secretrotation" can no longer be successfully performed, the application is handed over to the "probe-Skript" with a specific error code. In this case, the orchestration unit 4 can be notified, allowing it to, for example, re-modify the changed access information 5.

[0082] For example, for each entry within the alarm policy, it can be defined how long orchestration unit 4 should monitor for updated access information, how long it should be notified of updated access information, or how long container instances 3 and 7 may be newly started (by indicating the duration); whether access information 5 should be reset in the event of an error; and whether instances 3 and 7 should be notified in the same way.

[0083] For example, orchestration unit 4 can forward all password rotations (i.e., changes to access information) and alarms for failure to perform rotations to the central reporting system, and thus notify the operator of orchestration runtime environment 2 of unauthorized access.

[0084] exist Figure 2 For example, a flowchart illustrates the process of checking access to information. In this case, the flowchart, for instance, shows the loading of a rule set and the identification of attacks or unauthorized access.

[0085] In step S1, the central unit can provide at least one or more access messages 5 to the orchestration unit 4. In this case, a corresponding access data policy 6 can be additionally provided. In optional step S2, the access data policy 6 can be assigned to the corresponding access message 5. In optional step S3, the access message 4 can be assigned to the container instance 7, and the container instance 7 can be started, for example. In optional step S4, the orchestration unit 4 can check whether rules already exist for the access message 5 and the container instance 7. If so, the dataset can be expanded. This dataset can then include the access data policy 6 and an exception rule set 9. If these do not exist, the exception rule set 9 can be initially created and instantiated. In optional step S5, the created or generated exception rule set 9 can be provided to the anomaly identification unit 8. In step S6, access to the access message 5 can be performed by a process, particularly a process of the container instance 7. This can be achieved, for example, from an external source through a login attempt or by reading data.

[0086] In step S7, the access can be identified, in particular, by the anomaly identification unit 8. Then, in step S8, a comparison or check can be performed based on the anomaly rule set 9. When an unauthorized access is found, an alarm can be issued to the orchestration unit 4 in optional step S9. In this case, the orchestration unit 4 can now check the comparison between the access information 5 regarding the unauthorized access and the relevant access data policy 6 in optional step S10. In optional step S11, the access information 5 can be rotated or modified according to the measures defined in the access data policy 6. The orchestration unit 4 can then transmit information related to the modification of the access information 5 according to the definition in the access data policy 6 to the container instance 7.

[0087] In addition, in the optional step S13, the relevant information can be transmitted to other instances 3 in accordance with the data access strategy 6.

[0088] The present invention, and especially the embodiments described above, offers the following advantages. In particular, it is possible to define within orchestration unit 4 which access information is interdependent and which processes or instances 3 are permitted to access this information. For each individual namespace or container instance 3, 7, rotation of access information changes can be configured individually. Access can be identified not only at the orchestration node, i.e., within runtime environment 2, but also in the outsourced "secret manager," such as by means of corresponding "access logs." For example, the certificate manager can be coupled with access identification, i.e., with the identification of unauthorized access, to enable the updating of event-driven access data or access information. With the orchestration unit 4, event-driven changes to access information can be used to restart the application workload. If, by means of monitoring probes, it is identified that the application is not responding correctly, the access data can be reset to its initial value and an alarm can be triggered.

Claims

1. A method for checking access to access information within a runtime environment (2), wherein, A container instance (3, 7) can be authenticated in the runtime environment (2) by means of at least one access information (5), the method having: - provision, by an orchestration unit (4) of the runtime environment (2), of at least one access information (5); - assignment, by the orchestration unit (4), of an access data policy (6) to the at least one access information (5); - assignment, by the orchestration unit (4), of the at least one access information (5) to at least one container instance (7) of the runtime environment (2); - identification, by an anomaly recognition unit (8), of at least one access to the at least one access information (5); - checking, by the anomaly recognition unit (8), of the identified access to determine whether the identified access was made by a container instance (7) assigned to the at least one access information (5); and - if not: changing, by the orchestration unit (4), the at least one access information (5) on the basis of the respective access data policy (6). The changed at least one access information (5) is provided to the container instance (7) in relation to the change of the at least one access information (5).

2. The method of claim 1, wherein, The changed at least one access information (5) is transmitted to the container instance (7) and then an update of the container instance (7) is performed, wherein it is checked by a monitoring function of the container instance (7) whether the changed at least one access information (5) has been able to be updated in the container instance (7).

3. The method of claim 2, wherein, If the update cannot be successfully performed, corresponding information is transmitted to the orchestration unit (4) and then a re-change of the already changed access information (5) is performed by the orchestration unit (4), in particular the re-changed access information (5) is transmitted to the container instance (7).

4. The method of claim 3, wherein, It is checked with the orchestration unit (4) whether other container instances (3) use the changed at least one access information (5) and, if so, the changed access information (5) is provided to the container instances (3).

5. The method of any of the above claims, wherein, It is specified with the access data policy (6) which measures are to be performed in the event of an unauthorized access to the at least one access information (5).

6. The method of any of the above claims, wherein, With the measures, specific instructions are executed on the container instance (7) to which the unauthorized access relates, specific instruction signals are sent to the container instance (7) to which the unauthorized access relates and / or a reconfiguration is performed on the container instance (7) to which the unauthorized access relates.

7. The method of claim 6, wherein, It is specified with the access data policy (6) which user or process is allowed to access the at least one access information (5), in particular the access data policy (6) is taken into account in checking the identified access.

8. The method of any of the above claims, wherein, In checking the identified access, separate information is provided to the anomaly recognition unit (8) in relation to the container instance (7) assigned to the access information (5).

9. The method of any of the above claims, wherein, ​ 10. The method of any of the above claims, wherein, Based on the at least one access information (5) and the container instances (3, 7) of the runtime environment (2), an exception rule set (9) is generated by the orchestration unit (4) and provided to the exception identification unit (8), wherein the exception rule set (9) is taken into account when checking the identified access.

11. The method of any of the above claims, wherein, If it is ascertained when checking the identified access that the identified access was made by an unauthorized object, a corresponding alarm signal is generated by the exception identification unit (8) and transmitted to the orchestration unit (4).

12. The method of claim 11, wherein, Based on the alarm signal, an adaptation of the at least one access information (5) is carried out by the orchestration unit (4).

13. A runtime environment system (1) having: - a runtime environment (2); - a plurality of container instances (3) which can be authenticated within the runtime environment (2) by means of an access to at least one access information (5); - an orchestration unit (4) for providing the at least one access information (5); - the orchestration unit (4) which is designed to assign an access data policy (6) to the at least one access information (5); - the orchestration unit (4) which is designed to assign the at least one access information (5) to at least one container instance (7); - an exception identification unit (8) for identifying at least one access to the at least one access information (5); - the exception identification unit (8) which is designed to check the identified at least one access in order to determine whether the identified access was made by a container instance (7) assigned to the at least one access information (5); and - the orchestration unit (4) which is designed to change the at least one access information (5) based on a corresponding access data policy (6) if the identified access was not made by a container instance (7) assigned to the at least one access information (5).

14. A computer program (14) which can be directly loaded into the memory (13) of a control device (12) of a runtime environment system (1) according to claim 13, having program means for carrying out the steps of the method according to any one of claims 1 to 12 when the program (14) is executed in the control device (12) of the runtime environment system (1).

15. An electronically readable data carrier (15) on which electronically readable control information is stored, which electronically readable control information is designed such that, when the data carrier (15) is used in a control device (12) of a runtime environment system (1) according to claim 13, the electronically readable control information carries out the method according to any one of claims 1 to 12.

Images