Method for checking an accessing of access information within a runtime environment, and runtime environment system, computer program and data carrier
Patent Information
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- SIEMENS AG
- Filing Date
- 2024-07-17
- Publication Date
- 2026-05-13
Smart Images
Figure EP2024070257_20022025_PF_FP_ABST
Abstract
Description
[0001] Description
[0002] Method for checking access to access information within a runtime environment, as well as runtime environment system, computer program and data carrier
[0003] The invention relates to a method for checking access to access information within a runtime environment, wherein a container instance can authenticate itself in the runtime environment using at least one piece of access information.
[0004] Furthermore, the invention relates to a runtime environment system, a computer program and an electronically readable data carrier.
[0005] In container-based runtime environments, container instances are now created using an "image" or container image and a "deployment" configuration, and resources of the underlying host or runtime environment are assigned. Resources can be specifically provided by an underlying runtime environment or by the host. In addition to hardware and software resources, it is common for individual instances or objects to authenticate themselves within or outside the runtime environment using access credentials such as SSH keys, private certification keys, or passwords. These credentials can be managed, restricted, or access-restricted by an orchestrator, a "secret management system," or a central secret management system. Access control is typically implemented using "role-based access control."Using a token, the instance can authenticate itself with the secret management system. The secret management system authorizes the request and grants access to the access data or credentials. Using the token, the instance can receive or "retrieve" the access data. It is also conceivable for the orchestrator to take over access control and assign the access data to the instance using a dynamically generated "volume" or an environment variable.
[0006] To prevent such access data from being compromised, it is primarily transmitted in encrypted form and / or its validity is limited. However, one problem that cannot be solved by this approach is the case where an attacker is located directly on the runtime environment or the underlying device and is thus able to access the container instance and directly spy on the unprotected access data stored within the instance and use it in another context.
[0007] An application example here is a container-based industrial edge application, i.e. an application in a production or manufacturing line, which, for example, logs on to a backend system located outside the runtime environment using a unique password and for which no modern access mechanisms, such as restricted access tokens, can be used.
[0008] The problem with this application example is that the password cannot be limited in time and, on the other hand, without access monitoring, it cannot be ensured that other applications on the device, system users or attackers access the data and thus the password is read by an unauthorized entity.
[0009] In the current state of the art, for example, it is possible for an IAM system ("Identity Access Management System") to issue time-limited access tokens or certificates, which are then renewed whenever the requested system requests this from the IAM system. The problem here is that both the requested client and the target application must support the integration of the IAM system. This can, for example, involve supporting the "OAuth" process, which is typically used in web-based applications.
[0010] For example, there are procedures in which certificates or access tokens are issued for a limited time, and the "sidecar container," which performs the authentication, requests the access tokens or certificates independently. The "sidecar container" is specifically a container instance that performs "delivery work" for the main container instance. For example, it performs authentication to other services transparently for the main container instance.
[0011] There are also solutions that automatically rotate certificates and their associated keys. The rotation is controlled solely by the certificate's expiration date, not by suspicious access to the managed private key.
[0012] An object of the present invention is to make access to access information, such as access data, of a runtime environment more secure by detecting unauthorized access to such access information more efficiently.
[0013] This problem is solved by a method, a runtime environment system, a computer program, and an electronically readable data carrier according to the independent patent claims. Useful further developments arise from the dependent patent claims.
[0014] One aspect of the invention relates to a method for checking access to access information within a runtime environment, wherein a container instance can authenticate itself in the runtime environment by means of at least one piece of access information, comprising: - In particular, providing at least one piece of access information by an orchestration unit of the runtime environment,
[0015] - In particular, assigning an access data policy to the at least one access information by the orchestration unit,
[0016] - In particular, assigning the at least one access information to at least one container instance of the runtime environment by the orchestration unit,
[0017] - In particular, detecting at least one access to the at least one access information by an anomaly detection unit,
[0018] - In particular, checking the detected access by the anomaly detection unit to determine whether the detected access is carried out by a container instance associated with the at least one access information, and
[0019] - if not: In particular, changing the at least one access information on the basis of the corresponding access data policy by the orchestration unit.
[0020] The proposed method can provide or create improved verification or monitoring of access to access information. In particular, unauthorized access by an entity can be detected, and the corresponding access information can then be changed. In other words, the access information to which unauthorized or malicious access has occurred can be modified or regenerated accordingly. This can prevent or prevent corresponding access that is not permitted or is performed by an unauthorized entity.
[0021] The proposed procedure allows
[0022] Access information can be protected from unauthorized reading or unauthorized access. This can increase or improve IT security, particularly in the runtime environment. In other words, with the help of the proposed method, the orchestration unit or orchestration component, which is located outside the runtime environment, for example, can detect unauthorized access to access information inside and outside an instance, such as a container instance, and a password rotation or a change to the access information, particularly for the detected component, can be initiated and carried out on the basis of the unauthorized access.
[0023] Using the proposed method, an event-driven modification of access information, such as credentials, can be performed in an orchestrated environment, i.e. the runtime environment.
[0024] The runtime environment, also known as the execution environment, describes the requirements of a particular runtime system that are available and specified at the runtime of computer programs.
[0025] A container instance can be a virtually separated environment in which software applications are isolated for program deployment. Containers, for example, access an operating system together without the need for virtual machines. A container, for example, is not usually run in a standalone virtual machine and does not have its own complete operating system. Containerized applications can be composed of multiple container images. A container instance can, for example, contain components that are required in the application running in the container instance. These components include files, environment variables, dependencies and libraries. Container instances simplify the installation and operation of servers and applications as well as their management and distribution.Containers thus simplify the handling of complex server applications and enable extensive automation of rollout processes in data centers. This is particularly important for the deployment of scalable, distributed applications within cloud environments.
[0026] For example, the container instance can be an application, application, or computer program. Using at least one piece of access information or multiple pieces of access information, the container instance can authenticate itself within or externally in the runtime environment in order to be able to execute processes or functions of an application, for example.
[0027] An "overall application" can consist of multiple container instances created from different container images. Mutual authentication can then be performed using the access date or access information.
[0028] The at least one piece of access information, and in particular the access information, may be access data, such as certificates, passwords, or keys. In particular, the access information may be access data consisting of a user ID and a password. Thus, each pair forms an access identifier. In particular, the access information may comprise multiple pieces of access data and multiple pairs of access data. The orchestration unit may be an orchestration component or an orchestrator.
[0029] The orchestration unit can therefore be used to perform orchestration. Orchestration is the automated configuration, management, and coordination of computer systems, applications, and services. When using containers, the
[0030] Orchestration unit can distribute the instances across multiple execution environments managed by it.
[0031] The access data policy, which can be referred to as a "rotation policy," can be used to specify which processes in which container instances are allowed to read the corresponding access information, and what behavior should be taken in the event of a detected violation or unauthorized access. For example, the access data policy can first be generated or created.
[0032] Using the orchestration unit, at least one piece of access information or multiple pieces of access information can be assigned to a container instance. This means that an assignment is made on the system side. The access information or multiple pieces of access information can be provided accordingly or created or generated by the orchestration unit. Using the anomaly detection unit or an anomaly detection mechanism, each access can be checked to determine whether it is authorized or unauthorized. The system checks whether the access is being carried out by a container instance or an instance that is actually authorized to use the access information or access information in question.Should unauthorized access be detected, at least one piece of access information to which unauthorized access has occurred will be modified, depending on the access data policy associated with this access information. This occurs, in particular, automatically. Thus, this unauthorized access can be prevented or prevented. Using the proposed method, a rotation of access data or certificate keys can be performed after an unexpected access to a containerized runtime environment.
[0033] If access is granted by an authorized entity, this entity can access the corresponding access information.
[0034] In particular, the proposed method may be a computer-implemented method.
[0035] In one embodiment, the changed at least one piece of access information is made available to the container instance relating to the changing of the at least one piece of access information. As a result, after unauthorized or impermissible access to this access information has been prevented or prevented, the newly adjusted or changed access information can in turn be made available to the container instances, in particular transmitted, so that they are in turn up to date and can in turn access it. This prevents a situation in which authorized or permissible access by a container instance cannot be carried out successfully after the change of the at least one piece of access information because this access information was changed during a previous unauthorized access.Thus, in particular, all container instances that are assigned to the access information subject to at least one unauthorized access can be informed about the change in this access information.
[0036] In other words, in the event of unauthorized access to access information, all container instances that refer to this access information can be informed that the access information has now been changed and that this information will in turn be made available to these container instances.
[0037] Through this, particularly automated, adaptation of access information or access data following a detected or established unauthorized access, security, and in particular data security, can be continuously increased. Thus, defense against unauthorized access can be improved.
[0038] In one embodiment, it is provided that the changed at least one piece of access information is transmitted to the container instance, and then an update of the container instance is performed. A monitoring function of the container instance checks whether the changed at least one piece of access information could be updated in the container instance. For example, the orchestration unit that made the change to the access information can automatically transmit or send this changed access information to all relevant container instances.
[0039] The individual container instances or the at least one container instance can independently or autonomously adapt the stored, assigned access information so that the modified or changed access information is now stored. In order to ensure that after unauthorized access and a change to the access information has been detected, the other container instances can continue to access the access information assigned to them within the runtime environment, monitoring or checking can be carried out. In this case, a check is carried out, in particular using the monitoring function, as to whether the modified access information has been transmitted to the at least one container instance and is now saved or filed in the container instance.In this case, storage or updating can take place in a database or in a computing unit of the container instance.
[0040] In one embodiment, if the update could not be carried out successfully, corresponding information is transmitted to the orchestration unit, and then the orchestration unit changes the access information that has already been changed again.
[0041] For example, due to errors or faulty states, the transmission of the changed access information may not have been successful, and in turn, errors may have occurred when updating the changed access information. To remedy this situation and to ensure that the container instance can continue to access the access information assigned to it, the already changed access information can be adapted or changed again. This can be done, for example, by means of a computing unit of the corresponding container instance or by the monitoring function of the orchestration unit, to notify, for example by means of an indication signal, that the update of the changed access information could not be carried out successfully.The previously modified access information is then adjusted again to ensure that all container instances of the runtime environment that have access to the runtime environment can also access it successfully. It may also happen that the newly modified access information could not be updated because a cyber attack or other malicious intervention has already taken place. To remedy this situation, this access information is adjusted or regenerated and assigned to the container instances accordingly.
[0042] The already changed access information can then be transmitted again to the corresponding container instances by the orchestration unit.
[0043] In addition to or instead of the update, a time period can be taken into account to determine whether the update was successful or not. A predefined time limit can be set within which the update must be performed. If no positive feedback is received regarding the orchestration unit's update after this predefined time period, the already changed access information will be changed again for security reasons, particularly for IT security reasons, in order to prevent unauthorized access.
[0044] In one embodiment, the orchestration unit checks whether other container instances are using the at least one piece of access information that is being changed, and if so, the changed access information is provided to these container instances. For example, when assigning the access information to container instances, the container instances can be grouped or categorized accordingly with regard to the assigned access information, so that if unauthorized access is subsequently detected, the container instances that also use the changed access information can also receive it.
[0045] In one embodiment, the access data policy specifies which measures are to be taken in the event of unauthorized access to at least one piece of access information. This allows the system to quickly identify what action needs to be taken or implemented in the event of unauthorized access to the access information. For example, the scope or extent of the modification to the access information can be specified.
[0046] Likewise, the access data policy can specify appropriate warnings or security mechanisms that must be implemented or activated. In other words, the access data policy can be used to specify, on the system side, for a given piece of access information, which security measures (in particular, how and when) are to be implemented or activated by the orchestration unit upon detection of unauthorized access.
[0047] In one embodiment, it is provided that the measures include executing certain commands on a container instance affected by the unauthorized access, sending certain instruction signals to a container instance affected by the unauthorized access, and / or reconfiguring a container instance affected by the unauthorized access. These are exemplary measures that can be executed or carried out in any conceivable manner. In particular, at least some of these measures can be carried out or initiated accordingly by the orchestration unit.Corresponding signals or commands can be transmitted from the orchestration unit to the respective container instance, so that the corresponding measures can be implemented using a computing unit or processing unit of a respective container instance. This ensures that the container instances affected by the unauthorized access to the access information are not threatened by further threats or attacks. This particularly increases the general security regarding the runtime environment and the access information. In particular, the notification of the other instances is intended to inform the "client" applications running there that the login information required for logging into the "server" application has changed and that new access date or access information has been provided for this purpose.
[0048] In one embodiment, the access data policy is used to determine which user or process is authorized to access the at least one piece of access information. For example, when assigning the access information and the respective container instances, the orchestration unit can already be provided with information about which user or process is authorized to access a particular piece of access information or not. This can be advantageously used to detect unauthorized access, since it allows a check to be carried out based on the entity or instance that wishes to access an access information as to whether or not a corresponding user or process is accessing it. This makes it easier to detect unauthorized access.This allows the credential policy to be taken into account when checking the detected access.
[0049] In one embodiment, when checking the detected access, individual information regarding the container instance associated with these access data is provided to the anomaly detection unit. This individual information, such as specific information regarding the container instance, enables the anomaly detection unit to better or more efficiently check the detected access, since comprehensive information is available to assess or determine whether this is an authorized or unauthorized access.
[0050] In one embodiment, an anomaly rule set is generated by the orchestration unit on the basis of the at least one piece of access information and the container instances of the runtime environment and made available to the anomaly detection unit, wherein the anomaly rule set is taken into account, in particular additionally, when checking the detected access. Thus, a further verification criterion can be provided here in order to be able to better check the detected accesses with regard to illegal or unauthorized access. For example, an initial creation and instantiation of the anomaly rule set can be carried out by the orchestration unit. The anomaly rule set can be generated, in particular, already when the access data policy and the access information are assigned.
[0051] In one embodiment, it is provided that if, upon checking the detected access, it is determined that the detected access was made by an unauthorized object, a corresponding warning signal is generated by the anomaly detection unit and transmitted to the orchestration unit. Thus, in particular upon determination that unauthorized access is made by an object, such as an entity, an immediate warning or alarm can be issued. By means of the generated warning signal, the orchestration unit can be informed or notified by the anomaly detection unit that unauthorized access has occurred and that, in particular, appropriate measures or security precautions must be initiated or implemented as quickly as possible.In one embodiment, the orchestration unit performs a situation-adapted modification of the at least one piece of access information based on the warning signal. This can already provide an advantage if appropriate measures are taken for a particular situation. In particular, the modification can be used to implement or execute appropriate security measures, particularly data security measures, for a particular situation relating to a detected access. Modifying the access information can prevent unauthorized access.
[0052] Another aspect of the invention relates to a runtime environment system comprising,
[0053] - a runtime environment,
[0054] - several container instances that can authenticate themselves by accessing at least one access information within the runtime environment,
[0055] - an orchestration unit for providing the at least one access information,
[0056] - the orchestration unit, which is designed to assign an access data policy to the at least one piece of access information,
[0057] - the orchestration unit, which is designed to assign the at least one access information to at least one container instance,
[0058] - an anomaly detection unit for detecting at least one access to the at least one
[0059] Access information,
[0060] - the anomaly detection unit, which is designed to check the detected at least one access to determine whether the detected access is made by a container instance associated with the at least one piece of access information, and - the orchestration unit, which is designed to change the at least one piece of access information on the basis of the corresponding access data policy if the detected access is not made by the container instance associated with the at least one piece of access information.
[0061] In particular, with the help of the proposed runtime environment system, the aforementioned method according to the previous aspect can be carried out or executed.
[0062] For example, the runtime environment can be a container runtime environment (such as Docker).
[0063] Specifically, the multiple container instances can authenticate themselves within the runtime environment or each other using at least one access information.
[0064] A further aspect of the invention relates to a computer program which can be loaded directly into a memory of a control device of a computer network system according to the previous aspect, with program means for carrying out the method according to one of the previous aspects or an advantageous development thereof when the program is executed in a control device of a runtime environment system.
[0065] A further aspect of the invention relates to an electronically readable data carrier with electronically readable control information stored thereon, which is designed such that, when the data carrier is used in a control device of a runtime environment system according to one of the preceding aspects, it carries out a method according to one of the preceding aspects or an advantageous development thereof. For example, the runtime environment system can be a cloud-based technology. Specifically, the runtime environment system can be a container runtime environment that can be operated on an operating system.
[0066] Advantageous embodiments of one aspect of the invention may be considered advantageous embodiments of another aspect or all other aspects. The same applies in reverse.
[0067] For example, the computer program, the electronically readable data carrier and the runtime environment system may comprise means for executing or carrying out the method according to the invention.
[0068] Advantageous embodiments of the method are to be regarded as advantageous embodiments of the further method, the runtime environment system, the computer program, and the electronically readable data carrier. The runtime environment system, the computer program, and the electronically readable data carrier have material features that enable implementation of one of the methods or an advantageous embodiment thereof.
[0069] Regardless of the grammatical gender of a particular term, persons with male, female or other gender identities are included.
[0070] In various embodiments, the evaluation unit includes one or more hardware and / or software interfaces and / or one or more memory units.
[0071] A memory unit can be a volatile data memory, for example a dynamic random access memory (DRAM) or a static random access memory (SRAM), or a non-volatile data memory, for example a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory or flash EEPROM, a ferroelectric random access memory (FRAM), a magnetoresistive random access memory (MRM),MRAM (magnetoresistive random access memory) or phase-change random access memory, PCRAM (phase-change random access memory).
[0072] Unless otherwise stated, all steps of the method, in particular a computer-implemented method, can be carried out by at least one computing unit, which can also be referred to as a data processing device. In particular, the data processing device, which comprises at least one processing circuit designed or adapted to carry out a method according to the invention, in particular a computer-implemented method, can carry out the steps of the computer-implemented method. For this purpose, a computer program can be stored in the data processing device, in particular, which program comprises instructions which, when executed by the data processing device, in particular the at least one processing circuit, cause the data processing device to carry out the computer-implemented method.
[0073] For use cases or application situations that may arise during the method and which are not explicitly described here, it may be provided that, in accordance with the method, an error message and / or a request to enter user feedback is issued and / or a standard setting and / or a predetermined initial state is set.
[0074] The features and combinations of features mentioned above in the description, as well as the features and combinations of features mentioned below in the description of the figures and / or shown alone in the figures, can be used not only in the respective combination specified, but also in other combinations without departing from the scope of the invention. Embodiments and combinations of features are also to be considered disclosed that do not have all the features of an originally formulated independent claim and / or that go beyond or deviate from the combinations of features set out in the backreferences of the claims.
[0075] The invention is explained in more detail below with reference to specific exemplary embodiments and associated schematic drawings. In the figures, identical or functionally equivalent elements may be provided with the same reference numerals. The description of identical or functionally equivalent elements may not necessarily be repeated for different figures.
[0076] The following figures show in :
[0077] FIG 1 shows a schematic representation or overview of the components of the runtime environment system; and
[0078] FIG 2 shows an exemplary flowchart showing how unauthorized access can be detected within a runtime environment and what measures can be taken against it.
[0079] In the figures, functionally identical elements are provided with the same reference numerals. FIG. 1 shows a schematic representation of a runtime environment system 1. This higher-level, computer-based or data-based system can be used in particular to check access to access information within a runtime environment 2. The runtime environment system 1 can, for example, have a plurality of container instances 3 or instances or data-based objects. By means of the container instances 3, for example, processes or functions of an application can be executed. For this purpose, the container instances 3 can authenticate themselves by accessing access information assigned to a container instance 3 within the runtime environment 2 or from outside the runtime environment 2.
[0080] The runtime environment 2 can, in particular, be a containerized runtime environment. For security reasons, particularly IT security, no illegal, unauthorized, or unauthorised access to the access information, such as access data, may occur. For this purpose, specific access controls or access mechanisms must be provided. This is where the present invention advantageously comes into play. Using an anomaly detection mechanism, a reading of access information, such as a "secret", by an unexpected process, such as an instance, can be detected by an orchestration unit 4 or an orchestrator. In particular, the container instances can be processes, tasks, or program instances.
[0081] For example, at least one piece of access information 5 can be provided to the orchestration unit 4. At least one piece of access information 5 can be associated or assigned to this piece of access information 5 by the orchestration unit 4. The access data policy 6 can be a "rotation policy," for example. The piece of access information 5, which was referenced with the at least one piece of access data policy 6, can be associated or assigned by the orchestration unit 4 to at least one container instance 7 or multiple container instances 3. With the help of the access data policy 6, it can be determined in which container instances 3, 7 which processes are permitted to read or access the at least one piece of access information 5, and what behavior should be carried out by the orchestration unit 4 in the event of a known violation.
[0082] The access data policy 6, which can be individually specified for each piece of access information 5, can be used to determine which measures are to be taken in the event of unauthorized access to the access information 5. For this purpose, the access data policy 6 can contain a reference to the access information 6 managed by the orchestration unit 4.
[0083] For example, a direct reference to the name of the access information or a regular expression can be used to reference it. A reference to the container instance 7 can also be made using an assigned label, the direct reference, or a regular expression. Furthermore, the access data policy 6 can be used to define forbidden or permitted process names (if necessary in combination with process names) for the permitted users (by specifying the user name within the instance 7 or a user ID) as well as the reaction or measure to be taken, such as "allow," "rotate secret," or "alarm."
[0084] With the help of an anomaly detection unit 8, access within the runtime environment 2 or from outside to the runtime environment 2 can be monitored or checked. In particular, unauthorized access can be detected. In particular, access to access information, such as the access information 5, is checked. For the check, the anomaly detection unit 8 examines whether or not the detected access was made by a container instance 7 assigned to the access information 5. If unauthorized access is detected here, this access information 5 can be modified or regenerated. This can be done by the orchestration unit 4.
[0085] For example, based on an anomaly rule set 9, anomalies such as unauthorized access can be detected with the anomaly detection unit 8.
[0086] The following are example lines of code from part of the credential policy 6.
[0087] • Secret 1: Container instance 1 / reference: process name 1: process arguments 1: allow
[0088] • Secret 1: Container instance 2 / reference: process name 2: process arguments 2: allow
[0089] • any instance: any: any: alert
[0090] • ### definition of alert behavior
[0091] • secret X: Container instance a / reference: rotate secret
[0092] • secret X: Container instance b / reference: alarm only
[0093] For example, access information can be assigned to container instances 3 in different ways. Furthermore, different instance types can be provided within a deployment configuration in different paths or variable names. The integrity policy can be instantiated using the target values defined in the deployment configuration. For example, access information can be provided by assigning dynamically created "volumes" 10. By using such "volumes" 10, the use of environment variables can be dispensed with. Reading environment variables is more difficult to detect because they cannot be linked by opening a specific file, but are assigned in the process environment and can be easily read.Consequently, the rule set can be instantiated for each instance by assigning access information to the file associated with that instance. Furthermore, the runtime environment system 1 can have a kernel 11 or a kernel system or an operating system kernel.
[0094] Furthermore, it is conceivable for the runtime environment system 1 to have a corresponding control device 12. Furthermore, the control device 12 can have a memory 13 into which a computer program 14 can be loaded, for example to carry out the method according to the invention. For this purpose, the program 14 can be executed, for example, in the control device. Furthermore, an electronically readable data carrier 15 can be provided, which is designed to store electronically readable control information. When the data carrier 15 is used in the control device 12, the method according to the invention can in particular be carried out.
[0095] For example, once instantiation has occurred, the access data policy 6 can be transferred to the anomaly detection unit 8, in particular to its corresponding node. An update of the instantiation and an update of the anomaly monitoring policy or the anomaly rule set 9 on the nodes always takes place when new access information is provided or generated, instances 3 are stopped or started, or the access data policy 6 is updated. In other words, the anomaly rule set 9 can be generated based on the access information and a type and / or number of container instances 3.
[0096] For example, at least one piece of access information 5 or several pieces of access information may be confidential information or confidential data.
[0097] For example, the anomaly detection unit 8 can detect an unauthorized action by reading a secret file or the access information 6 and inform the orchestration unit 4 accordingly. The anomaly detection unit 8 can, for example, use a system command "fopen" for a secret file or access information 5 to detect whether or not a specific file has been accessed by an unauthorized user or process and compares this with the existing set of rules, in particular the anomaly rule set 9. If an alarm occurs, the behavior defined in the set of rules of the access data policy 6 can be executed. In this case, for example, within a "secret management" of the orchestration unit 4, it can be defined which complexity, for example, a piece of access information should have and, if necessary, which further actions should be carried out.The action that can be taken here is to request a new certificate or new access information.
[0098] If access to the access information 5 is used from outside the area managed by the orchestration unit 4, automated rotation cannot be performed. This may trigger special warning and security mechanisms.
[0099] For example, an alarm policy can be defined using the access data policy 6. This can be used to define how an alarm or information is to be sent to the other instances 3, provided they use the associated access information 5. If an alarm occurs, the orchestration unit 4 checks which instance is using the access information and whether this is referenced in the alarm policy, for example using labels, regular expressions, or direct specifications of the instance name. It is also defined how the instances 3 are to be informed of changes to the access information 5. Specific operations that are to be applied to the affected instances 3 can then be defined in the policy.Possible operations include, for example, the execution of certain "scripts" within the instances 3 , the execution of certain "kill signals" on the affected instances 3 , or the execution of a complete "re-deployment".
[0100] For the container instances 3, 7, it may be common practice to monitor the correct functioning of individual instances 3, 7 by means of a "probe script" or monitoring the container probe script. This property can also be used to pass applications with a specific error code to the "probe script" if the application thereby detects that a change to the access information, i.e. a "secret rotation", could not be carried out successfully. In this case, the orchestration unit 4 in particular can be informed so that it can, for example, carry out a further change to the access information 5 that has already been changed.
[0101] For example, for each entry within the alarm policy, it can be defined how long (by specifying a period of time) an updated access information-equipped, notified or, if applicable, restarted container instance 3, 7 is to be monitored by the orchestration unit 4 and whether, in the event of an error, the access information 5 is to be reset and the instances 3, 7 are to be notified in the same way.
[0102] For example, all password rotations, i.e., changes to access information, and alarms that do not perform a rotation can be forwarded by the orchestration unit 4 to a central reporting system, thus informing an operator of the orchestrated runtime environment 2 about unauthorized access.
[0103] For example, FIG. 2 shows a flowchart illustrating the process for verifying access to access information. This flowchart illustrates the implementation of the rules and the detection of an attack or unauthorized access.
[0104] In a step S1, at least one piece of access information 5 or more pieces of access information can be provided to the orchestration unit 4 by a central unit. The respective access data policies 6 can also be provided here. In an optional step S2, the access data policies 6 can again be assigned to the respective piece of access information 5. In an optional step S3, the access information 4 can again be assigned to the container instance 7 and the container instance 7 can again be started, for example. In an optional step S4, the orchestration unit 4 can check whether rules already exist for the access information 5 and the container instance 7. If so, the set of rules can be expanded. This set of rules can then comprise the access data policy 6 and the anomaly rule set 9.If this is not available, an initial creation and instantiation of the anomaly rule set 9 can take place. The created or generated anomaly rule set 9 can be provided or made available to the anomaly detection unit 8 in an optional step S5. In a step S6, access to the access information 5 can again take place by a process, in particular a process of the container instance 7. This occurs, for example, from outside through a log-in attempt or by reading data.
[0105] In a step S7, this access can be detected in particular by the anomaly detection unit 8. A comparison or comparison or check can then be carried out in a step S8 against the anomaly rule set 9. If it is determined that unauthorized access has occurred, the orchestration unit 4 can be alerted in an optional step S9. In this case, in an optional step S10, the orchestration unit 4 can compare the access information 5 to determine that unauthorized access has occurred and check the associated access data policy 6. Depending on which measures are defined in the access data policy 6, the access information 5 can be rotated or changed in an optional step S11.The orchestration unit 4 can in turn transmit information about the changes to the access information 5 according to the definition in the access data policy 6 to the container instance 7.
[0106] Furthermore, in an optional step S 13, corresponding information can be transmitted to further instances 3 in accordance with the access data policy 6.
[0107] In particular, the present invention and in particular the aforementioned embodiments can generate the following advantages. In particular, within the orchestration unit 4, it can be defined which access information is interdependent and which processes or instances 3 may access it. The rotation regarding the change of the access information can be individually configured for each individual namespace or container instance 3, 7. Access can be detected both on the orchestrated nodes, i.e., within the runtime environment 2, and in the outsourced "secret manager," for example, using corresponding "access logs." For example, certificate managers can be linked to access detection, i.e., the detection of unauthorized access, in order to be able to renew event-driven access data or access information.With the help of Orchestration Unit 4, event-driven changes to the access credentials can be used to restart the application workloads. If the monitoring probe detects that an application is not responding correctly, the access credentials can be reset to their original value and an alarm triggered.
Claims
Patent claims 1. A method for checking access to access information within a runtime environment (2), wherein a container instance (3, 7) can authenticate itself in the runtime environment (2) by means of at least one piece of access information (5), comprising: - Providing at least one access information item (5) by an orchestration unit (4) of the runtime environment (2), - Assigning an access data policy (6) to the at least one access information item (5) by the orchestration unit (4), - Assigning the at least one access information (5) to at least one container instance (7) of the runtime environment (2) by the orchestration unit (4), - detecting at least one access to the at least one access information (5) by an anomaly detection unit (8), - checking the detected access by the anomaly detection unit (8) to determine whether the detected access is carried out by a container instance (7) associated with the at least one access information item (5), and - if not: changing the at least one access information item (5) on the basis of the corresponding access data policy (6) by the orchestration unit (4).
2. The method according to claim 1, wherein the changed at least one access information (5) is provided to the container instance (7) relating to the changing of the at least one access information (5).
3. The method according to claim 2, wherein the changed at least one access information item (5) is transmitted to the container instance (7) and subsequently an update the container instance (7), wherein a monitoring function of the container instance (7) checks whether the changed at least one access information item (5) could be updated in the container instance (7).
4. The method according to claim 3, wherein if the update could not be carried out successfully, corresponding information is transmitted to the orchestration unit (4) and then the orchestration unit (4) again changes the already changed access information (5), in particular the again changed access information (5) is transmitted to the container instance (7).
5. Method according to one of the preceding claims, wherein the orchestration unit (4) checks whether further container instances (3) use the at least one item of access information (5) which is changed, and if so, the changed access information (5) is provided to these container instances (3).
6. Method according to one of the preceding claims, wherein the access data policy (6) specifies which measures are to be carried out in the event of unauthorized access to the at least one piece of access information (5).
7. The method according to claim 6, wherein the measures include executing certain commands on a container instance (7) affected by the unauthorized access, sending certain instruction signals to a container instance (7) affected by the unauthorized access and / or reconfiguring a container instance (7) affected by the unauthorized access.
8. Method according to one of the preceding claims, wherein the access data policy (6) determines which user or process may access the at least one access information (5), in particular when Checking the detected access the credential policy (6) is taken into account.
9. Method according to one of the preceding claims, wherein, when checking the detected access, individual information concerning the container instance (7) associated with this access information (5) is provided to the anomaly detection unit (8).
10. The method according to any one of the preceding claims, wherein, on the basis of the at least one access information item (5) and the container instances (3, 7) of the runtime environment (2), an anomaly rule set (9) is generated by the orchestration unit (4) and provided to the anomaly detection unit (8), wherein the anomaly rule set (9) is taken into account when checking the detected access.
11. Method according to one of the preceding claims, wherein if it is determined during the checking of the detected access that the detected access is made by an unauthorized object, a corresponding warning signal is generated by the anomaly detection unit (8) and transmitted to the orchestration unit (4).
12. The method according to claim 11, wherein the orchestration unit (4) carries out a situation-adapted modification of the at least one item of access information (5) on the basis of the warning signal.
13. Runtime environment system (1) with, - a runtime environment (2) , - several container instances (3) which can authenticate themselves by accessing at least one access information (5) within the runtime environment (2), - an orchestration unit (4) for providing the at least one access information item (5), - the orchestration unit (4) which is designed to assign an access data policy (6) to the at least one access information item (5), - the orchestration unit (4) which is designed to assign the at least one access information item (5) to at least one container instance (7), - an anomaly detection unit (8) for detecting at least one access to the at least one access information item (5), - the anomaly detection unit (8) which is designed to check the detected at least one access to determine whether the detected access is carried out by a container instance (7) associated with the at least one access information item (5), and - the orchestration unit (4) which is designed to change the at least one piece of access information (5) on the basis of the corresponding access data policy (6) if the detected access is not carried out by the container instance (7) assigned to the at least one piece of access information (5).
14. Computer program (14) which can be loaded directly into a memory (13) of a control device (12) of a runtime environment system (1) according to claim 13, with program means for carrying out the steps of the method according to one of claims 1 to 12 when the program (14) is executed in the control device (12) of the runtime environment system (1).
15. Electronically readable data carrier (15) with electronically readable control information stored thereon, which is designed such that it carries out a method according to one of claims 1 to 12 when the data carrier (15) is used in a control device (12) of a runtime environment system (1) according to claim 13.