Method for carrying out an authorization process for a client application

Abstract

The invention relates to a method for carrying out an authorization process for a client application (3) in a computer network system (1), wherein - an individual degree of confidence (12) for the client application (3) is generated by an authentication application (6), - contact information (13) relating to the client application (3) is generated by the authentication application (6), and - on the basis of the contact information (13) and the degree of confidence (12) access information (14) of the client application (3) is determined for an application program (7) of the computer network system (1). The invention additionally relates to a method for running an application program (7), to the computer network system (1), to a computer program product (10), and to an electronically readable data carrier (11).

Description

[0001] Description

[0002] Method for performing an authorization process of a client application

[0003] The invention relates to a method for performing an authorization process for a client application in a computer network system. The invention also relates to a method for executing an application program. Furthermore, the invention relates to a computer network system with at least one client application. Furthermore, the invention relates to a computer program product and an electronically readable data carrier.

[0004] In information technology, authorized access to systems, applications, and / or networks is essential. Various security systems and / or security architectures are known for this purpose. For example, so-called "zero-trust security" can provide a security model in which no one is automatically trusted. In a "zero-trust model," every access to a network is checked multiple times, for example, through mechanisms such as multi-factor authentication. This is particularly useful for cybersecurity. The guiding principle of a "zero-trust architecture" is "trust no one, check everything." This allows countless applications and devices to be better protected.

[0005] Zero-trust data security is important because it provides a reliable cybersecurity framework to protect against advanced attacks targeting complex IT environments with dynamic workloads that frequently move between locations and devices. Zero-trust architectures are also particularly relevant as multi-cloud and hybrid cloud deployments become increasingly prevalent, increasing the number of externally exposed applications used within companies.

[0006] In a zero-trust model, every single identity on the network is assessed for risk, with activities closely tracked, sometimes in real time. At the heart of this approach is the principle of least-privilege access, which means each user is granted only as much access as they need to perform the task at hand. Zero-trust frameworks never assume an identity is trustworthy and always require confirmation before access to the network is permitted. Zero-trust security is a software-defined model that is constantly evolving to protect applications and sensitive data—regardless of the user, device, or location.

[0007] For example, if applications are protected with a Zero Trust Policy Enforcement Point (ZT-PEP), the respective trust status of a client and its user is recorded along with other threat and risk indicators. These attributes are appropriately combined and calculated using a mathematical and / or logical formula to form a numerical value, the so-called "trust score." This "trust score" can be transmitted to the application and evaluated by the application. If it is used to authorize access, access can be granted with the appropriate authorization, particularly depending on the trust score. To transmit the status, the "authorization service" of the "policy enforcement point" typically creates time-limited certificates or OAuth / JSON web tokens containing the trust score and other information relevant to the application.

[0008] The requested application, protected by the policy enforcement point, can assign access rights solely based on the trust score, but has no information about how this score is calculated. A trust score is compiled from various client parameter information. This includes, for example, the strength of authentication (one or two factors), the client's operating system, the device's patch level, or the device's location (e.g., a secured network segment or a direct internet connection). The current global threat situation, known vulnerabilities in the communication protocol, or heuristics, such as the volume and regularity of network traffic, can also be incorporated into the trust score calculation.As with a hash function, the share of certain user parameters (which are crucial for authorization to access a resource) in the overall score that allows access over the network is no longer visible or calculable.

[0009] When authorizing a service running on a server, the problem now arises that the service can only use the trust score for authorization, but cannot independently assign granular access rights to applications launched by the application based on one or more aspects of the property determined by the Zero Trust Policy Enforcement point, and can therefore independently reprioritize them.

[0010] For remote access, such as via Secure Shell or remote desktop connections, only a check is performed to determine whether the login is permitted or denied, and after login, the permissions statically assigned to the user account are used. Permissions cannot be assigned dynamically within a session or while using a launchable application.

[0011] With remote access solutions such as those provided by CITRIX, it would be possible for the Zero Trust Policy Enforcement point to grant authenticated users access to individual applications via the associated CITRIX login portal, depending on the score. However, once a remote session is authorized, it can only be restricted if individual applications to be protected and called within the session also request authentication at a Zero Trust Policy Enforcement point, and the original context of the initial client cannot be authorized, or cannot be fully authorized, during authorization by the application.

[0012] Another well-known feature of remote access solutions such as SSH is SSH agent forwarding. This involves using the SSH key for logging on to the first server and then logging on to downstream servers, as the protocol supports transitive access to the original authentication agent.

[0013] A disadvantage of the options mentioned is that the assignment of access authorizations is static.

[0014] Thus, one object of the present invention is to be able to manage or adapt access or multiple accesses to an application or applications more dynamically.

[0015] This problem is solved by several methods, a computer network system, a computer program product, and an electronically readable data carrier according to the independent patent claims. Useful further developments arise from the dependent patent claims.

[0016] One aspect of the invention relates to a method for performing an authorization process of a client application in a computer network system, wherein

[0017] - an individual trust level of the client application is generated with an authentication application,

[0018] - context information about the client application is generated by the authentication application, the context information (13) being client-specific information with which the client application (3) can be characterized, and

[0019] - depending on the context information and the degree of trust, access information of the client application for an application program of the computer network system is determined.

[0020] In particular, the proposed method is a computer-implemented method. In particular, the method may be a cloud-based application.

[0021] The proposed method allows access and access rights for a client or client application and its users to be managed more dynamically. Thus, based on the diverse information provided, for example, by the context information, various access options for the client application can be authorized, blocked, or partially restricted. This results in secure, controlled, and customized access.

[0022] Using the determined or generated access information, dynamic access of the client application to the application program can be granted or authorized. In particular, access rights for the client application can be generated using the access information. In particular, the proposed method enables the assignment of context-related access rights for applications and / or downstream applications in a zero-trust environment.

[0023] The proposed method can be used to restrict authorizations on a platform and / or a computer network system on a session-related basis, even for applications that do not require network login. When logging on to services that are accessible via the network or computer network system, for example, it is possible to take into account the context of the upstream systems or the application program. On the computer network system or system, local server services, such as container runtime environments and local databases, can be restricted depending on the context. For shell access, context-related application whitelisting can also be performed.With the aid of the access information, the application program or an application for authorizing the client application can be provided with, in particular, more precise context information, which they can then use to grant access rights for the application program and / or other application programs and / or applications.

[0024] An example of this application is remote access to an admin console via "Secure Shell" (SSH) on a server accessible from the Internet or, for example, an industrial control device. If a login is made on the device based on the assigned trust score, i.e. the level of trust, of the authorization server used by the policy enforcement point, a decision is made as to whether or not a user may log in using the user account. The permitted application or application program (in this case, for example, a login shell) is then started, which, however, does not further exploit the context information but is statically assigned to the assigned account. Thus, the access rights of the shell cannot be graded depending on the trust score or process authorization.

[0025] For example, the application program can be implemented as a database or at least access a database. Using access information, access to individual tables or columns in the database can be regulated or restricted depending on the context information or login context.

[0026] Using access information, trust information assigned by a Zero Trust Policy enforcement point on a system, such as the computer network system, such as the trust level, can be passed on to applications running on another system. This allows not only the access permissions of the admin console (shell access via SSH) on an industrial control device to be restricted, but also, for example, a logged-in user can receive graded access to a Docker runtime environment running on it, depending on their location.One use case for this would be, for example, that when logging in from an insecure network, only access to the status of the containers or data containers is possible, and when accessing from a better secured network, the container instances running on the container runtime environment can also be started and stopped.

[0027] The proposed method is particularly advantageous for remote connections or remote applications. This can, in particular, improve cybersecurity or IT security.

[0028] A client application, client-side application, client application, or client program is a computer program that runs on a terminal device of a network, for example, a multi-network system, and communicates with a server or central computer of the computer network system. In particular, the client application is executed by a user on a computing unit or terminal device.

[0029] The authentication application can, for example, be referred to as an authentication service. This, in turn, can be implemented in a central processing unit of the computer network system. With the help of the authentication application, which is executed on a processing unit, the individual trust level or trustworthiness level can be generated. The trust level can be the "trust score" mentioned above.

[0030] Using the context information, additional information can be provided. Thus, based on the trust level, the context information provides further information so that information can be expanded. For example, the context information can be client-specific information with which the client application can be characterized. For example, the authentication application and / or a computing unit can determine or generate the access information depending on the context information and the trust level. This links the trust level to the context information. This can be used for later access or for managing access rights.

[0031] The computer network system can be referred to, for example, as a computer network, computer network, or computer network. For example, the computer network system can have a central computer or mainframe computer. Such a central computer can provide the connected computers (workstations or terminals) with the programs, services, system programs, or application programs running on it.

[0032] In one embodiment of the present invention, it is further provided that the client application is executed on a terminal device of the computer network system, wherein a property of the terminal device and / or a property of the client application and / or user information of a user of the client application and / or a property of a communication connection between the terminal device and the computer network system is taken into account for generating the trust measure. In particular, the properties and / or information just counted can be used to generate the trust measure or "trust score". In particular, this information and / or properties can be made available to the authentication application, for example, the aforementioned properties and / or information can be made available to the Zero Trust Policy Enforcement point mentioned above.The client, in turn, can make this information available or transmit it to the authentication application, so that, depending on the various information, properties, and / or parameters, an individual trust measure can be generated for each client application. This trust measure is a zero-trust score.

[0033] In particular, a wide variety of information and / or properties and / or threat indicators and / or risk indicators or a location of the end device and / or a wide variety of parameter information can be taken into account when generating the trust measure. In particular, the strength of the authentication, an operating system of the end device, the patch standard of the end device, the location of the end device, known vulnerabilities in protocols or heuristics of the communication connection and / or any other existing, particularly situation-dependent, influencing factors can be taken into account when calculating the trust measure. This means that access information that is suitable for the client application and, in particular, adapted to the situation can be generated later.

[0034] For example, the access information can be referred to as authentication information.

[0035] In addition, or instead, the context information can be assigned to the authentication information queried by the authentication application and assigned to a request, for example, from the Zero Trust Policy Enforcement point. For example, the trust measure can be provided as a certificate, a signed OAuth token (Open Authorization Protocol token), or a JSON web token (JavaScript Object Notation token).

[0036] In one embodiment, access to the application program is permitted depending on the access information, wherein, depending on the context information, the client application is additionally permitted access to at least one subroutine of the application program and / or at least one function of the application program. Consequently, context-dependent, in particular dynamic, access to a wide variety of application programs and in particular applications of the client application can be enabled or provided. Based on the access information generated once, the client application can be granted access to further subapplications (subroutines) in addition to the main application (application program). In this way, the one-time authorization process of the client application can be provided with multiple accesses or access rights to various functions, applications and / or applications.This allows the client application, and thus the underlying user, to be provided with multiple context-dependent access options efficiently and easily. When the client application accesses various programs or applications, a separate authorization or access process is not required for each access. This is done using the access information generated during a primary access to the application program.

[0037] In other words, the access information can be used to provide the client application with various access rights or privileges to a wide variety of application programs and / or functions. Furthermore, individual access can be granted or restricted for a particular application program and / or subprogram and / or function. For example, the client application can be granted greater access rights or a greater degree of access to the application program than to the downstream or subordinate subprograms of the application program. This allows security-critical and / or data protection-critical functions and / or subprograms of the application program to be restricted depending on the situation or specifically.

[0038] In one embodiment, it is further provided that, depending on the context information when accessing the application program, a functional scope, an access right, a program scope, a number of authorized subprograms and / or functions, an application duration, read access, and / or write access for the at least one subprogram and / or the at least one function of the application are determined. This results in a dynamic allocation of access executions for the client application or the client. Accordingly, an access model or access options tailored to the client can be provided based on the various context information.Using the context information, the client application can, for example, individually, situationally and / or client-specifically define access types or scopes of access with regard to the at least one subprogram (or multiple subprograms) and / or the at least one function (or multiple functions) of the application program. Thus, depending on the client application and in particular on the context information assigned to the client application, an application option with regard to the application program, the subprograms of the application program and / or the functions of the application program can be tailored. Consequently, when the client application accesses the application program, the access, scope of access and / or access authorization for all functions of the application program and all subprograms or subordinate programs and / or applications of the application program are determined.

[0039] In one embodiment, a policy for the authentication application is provided in a policy database, wherein the individual trust level of the client application is generated with the authentication application depending on at least one trust criterion stored in the policy. Using the policy or policies and the trust criterion or multiple trust criteria stored therein, the trust level of the client application can be generated individually and in a situation-adapted manner, depending on the application and / or circumstances or a particular situation.

[0040] The policy can, for example, contain specifications or rules that specifically address the IT security of the computer network system. This allows the level or quality of IT security or security required by the computer network system to be determined in advance. This can be taken into account in advance, so that every client application that wishes to authorize itself in the computer network system can be classified accordingly in terms of security.

[0041] For example, the trust criterion can be used to provide a trust criterion for the client application and to take this into account when generating the trust measure.

[0042] With the help of the policy and in particular the trust criterion stored in the policy, a weighting or evaluation of the client application, especially one that is relevant for security, can be carried out. In particular, the policy database is, for example, a component of the computer network system. In one embodiment, it is provided that the trust level is signed as a certificate by the authentication application, with this signed certificate being assigned to the client application. In this way, for example, an individual trust score or trust level can be clearly assigned to the client application. This is then advantageous for carrying out a clear authorization or authorization process of the client application with regard to the application program.The application program can thus uniquely identify the client application and take into account the level of trust assigned to the client application when determining the access information and thus the access.

[0043] Specifically, the trust measure can also be generated or signed in other, particularly proprietary, formats.

[0044] In particular, signing only takes place after checking the authenticity of the trust measure, so that the creation of the trust measure cannot be manipulated.

[0045] For example, the trust measure can be generated and signed as a certificate or token. Thus, the signed certificate can be used to uniquely assign the trust measure or trust score to the client application.

[0046] In one embodiment, it is provided that, depending on the specific access information, a session of the client application on the application program is carried out or started, wherein, within this session, a respective current context information is dynamically determined and a dynamic allocation of access rights of the client application for subprograms and / or functions of the application program is carried out depending on the respective current context information determined. This has the advantage that, during an existing or started session of the client application on the application program, the range of functions or the application options of the client application for subprograms and / or functions of the application program can be dynamically changed or adapted.This means that the access rights of the client application are dynamically allocated or adjusted even while the client application has already granted access to the application program.

[0047] For example, context information can be made available again or context information can be updated. This allows the client application's access to the application program and the underlying functions or subroutines to be corrected, restricted, or expanded at any time in an intelligent manner. Consequently, access to the client application can be restricted, particularly if it is determined that, for example, due to current circumstances, the security of the application program and, in particular, of the computer network system is no longer fully guaranteed.

[0048] A session is a permanent connection between a client and a server or the computer network system. At the beginning of such a session, a login, i.e., the authorization process, occurs, and at the end, a logout, i.e., the logout process, occurs.

[0049] An application program is an application software or computer program.

[0050] In one embodiment, it is further provided that a trustworthiness list with context information values ​​and trust measure values ​​is provided, wherein access rights to the application program and / or other application programs are assigned in the client application using the trustworthiness list. Such a trustworthiness list can be used to assign or assign presets or predefined access rights to the client application. Thus, the client application can already be assigned a type of basic access option or basic access rights. This can be taken into account, in particular, when generating or determining the access information.

[0051] In particular, specific values ​​regarding context information and values ​​regarding the trust level can be predefined in a special list or table. This can be done, for example, by the authentication application.

[0052] For example, the trust list can be an exception list (e.g. "deny list or "blacklist"), a white list or an "application whitelisting" (e.g. "allow list").

[0053] In one embodiment, the access information is encoded based on a place-value system. Thus, the authentication application can generate and provide a data format for the access information. This can be transmitted to the respective applications, systems, and / or computer programs. In particular, the access information can be based on a binary, decimal, or hexadecimal system. Other known place-value systems from information technology are also applicable.

[0054] For example, all attributes used and combined for authorization or authentication can be reconstructed using a suitable mask with the help of the place value system. This is important for the unambiguous and, in particular, security-critical authorization of the client application. A further aspect of the invention relates to a method for executing an application program, in which a client application authorizes itself according to a method according to one of the preceding aspects or an advantageous development thereof. The client application is granted access to the application program according to the access information. In particular, advantageous embodiments of the preceding aspect can be regarded as advantageous embodiments of the present method.

[0055] In particular, after the access information has been generated, an access process or authorization process of the client application can be performed on the application program. For this purpose, the application program analyzes and evaluates the access information accordingly, so that the corresponding access and, in particular, the corresponding access rights of the client application can be granted or restricted.

[0056] In one embodiment of the further aspect, it is provided that the access information is additionally provided with at least one attribute and stored in an attribute database of the application program. This occurs in particular during the access process or during a registration process or login process of the client application on the application program. For example, when the access information is generated, at least one additional attribute or several attributes can be added to the access information. If access by the client application to the application program is permitted, the at least one attribute can be automatically saved or temporarily stored in the attribute database. In particular, the at least one attribute can be used for the dynamic assignment of access rights during the already permitted access to the application program.In one embodiment of the further aspect, it is provided that, depending on the stored attribute, a specific access of the client application to a subprogram and / or a function of the application program is determined. Thus, downstream functions and / or subordinate subprograms of the application program can be restricted or enabled for use by the client application without requiring their own specific access.

[0057] In particular, the stored attribute can be used in a current session, i.e., session-related, of the client application with respect to the application program. In a subsequent access process or when starting a new or additional session, the stored attribute can no longer be used. In particular, this is usable with permitted access and thus with a started session of the application program.

[0058] A further aspect of the invention relates to a computer network system having a client unit for executing a client application and a server unit for executing an authentication application and an application program. The computer network system is configured to carry out a method according to one of the preceding aspects or an advantageous embodiment of at least one of the aforementioned aspects.

[0059] In particular, a method is carried out or executed according to the aforementioned aspects or an advantageous further development from one of these aspects.

[0060] The computer network system can be a computing network, computer network, or computer network. For example, the computer network system can be an industrial system, such as a processing line, processing process, assembly line, manufacturing equipment, or a corporate network. In particular, the client unit is a computing unit. The server unit is, for example, a local, centralized, or decentralized server. In particular, the server unit can be a cloud-based unit.

[0061] The computer network system can also be a cloud-based system.

[0062] A further aspect of the invention relates to a computer program product 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 computer network system.

[0063] A further aspect of the invention relates to an electronically readable data carrier having electronically readable control information stored thereon, which is designed such that, when the data carrier is used in a control device of a computer network 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 computer network system can be a cloud-based technology.

[0064] Embodiments of one aspect are to be regarded as advantageous embodiments of the other aspects and vice versa.

[0065] Advantageous embodiments of the method are to be regarded as advantageous embodiments of the further method, the computer network system, the computer program product, and the electronically readable data carrier. The computer network system, the computer program product, and the electronically readable data carrier have material features that enable implementation of one of the methods or an advantageous embodiment thereof.

[0066] A computing unit, such as a client unit, a terminal device, or a server unit, can be understood in particular as a data processing device that contains a processing circuit. The computing unit can therefore, in particular, process data to perform computing operations. This may also include operations for performing indexed access to a data structure, for example, a lookup table (LUT).

[0067] The computing unit can in particular contain one or more computers, one or more microcontrollers and / or one or more integrated circuits, for example one or more application-specific integrated circuits (ASICs), one or more field-programmable gate arrays (FPGAs), and / or one or more single-chip systems (SoCs). The computing unit can also contain one or more processors, for example one or more microprocessors, one or more central processing units (CPUs), one or more graphics processing units (GPUs), and / or one or more signal processors, in particular one or more digital signal processors (DSPs). The computing unit can also contain a physical or virtual network of computers or other of the aforementioned units.

[0068] In various embodiments, the computing unit includes one or more hardware and / or software interfaces and / or one or more memory units.

[0069] 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,MRAM (magnetoresistive random access memory) or as phase-change memory - rather with random access, PCRAM (phase-change random access memory).

[0070] 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.

[0071] For applications or application situations that may arise during the method and which are not explicitly described here, it can be provided that, according to the method, an error message and / or a request to enter user feedback is output and / or a default setting and / or a predetermined initial state is set. The features and feature combinations mentioned above in the description as well as the features and feature combinations 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 regarded as disclosed which do not have all the features of an originally formulated independent claim and / or which go beyond or deviate from the combinations of features set out in the reliances of the claims.

[0072] The invention is explained in more detail below using specific 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.

[0073] The following figures show in :

[0074] FIG 1 is a schematic representation of a computer network system; and

[0075] FIG 2 shows a schematic sequence of an embodiment of a method according to the invention.

[0076] In the figures, functionally identical elements are provided with the same reference numerals.

[0077] FIG 1 shows an exemplary view of a computer network system 1. The computer network system 1, which is for example a computing network or a data processing network, can have at least one client unit 2 for executing a client application 3. For example, a plurality of client applications 3 can be executed with the client unit 2. For example, the client application 3 and / or the client unit 2 can be executed and in particular implemented on a terminal 4 of the computer network system 1. In one possible variant, the client unit 2 and the terminal 4 can be referred to as one unit. It is also conceivable that they are separate units.

[0078] Furthermore, the computer network system 1 can have a plurality of client units 2 and in particular end devices 4. For example, the end device 4 can be a computing unit. For example, the computer network system 1 can have a plurality of computing units which can be communicatively networked with one another. Furthermore, the computer network system 1 can have at least one server unit 5. An authentication application 6 and an application program 7 can be executed with the server unit 5, which is for example a computing device, computing unit or cloud-based unit. In particular, application programs, applications, or other software-based systems can be executed with the server unit 5, which can be regarded for example as the central computer or central computing unit of the system 1.

[0079] Furthermore, the computer network system 1 can have a control device 8. This control device 8 can in turn have a memory 9, onto which, for example, a computer program, also referred to as a computer program product, 10 can be loaded. For example, the computer program product 10 can have program means for carrying out one of the methods according to the invention or a development thereof when the program 10 is executed in the control device 8 of the computer network system 1. Furthermore, an electronically readable data carrier 11 can be provided which contains stored electronically readable control information which is designed such that, when the data carrier 11 is used in the control device 8 of the computer network system 1, it optionally carries out a method according to the invention.

[0080] For example, the client application 3 can carry out an authorization process in the computer network system 1. For this purpose, an individual trust level 12 of the client application 3 can be generated or created using the authentication application 6. In addition, context information 13 about the client application 3 can be generated by the authentication application 6. Depending on the context information 13 and the trust level 12, access information 14 of the client application 3 to the application program 7 can be determined. With the help of the access information 14, the client application 3 can access the application program 7. Thus, with the help of the determination of the access information 14, an authorization process of the client application 3 to the application program 7 is carried out.

[0081] For example, a property of the terminal device 4 and / or the client unit 2 and / or a property of the client application 3 and / or a user information of a user

[0082] 15 of the client application 3 and / or a property of a communication connection 16 between the terminal device 4 and the system 1 of the authentication application 6 are made available or transmitted, so that at least one of these pieces of information or properties can be taken into account and thus used for generating the trust level 12. In the communication connection

[0083] 16 can, for example, be any communication connection or data transmission connection within the computer network system 1.

[0084] Furthermore, depending on the access information 14, access to the application program 7 can be permitted. In this case, depending on the context information 13, access of the client application 3 to at least one subprogram 17 of the application program 7 and / or at least one function 18 of the application program 7 can additionally be permitted. Furthermore, for example by the authentication application 6 and / or the server unit 5, depending on the context information 13 when accessing the application program 7, a range of functions, an access right, a program scope, a number of authorized subprograms and / or functions, an application duration, a read access and / or a write access for the at least one subprogram 17 and / or the at least one function 18 of the application program 7 can be determined.

[0085] Furthermore, the system 1 can contain or have a policy database 19. This can contain special policies and / or rules and / or regulations and / or specifications for generating the trust level 12. For this purpose, at least one policy for the authentication application 6 can be provided in the policy database 19, and the individual trust level 12 can be generated depending on at least one trust criterion stored in the policy.

[0086] Furthermore, the authentication application 6 can be designed to generate a signed certificate depending on the trust level 12, so that a unique assignment and in particular identification of the client application 3 can be carried out with the help of this certificate. If the client application 3 successfully accesses the application program 7, a session can be started or carried out. Within this session, the client application 3 can execute or apply or use the application program 7, the at least one subroutine 17 and / or the at least one function 18 in accordance with the assigned access rights. In order to be able to carry out an intelligent and in particular dynamically adapted security check, a current piece of context information can be dynamically determined within the session.This can be done, for example, with the server unit 5. Thus, a dynamic allocation of access rights of the client application 3 for subprograms 17 and / or functions 18 can be carried out depending on the current context information determined in each case.

[0087] Furthermore, it can be provided that a trustworthiness list or exception list or white list or application white list with context information values ​​and trust measure values ​​with regard to the context information 13 and the trust measure 12 is provided, whereby the client application 3 can thus be assigned certain or predetermined access rights in advance.

[0088] The server unit 5 can, for example, generate the access information 14 in such a way that it is encoded based on a place value system. This can be better utilized for further data processing.

[0089] For example, in addition to the context information 13, at least one attribute can be added to the access information 14. When the client application 3 accesses the application program 7, this additional attribute can be stored or temporarily stored in an attribute database 20, which is, for example, a component of the application program 7. This special attribute can, in turn, be used, in particular, within the session, to determine special accesses of the client application 3 to a subprogram 17 and / or a function 18 of the application program 7.

[0090] In FIG 2, for example, an authorization process or a login process using SSH (Secure Shell) is explained.

[0091] First, the client application 3 is authenticated at a zero-trust policy enforcement point 21. This can occur in an exemplary first step S1. Here, a special trust score (for example, trust measure 12) can be assigned to the client application 3. For example, in a subsequent second step S2, the trust score for the creation of a token or certificate can be transmitted to the authentication application 6 or authentication service. The authentication application 6 can in turn perform the authentication of the client application 3. The zero-trust policy enforcement point 21 can query the policy database 19 after determining the trust score (trust measure 12). For example, the policy database 19 can be referred to as a policy definition point.This can, for example, define or provide application-specific or application-program-specific policies. In an optional third step S3, an authentication token with context information can be created or generated. This, in turn, corresponds to the access information 14. With this authentication token, which contains context information, the client application 3 can log in to an SSH DAEMON ("Secure Shell Daemon") in an optional fourth step S4. This can, for example, be a terminal session via SSH.

[0092] In particular, the Zero Trust Policy Enforcement Point 21 can store additional client-specific information (context information 13) in the authentication information requested by the authentication application 6 and assigned to the request, which is issued, for example, as a certificate or signed token. This context information is then initially sent back to the client application 3. This client-specific information can, for example, be independent meta-information, encrypted, or calculated according to a fixed procedure (for example, certain values ​​at a defined point in the trust score) that represent the overall score, i.e., the trust score. Likewise, other attributes relating to the context of the request or the global threat situation can be part of the authentication information.In one embodiment, the authentication information (access information 14) is encoded as a place value system, so that all attributes used and combined for authentication can be reconstructed using a suitable mask. The trust score must be signed by the issuer, i.e., the authentication application 6.

[0093] The client application 3 can use the access information 14 to connect to the application (application program 7) running on the resource server (terminal device 4), which authorizes access to a requested resource based on the properties stored in the token. The authentication information (access information 14) can be validated for this purpose during the login process.

[0094] If authorization is only performed during the login process, such as in a terminal session via SSH, the attributes (additional attributes) supplied with the authentication information are temporarily stored in a non-persistent, secure attribute database (attribute database 20) operated on the system, along with the underlying session ID (the session for the access authorization process). The session ID can be defined, for example, by the process ID of the login process or randomly determined. For this purpose, authorization can be performed with the token during the login process in an optional fifth step S5. This can be done, for example, with an authentication module 23 ("Plugable Authentication Module System").

[0095] In an optional sixth step S6, the attributes can again be recorded with values ​​per session and temporarily stored in the attribute database 20. The attribute database 20 can only be accessed via SSH. In an optional seventh step S7, after the login process, a request to start the application program 7 can be made. For this purpose, for example, a login shell can be started. For this purpose, for example, an authorization allocation component 24, which is, for example, a component of the server unit 5, can be used. This can, for example, be implemented as a standalone kernel module.

[0096] In an optional eighth step S8, the authorization allocation component 24 can again determine the session and the associated privileges with respect to the client application 3.

[0097] In a ninth step S9, which is optional, session-related privileges can be determined for the session. These can be determined using loaded application policies 27.

[0098] In an optional tenth step S10, the program or application program 7 can again be executed. Thus, a process start 28 of the application program 7 occurs here. In addition, a set of rules can be made available, for example, to the authorization allocation component 24 using a privilege loader 25. This privilege loader 25 can in turn be examined using the policy database 19, which contains application policies 26, to determine restrictions of the application program 7.

[0099] In the following, advantageous embodiments of the present invention are explained in other words.

[0100] Furthermore, the session ID can be defined, for example, by a process ID of the login process or determined randomly. During a login process (for example, via an SSH modem service), the process ID is only known once the login shell 22 is started. In this case, a generic session ID is therefore initially used and the final process ID is only assigned to the attribute database 20 after the login shell has been started (step S7). In addition, it must be ensured that only defined applications, such as the SSH server service, can access the attribute database 20. Access can be restricted, for example, on Linux systems, to corresponding PAM modules (Plugable Authentication Module 23), which manage the attribute database 20 as a non-volatile component.Furthermore, it is possible for the database 20 to be operated using a standalone server component on the system 1, to which a stored application logs on using appropriate access data, for example via a Unix domain socket.

[0101] For example, a new process (e.g., subroutine 17 or function 18) can be started within the session, such as a login shell. This new process can be restricted using various measures. In addition to typical process privileges, such as permitted system calls or capabilities, in the example of a login shell, the execution of further operations can also be prohibited or permitted context-dependently using additional server services.

[0102] For this purpose, the solutions "sudo" or "fapolicyd" are used using the example of a Linux system. In order to be able to implement context-related restrictions, it can be stored for each application or application program 7 on System 1, for which attribute type and value which restriction is to be implemented. The policy to be defined for this can be stored in a central "Policy Definition Point" (Policy Database 19). This can either be requested by the target system (System 1) on which the application (application program 7) is running, distributed by this system to the target systems (also secured using signature integrity) or stored locally on the respective System 1.For each attribute, the privileges or access rights to be granted are determined session-related (i.e., for each individual session) with the help of an authorization allocation component 24 and the attribute database 20. The authorization allocation component 24 can be operated as an independent server process on the system 1, which manages the policy in user space and is informed by the kernel about the start of a new process with the help of its own kernel module or "Extended Berkeley Packet Filter programs", and the kernel waits until the process receives the privileges relevant for the session from the allocation component 24. Alternatively, the authorization allocation component 24 can be a component of the kernel.In this case, this component is implemented as an independent module, for example, which actively receives the set of rules, such as firewall rules, when the system starts or when changes are made by a user space program.

[0103] If, in turn, further programs (subprogram 17, for example) are executed within the application program 7, in particular within a shell, the authorization allocation component 24 can determine attributes of the respective initial session. This can be determined, for example, by determining the login process or its ID within the system's process management. The privileges to be granted can either be formed using the union sets across all attributes or using a best-match policy for the stored attributes, whereby these can be weighted accordingly if necessary. Furthermore, a score-based approach is also possible, whereby a corresponding score (trust measure 12) can be determined system- or application-specifically, taking into account the application to be used (application program 7).The respective behavior can be defined in the policy. In order to be able to set up context-related services and "application whitelisting" for the session in parallel with the session, it can be provided that, in addition to the privileges assigned directly to the application program 7 (access information 14), further applications (subprograms 17 and functions 18) are also referenced, for which further policies or guidelines are to be determined in parallel with the start of the application program 7 and are to be set up in parallel with the start of the application program 7.

[0104] Once the session-related restrictions have been determined (i.e., for the access rights for a session of the client application 3), the application program 7 can be started. If additional concurrent applications, such as subroutines for restricting the main application (application program 7), are executed, these must support the session-related enforcement of restrictions, for example by supporting session-related enforcement of restrictions, for example by performing session-related application whitelisting. Such a program can be executed in parallel to the initially started application (application program 7) and, for example, implements restrictions in the operating system kernel by only applying them to the process ID of the application program 7.If local server services, such as a database or access to container runtime environments, are restricted, they must determine which process ID is accessing the server service, for example by using the operating system's audit systems or corresponding "Extended Berkley Packet Filter programs". The process ID can be assigned to a session by assigning child processes to the parent restricted process via the system's process management. The server service can request this. The service can query the attributes stored for the session from the attribute database 20 and applies these with the procedures stored for the policy (for example agreement sets or first match) to determine the restrictions for the server component.Once the restrictions have been determined, a check is first performed to determine whether the connection to the local server component is permitted. If so, an application-specific restriction can then be defined for the session within the server component. Access information 14 can be taken into account for this purpose.

[0105] If additional application components not operated on the system are to be accessed, for example, via the network, it can be provided that either the client applications 3 themselves, which construct the request, request a session-related authentication object from the local attribute database 20, or an independent service on the server side can request this from the client application 3. Authorization to a remote service is then carried out analogously to the initial connection establishment, but the authentication taboo issued by the Zero Trust Policy Enforcement Point 21 is no longer used. Instead, the session-based object (attribute) created and signed by the attribute database is used for authorization.

Claims

Patent claims 1. Method for performing an authorization operation of a client application (3) in a computer network system (1) , wherein - an individual measure of trust (12) of the client application (3) is generated with an authentication application (6), characterized in that - a context information (13) for the client application (3) is generated by the authentication application (6), wherein the context information (13) is client-specific information with which the client application (3) is characterized, and - depending on the context information (13) and the level of trust (12), access information (14) of the client application (3) for an application program (7) of the computer network system (1) is determined.

2. Method according to claim 1, characterized in that the client application (3) is executed on an end device (4) of the computer network system (1), wherein a property of the end device is used for generating the confidence measure (12). (4) and / or a property of the client application (3) and / or user information of a user (15) of the client application (3) and / or a property of a communication link (16) between the terminal device (4) and the computer network system (1) is taken into account.

3. Method according to claim 1 or 2, characterized in that access to the application program (7) is permitted depending on the access information, wherein, depending on the context information (13), access of the client application (3) to at least one subroutine (17) of the application program (7) and / or at least one function (18) of the application program (7) is additionally permitted.

4. Method according to claim 3, characterized in that, depending on the context information (13), when accessing the application program (7) defines a range of functions, an access right, a program scope, a number of authorized subprograms and / or functions, an application duration, a read access and / or a write access for which at least one subprogram (17) and / or at least one function (18) of the application program (7) is specified.

5. Method according to one of the preceding claims, characterized in that a policy for the authentication application (6) is provided in a policy database (19), wherein, depending on at least one trust criterion which is stored in the policy, the individual trust level of the client application (3) with the authentication application (6) is generated.

6. Method according to one of the preceding claims, characterized in that the trust measure (12) is signed as a certificate by the authentication application (6), wherein this signed certificate is assigned to the client application (3).

7. Method according to one of the preceding claims, characterized in that, depending on the specific access information (14), a session of the client application (3) is conducted on the application program (7), wherein within this session a current context information is dynamically determined and a dynamic allocation of access rights of the client application (3) for subroutines (17) and / or functions (18) of the application program (7) is carried out depending on the current context information determined.

8. A method according to one of the preceding claims, characterized in that a trustworthiness list with context information values ​​and trust measures is provided, wherein the client application (3) is granted access rights to the application program using the trustworthiness list. gramm (7) and / or other application programs are assigned.

9. Method according to one of the preceding claims, characterized in that the specific access information (14) is encoded on the basis of a positional value system.

10. Method for executing an application program in which a client application (3) authorizes itself according to a method according to one of the preceding claims 1 to 9, and the client application (3) is granted access to the application program (7) according to the access information (14).

11. Method according to claim 10, characterized in that the access information (14) is additionally provided with at least one attribute and is stored in an attribute database (20) of the application program (7).

12. Method according to claim 11, characterized in that, depending on the stored attribute, a special access of the client application (3) to a subroutine (17) and / or a function (18) of the application program (7) is determined.

13. Computer network system (1) with, - a client unit (2) for running a client application (3) and - a server unit (5) for running an authentication application (6) and an application program (7) , wherein - the computer network system (1) is configured to perform a method according to any one of the preceding claims 1 to 12 .

14. Computer program product (10) which can be loaded directly into a memory (9) of a control unit (8) of a computer network system (1) according to claim 13, comprising program means to implement a method according to any one of claims 1 to 12 to be executed when the program (10) is executed in the control unit (8) of the computer network system (1).

15. Electronically readable data carrier (11) with electronically readable control information stored thereon, which is designed such that when the data carrier (11) is used in a control unit (8) of a computer network system (1) according to claim 13, it performs a method according to one of claims 1 to 12.

Images