EP3970337A1 - Verfahren zum selektiven ausführen eines containers und netzwerkanordnung - Google Patents

Verfahren zum selektiven ausführen eines containers und netzwerkanordnung

Info

Publication number
EP3970337A1
EP3970337A1 EP20726745.1A EP20726745A EP3970337A1 EP 3970337 A1 EP3970337 A1 EP 3970337A1 EP 20726745 A EP20726745 A EP 20726745A EP 3970337 A1 EP3970337 A1 EP 3970337A1
Authority
EP
European Patent Office
Prior art keywords
container
network
authorization
rac
authentication data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20726745.1A
Other languages
English (en)
French (fr)
Inventor
Michael Menth
Frederik HAUSER
Mark Schmidt
Julian RILLI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Eberhard Karls Universitaet Tuebingen
Original Assignee
Eberhard Karls Universitaet Tuebingen
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Eberhard Karls Universitaet Tuebingen filed Critical Eberhard Karls Universitaet Tuebingen
Publication of EP3970337A1 publication Critical patent/EP3970337A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Definitions

  • the invention relates to a method for selectively executing a container containing an application.
  • the invention also relates to an associated network arrangement.
  • the invention relates to a method for selectively executing a container containing an application, the method having the following steps:
  • the authorization response at least one Contains release information, which can have either a positive or a negative value
  • Release information has a positive value, and the container is not to be executed if the release information has a negative value, only if the container is to be executed, starting and executing the container.
  • the method according to the invention enables a user to be authorized by an authorization server, which is typically available centrally for a large number of users. This allows different users to be managed centrally, with users being able to be authenticated by the authorization server, for example by accessing identity management servers such as LDAP. There can be security functions such as in particular the authorization or
  • Execution prevention of a container are provided, which at
  • an application is typically an integral part of a container.
  • a container can be viewed as an application with dependencies.
  • the application is typically executed in the container, which represents a suitable environment for the application.
  • Other components of a container can be viewed as an application with dependencies.
  • Operating systems are typically encapsulated from the application by the container.
  • the container can provide interfaces by means of which the application can access certain resources of the operating system. In this way, such access can be controlled and prevented if there is no authorization.
  • user authentication data can be a combination of
  • user authentication information can be entered manually via a
  • User interface can be entered or can be made from an automatic or semi-automatic user authentication originate, for example by means of a card or fingerprint recognition, by which for example
  • User authentication data can be read out automatically from a vault or other memory created for this purpose.
  • the container management component is typically a software component which takes on administrative tasks for the container and typically runs outside the container. For example, it can start, stop and / or assign resources to the container.
  • the container applicant is
  • the authorization request can be in addition to the
  • User authentication data also contain further data, for example those which are described in more detail below.
  • the authorization response can also contain further information, for example that which is described in more detail below.
  • Release information can be implemented, for example, in the form of a bit, which can assume two states which are each assigned to a positive or negative value.
  • the container management component can in particular initiate the start of the container with the application.
  • the method can basically be carried out on only one electronic component such as a computer or a host. For example, it can also be executed in a virtual host, such as those offered by large data centers.
  • communication takes place with components that can be external to this, for example with the authorization server.
  • Such components can, for example, be located in the same network and communicate with one another accordingly via the network.
  • steps that must be carried out on external components such as the authorization server.
  • the method relates to an arrangement which can also contain several components.
  • the authorization server determines the
  • the authorization server can match the user authentication data with a database of authorized users.
  • the authorization server can be provided that the authorization server
  • User authentication data correspond to one of the user default values.
  • the user default values can be used to determine in a simple manner which users are authorized to run the container.
  • user default values can be found on the authorization server
  • the release information is always set to a positive value when the user authentication data to one of the
  • the container can also be authenticated, as described further below.
  • Correspondence between data and default values can basically be understood to mean that the data is exactly identical to the default values, or that the data has a specific relationship to the default values. Such a relationship can be specified, for example, as an equation or an algorithm.
  • the authorization response also contains authentication information. This can be generated, for example, by the authorization server or a component that works with it.
  • Authentication information can be used in particular in the event that the
  • Release information assumes a negative value, so the user is not authorized to provide information about whether the user is authenticated, that is, is known and has identified himself with a correct password. This allows the user to receive feedback on his
  • Incorrect entries are recognized, as in this case a user is not authenticated. In this way, however, feedback can also be given to the user that he is known but not authorized, for example due to a missing booking or other authorization problems.
  • the container applicant can in particular be an 802.1X supplicant.
  • Authorization server can in particular be an 802.1X authorization server.
  • the container management component can in particular be a
  • the method can in particular have the following step:
  • Container or a container image of the container.
  • a container image can in particular be a code which is present on a computer or another unit and by means of which the container is generated or executed.
  • the container can thus be generated with the container image, for example.
  • the container image can, for example, from a
  • Provisioning server to be downloaded.
  • the method can in particular have the following step:
  • the authorization request can contain the container authentication data. This allows the request to contain the container authentication data.
  • container authentication data can also be used in a
  • Authorization request separate message sent to the authorization server.
  • the method can have the following steps:
  • the nonce can in particular be received by the container management component and / or by the container applicant. They can also make the change. Such a procedure makes it possible to implement a challenge-response procedure. For example, the nonce can be sent to the
  • Container authentication data are appended and / or taken into account when calculating a checksum. This can be understood as a change. This ensures that only the container management component or only the container applicant can send the container authentication data in such a way that it is recognized as valid by the authorization server. Eventual
  • Manipulation or sending of such data by a unit that does not know the nonce could be detected by the authorization server.
  • the container authentication data can in particular be used as a checksum of the
  • Container or the container image can be determined. This gives a value which can distinguish containers from one another and which makes it possible to identify any changes to a container. A nonce mentioned above can also be included. An example of a calculation of a
  • Checksum across a container, rather than just a container image, would be a Resource access of a certain container, which can at least be configured in Docker by users (eg “Container A may only use one CPU core”).
  • the calculation of a checksum of the container can, however, also be the calculation of a checksum of the container image.
  • the checksum can, for example, after receiving the
  • User authentication data is calculated. In particular, this can relate to receiving the user authentication data by the
  • the container authentication data is a
  • Identification number of the container This can for example be specified for each container.
  • the calculation of a checksum can then advantageously be dispensed with.
  • Container management component can be configured to ensure a clear assignment between identification number and container. This will ensure the trustworthiness of the container on the
  • the method also has the following step:
  • Container authentication data as a checksum of the container or a container image of the container, the authorization request containing the container authentication data.
  • the container or the application can also be authenticated. This can, for example, prevent the container or application from running after being accidentally or maliciously modified.
  • the checksum can in particular be created instantaneously or ad hoc when the method is carried out, so that it is basically up-to-date and not later Modification of the container or the application can take place or such a modification would be recognized and lead to a refusal of execution.
  • the authorization server preferably determines the release information based at least on the container authentication data. This can in particular take place in addition to the user authentication data.
  • the authorization server could use the container authentication data, in particular the checksum, to recognize a possible modification of the container or the application and thus ensure that the application is only executed when it is not in the
  • the release information can assume the negative value or be set to the negative value by the authorization server if the authorization server based on the
  • Container authentication data determines that there has been a change in the application or the container.
  • the authorization server can compare the container authentication data with a number of container default values and only then set the release information to a positive value if the container authentication data correspond to one of the container default values.
  • the container default values can thus be used to determine which containers or types of containers may be executed. They can be stored on the authorization server or obtained externally.
  • Authorization servers also calculate a checksum based on the nonce and a container image or container available to it. This enables a comparison to be made as to whether the container authentication data was received from a unit that knows the nonce. Alternatively, for example, checksums in
  • the authorization response can in particular include authorization information
  • the application is executed with rights which are determined based on the authorization information. This can be used, for example, to tell different users what different
  • User authentication data have to assign different rights. For example, certain users can be granted access to certain resources, but others can be denied.
  • the authorization information can in particular be determined by the authorization server, for example based on the user authentication data and / or the container authentication data.
  • the method preferably also has the following step:
  • the container can be uniquely identified, which in particular makes it possible to unambiguously transfer a data stream to or from this container
  • the network address can in particular be an IPv6 address, although other addresses can also be used depending on the implementation.
  • the network address can in particular be assigned by the container management component. This can for example fall back on suitable address ranges.
  • the authorization request can contain the network address, for example.
  • other units for example the container authenticator mentioned below, can be informed of the network address.
  • the container management component can use the
  • the authorization request can in particular be sent to the authorization server via a container authenticator.
  • the container authenticator is typically an additional component which, for example, is software and / or
  • the container authenticator can add additional
  • the container authenticator can be an 802.1X authenticator, which is the Access to an existing 802.1X system is simplified and extensive
  • the method preferably also has the following steps:
  • the container authenticator Sending, by the container authenticator, the network release information to a network control component, wherein the network control component enables or blocks traffic to and / or from the container based on the network release information.
  • the method can also have the following steps:
  • the container authenticator Sending, by the container authenticator, the network release information to a network control component, wherein the network control component enables or blocks traffic to and / or from the container based on the network release information.
  • the data traffic can also be controlled as a function of authenticated and / or authorized users. For example, access to certain resources or certain types of traffic can be released for certain users, but blocked for others.
  • the network control component can be, for example, a firewall or an SDN controller, the network control component
  • the authorization server generates the
  • the container authenticator can in particular the network release information based on the
  • Generate network share data This can take place in the form of an identical transfer of the network release data or after modification.
  • the authorization server can thus also be used to configure the network control component. This makes the configuration easier.
  • the authorization server can generate the network release data in particular as a function of the user authentication data and / or the container authentication data. This means that users or containers can be addressed individually and specific rights can be assigned.
  • the network control component can in particular be arranged such that any data traffic to and from the container and / or to and from a protected server is routed through the network control component. This enables complete control of the data traffic to and from the container or to and from a protected server.
  • the container can be shielded and / or the container can with certain
  • Access rights are provided, which can be controlled by the network control component.
  • a protected server which can be present in the network, for example, can be particularly protected against unauthorized access.
  • a protected server can in particular be a server that stores particularly sensitive information or information that is worth protecting.
  • the network control component can also be a gateway which connects two networks.
  • it can be a gateway between a local network and the Internet. This means, for example, that only the container or only certain containers are allowed to communicate with the Internet, whereas other network elements are only allowed to communicate in the local network.
  • the container authenticator can preferably be the one assigned to the container
  • the container authenticator can use the network address, for example
  • the Network control component can then in particular enable or block data traffic based on the network address. This is particularly useful because the container can be clearly identified by means of the network address and thus rights for the data traffic of this container can be reliably established and monitored.
  • the network address can in particular be sent from the container management component to the container authenticator. This allows the network address to be communicated easily.
  • a protected communication channel running through the network control component can be formed between the container and a network element. This can prevent a large number of attacks.
  • the network element to which the protected communication channel can be formed between the container and a network element.
  • Communication channel is formed, be a protected server to which only a specific container or several specific containers has access or have.
  • the protected communication channel can in particular be end-to-end encrypted. This can prevent unauthorized persons from reading along.
  • the protected communication channel can in particular be a VPN channel (Virtual Private Network).
  • VPN Virtual Private Network
  • IPsec can be used as a VPN technology. This has been found to be advantageous for such applications. However, other technologies can also be used.
  • the authorization server can preferably supply information and / or keys for setting up the protected communication channel to the container applicant.
  • the authorization server can provide information such as in particular keys for the protected connection. This enables such information and keys to be provided in a particularly simple and reliable manner, as well as shared management on the authorization server.
  • Communication channels can in particular be included in the authorization response. To this end, they can be included in the authorization response by the authorization server. This allows the authorization response to be sent to the Providing such information can be used. Also a separate one
  • the network release information can in particular the
  • a network can be shielded from another network, for example the Internet, in order to
  • a protected browser can be implemented for secure environments.
  • Network elements can in particular take place via a protected and / or encrypted network. This can prevent a large number of possible attacks.
  • the protected and / or encrypted network can in particular be encrypted using MACsec. This has proven to be advantageous for typical applications, although other designs are also possible.
  • the container is configured to run only one application. This can further increase security, since each container is only assigned to one application and vice versa.
  • containers with associated applications can also be provided centrally in this way, preventing users or other persons from executing additional applications in the respective container that may violate guidelines or
  • the method preferably also has the following step:
  • Provisioning server This allows containers and / or associated applications to be provided centrally, for example within a facility such as a company or an educational institution. More preferably, the container is configured to run exclusively applications downloaded from the provisioning server. This ensures that only approved applications are running, which can avoid security problems. In particular, the execution of exclusively permitted applications and / or containers can also be carried out using the checksum already mentioned above and the associated processing
  • the authorization request and / or the authorization response are preferably EAP messages or EAPoUDP messages.
  • EAP protocol can be used, which avoids additional administrative effort or development work. Such messages have proven to be advantageous for carrying out the method.
  • the container can in particular be a remote application container (RAC).
  • RAC remote application container
  • the invention also relates to a network arrangement which is configured to carry out a method according to one of the preceding claims.
  • the network arrangement has a first computer unit which is used to execute the
  • Container management component the container and the container applicant is configured, and a second computer unit that is used to execute the
  • Authorization server is configured.
  • the computer units are networked with one another for data traffic. This applies to the computer units mentioned here as well as to other computer units. Regarding the procedure, all herein
  • a computer unit can in particular be a physically delimitable computer or, for example, a virtual machine on a computer or a server farm.
  • Networking can be wired or wireless and, in particular, provide a defined interface for data traffic.
  • the network arrangement can, in particular, be used to carry out the method
  • Container authenticator must be configured.
  • it can also include a third Have computer unit configured to run the container authenticator.
  • the network arrangement can in particular be configured to carry out a method with network control components. It can also have a fourth
  • Computing unit configured to execute a network control component.
  • the network control component can be a gateway between the network arrangement and a separate network.
  • the network control component can be a gateway between the network arrangement and a separate network.
  • data traffic between a local or specific network and the Internet can be controlled, as described above.
  • Internet access can, for example, be restricted to certain containers.
  • the network arrangement can have a protected server which can only be addressed via the network control component. This enables the
  • the access to the protected server can be controlled, for example in such a way that only one container or certain containers have access to the server or have.
  • the invention also relates to an electronic device such as a computer, which is configured to carry out a method according to the invention.
  • the invention also relates to a non-volatile computer-readable storage medium which contains program code, when it is executed
  • Fig. 1 A comparison of system virtualization and container virtualization
  • Fig. 2 A Docker architecture
  • Fig. 3 A port-based authorization model of 802.1X
  • Fig. 4 A communication example of authentication and authorization
  • Fig. 6 A managed host that has a RAC and a
  • Fig. 8 A data model
  • Fig. 9 A data flow
  • Fig. 1 1 A test environment
  • Fig. 12 A network configuration of Docker in the test environment
  • containers can implement virtualization at the operating system level. For example, you provide virtualized
  • Containers included. Examples of container platforms are Docker, Kubernetes, System d-nspawn, BSD Jails, Linux Containers, Windows Containers, Solaris
  • Containers, Virtuozzo and rkt. Docker has proven to be particularly advantageous for the method disclosed herein.
  • Virtualization facilitates the efficient and flexible use of hardware resources, increases security through isolation and ensures fault tolerance and scalability through simple migration processes.
  • containers also have the advantages described below. Due to the shared operating system, containers require less CPU, memory and
  • Container images referred to as container images in English, are much smaller, which makes it easier to distribute them over numerous recipients. Containers simplify application distribution. Instead of providing support for complex combinations of applications, dependencies and
  • containers that are tested in advance.
  • containers have no boot times, which makes them particularly advantageous for applications that are only required for a short time.
  • VMs Virtual machines in system virtualization are typically operated on virtualized hardware components of a hypervisor system and emulated components.
  • the hypervisor controls isolation in terms of resources and security.
  • VMs run complete operating systems, all of which are binary
  • FIG. 2 shows a simplified overview of the Docker platform and its operation.
  • Docker CMD Container Management Daemon
  • Container images are read-only templates, which applications and their dependencies such as binary components, databases and
  • Containers are runtime instances that the Extend read-only container images with a writable layer.
  • the Docker CMD is controlled by the Docker client via a REST interface.
  • the Docker client can be arranged in the host in which the Docker CMD is also located, or in a remote host.
  • a Docker command line interface (CLI) is an example of user control through CLI calls.
  • the Docker CMD can be connected to Docker registers that allow users to upload or download container images (push or pull). Such registers are available either privately or publicly.
  • a Docker hub with more than 100,000 container images is an example of the latter.
  • Common operations are build (1), pull (2) and run (3). With build, users can create individual container images. With pull, users can download existing container images from a Docker registry to become part of the local container image store. With run, container images can be executed from the local image store on the host system.
  • a Docker registry can also be referred to as a provisioning server.
  • a container format and a runtime environment from Docker were adopted as open industry standards by the Open Container Initiative.
  • Twistlock and the Aqua Container Security platform enable a runtime environment based on
  • the Sysdig Secure platform allows the formulation of service specifications, for example specifications based on applications, containers, hosts or network activities.
  • the platform delivers alarms and actions based on compliance violations, an event log and current
  • the Atomicorp Secure Docker Kernel is a hardened Linux kernel that has security-relevant features such as outbreak prevention,
  • the Docker Authorization Framework has been part of Docker since version 1 .10. It expands the Docker CMD through a REST interface to external plug-ins for authorization. Requests from the Docker CMD, for example to start a container, are forwarded to a plug-in for authorization, which
  • the Docker Authorization Framework does not implement any security functions, but provides a basis for implementing such security concepts. The method disclosed herein extends this further.
  • Containers typically deliver applications or services without graphical user interfaces
  • GUI Graphical User Interface
  • Examples are containers which contain web applications and their needs, for example an nginx web server with a PHP runtime and a MySQL database.
  • EAPoUDP is also presented, which is an alternative protocol for data traffic for AA in 802.1X. It is summarized how AA for applications is currently carried out in practice.
  • IEEE 802.1X introduces port-based network access control in wired Ethernet networks. Even so, it is mostly known today from the 802.11 wireless networks.
  • 802.11 wireless networks One example is eduroam, which is an amalgamation of wireless campus networks from universities. Participants can connect to the Internet regardless of whether they are connected to their
  • FIG. 3 shows the three components of 802.1X and the principle of port-based network access control.
  • a supplicant system is a network host that uses the 802.1X supplicant includes (802.1XS), an authenticator system includes an 802.1X authenticator (802.1XA) and controls network access from network hosts. Examples are access switches or switches, which network hosts with the
  • an 802.1X AS (authorization server) is, for example, an authentication, authorization and accounting server. It stores authentication data for checking user identities and authorization data for allowing access to the network. It authenticates and / or authenticates the 802.1X S and provides authorization information to the 802.1X A.
  • Authentication Dial-In User Service for exchanging AA data. Both provide fixed request and response schemes for exchanging AA data.
  • the diameter protocol is a less common alternative.
  • Authentication data are transmitted in Ethernet frames, called frames in English, as EAP-over-LAN (EAPoLAN) encapsulation between the 802.1X S and 802.1X A and as EAP-over-RADIUS (EAPoRADIUS) between 802.1X A and 802.1X AS.
  • Fig. 5 shows the packet structure of EAPoL.
  • Authorization data are transmitted between the 802.1X AS and 802.1X A in RADIUS frames.
  • 802.1XS initializes the authentication by sending an EAPoL start message to the 802.1X A.
  • the 802.1XA queries the identity of the 802.1XS (2a) and forwards it to the 802.1X AS continue (2b).
  • RADIUS supports large domains which contain several hierarchically organized RADIUS servers. Each identity is linked to a domain and is known to the RADIUS server of this domain, so that AA attempts can be forwarded in RADIUS infrastructures.
  • the authenticator decapsulates EAP packets from EAPoL frames and encapsulates them again as EAPoRADIUS frames and vice versa.
  • the flexible message structure of EAP allows the use of different authentication procedures. Simple approaches carry identity information in plain text or simple MD5 hashed information
  • the RADIUS server can return authorization data to the 802.1XA after successful authentication and authentication. This can be roughly granular, for example a binary access decision as to whether the supplicant system gets access or not, or finely granular, for example VLAN tags, which are expected
  • User traffic or filter rules can be set, which are applied by the authenticator.
  • the authenticator applies the authorization data to the specific physical port of the switch, for example it sets a VLAN tag.
  • the authenticator then confirms successful AA for the supplicant with an EAP success message (4b).
  • EAPoUDP is a variation of EAP, which allows the transmission of EAP data via UDP and IP.
  • Fig. 5 shows the associated packet structure in comparison with EAPoL.
  • EAPoUDP can be used to authenticate multiple applications running on a network host.
  • UDP packets can also be transmitted using any connection technology, or they can even be routed within multi-domain networks.
  • EAPoUDP was introduced as an Internet draft, which expired in 2002 without standardization in the PANA Working Group at IETF.
  • 802.1X specializes in port-based access control for network hosts.
  • AA is implemented for applications as part of the applications or using the Kerberos AA protocol.
  • client certificates which are used together with TLS, and an infrastructure with public
  • Kerberos is a network authentication protocol that enables different authentication for clients and servers over an insecure network.
  • Clients are, for example, complete hosts, users or applications; Servers represent hosts that offer certain network applications. Kerberos adapts user tickets for the authentication of various
  • Kerberos must be run through applications on both client and
  • FlowNAC inserts fine-grained SDN network access control systems using 802.1X for AA from applications on network hosts. This enables different versions of AA for different applications on a network host. To enable different AA for different applications on a network host, EAPoL-over-EAPoLAN encapsulations are introduced. As shown in FIG. 5 in a comparison of data packets for EAPoL, EAPoUDP and EAPoL in EAPoL, FlowNAC inserts another variation of EAPoL. An EAPoL-in-EAPoL packet field identifies up to 64,000 different EAP processes, which are transmitted as encapsulated EAP payload. However, this deviation from the old 802.1X requires significant changes
  • the 802.1X S is part of a kernel of an operating system
  • the 802.1X A is part of network switches, so only open source operating systems and firmware allow modifications. Nevertheless, it is difficult to carry out the modification in new versions of the operating system kernel or the firmware images.
  • EAPoL is set, i.e. AA data transfer is restricted to the Ethernet connection.
  • EAPoUDP can basically also be used.
  • FlowNAC also does not insert IP addresses for applications, nor is the start of applications restricted by AA.
  • RACs Remote Application Containers
  • xRAC the method described here
  • RACs Restricted Application Containers
  • Container images which are a single application whose
  • RACs in a container runtime environment running parallel to the operating system's own applications.
  • the CMD controls the execution of RACs and provides an interface for users to create, delete and start or stop RACs.
  • Each RAC has its own IPv6 address so that traffic on the network can be easily identified.
  • RAC images are for example through
  • CMD container management daemon
  • RAC remote application container
  • 802.1X CS container supplicant
  • the firewall FW is one
  • xRAC provides execution and access control for RACs on managed hosts.
  • a RAC is thereby preferably authenticated and authorized, namely before an execution takes place.
  • Figure 7 shows an AA process for RACs with 802.1X.
  • a user tries to start a RAC via the CMD (1) and the CMD instructs the 802.1X CS for the AA (2).
  • the 802.1X AS replies with authorization data or an authorization response via the 802.1X CA (4) to the 802.1X CS (4a).
  • the 802.1X CS informs the CMD that the RAC should be started (4b).
  • the 802.1X CA informs network control elements about the authorized RAC.
  • the firewall FW is configured to allow access to a to allow protected server (4c).
  • Other examples are SDN controllers that program SDN switches. Now the authorized RAC, but not the managed host or other RACs, communicate with the protected server (5).
  • AA Application delivery and network security.
  • AA restricts RAC execution on managed hosts to predefined RAC images and permitted users. This allows network operators to ensure that only current and unmodified RAC images can be executed. This improves computer and network security as only valid RAC images can be executed on the managed hosts.
  • network operators are able to distribute RAC images to managed hosts in advance, for example by synchronizing their set of RAC images with an internal RAC repository in the background. This gives users access to all available RAC images on managed hosts, but they are only able to start them after they have been authorized by AA. After all, every RAC has a globally uniform IPv6 address which can be used to identify data traffic to and from a specific RAC.
  • RAC authorization data on the 802.1X AS includes information about how network elements should control the RAC's traffic. This allows a configuration of network elements or
  • Container management component receiving user authentication data from the user.
  • the user authentication data is forwarded to the container applicant 802.1X CS.
  • This generates an authorization request which contains the user authentication data.
  • it also generates a checksum of the container, the checksum
  • the authorization request is then transmitted to the 802.1X AS authorization server via the 802.1X CA container authenticator. This resembles both the
  • the authorization server generates a
  • Authorization response with positive release information and possibly also with authorization information.
  • the authorization response is sent via the
  • Container authenticator 802.1X CA sent back to the container applicant 802.1X CS.
  • the authorization response is then sent to the
  • Containermanagementdaemon CMD which determines based on whether an application is allowed to be executed and, if necessary, with which
  • the container management daemon starts the application and assigns it the appropriate authorizations.
  • the authorization server should the authorization server not be able to authenticate the user, or should it be able to authenticate the user but discover a lack of authorization, the authorization server generates an authorization response with negative release information and sends it back accordingly.
  • the RAC container is assigned a unique network address, for example an IPv6 address. This address is communicated to the firewall FW. Furthermore, the container authenticator 802.1X CA notifies the firewall FW of network release information relating to the container RAC, which comes in the form of network release data from the authorization server 802.1X AS. The firewall FW then controls data traffic from and to the container RAC depending on the network release information and identifies the container on the basis of its IPv6 address. In this way, for example, access to the protected server can be controlled. For this purpose, the firewall FW is arranged in the present case in such a way that all data traffic from and to the protected server runs through the firewall FW. In particular, a protected channel, in particular a VPN channel, can be formed between the container and the protected server. This means that exchanged data can be protected against changes and unauthorized reading.
  • a protected channel in particular a VPN channel
  • the authorization request from the container applicant 802.1X CS to the authorization server 802.1X AS thus includes in particular
  • the 802.1X AS authorization server authenticates the user and verifies the integrity of the RAC image. If the image is valid and the user is authenticated and if the user has permission to run the RAC, the 802.1X AS authorization server replies to the 802.1X CA container authenticator
  • a new data model can be used, which is shown in FIG. It has, for example, user profiles (1), RAC profiles (2) and groups (3) which define whether a specific user is authorized to execute a specific RAC. Include user profiles (1)
  • RAC profiles (2) contain container authentication data (CAND) and container authorization data (CAZD). The first is used to verify the integrity of the RAC by computing the cryptographic hash function over the RAC image. CAZD contains all authorizations of a RAC, for example whether it can be started by the requesting user and whether it is authorized
  • the RAC is allowed to specify specified
  • the AA data of the described model is stored in the authorization server 802.1X AS.
  • the data model is an example that can easily be extended to support other requirements.
  • the container applicant 802.1 X CS authenticates RACs with the authorization server 802.1X AS via the container authenticator 802.1 X CA. It sends UAND and CAND to the 802.1X AS authorization server and receives CAZD from it
  • Container Authenticator 802.1X CA Container Authenticator 802.1X CA.
  • the managed host, container authenticator, authorization server, firewall and protected server components shown in FIG. 7 can be used as respective
  • FIG. 9 illustrates the process for AA from the perspective of the container applicant 802.1X CS.
  • This runs on the managed host, offers an interface for the CMD and is linked to the IP address or URL of the container authenticator 802.1X CA configured so that it can initiate AA.
  • the user asks the CMD to start a specific RAC on the managed host.
  • the request includes UAND.
  • the CMD asks the container applicant 802.1X CS whether this can be allowed to the user (2).
  • the request contains UAND and CAND, which are received by the CMD, with CAND being calculated ad hoc as the checksum of the RAC container or from its container image.
  • the container applicant 802.1X CS initiates AA by establishing an EAPoUDP session with the container authenticator 802.1X CA.
  • Authorization is then carried out with the authorization server 802.1X AS via the container authenticator 802.1X CA (3).
  • backend authentication can be carried out via EAPoRADIUS, with frontend authorization being carried out via EAPoUDP.
  • the container applicant receives 802.1X CS CAZD from the container authenticator 802.1X CA (4). Then he allows
  • the 802.1X CA container authenticator routes AA data between the
  • step (1) of FIG. 10 authentication data are transported via EAP between the container applicant 802.1X CS and the authorization server 802.1X AS for authentication. Between the container applicant 802.1X CS and the
  • the EAP data is transmitted via UDP (EAPoUDP) and between the Container Authenticator 802.1X CA and the
  • Authorization server 802.1X AS CAZD via RADIUS to the container authenticator 802.1X CA back (2), which then informs the container applicant 802.1X CS about the successful authorization (3a). While the conventional 802.1X A only opens ports on a switch for authorized devices, the
  • Container Authenticator 802.1X CA general network control elements via authorized RACs. These can be ports on a switch, firewalls (3b) or SDN controllers (3c). The firewall is then programmed to allow all outgoing traffic with the IP address of the RAC and the SDN controller instructs SDN switches to allow all traffic with the IP address of the RAC through, provided that appropriate permissions have been granted. More specific flow descriptors are typically not needed, but can be implemented.
  • Network flow control ensures that the server is only served by legitimate RACs and User can be reached, but not through other RACs or the managed host itself.
  • XRAC extends the benefits of virtualization and
  • xRAC can guarantee that only valid containers are executed on managed hosts and that they can only be used by legitimate users.
  • xRAC performs AA (Authentication and Authorization) for applications without the need to modify them, which is a particular advantage for older applications.
  • the 802.1X CA container authenticator can configure network controls so that authorized RACs have access to protected network resources. RACs enable this control because all network traffic on a RAC is identified by a single IPv6 address. This is a particular advantage because in today's networks there is no information about legitimate flow and numerous application flows can have the same IP address. Applications can even be invisible due to encryption.
  • xRAC provides a solution to the serious problem of controlling legitimate traffic.
  • xRAC is flexible because it implements software-defined network access control by interacting with other network control elements. In particular, it is not dependent on or limited to specific technologies.
  • Fig. 1 1 shows a test environment.
  • the managed host is running RACs.
  • An SDN switch connects the managed host, a protected web server and a public web server and is controlled by an SDN controller.
  • the 802.1X CA runs on the SDN controller as an SDN application that communicates with an 802.1X AS.
  • Nested virtualization can be used here, i.e. a virtual machine (VM) encapsulates all parts of the test environment, including the managed host. This approach allows the entire test environment to be transferred to others
  • VM virtual machine
  • Hardware platforms are migrated.
  • a KVM hypervisor with QEMU for hardware-assisted virtualization and libvirt for orchestration was used for a test.
  • the managed host both web servers and a RADIUS server run as nested VMs with Ubuntu 17.04.
  • An Open vSwitch serves as an SDN switch, which is controlled by a Ryu SDN controller.
  • Docker version 17.05 is used as the container virtualization platform for implementing RACs.
  • the Docker-CMD is configured in such a way that each RAC receives a globally unique IPv6 address that can be reached by other network hosts.
  • Fig. 12 shows the network configuration used. It is preset that RACs only receive one link-local IPv6 address.
  • a fixed IRnd subnet with routable addresses for RACs is therefore set up.
  • the managed host is configured with the IPv6 subnet 2001: db8 :: 1 1: 0/1 16 and the RACs receive an IPv6 address from this range.
  • the first RAC receives 2001: db8:: 1 1: 1 and the second RAC receives 2001: db8 :: 1 1: 2.
  • the Dockerdaemon automatically adds routes to a system's routing table and enables IPv6 forwarding so that all traffic to the IPv6 subnet can be routed via a dockerO interface.
  • An NDP proxy daemon is used here to make the RACs accessible from other network hosts.
  • the 802.1X CS is implemented as a plug-in for the Docker Authorization Framework, which was described above.
  • the plug-in is programmed in Python and uses a Flask library to implement a REST interface.
  • Fig. 13 shows the authorization process.
  • the user requests the CMD to start a container.
  • the request contains UAND, for example consisting of a user name and a password.
  • the Docker Authorization Framework defines a two-stage authorization process, whereby only the second step is required here.
  • the first authorization request (2) contains only minimal data, for example the name of the RAC picture. Since the present implementation is based only on the second authorization step, the 802.1X CS corresponds to a permission as a default.
  • the second authorization request (3) includes UAND and CAND.
  • the 802.1X CS performs authentication with the 802.1X AS by the 802.1X CA as described above (3).
  • the 802.1X AS returns CAZD, which is forwarded to the 802.1X CS in the event of a successful
  • the 802.1X CA is programmed as an SDN application for the Ryu SDN controller.
  • the 802.1XA which is known from the prior art, is expanded by adding support for authentication with the 802.1X CS using EAPoUDP.
  • the 802.1X CA opens a UDP socket on port 5995 and waits for connections from the 802.1X CS.
  • the 802.1X CA can still act as the legacy 802.1XA that does AA for network hosts in legacy 802.1X over EAPoL.
  • a restricted MAC learning switch is implemented. It learns MAC addresses from connected hosts, but only forwards packets if the IP addresses of the sender and recipient are in a whitelist.
  • the whitelist contains static
  • Entries e.g. for public servers, and dynamic entries, which can be modified by the 802.1X CA after receiving CAZD from the 802.1X AS.
  • the restricted MAC learning switch is implemented by extending the L2 switching SDN application from the Ryu SDN controller framework.
  • FreeRADIUS is used as 802.1X AS, with an AA data model being expanded to implement CAND and CAZD.
  • additional attributes for AA and simple features can be implemented using specific attributes which are defined in the unlang processing language.
  • the defined AA data model can easily be expanded and modified by adding several Vendor-Specific Attributes (VSAs).
  • VSAs Vendor-Specific Attributes
  • Two web server VMs in the test environment operate a Python web server, which delivers HTML files via HTTP.
  • the protected web server with the static IPv6 address 2001: db8 :: aa: 0 delivers an HTML page with the sentence “protected content”.
  • the public web server with the static IPv6 address 2001: db8 :: bb: 0 delivers an HTML page with the sentence “public content”.
  • a wget tool is encapsulated as a RAC to receive files using HTTP.
  • the RAC is used to extract an HTML file from both the protected and
  • the RAC cannot start on the managed host. It is now demonstrated that the correct RAC can be started and that it can reach the protected web server after successful AA. After entering a command to start the RAC, it is authenticated and authorized as described above (2a).
  • the SDN controller receives CAZD and programs the SDN switch to allow forwarding of packets between the RAC and the protected web server (2c).
  • the RAC is now able to receive the received HTML file from the protected web server.
  • xRAC is proposed, a concept for implementing access control from Restricted Application Containers (RACs) on managed clients. It includes authentication and authorization (AA) for RACs such that only current RAC images can be executed by authorized users. Furthermore, the authorization is extended to protected network resources in such a way that authorized RACs can access them.
  • Traffic control is simplified by the fact that all traffic from a RAC is identified by its IPv6 address.
  • the architecture of xRAC is presented and it is demonstrated through a prototype implementation that xRAC can be built using standardized technology, protocols and infrastructure.
  • a prototype of xRAC uses Docker as a
  • Container virtualization platform for distributing and executing RACs, and signaling is based on 802.1X components. Modifications can be made to a supplicant, an authenticator and an authorization server so that both user and container AA data can be exchanged. Furthermore, the container authenticator is extended to include required
  • xRAC supports software-defined network control and improves network security without modifying core components of applications, hosts and infrastructure.
  • Mentioned steps of the method according to the invention can preferably be carried out in the order given. However, a different order is also possible if this is technically sensible.
  • the method according to the invention can be carried out in one of its embodiments, for example with a specific combination of steps, in such a way that no further steps are carried out. In principle, however, further steps can also be carried out, including those which are not mentioned.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Power Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum selektiven Ausführen eines Containers, der eine Anwendung beinhaltet, wobei Benutzerauthentisierungsdaten durch eine Containermanagementkomponente erhalten und über einen Containerantragsteller an einen Autorisierungsserver weitergeleitet werden. Dieser sendet eine Autorisierungsantwort, basierend auf welcher entschieden wird, ob die Anwendung in dem Container ausgeführt werden darf.

Description

Verfahren zum selektiven Ausführen eines Containers und Netzwerkanordnung
Die Erfindung betrifft ein Verfahren zum selektiven Ausführen eines Containers, der eine Anwendung beinhaltet. Die Erfindung betrifft des Weiteren eine zugehörige Netzwerkanordnung.
Im Allgemeinen wird hierin das Problem betrachtet, Benutzern zu erlauben, spezielle Anwendungen auf verwalteten Hosts (Managed Hosts) auszuführen und ihnen Zugriff auf geschützte Netzwerkressourcen zu geben. Es ist im Stand der Technik zwar bekannt, Anwendungen in Containern auszuführen, um eine gewisse Trennung von anderen Anwendungen oder Betriebssystemkomponenten zu erreichen. Allerdings fehlt es bislang an weitergehenden Sicherheits- und Zugriffskontrollmechanismen.
Es ist deshalb eine Aufgabe der Erfindung, ein Verfahren zum selektiven Ausführen eines Containers, der eine Anwendung beinhaltet, bereitzustellen, welches im Vergleich zu bekannten Ausführungen alternativ oder verbessert ist. Es ist des Weiteren eine Aufgabe der Erfindung eine zugehörige Netzwerkanordnung bereitzustellen Dies wird erfindungsgemäß durch ein Verfahren und eine Netzwerkanordnung gemäß den jeweiligen Hauptansprüchen erreicht. Vorteilhafte Ausgestaltungen können
beispielsweise den jeweiligen Unteransprüchen entnommen werden. Der Inhalt der Ansprüche wird durch ausdrückliche Inbezugnahme zum Inhalt der Beschreibung gemacht.
Die Erfindung betrifft ein Verfahren zum selektiven Ausführen eines Containers, der eine Anwendung beinhaltet, wobei das Verfahren folgende Schritte aufweist:
Empfangen von Benutzerauthentisierungsdaten durch eine
Containermanagementkomponente,
Weiterleiten der Benutzerauthentisierungsdaten an einen Containerantragsteller,
Senden, durch den Containerantragsteller, einer Autorisierungsanforderung an einen Autorisierungsserver, wobei die Autorisierungsanforderung zumindest die Benutzerauthentisierungsdaten beinhaltet,
Empfangen, durch den Containerantragsteller, einer Autorisierungsantwort von dem Autorisierungsserver, wobei die Autorisierungsantwort zumindest eine Freigabeinformation beinhaltet, welche entweder einen positiven oder einen negativen Wert annehmen kann,
Weiterleiten der Autorisierungsantwort an die
Containermanagementkomponente,
Entscheiden, durch die Containermanagementkomponente, ob der Container auszuführen ist, wobei der Container auszuführen ist, wenn die
Freigabeinformation einen positiven Wert hat, und wobei der Container nicht auszuführen ist, wenn die Freigabeinformation einen negativen Wert hat, nur wenn der Container auszuführen ist, Starten und Ausführen des Containers.
Das erfindungsgemäße Verfahren ermöglicht eine Autorisierung eines Benutzers durch einen Autorisierungsserver, welcher typischerweise zentral für eine Vielzahl von Benutzern zur Verfügung steht. Dadurch können unterschiedliche Benutzer zentral verwaltet werden, wobei Benutzer durch den Autorisierungsserver beispielsweise unter Zugriff auf Identity-Management-Server wie LDAP authentifiziert werden können. Es können Sicherheitsfunktionen wie insbesondere die Autorisierung oder
Ausführungsverhinderung eines Containers bereitgestellt werden, welche bei
Ausführungen nach dem Stand der Technik nicht möglich sind.
Eine Anwendung ist bei dem Verfahren typischerweise integraler Bestandteil eines Containers. Ein Container kann als Anwendung mit Abhängigkeiten betrachtet werden. Typischerweise wird dabei die Anwendung in dem Container ausgeführt, welcher eine geeignete Umgebung für die Anwendung darstellt. Andere Komponenten eines
Betriebssystems sind dabei typischerweise durch den Container von der Anwendung abgekapselt. Beispielsweise kann der Container Schnittstellen bereitstellen, mittels welchen die Anwendung auf gewisse Ressourcen des Betriebssystems zugreifen kann. Damit können derartige Zugriffe gesteuert und bei fehlender Berechtigung unterbunden werden.
Benutzerauthentisierungsdaten können beispielsweise eine Kombination aus
Benutzername und Passwort darstellen. Auch andere Ausführungen von
Benutzerauthentisierungsdaten sind jedoch möglich. Die
Benutzerauthentisierungsdaten können beispielsweise manuell über eine
Benutzerschnittstelle eingegeben werden oder können aus einer automatischen oder halbautomatischen Benutzerauthentisierung stammen, beispielsweise mittels einer Karte oder einer Fingerabdruckerkennung, durch welche beispielsweise
Benutzerauthentisierungsdaten aus einem hierfür angelegten Tresor oder sonstigem Speicher automatisiert ausgelesen werden können.
Die Containermanagementkomponente ist typischerweise eine Softwarekomponente, welche Verwaltungsaufgaben für den Container übernimmt und typischerweise außerhalb des Containers läuft. Sie kann den Container beispielsweise starten, anhalten und/oder ihm Ressourcen zuweisen. Der Containerantragsteller ist
typischerweise eine Softwarekomponente, welche außerhalb des Containers läuft und mit externen Komponenten wie beispielsweise dem Autorisierungsserver direkt oder indirekt kommuniziert, um beispielsweise die beschriebenen Funktionalitäten
auszuführen. Die Autorisierungsanforderung kann zusätzlich zu den
Benutzerauthentisierungsdaten auch weitere Daten beinhalten, beispielsweise solche, welche weiter unten näher beschrieben werden. Die Autorisierungsantwort kann ebenfalls zusätzlich zu der Freigabeinformation noch weitere Informationen beinhalten, beispielsweise solche, welche weiter unten näher beschrieben werden. Die
Freigabeinformation kann beispielsweise in Form eines Bits realisiert sein, welches zwei Zustände einnehmen kann, welche jeweils einem positiven bzw. negativen Wert zugeordnet sind. Das Starten des Containers mit der Anwendung kann insbesondere durch die Containermanagementkomponente veranlasst werden.
Es sei erwähnt, dass das Verfahren soweit bisher beschrieben grundsätzlich auf nur einer elektronischen Komponente wie beispielsweise einem Computer oder einem Host ausgeführt werden kann. Beispielsweise kann es auch in einem virtuellen Host ausgeführt werden, wie sie beispielsweise von großen Rechenzentren angeboten werden. Im Rahmen des Verfahrens wird dabei mit Komponenten kommuniziert, welche dazu extern sein können, beispielsweise mit dem Autorisierungsserver. Derartige Komponenten können sich beispielsweise im gleichen Netzwerk befinden und entsprechend über das Netzwerk miteinander kommunizieren. Nachfolgend werden auch Schritte beschrieben, welche auf externen Komponenten wie beispielsweise dem Autorisierungsserver durchzuführen sind. In diesem Fall sei verstanden, dass sich das Verfahren auf eine Anordnung bezieht, welche auch mehrere Komponenten beinhalten kann. Gemäß einer bevorzugten Ausführung bestimmt der Autorisierungsserver die
Freigabeinformation zumindest basierend auf den Benutzerauthentisierungsdaten. Dadurch kann sichergestellt werden, dass lediglich Benutzer, welche korrekte
Benutzerauthentisierungsdaten haben, die Anwendung im Container ausführen können. Beispielsweise kann der Autorisierungsserver die Benutzerauthentisierungsdaten mit einer Datenbank zugelassener Benutzer abgleichen.
Insbesondere kann vorgesehen sein, dass der Autorisierungsserver die
Benutzerauthentisierungsdaten mit einer Anzahl von Benutzervorgabewerten vergleicht und die Freigabeinformation nur dann auf einen positiven Wert setzt, wenn die
Benutzerauthentisierungsdaten zu einem der Benutzervorgabewerte entsprechen.
Dadurch kann mittels der Benutzervorgabewerte in einfacher Weise festgelegt werden, welche Benutzer eine Berechtigung zum Ausführen des Containers haben. Die
Benutzervorgabewerte können beispielsweise auf dem Autorisierungsserver
gespeichert werden oder können auch von extern bezogen werden. Es kann
vorgesehen sein, dass die Freigabeinformation grundsätzlich auf einen positiven Wert gesetzt wird, wenn die Benutzerauthentisierungsdaten zu einem der
Benutzervorgabewerte entsprechen. Es können jedoch auch noch weitere Kriterien vorgesehen sein, welche dafür erfüllt sein müssen. Beispielsweise kann auch eine Authentisierung des Containers erfolgen, wie weiter unten beschrieben.
Unter einem Entsprechen von Daten mit Vorgabewerten kann grundsätzlich verstanden werden, dass die Daten mit den Vorgabewerten exakt identisch sind, oder dass die Daten in einer bestimmten Beziehung zu den Vorgabewerten stehen. Eine solche Beziehung kann beispielsweise als Gleichung oder Algorithmus vorgegeben werden.
Gemäß einer bevorzugten Ausführung enthält die Autorisierungsantwort zusätzlich eine Authentifizierungsinformation. Diese kann beispielsweise vom Autorisierungsserver oder einer damit zusammenarbeitenden Komponente erzeugt werden. Die
Authentifizierungsinformation kann insbesondere für den Fall, dass die
Freigabeinformation einen negativen Wert annimmt, der Benutzer also nicht autorisiert ist, eine Information darüber mitliefern, ob der Benutzer authentifiziert ist, also bekannt ist und sich mit einem korrekten Passwort ausgewiesen hat. Dies erlaubt es, dem Benutzer im Fall fehlender Autorisierung eine Rückmeldung über seine
Authentifizierung zu geben. Beispielsweise können dadurch versehentliche
Fehleingaben erkannt werden, da in diesem Fall ein Benutzer nicht authentifiziert wird. Dem Benutzer können auf diese Weise jedoch auch Rückmeldungen darüber gegeben werden, dass er zwar bekannt, jedoch nicht autorisiert ist, beispielsweise aufgrund fehlender Buchung oder sonstigen Berechtigungsproblemen.
Der Containerantragsteller kann insbesondere ein 802.1X Supplicant sein. Der
Autorisierungsserver kann insbesondere ein 802.1X Autorisierungsserver sein. Die Containermanagementkomponente kann insbesondere ein
Containermanagementdaemon sein. Dadurch kann auf bekannte Komponenten zur Authentifizierung und/oder Autorisierung von Benutzern zurückgegriffen werden, welche beispielsweise durch das bekannte IEEE 802.1X-System bereitgestellt werden. Eine Neuentwicklung solcher Komponenten oder ein zusätzliches Bereitstellen kann damit vorteilhafterweise vermieden werden. Insbesondere sind derartige Systeme häufig bereits in Einrichtungen wie Unternehmen oder Hochschulen vorhanden, um
beispielsweise eine portbasierte Zugangskontrolle zu gewährleisten. Die Anpassung derartiger Systeme an das hierin beschriebene Verfahren erfordert typischerweise nur einen geringen Aufwand.
Das Verfahren kann insbesondere folgenden Schritt aufweisen:
Erzeugen von Containerauthentisierungsdaten in Abhängigkeit von dem
Container oder einem Containerbild des Containers.
Damit kann auch der Container einer separaten Authentisierung unterzogen werden. Dies ermöglicht es festzulegen, welche Container ausgeführt werden dürften und die Ausführung anderer Container kann verhindert werden.
Ein Containerbild kann insbesondere ein Code sein, welcher auf einem Computer oder einer anderen Einheit vorhanden ist und mittels welchem der Container erzeugt oder ausgeführt wird. Der Container kann somit beispielsweise mit dem Containerbild erzeugt werden. Das Containerbild kann beispielsweise von einem
Bereitstellungsserver heruntergeladen werden.
Das Verfahren kann insbesondere folgenden Schritt aufweisen:
Senden der Containerauthentisierungsdaten an den Autorisierungsserver. Dadurch kann der Autorisierungsserver die Containerauthentisierungsdaten bei der Entscheidung verwenden, ob die Freigabeinformation auf einen positiven Wert oder auf einen negativen Wert gesetzt wird.
Insbesondere kann die Autorisierungsanforderung die Containerauthentisierungsdaten beinhalten. Dies erlaubt ein besonders einfaches Senden der
Containerauthentisierungsdaten an den Autorisierungsserver. Die
Containerauthentisierungsdaten können jedoch auch in einer zur
Autorisierungsanforderung separaten Nachricht an den Autorisierungsserver gesendet werden.
Das Verfahren kann gemäß einer Ausführung folgende Schritte aufweisen:
Empfangen einer Nonce von dem Autorisierungsserver, und
Verändern der Containerauthentisierungsdaten basierend auf der Nonce, bevor die Containerauthentisierungsdaten an den Autorisierungsserver gesendet werden.
Die Nonce kann dabei insbesondere von der Containermanagementkomponente und/oder von dem Containerantragsteller empfangen werden. Diese können auch die Veränderung vornehmen. Eine solche Verfahrensführung erlaubt es, ein Challenge- Response-Verfahren zu implementieren. Die Nonce kann beispielsweise an die
Containerauthentisierungsdaten angehängt werden und/oder bei der Berechnung einer Prüfsumme berücksichtigt werden. Dies kann als Veränderung verstanden werden. Dadurch kann sichergestellt werden, dass nur die Containermanagementkomponente oder nur der Containerantragsteller die Containerauthentisierungsdaten so senden kann, dass sie vom Autorisierungsserver als gültig erkannt werden. Eventuelle
Manipulationen oder ein Senden solcher Daten von einer Einheit, die die Nonce nicht kennt, könnte vom Autorisierungsserver erkannt werden.
Die Containerauthentisierungsdaten können insbesondere als Prüfsumme des
Containers oder des Containerbilds bestimmt werden. Dadurch wird ein Wert erhalten, der Container voneinander unterscheiden kann und der es ermöglicht, eventuelle Veränderungen eines Containers zu identifizieren. Auch eine weiter oben erwähnte Nonce kann dabei einbezogen werden. Ein Beispiel für eine Berechnung einer
Prüfsumme über einen Container, anstatt nur über ein Containerbild, wäre ein Ressourcenzugriff eines bestimmten Containers, der zumindest in Docker von Nutzern konfiguriert werden kann (z.B.„Container A darf nur einen CPU-Kern nutzen”). Die Berechnung einer Prüfsumme des Containers kann jedoch auch die Berechnung einer Prüfsumme des Containerbilds sein.
Die Prüfsumme kann beispielsweise nach dem Empfangen der
Benutzerauthentisierungsdaten berechnet werden. Insbesondere kann sich dies auf ein Empfangen der Benutzerauthentisierungsdaten durch die
Containermanagementkomponente beziehen. Dadurch kann die Prüfsumme
unmittelbar vor der beabsichtigten Verwendung des Containers berechnet werden. Die Gefahr eventueller späterer Änderungen am Container oder am Containerbild vor dessen Ausführen kann dadurch minimiert werden.
Gemäß einer Ausführung sind die Containerauthentisierungsdaten eine
Identifikationsnummer des Containers. Diese kann beispielsweise für jeden Container vorgegeben sein. Auf das Berechnen einer Prüfsumme kann dann vorteilhaft verzichtet werden.
Insbesondere in diesem Fall, aber auch allgemein, kann die
Containermanagementkomponente dazu konfiguriert sein, eine eindeutige Zuordnung zwischen Identifikationsnummer und Container sicherzustellen. Dadurch wird die Sicherstellung der Vertrauenswürdigkeit des Containers auf die
Containermanagementkomponente verlagert, welche typischerweise ohnehin eine hohe Zuverlässigkeit aufweist.
Gemäß einer bevorzugten Ausführung weist das Verfahren ferner folgenden Schritt auf:
Erzeugen von Containerauthentisierungsdaten als Prüfsumme des Containers oder eines Containerbilds des Containers, wobei die Autorisierungsanforderung die Containerauthentisierungsdaten beinhaltet.
Dadurch kann zusätzlich zu den Benutzerauthentisierungsdaten, welche einen Benutzer eindeutig identifizieren sollen, auch der Container bzw. die Anwendung authentisiert werden. Dadurch kann beispielsweise verhindert werden, dass der Container oder die Anwendung ausgeführt werden, nachdem sie versehentlich oder bösartig verändert wurden. Die Prüfsumme kann insbesondere instantan bzw. ad hoc bei Ausführung des Verfahrens erstellt werden, so dass sie grundsätzlich aktuell ist und keine spätere Modifikation des Containers oder der Anwendung mehr erfolgen kann bzw. eine solche Modifikation erkannt werden würde und zu einer Verweigerung der Ausführung führen würde.
Bevorzugt bestimmt der Autorisierungsserver dabei die Freigabeinformation zumindest basierend auf den Containerauthentisierungsdaten. Dies kann insbesondere zusätzlich zu den Benutzerauthentisierungsdaten erfolgen. Der Autorisierungsserver könnte anhand der Containerauthentisierungsdaten, insbesondere anhand der Prüfsumme, eine eventuelle Modifikation des Containers oder der Anwendung erkennen und somit sicherstellen, dass die Anwendung nur dann ausgeführt wird, wenn sie nicht im
Vergleich zu einer beabsichtigten Version verändert wurde. Insbesondere kann die Freigabeinformation den negativen Wert annehmen oder vom Autorisierungsserver auf den negativen Wert gesetzt werden, wenn der Autorisierungsserver anhand der
Containerauthentisierungsdaten bestimmt, dass eine Veränderung der Anwendung oder des Containers vorliegt.
Insbesondere kann der Autorisierungsserver die Containerauthentisierungsdaten mit einer Anzahl von Containervorgabewerten vergleichen und die Freigabeinformation nur dann auf einen positiven Wert setzen, wenn die Containerauthentisierungsdaten zu einem der Containervorgabewerte entsprechen. Die Containervorgabewerte können somit dazu verwendet werden, festzulegen welche Container oder Arten von Containern ausgeführt werden dürfen. Sie können auf dem Autorisierungsserver gespeichert sein oder auch extern bezogen werden.
Sofern die weiter oben bereits erwähnte Nonce verwendet wird kann der
Autorisierungsserver auch eine Prüfsumme basierend auf der Nonce und einem ihm zur Verfügung stehenden Containerbild oder Container berechnen. Dies ermöglicht den Vergleich, ob die Containerauthentisierungsdaten von einer Einheit empfangen wurden, welche die Nonce kennt. Alternativ können beispielsweise auch Prüfsummen im
Autorisierungsserver abgespeichert sein, welche jeweiligen Nonces zugeordnet sind.
Die Autorisierungsantwort kann insbesondere eine Berechtigungsinformation
beinhalten, wobei die Anwendung mit Rechten ausgeführt wird, welche basierend auf der Berechtigungsinformation festgelegt werden. Dies kann beispielsweise verwendet werden, um unterschiedlichen Benutzern, welche unterschiedliche
Benutzerauthentisierungsdaten haben, unterschiedliche Rechte zuzuweisen. Beispielsweise kann bestimmten Benutzern der Zugriff auf bestimmte Ressourcen gewährt, anderen jedoch verwehrt werden. Die Berechtigungsinformation kann insbesondere vom Autorisierungsserver festgelegt werden, beispielsweise basierend auf den Benutzerauthentisierungsdaten und/oder den Containerauthentisierungsdaten.
Bevorzugt weist das Verfahren ferner folgenden Schritt auf:
Zuweisen einer Netzwerkadresse zu dem Container.
Dadurch kann der Container eindeutig identifiziert werden, was es insbesondere ermöglicht, einen Datenstrom zu oder von diesem Container eindeutig von
Datenströmen zu oder von anderen Containern oder anderen Komponenten
abzugrenzen. Dies ermöglicht die Zuweisung von bestimmten Rechten für diesen Datenstrom. Bei der Netzwerkadresse kann es sich insbesondere um eine IPv6- Adresse handeln, wobei je nach Implementierung auch andere Adressen verwendet werden können.
Die Netzwerkadresse kann insbesondere von der Containermanagementkomponente zugewiesen werden. Diese kann hierzu beispielsweise auf geeignete Adressbereiche zurückgreifen. Die Autorisierungsanforderung kann beispielsweise die Netzwerkadresse beinhalten. Dadurch können weitere Einheiten, beispielsweise der weiter unten erwähnte Containerauthentifikator, über die Netzwerkadresse informiert werden.
Alternativ oder zusätzlich kann die Containermanagementkomponente die
Netzwerkadresse auch separat zur Autorisierungsanforderung versenden. Dies kann beispielsweise in einer separaten Nachricht oder Mitteilung erfolgen.
Die Autorisierungsanforderung kann insbesondere über einen Containerauthentifikator zu dem Autorisierungsserver gesendet werden. Ebenso kann insbesondere die
Autorisierungsantwort über den Containerauthentifikator von dem Autorisierungsserver empfangen werden. Der Containerauthentifikator ist dabei typischerweise eine zusätzliche Komponente, welche beispielsweise softwaremäßig und/oder
hardwaremäßig von der Komponente, welche den Container ausführt, und dem
Autorisierungsserver getrennt ist. Der Containerauthentifikator kann zusätzliche
Aufgaben ausführen, welche weiter unten beispielhaft näher beschrieben werden. Insbesondere kann der Containerauthentifikator ein 802.1X Authenticator sein, was den Rückgriff auf ein bestehendes 802.1X-System vereinfacht und umfangreiche
Neuentwicklungen vermeidet.
Bevorzugt weist das Verfahren ferner folgende Schritte auf:
Erzeugen, durch den Containerauthentifikator, einer Netzwerkfreigabeinformation basierend auf der Autorisierungsanforderung und/oder der
Autorisierungsantwort, und
Senden, durch den Containerauthentifikator, der Netzwerkfreigabeinformation an eine Netzwerksteuerungskomponente, wobei die Netzwerksteuerungskomponente Datenverkehr zu und/oder von dem Container basierend auf der Netzwerkfreigabeinformation freigibt oder blockiert.
Insbesondere kann das Verfahren ferner folgende Schritte aufweisen:
Erzeugen, durch den Containerauthentifikator, einer Netzwerkfreigabeinformation basierend auf der Autorisierungsantwort, und
Senden, durch den Containerauthentifikator, der Netzwerkfreigabeinformation an eine Netzwerksteuerungskomponente, wobei die Netzwerksteuerungskomponente Datenverkehr zu und/oder von dem Container basierend auf der Netzwerkfreigabeinformation freigibt oder blockiert.
Dies ermöglicht eine Kontrolle des Datenverkehrs von und/oder zu dem Container, so dass auch der Datenverkehr abhängig von authentisierten und/oder autorisierten Benutzern gesteuert werden kann. Beispielsweise kann der Zugriff auf bestimmte Ressourcen oder bestimmte Arten von Datenverkehr für bestimmte Benutzer freigegeben, für andere jedoch gesperrt werden. Bei der
Netzwerksteuerungskomponente kann es sich beispielsweise um eine Firewall oder einen SDN-Controller handeln, wobei die Netzwerksteuerungskomponente
typischerweise softwaremäßig und/oder hardwaremäßig von den anderen bereits erwähnten und/oder nachfolgend erwähnten Komponenten unterscheidbar ist. Es kann sich auch um einen Server oder um einen anderen Computer handeln.
Eine solche Implementierung stellt eine Erweiterung der Authentifizierung und
Autorisierung um eine Konfiguration einer Netzwerksteuerungskomponente dar. Gemäß einer bevorzugten Ausführung erzeugt der Autorisierungsserver die
Autorisierungsantwort mit Netzwerkfreigabedaten. Der Containerauthentifikator kann insbesondere die Netzwerkfreigabeinformation basierend auf den
Netzwerkfreigabedaten erzeugen. Dies kann in Form einer identischen Übernahme der Netzwerkfreigabedaten oder nach Modifikation erfolgen. Der Autorisierungsserver kann somit auch zur Konfiguration der Netzwerksteuerungskomponente verwendet werden. Dies erleichtert die Konfiguration.
Der Autorisierungsserver kann die Netzwerkfreigabedaten insbesondere abhängig von den Benutzerauthentisierungsdaten und/oder den Containerauthentisierungsdaten erzeugen. Dadurch kann individuell auf Benutzer bzw. Container eingegangen werden und es können spezifische Rechte zugewiesen werden.
Die Netzwerksteuerungskomponente kann insbesondere so angeordnet sein, dass jeglicher Datenverkehr zu und von dem Container und/oder zu und von einem geschützten Server durch die Netzwerksteuerungskomponente geleitet wird. Dies ermöglicht eine vollständige Kontrolle des Datenverkehrs zum und vom Container oder auch zu und von einem geschützten Server. Beispielsweise kann der Container dadurch abgeschirmt werden und/oder der Container kann mit bestimmten
Zugriffsrechten ausgestattet werden, welche von der Netzwerksteuerungskomponente kontrolliert werden können. Außerdem kann ein geschützter Server, welcher beispielsweise im Netzwerk vorhanden sein kann, besonders gegen unbefugten Zugriff geschützt werden. Ein geschützter Server kann insbesondere ein Server sein, welcher besonders sensible oder schützenswerte Informationen speichert.
Die Netzwerksteuerungskomponente kann auch ein Gateway sein, welcher zwei Netzwerke verbindet. Beispielsweise kann es sich hierbei um einen Gateway zwischen einem lokalen Netz und dem Internet handeln. Dadurch kann beispielsweise festgelegt werden, dass nur der Container oder nur bestimmte Container mit dem Internet kommunizieren dürfen, andere Netzwerkelemente dagegen nur im lokalen Netz kommunizieren dürfen.
Der Containerauthentifikator kann bevorzugt die dem Container zugewiesene
Netzwerkadresse an die Netzwerksteuerungskomponente senden. Die
Netzwerkadresse kann der Containerauthentifikator beispielsweise über die
Autorisierungsanforderung oder eine separate Nachricht erhalten. Die Netzwerksteuerungskom ponente kann dann insbesondere den Datenverkehr basierend auf der Netzwerkadresse freigeben oder blockieren. Dies ist insbesondere sinnvoll, weil mittels der Netzwerkadresse der Container eindeutig identifiziert werden kann und somit Rechte für den Datenverkehr dieses Containers zuverlässig festgelegt und überwacht werden können.
Die Netzwerkadresse kann insbesondere von der Containermanagementkomponente an den Containerauthentifikator gesendet werden. Dies erlaubt eine einfache Mitteilung der Netzwerkadresse.
Zwischen dem Container und einem Netzwerkelement kann insbesondere ein durch die Netzwerksteuerungskomponente verlaufender geschützter Kommunikationskanal ausgebildet werden. Dadurch kann einer Vielzahl von Angriffen vorgebeugt werden. Beispielsweise kann das Netzwerkelement, zu welchen der geschützte
Kommunikationskanal ausgebildet wird, ein geschützter Server sein, auf welchen nur ein bestimmter Container oder mehrere bestimmte Container Zugriff hat bzw. haben.
Der geschützte Kommunikationskanal kann insbesondere Ende-zu-Ende-verschlüsselt sein. Dadurch kann einem Mitlesen durch Unbefugte vorgebeugt werden.
Der geschützte Kommunikationskanal kann insbesondere ein VPN-Kanal (Virtual Private Network) sein. Beispielsweise kann IPsec als VPN-Technologie verwendet werden. Dies hat sich für derartige Anwendungen als vorteilhaft herausgestellt. Auch andere Technologien können jedoch verwendet werden.
Bevorzugt kann der Autorisierungsserver Informationen und/oder Schlüssel zum Aufbau des geschützten Kommunikationskanals an den Containerantragsteller liefern. Dadurch kann der Autorisierungsserver, zusätzlich zu den bereits erwähnten Informationen bzw. zusätzlich zur bereits beschriebenen Funktionalität, Informationen wie insbesondere Schlüssel für die geschützte Verbindung bereitstellen. Dies ermöglicht eine besonders einfache und zuverlässige Bereitstellung solcher Informationen und Schlüssel sowie eine gemeinsame Verwaltung auf dem Autorisierungsserver.
Die Informationen und/oder Schlüssel zum Aufbau des geschützten
Kommunikationskanals können insbesondere in der Autorisierungsantwort enthalten sein. Hierzu können sie von dem Autorisierungsserver in die Autorisierungsantwort aufgenommen werden. Dadurch kann die Autorisierungsantwort in einfacher Weise zum Bereitstellen derartiger Informationen verwendet werden. Auch eine separate
Bereitstellung ist jedoch möglich.
Die Netzwerkfreigabeinformation kann insbesondere die
Netzwerksteuerungskomponente dazu konfigurieren, dass ausschließlich Datenverkehr zu und von dem Container oder mehreren Containern durchgelassen wird. Dies kann beispielsweise verwendet werden, wenn die Netzwerksteuerungskomponente ein Gateway zwischen zwei Netzwerken ist. Ein Netzwerk kann dabei beispielsweise gegen ein weiteres Netzwerk, beispielsweise das Internet, abgeschirmt werden, um
unberechtigte Zugriffe zu unterbinden. Beispielsweise kann in diesem Fall lediglich ein Container oder können mehrere Container die Berechtigung erhalten, mit seinem jeweiligen Datenverkehr die Netzwerksteuerungskomponente zu passieren,
beispielsweise also auf das Internet zuzugreifen. Dadurch kann beispielsweise ein geschützter Browser für sichere Umgebungen implementiert werden.
Datenverkehr zwischen dem Container und einem oder mehreren anderen
Netzwerkelementen kann insbesondere über ein geschütztes und/oder verschlüsseltes Netzwerk erfolgen. Dadurch kann einer Vielzahl möglicher Angriffe vorgebeugt werden. Das geschützte und/oder verschlüsselte Netzwerk kann insbesondere mittels MACsec verschlüsselt sein. Dies hat sich für typische Anwendungen als vorteilhaft erwiesen, wobei auch andere Ausführungen möglich sind.
Gemäß einer bevorzugten Ausführung ist der Container dazu konfiguriert, nur eine Anwendung auszuführen. Dies kann die Sicherheit weiter erhöhen, da jeder Container nur einer Anwendung zugeordnet ist und umgekehrt. Insbesondere können dadurch auch Container mit zugehörigen Anwendungen zentral bereitgestellt werden, wobei verhindert wird, dass Benutzer oder andere Personen zusätzliche Anwendungen in dem jeweiligen Container ausführen, welche eventuell gegen Richtlinien oder
Sicherheitsbedürfnisse verstoßen. Insbesondere kann darunter verstanden werden, dass nicht zwei oder mehr Anwendungen in dem Container ausgeführt werden können.
Bevorzugt weist das Verfahren ferner folgenden Schritt auf:
Herunterladen der Anwendung und/oder des Containers von einem
Bereitstellungsserver. Dadurch können Container und/oder zugehörige Anwendungen zentral bereitgestellt werden, beispielsweise innerhalb einer Einrichtung wie einem Unternehmen oder einer Bildungseinrichtung. Weiter bevorzugt ist der Container dazu konfiguriert, ausschließlich von dem Bereitstellungsserver heruntergeladene Anwendungen auszuführen. Dadurch kann sichergestellt werden, dass ausschließlich zugelassene Anwendungen ausgeführt werden, was Sicherheitsprobleme vermeiden kann. Insbesondere kann die Ausführung von ausschließlich zugelassenen Anwendungen und/oder Containern auch durch die weiter oben bereits erwähnte Prüfsumme und die dazugehörige Verarbeitung
sichergestellt werden.
Bevorzugt sind die Autorisierungsanforderung und/oder die Autorisierungsantwort EAP- Nachrichten oder EAPoUDP-Nachrichten. Dabei kann auf das bekannte EAP-Protokoll zurückgegriffen werden, was zusätzlichen Verwaltungsaufwand oder Entwicklungsarbeit vermeidet. Derartige Nachrichten haben sich für die Ausführung des Verfahrens als vorteilhaft erwiesen.
Bei dem Container kann es sich insbesondere um einen Remote Application Container (RAC) handeln.
Die Erfindung betrifft des Weiteren eine Netzwerkanordnung, welche zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche konfiguriert ist. Die Netzwerkanordnung weist eine erste Computereinheit, die zur Ausführung der
Containermanagementkomponente, des Containers und des Containerantragstellers konfiguriert ist, und eine zweite Computereinheit, die zur Ausführung des
Autorisierungsservers konfiguriert ist, auf. Die Computereinheiten sind miteinander zum Datenverkehr vernetzt. Dies gilt für die hier genannten Computereinheiten sowie für weitere Computereinheiten. Bezüglich des Verfahrens kann auf alle hierin
beschriebenen Ausführungen und Varianten zurückgegriffen werden.
Eine Computereinheit kann insbesondere ein physisch abgrenzbarerer Computer oder beispielsweise auch eine virtuelle Maschine auf einem Computer oder einer Serverfarm sein. Eine Vernetzung kann drahtgebunden oder drahtlos erfolgen und insbesondere eine definierte Schnittstelle zum Datenverkehr bereitstellen.
Die Netzwerkanordnung kann insbesondere zur Ausführung des Verfahrens mit
Containerauthentifikator konfiguriert sein. Sie kann insbesondere ferner eine dritte Computereinheit aufweisen, die zur Ausführung des Containerauthentifikators konfiguriert ist.
Die Netzwerkanordnung kann insbesondere zur Ausführung eines Verfahrens mit Netzwerksteuerungskomponente konfiguriert sein. Sie kann ferner eine vierte
Computereinheit aufweisen, die zur Ausführung einer Netzwerksteuerungskomponente konfiguriert ist.
Die Netzwerksteuerungskomponente kann gemäß einer Ausführung ein Gateway zwischen der Netzwerkanordnung und einem dazu separaten Netzwerk sein. Dadurch kann beispielsweise ein Datenverkehr zwischen einem lokalen bzw. bestimmten Netzwerk und dem Internet kontrolliert werden, wie weiter oben beschrieben. Ein Internetzugriff kann beispielsweise auf bestimmte Container eingeschränkt werden.
Die Netzwerkanordnung kann gemäß einer Ausführung einen geschützten Server aufweisen, der ausschließlich über die Netzwerksteuerungskomponente ansprechbar ist. Dadurch kann durch eine geeignete Konfiguration der
Netzwerksteuerungskomponente, beispielsweise wie weiter oben beschrieben, der Zugriff auf den geschützten Server kontrolliert werden, beispielsweise derart, dass nur ein Container bzw. bestimmte Container Zugriff auf den Server hat bzw. haben.
Bezüglich des zu implementierenden Verfahrens bei den jeweiligen Komponenten bzw. Computereinheiten kann auf alle hierin beschriebenen Ausführungen und Varianten zurückgegriffen werden.
Die Erfindung betriff des Weiteren eine elektronische Einrichtung wie beispielsweise einen Computer, welche zum Ausführen eines erfindungsgemäßen Verfahrens konfiguriert ist. Die Erfindung betrifft außerdem ein nichtflüchtiges computerlesbares Speichermedium, welches Programmcode enthält, bei dessen Ausführung ein
Prozessor ein erfindungsgemäßes Verfahren ausführt. Bezüglich des Verfahrens kann dabei jeweils auf alle hierin beschriebenen Ausführungen und Varianten zurückgegriffen werden. Nachfolgend werden die hierin offenbarte Implementierung sowie Grundlagen hierzu mit Bezug auf die beigefügte Zeichnung beschrieben. Es zeigen:
Fig. 1 : Einen Vergleich von Systemvirtualisierung und Containervirtualisierung,
Fig. 2: Eine Docker-Architektur,
Fig. 3: Ein Port-basiertes Autorisierungsmodell von 802.1X,
Fig. 4: Ein Kommunikationsbeispiel von Authentifizierung und Autorisierung
basierend auf 802.1 X,
Fig. 5: Einen Vergleich von Protokollen,
Fig. 6: Einen verwalteten Host, welcher eine RAC- und eine
Betriebssystemanwendung ausführt,
Fig. 7: Eine Anpassung von 802.1X für die Ausführung eines erfindungsgemäßen
Verfahrens,
Fig. 8: Ein Datenmodell,
Fig. 9: Einen Datenfluss,
Fig. 10: Einen weiteren Datenfluss,
Fig. 1 1 : Eine Testumgebung,
Fig. 12: Eine Netzwerkkonfiguration von Docker in der Testumgebung,
Fig. 13: Einen zweischrittigen Autorisierungsvorgang, und
Fig. 14: Experimente zum Beurteilen der Kommunikation zwischen dem
verwalteten Host, einem RAC und zwei Webservern.
Im Allgemeinen sei erwähnt, dass Container virtualisierung auf Betriebssystemebene implementieren können. Sie stellen beispielsweise virtualisierte
Betriebssystemumgebungen bereit, welche mit Bezug auf Hardwareressourcen und Sicherheit isoliert sind. Typischerweise teilen sie sich einen Betriebssystemkernel und können Bibliotheken beinhalten, welche benötigt werden, um eine oder mehrere beinhaltete Anwendungen auszuführen. Container, welche im Rahmen des hierin beschriebenen Verfahrens verwendet werden können, können auch als xRAC bezeichnet werden. Dabei können beispielsweise nur spezielle Anwendungen mit ihren Abhängigkeiten und Konfigurationen in einem
Container beinhaltet sein. Beispiele für Containerplattformen sind Docker, Kubernetes, System d-nspawn, BSD Jails, Linux Containers, Windows Containers, Solaris
Containers, Virtuozzo und rkt. Als besonders vorteilhaft für das hierin offenbarte Verfahren hat sich Docker erwiesen.
Virtualisierung erleichtert effiziente und flexible Verwendung von Hardwareressourcen, erhöht die Sicherheit durch Isolation und sorgt für Fehlertoleranz und Skalierbarkeit durch einfache Migrationsprozesse. Container haben im Vergleich zu kompletten Betriebssystemen zusätzlich die nachfolgend beschriebenen Vorteile. Aufgrund des geteilten Betriebssystems benötigen Container weniger CPU, Speicher und
Festplattenressourcen. Containerbilder, auf Englisch als Container-Images bezeichnet, sind wesentlich kleiner, was eine Verteilung über zahlreiche Rezipienten erleichtert. Container vereinfachen eine Anwendungsverteilung. Anstatt einen Support für komplexe Kombinationen von Anwendungen, Abhängigkeiten und
Benutzerkonfigurationen bereitstellen zu müssen, können Administratoren Container bereitstellen, welche vorab getestet sind. Außerdem haben Container keine Bootzeiten, was sie insbesondere für nur kurzzeitig benötigte Anwendungen vorteilhaft erscheinen lässt.
Fig. 1 vergleicht die Konzepte Containervirtualisierung und Systemvirtualisierung.
Virtuelle Maschinen (VMs) in der Systemvirtualisierung werden typischerweise auf virtualisierten Hardwarekomponenten eines Hypervisor-Systems und emulierten Komponenten betrieben. Der Hypervisor kontrolliert Isolation mit Bezug auf Ressourcen und Sicherheit. VMs betreiben komplette Betriebssysteme, welche alle binären
Komponenten und Datenbanken zum Ausführen von Anwendungen beinhalten.
Eine der am weitesten verbreiteten Containerplattformen ist derzeit Docker. Fig. 2 zeigt eine vereinfachte Übersicht der Dockerplattform und ihres Betriebs. Ein Host mit einem gemeinsamen Betriebssystem (OS = Operating System) beinhaltet den Docker CMD (Container Management Daemon), welcher Container und Containerbilder erzeugt und verwaltet. Containerbilder sind schreibgeschützte Vorlagen, welche Anwendungen mit ihren Abhängigkeiten wie beispielsweise Binärkomponenten, Datenbanken und
Konfigurationen beinhalten. Container sind Laufzeitinstanzen, welche die schreibgeschützten Containerbilder durch eine beschreibbare Schicht erweitern.
Deshalb können unterschiedliche Containerinstanzen ein gemeinsames Bild teilen. Dies führt zu Skalierbarkeit mit geringen Festplattenerfordernissen. Der Docker CMD wird durch den Docker Client über eine REST -Schnittstelle gesteuert. Der Docker Client kann in dem Host angeordnet sein, in welchem sich auch die Docker CMD befindet, oder auch in einem entfernten Host. Eine Docker-Befehlszeilenschnittstelle (CLI = Command Line Interface) ist ein Beispiel für eine Benutzersteuerung durch CLI-Aufrufe. Der Docker CMD kann mit Docker-Registern verbunden werden, die es Benutzern erlauben, Containerbilder hoch- oder herunterzuladen (push bzw. pull). Derartige Register sind entweder privat oder öffentlich verfügbar. Ein Docker Hub mit mehr als 100.000 Containerbildern ist ein Beispiel für das letztere. Gemeinsame Operationen sind build (1 ), pull (2) und run (3). Mit build können Benutzer individuelle Containerbilder erzeugen. Mit pull können Benutzer existierende Containerbilder von einem Docker- Register herunterladen, um Teil des lokalen Containerbildspeichers zu werden. Mit run können Containerbilder von dem lokalen Bildspeicher auf dem Hostsystem ausgeführt werden. Ein Docker-Register kann auch als Bereitstellungsserver bezeichnet werden.
Docker verwendet unterschiedliche Funktionen des Betriebssystemkernels zum
Vorsehen von Isolation und Ressourcenimitierung, und unterstützt Speichertreiber wie beispielsweise AuFS, OverlayFS und ZFS, um ein Stacking eines Dateisystems zu ermöglichen. Ein Containerformat und eine Laufzeitumgebung von Docker wurden durch die Open Container Initiative als offene Industriestandards angenommen.
Containersicherheitsplattformen erweitern den Container Management Daemon (CMD) durch Sicherheitsfunktionen. Beispielsweise ermöglichen Twistlock und die Aqua Container Security-Plattform eine Laufzeitumgebung basierend auf
Maschinenlernmechanismen zum permanenten Überwachen von Containern zum Detektieren von kompromittierendem Verhalten und spezielle Netzwerkfirewalls zum Filtern von Containerverkehr. Die Sysdig Secure-Plattform erlaubt das Formulieren von Servicevorgaben, zum Beispiel Vorgaben, welche auf Anwendungen, Containern, Hosts oder Netzwerkaktivitäten basieren. Die Plattform liefert Alarme und Aktionen basierend auf Verletzungen von Vorgaben, einer Ereignisprotokollierung und aktuellen
Ereignissen. Der Atomicorp Secure Docker Kernel ist ein gehärteter Linux-Kernel, welcher sicherheitsrelevante Merkmale wie Ausbruchverhinderung,
Speicherveränderungsverhinderung oder Verhinderung von direktem Benutzerzugriff durch den Kernel bereitstellt. Alle Plattformen fokussieren auf das Überwachen und Kontrollieren von möglicherweise nicht zuverlässigen Containern, welche auf einer geteilten Containerlaufzeitumgebung ausgeführt werden. Merkmale für Authentifizierung und Autorisierung (AA) von Benutzern, Containern und ihren Netzwerkflüssen sind jedoch nicht Teil dieser Plattformen.
Das Docker Authorization Framework ist seit der Version 1 .10 Teil von Docker. Es erweitert den Docker CMD durch eine REST-Schnittstelle auf externe Plug-ins zur Autorisierung. Anfragen von dem Docker CMD, beispielsweise zum Starten eines Containers, werden auf ein Plug-in zur Autorisierung weitergeleitet, welches
Mechanismen zum Entscheiden beinhaltet, ob die Anfrage erlaubt oder verwehrt wird. Das Docker Authorization Framework implementiert keine Sicherheitsfunktionen, aber liefert eine Basis zum Implementieren derartiger Sicherheitskonzepte. Das hierin offenbarte Verfahren erweitert dies noch.
Container liefern typischerweise Anwendungen oder Dienste ohne graphische
Benutzerschnittstelle (GUI = Graphical User Interface), welche in einer Cloud oder auf einer Datencenter-Infrastruktur laufen. Beispiele sind Container, welche Web- Anwendungen beinhalten, mit ihren Bedürfnissen, zum Beispiel ein nginx-Webserver mit einer PHP-Laufzeit und MySQL-Datenbank.
Nachfolgend wird eine Beschreibung von 802.1X gegeben sowie eine Erläuterung, wie damit Authentifizierung und Autorisierung (AA) unterstützt werden kann. Ebenfalls wird EAPoUDP vorgestellt, was ein alternatives Protokoll zum Datenverkehr für AA in 802.1X darstellt. Es wird zusammengefasst, wie AA für Applikationen derzeit in der Praxis ausgeführt wird.
IEEE 802.1X führt portbasierte Netzwerkzugriffskontrolle in drahtgebunden Ethernet- Netzwerken ein. Trotzdem ist es heutzutage hauptsächlich von den drahtlosen 802.1 1 - Netzwerken bekannt. Ein Beispiel ist eduroam, was einen Zusammenschluss von drahtlosen Campusnetzwerken von Universitäten darstellt. Teilnehmer können sich mit dem Internet verbinden, und zwar unabhängig davon, ob sie sich an ihrer
Heimatuniversität oder an einer fremden Universität befinden.
Fig. 3 zeigt die drei Komponenten von 802.1X und das Prinzip von portbasierter Netzwerkzugriffskontrolle. Ein Supplicant-System ist ein Netzwerk-Host, welcher den 802.1X Supplicant beinhaltet (802.1X S), ein Authentifikatorsystem beinhaltet einen 802.1X-Authentifikator (802.1X A) und steuert Netzwerkzugriff von Netzwerk-Hosts. Beispiele sind Zugriffsschalter bzw. Switches, welche Netzwerk-Hosts mit dem
Hauptnetzwerk verbinden. Vor der Autorisierung kann das Supplicant-System den 802.1X A erreichen, jedoch nicht das Netzwerk. Ein 802.1X AS (Autorisierungsserver) ist vorliegend beispielsweise ein Authentifizierungs-, Autorisierungs- und Accounting- Server. Er speichert Authentisierungsdaten zum Überprüfen von Benutzeridentitäten und Autorisierungsdaten zum Erlauben von Zugriff auf das Netzwerk. Er authentisiert und/oder authentifiziert den 802.1X S und liefert Autorisierungsinformation zu dem 802.1X A.
802.1X erweitert das Extensible Authentication Protocol (EAP) und den Remote
Authentication Dial-In User Service (RADIUS) zum Austauschen von AA-Daten. Beide sehen feste Anfrage- und Antwortschemata vor, und zwar zum Austauschen von AA- Daten. Das Diameter-Protokoll ist eine weniger verbreitete Alternative.
Authentisierungsdaten werden in Ethernet-Rahmen, auf Englisch Frames genannt, als EAP-over-LAN (EAPoLAN)-Kapselung zwischen dem 802.1X S und 802.1X A und als EAP-over-RADIUS (EAPoRADIUS) zwischen 802.1X A und 802.1X AS übertragen. Fig. 5 zeigt die Paketstruktur von EAPoL. Autorisierungsdaten werden in RADIUS-Rahmen zwischen dem 802.1X AS und 802.1X A übertragen.
Details von 802.1X werden anhand eines vierschrittigen Vorgehens von AA gemäß Fig. 4 erklärt. In einem ersten Schritt (1 ) initialisiert 802.1X S die Authentisierung durch Senden einer EAPoL-Startnachricht zu dem 802.1X A. In einem zweiten Schritt frägt der 802.1X A die Identität von dem 802.1X S an (2a) und leitet sie zu dem 802.1X AS weiter (2b). RADIUS unterstützt große Domänen, welche mehrere hierarchisch organisierte RADIUS-Server beinhalten. Jede Identität ist mit einer Domäne verknüpft und dem RADIUS-Server dieser Domäne bekannt, so dass AA-Versuche in RADIUS- Infrastrukturen weitergeleitet werden können. In einem dritten Schritt (3) wird
Authentifizierung durchgeführt, und zwar zwischen 802.1X S und 802.1X AS. Der Authentifikator entkapselt EAP-Pakete von EAPoL-Rahmen und kapselt sie wieder ein als EAPoRADIUS-Rahmen und umgekehrt. Die flexible Nachrichtenstruktur von EAP erlaubt die Verwendung von unterschiedlichen Authentifizierungsprozeduren. Einfache Ansätze tragen Identitätsinformation im Klartext oder einfache MD5-gehashte
Passwörter, jedoch werden auch sicherere Authentifizierungsprozeduren wie EAP Tunneled TLS und EAP-TLS unterstützt. Der Authentifikator leitet nur EAP-Nachrichten durch. Deshalb müssen neue EAP-Typen nur auf dem 802.1X S und 802.1X AS implementiert werden, jedoch nicht in dem 802.1 X A. In dem vierten Schritt kann der RADIUS-Server Autorisierungsdaten zu dem 802.1X A zurückliefern, und zwar nach erfolgreicher Authentisierung und Authentifizierung. Dies kann grob granulär sein, zum Beispiel eine binäre Zugriffsentscheidung, ob das Supplicant-System Zugriff bekommt oder nicht, oder fein granulär, zum Beispiel VLAN-Tags, welche für erwarteten
Benutzerverkehr oder Filterregeln gesetzt werden, welche durch den Authentifikator angewendet werden. Der Authentifikator wendet die Autorisierungsdaten auf den bestimmten physikalischen Port des Switches an, zum Beispiel setzt er einen VLAN- Tag. Danach bestätigt der Authentifikator erfolgreiches AA zu dem Supplicant mit einer EAP-Erfolgsnachricht (4b).
EAPoUDP ist eine Variation von EAP, welche die Übertragung von EAP-Daten über UDP und IP erlaubt. Fig. 5 zeigt die zugehörige Paketstruktur im Vergleich mit EAPoL. Im Gegensatz zu EAPoL kann EAPoUDP verwendet werden zum Authentifizieren von mehreren Anwendungen, welche auf einem Netzwerk-Host laufen. Auch können UDP- Pakete über jede Verbindungstechnologie übertragen werden, oder können sogar innerhalb von Multidomain-Netzwerken geroutet werden. EAPoUDP wurde als Internet- Draft eingeführt, welcher ohne Standardisierung in der PANA Working Group bei IETF im Jahr 2002 ausgelaufen ist.
802.1X ist spezialisiert auf portbasierte Zugriffskontrolle für Netzwerk-Hosts. In der Praxis ist AA für Anwendungen implementiert als Teil der Anwendungen oder unter Verwendung des Kerberos-AA-Protokolls.
Die meisten Netzwerkanwendungen implementieren eine Art von AA-Mechanismus. Beispiele sind Log-in-Formulare in einem Startbildschirm, wo Benutzer dazu
aufgefordert werden, gültige Zugriffsinformationen einzugeben, um mit der Benutzung einer Anwendung zu beginnen. Andere Beispiele sind Client-Zertifikate, welche zusammen mit TLS verwendet werden, und eine Infrastruktur mit öffentlichem
Schlüssel. Jedoch haben AA-Funktionalitäten, welche Teil der Anwendung sind, einen Einfluss, welcher auf die Client- und Serverseite der Netzwerkanwendung beschränkt ist. Weder der Start der Anwendung noch die Netzwerkinfrastruktur dazwischen kann gesteuert werden. Kerberos ist ein Netzwerkauthentifizierungsprotokoll, welches unterschiedliche Authentifizierung für Clients und Server über ein unsicheres Netzwerk ermöglicht. Clients sind beispielsweise komplette Hosts, Benutzer oder Anwendungen; Server repräsentieren Hosts, welche bestimmte Netzwerkanwendungen bieten. Kerberos adaptiert Benutzertickets für die Authentifizierung von verschiedenen
Netzwerkanwendungen. Kerberos muss durch Anwendungen auf Client- und
Serverseite implementiert werden, was die Anwendung für ältere Anwendungen verhindert, welche nicht verwendet werden können.
FlowNAC fügt fein granuläre SDN-Netzwerkzugriffskontrollsysteme unter Verwendung von 802.1X für AA von Anwendungen auf Netzwerk-Hosts ein. Dies ermöglicht unterschiedliche Versionen von AA für unterschiedliche Anwendungen auf einem Netzwerk-Host. Zum Ermöglichen von unterschiedlichem AA für unterschiedliche Anwendungen auf einem Netzwerk-Host werden EAPoL-over-EAPoLAN- Verkapselungen eingeführt. Wie in Fig. 5 in einem Vergleich von Datenpaketen für EAPoL, EAPoUDP und EAPoL in EAPoL dargestellt, fügt FlowNAC eine andere Variation von EAPoL ein. Ein EAPoL-in-EAPoL-Paketfeld identifiziert bis zu 64.000 unterschiedliche EAP-Prozesse, welche als verkapselte EAP-Nutzlast übertragen werden. Jedoch erfordert diese Abweichung vom alten 802.1X wesentliche
Veränderungen von 802.1X S und 802.1X A. Das 802.1X S ist ein Teil eines Kernels eines Betriebssystems, und der 802.1X A ist Teil von Netzwerkswitches, so dass nur Open Source-Betriebssysteme und -Firmwares Modifikationen erlauben. Trotzdem ist es schwierig, die Modifikation in neuen Versionen des Betriebssystemkernels oder der Firmwarebilder auszuführen. Es wird vorliegend auf EAPoL gesetzt, d.h. AA- Datentransfer wird auf die Ethernet-Verbindung eingeschränkt. EAPoUDP kann grundsätzlich ebenfalls verwendet werden. Ebenso fügt FlowNAC weder IP-Adressen für Anwendungen ein noch wird der Start von Anwendungen durch AA eingeschränkt.
Nachfolgend werden RACs (Restricted Application Containers) und das hierin beschriebene Verfahren (xRAC) beschrieben. Außerdem wird der Betrieb der
Steuerungskomponenten im Detail erklärt.
Restricted Application Containers (RACs) sind im Allgemeinen ausführbare
Containerbilder (Container images), welche eine einzige Anwendung, deren
Abhängigkeiten und Konfigurationsdaten wie Programmeinstellungen und
Softwarelizenzinformationen beinhalten. Wie aus Fig. 6 hervorgeht, werden RACs in einer Containerlaufzeitumgebung parallel zu betriebssystemeigenen Anwendungen ausgeführt. Der CMD steuert die Ausführung von RACs und liefert eine Schnittstelle für Benutzer zum Erzeugen, Löschen und Starten oder zum Anhalten von RACs. Jeder RAC hat eine eigene IPv6-Adresse, so dass der Verkehr in dem Netzwerk einfach identifiziert werden kann. RAC-Bilder werden beispielsweise durch
Netzwerkadministratoren erzeugt und über RAC-Register verteilt. Sie werden
beispielsweise entweder von derartigen Registern durch Benutzer heruntergeladen oder werden automatisch durch verwaltete Hosts synchronisiert.
In Fig. 7 ist ein Benutzer zu sehen, weicher auf einen Containermanagementdaemon (CMD) zugreifen kann, welcher eine Containermanagementkomponente darstellt. Der CMD befindet sich in einem verwalteten Host (managed host), in welchem sich des Weiteren ein Remote Application Container (RAC) sowie ein Containerantragsteller in Form eines 802.1X CS (Container Supplicant) befinden. Hierbei handelt es sich um entsprechende Softwaremodule. Zur Autorisierung ist ein dazu externer
Autorisierungsserver 802.1X AS vorhanden, wobei dieser Benutzerdaten und
gegebenenfalls auch Daten über zugelassene Anwendungen und/oder Container sowie zugehörige Prüfsummen speichert. Zwischen dem verwalteten Host bzw. dem darin enthaltenen 802.1X CS und dem Autorisierungsserver ist ein Containerauthentifikator vorhanden, welcher mit 802.1X CA bezeichnet ist. Des Weiteren ist eine Firewall FW vorhanden, welche Netzwerkverkehr von und zu dem verwalteten Host kontrolliert und steuert. Damit wird ein Zugriff insbesondere auf einen geschützten Server gesteuert, welcher untenstehend eingezeichnet ist. Die Firewall FW ist eine
Netzwerksteuerungskomponente. xRAC sieht beispielsweise eine Ausführungs- und Zugriffskontrolle für RACs auf verwalteten Hosts vor. Ein RAC wird dabei vorzugsweise authentifiziert und autorisiert, und zwar bevor eine Ausführung erfolgt. Fig. 7 zeigt einen AA-Vorgang für RACs mit 802.1X. Zuerst versucht ein Benutzer, ein RAC über den CMD zu starten (1 ), und der CMD weist den 802.1X CS für die AA an (2). Nach der erfolgreichen Authentifizierung (3) und Autorisierung antwortet der 802.1X AS mit Autorisierungsdaten bzw. einer Autorisierungsantwort über den 802.1X CA (4) zu dem 802.1X CS (4a). Der 802.1X CS informiert den CMD darüber, dass der RAC gestartet werden soll (4b). Zusätzlich informiert der 802.1X CA Netzwerksteuerungselemente über den autorisierten RAC. In diesem Beispiel wird die Firewall FW konfiguriert, um einen Zugriff auf einen geschützten Server zu erlauben (4c). Andere Beispiele sind SDN-Controller, welche SDN-Switches programmieren. Nunmehr kommunizieren der autorisierte RAC, jedoch nicht der verwaltete Host oder andere RACs mit dem geschützten Server (5).
AA für RACs führt zwei zusätzliche Vorteile im Vergleich zu bekannter
Anwendungsbereitstellung und Netzwerksicherheit ein. Zum einen schränkt AA für RACs eine RAC-Ausführung auf verwalteten Hosts auf vordefinierte RAC-Bilder und zugelassene Benutzer ein. Dies erlaubt Netzwerkbetreibern sicherzustellen, dass nur aktuelle und nicht modifizierte RAC-Bilder ausgeführt werden können. Dies verbessert Computer- und Netzwerksicherheit, da nur valide RAC-Bilder auf den verwalteten Hosts ausgeführt werden können. Zusätzlich sind Netzwerkbetreiber dazu in der Lage, RAC- Bilder auf verwaltete Hosts vorab zu verteilen, zum Beispiel durch Synchronisieren ihres Satzes von RAC-Bildern mit einer internen RAC-Ablage im Hintergrund. Benutzer haben dadurch alle verfügbaren RAC-Bilder auf verwalteten Hosts im Zugriff, sind jedoch nur dazu in der Lage, diese zu starten, nachdem sie durch AA autorisiert wurden. Schließlich hat jeder RAC eine global einheitliche IPv6-Adresse, welche verwendet werden kann, um Datenverkehr zu und von einem bestimmten RAC zu identifizieren. RAC-Autorisierungsdaten auf dem 802.1X AS beinhalten Informationen darüber, wie der Datenverkehr des RACs durch Netzwerkelemente gesteuert werden soll. Dies erlaubt eine Konfiguration von Netzwerkelementen bzw.
Netzwerksteuerungskomponenten vom Autorisierungsserver AS aus.
Insgesamt kann somit beispielsweise folgender Verfahrensablauf realisiert werden.
Zunächst werden von dem Containermanagementdaemon CMD als
Containermanagementkomponente Benutzerauthentisierungsdaten von dem Benutzer empfangen. Die Benutzerauthentisierungsdaten werden an den Containerantragsteller 802.1X CS weitergeleitet. Dieser erzeugt eine Autorisierungsanforderung, welche die Benutzerauthentisierungsdaten beinhaltet. In einer bevorzugten Ausführung erzeugt er ferner eine Prüfsumme des Containers, wobei die Prüfsumme
Containerauthentisierungsdaten darstellt, welche auch mit in die
Autorisierungsanforderung aufgenommen werden.
Die Autorisierungsanforderung wird dann über den Containerauthentifikator 802.1X CA zu dem Autorisierungsserver 802.1X AS übertragen. Dieser gleicht sowohl die
Benutzerauthentisierungsdaten wie auch die Prüfsumme mit entsprechenden Datenbanken ab. Dies wird als Authentifizierung bezeichnet. Kommt er zu einem positiven Ergebnis, d.h. die Benutzerauthentisierungsdaten sind einem berechtigten Benutzer zugeordnet und die Prüfsumme zeigt an, dass Container und/oder
Anwendung nicht verändert wurden, erzeugt der Autorisierungsserver eine
Autorisierungsantwort mit einer positiven Freigabeinformation und gegebenenfalls auch mit Berechtigungsinformationen. Die Autorisierungsantwort wird über den
Containerauthentifikator 802.1X CA zu dem Containerantragsteller 802.1X CS zurückgesendet. Die Autorisierungsantwort wird dann an den
Containermanagementdaemon CMD weitergeleitet, welcher basierend darauf ermittelt, ob eine Anwendung ausgeführt werden darf, und gegebenenfalls mit welchen
Berechtigungen. Der Containermanagementdaemon startet bei entsprechend positiver Antwort die Anwendung und weist ihr die entsprechenden Berechtigungen zu. Sollte der Autorisierungsserver jedoch den Benutzer nicht authentifizieren können, oder sollte er den Benutzer zwar authentifizieren können, jedoch eine fehlende Berechtigung feststellen, so erzeugt der Autorisierungsserver eine Autorisierungsantwort mit einer negativen Freigabeinformation und sendet diese entsprechend zurück.
Des Weiteren wird nach erfolgtem Start der Anwendung dem Container RAC eine eindeutige Netzwerkadresse, beispielsweise eine IPv6-Adresse, zugewiesen. Diese Adresse wird der Firewall FW mitgeteilt. Des Weiteren teilt der Containerauthentifikator 802.1X CA der Firewall FW Netzwerkfreigabeinformationen bezüglich des Containers RAC mit, welche in Form von Netzwerkfreigabedaten vom Autorisierungsserver 802.1X AS stammen. Die Firewall FW steuert dann Datenverkehr von und zu dem Container RAC in Abhängigkeit von den Netzwerkfreigabeinformationen und identifiziert den Container dabei anhand seiner IPv6-Adresse. Dadurch kann beispielsweise ein Zugriff auf den geschützten Server kontrolliert werden. Hierzu ist die Firewall FW vorliegend so angeordnet, dass jeglicher Datenverkehr von und zu dem geschützten Server durch die Firewall FW verläuft. Zwischen dem Container und dem geschützten Server kann insbesondere ein geschützter Kanal, insbesondere ein VPN-Kanal, ausgebildet werden. Dadurch können ausgetauschte Daten gegen Veränderung und unbefugtes Mitlesen geschützt werden.
Die Autorisierungsanforderung von dem Containerantragsteller 802.1X CS zu dem Autorisierungsserver 802.1X AS beinhaltet somit insbesondere
Benutzerauthentisierungsdaten (UAND) und Containerauthentisierungsdaten (CAND). Der Autorisierungsserver 802.1X AS authentifiziert den Benutzer und verifiziert die Integrität des RAC-Bilds. Wenn das Bild valide ist und der Benutzer authentifiziert ist und wenn der Benutzer die Erlaubnis zum Ausführen des RAC hat, antwortet der Autorisierungsserver 802.1X AS dem Containerauthentifikator 802.1X CA mit
Autorisierungsdaten bzw. einer Autorisierungsantwort. Zum Ausführen der
Entscheidung kann beispielsweise ein neues Datenmodell verwendet werden, welches in Fig. 8 dargestellt ist. Es weist beispielhaft Benutzerprofile (1 ), RAC-Profile (2) und Gruppen (3) auf, welche definieren, ob ein bestimmter Benutzer dazu ermächtigt ist, einen bestimmten RAC auszuführen. Benutzerprofile (1 ) beinhalten
Benutzerauthentisierungsdaten (UAND), welche verwendet werden zum Authentisieren des Benutzers. Beispiele sind Zugangsdaten, beispielsweise Benutzername und Passwörter. RAC-Profile (2) beinhalten Containerauthentisierungsdaten (CAND) und Containerautorisierungsdaten (CAZD). Das erste wird verwendet zum Verifizieren der Integrität des RAC durch Berechnen der kryptographischen Hash-Funktion über das RAC-Bild. CAZD beinhaltet alle Berechtigungen eines RAC, zum Beispiel ob es durch den anfragenden Benutzer gestartet werden kann und ob es berechtigt ist,
Netzwerkressourcen zu benutzen. Dies kann auch als Autorisierungsantwort bezeichnet werden. In dem dargestellten Beispiel ist es dem RAC erlaubt, spezifizierte
Netzwerkressourcen zu benutzen. Die AA-Daten des beschriebenen Modells werden in dem Autorisierungsserver 802.1X AS gespeichert. Das Datenmodell ist ein Beispiel, welches einfach zur Unterstützung anderer Anforderungen erweitert werden kann. Der Containerantragsteller 802.1 X CS authentifiziert RACs mit dem Autorisierungsserver 802.1X AS über den Containerauthentifikator 802.1 X CA. Er sendet UAND und CAND zu dem Autorisierungsserver 802.1X AS und empfängt CAZD von dem
Containerauthentifikator 802.1X CA.
Die in Fig. 7 gezeigten Komponenten verwalteter Host, Containerauthentifikator, Autorisierungsserver, Firewall und geschützter Server können als jeweilige
Computereinheiten angesehen werden. Die gesamte Anordnung stellt eine
Netzwerkanordnung dar, welche dazu konfiguriert ist, ein hierin beschriebenes
Verfahren auszuführen.
Fig. 9 illustriert den Vorgang für AA aus der Perspektive des Containerantragstellers 802.1X CS. Dieser läuft auf dem verwalteten Host, bietet eine Schnittstelle für den CMD und ist mit der IP-Adresse oder URL des Containerauthentifikators 802.1X CA konfiguriert, so dass er AA initiieren kann. In (1 ) fragt der Benutzer beim CMD an, einen bestimmten RAC auf dem verwalteten Host zu starten. Die Anfrage beinhaltet UAND. Der CMD frägt bei dem Containerantragsteller 802.1X CS an, ob dies dem Benutzer gestattet werden kann (2). Die Anfrage beinhaltet UAND und CAND, welche durch den CMD erhalten werden, wobei CAND ad hoc als Prüfsumme des Containers RAC oder von dessen Containerbild berechnet wird. Der Containerantragsteller 802.1X CS initiiert AA durch Etablieren einer EAPoUDP-Sitzung mit dem Containerauthentifikator 802.1X CA. Danach wird eine Autorisierung mit dem Autorisierungsserver 802.1X AS über den Containerauthentifikator 802.1 X CA durchgeführt (3). Beispielsweise kann in älteren Ausführungen von 802.1X eine Backend-Authentifizierung über EAPoRADIUS durchgeführt werden, wobei Frontend-Autorisierung durch EAPoUDP ausgeführt wird. Im Fall einer erfolgreichen Autorisierung empfängt der Containerantragsteller 802.1X CS CAZD von dem Containerauthentifikator 802.1X CA (4). Dann erlaubt der
Containerantragsteller 802.1 X CS dem CMD, das RAC zu starten (5).
Der Containerauthentifikator 802.1X CA leitet AA-Daten zwischen dem
Containerantragsteller 802.1X CS und dem Autorisierungsserver 802.1X AS weiter. Ferner informiert er Netzwerksteuerungselemente über autorisierte RACs.
In Schritt (1 ) von Fig. 10 werden zur Authentifizierung Authentisierungsdaten über EAP zwischen dem Containerantragsteller 802.1X CS und dem Autorisierungsserver 802.1X AS transportiert. Zwischen dem Containerantragsteller 802.1X CS und dem
Containerauthentifikator 802.1X CA werden die EAP-Daten über UDP übertragen (EAPoUDP) und zwischen dem Containerauthentifikator 802.1X CA und dem
Autorisierungsserver 802.1X AS werden sie über RADIUS übertragen. Somit ist es eine Aufgabe des Containerauthentifikators 802.1X CA, den Tunnel für EAP-Daten zu modifizieren. Ferner gibt nach der erfolgreichen Authentifizierung der
Autorisierungsserver 802.1X AS CAZD über RADIUS zu dem Containerauthentifikator 802.1X CA zurück (2), welcher dann den Containerantragsteller 802.1X CS über die erfolgreiche Autorisierung informiert (3a). Während der konventionelle 802.1X A lediglich Ports auf einem Switch für autorisierte Geräte öffnet, informiert der
Containerauthentifikator 802.1 X CA allgemeine Netzwerksteuerungselemente über autorisierte RACs. Diese können Ports auf einem Switch, Firewalls (3b) oder SDN- Controller (3c) sein. Der Firewall wird dann derart programmiert, dass er allen ausgehenden Verkehr mit der IP-Adresse des RACs durchlässt und der SDN-Controller weist SDN-Switches an, jeglichen Verkehr mit der IP-Adresse des RACs durchzulassen, sofern entsprechende Berechtigungen erteilt wurden. Spezifischere Flussdeskriptoren werden typischerweise nicht benötigt, können aber implementiert werden.
Nachfolgend werden unterschiedliche Einsatzszenarien der hier offenbarten bzw.
erfindungsgemäßen Vorgehensweise beschrieben.
Zunächst wird auf einem Webbrowser in Hochsicherheitsumgebungen eingegangen. Dies kann beispielsweise für Forschungseinrichtungen, staatliche Institutionen oder Krankenhäuser relevant sein, welche mit hochsensitiven Daten arbeiten und ihr internes Netzwerk vom Internet abschirmen müssen. Jedoch werden trotzdem Webbrowser für unterschiedliche Aktivitäten benötigt. Es wird vorgeschlagen, Webbrowser als RACs auf verwalteten Hosts einzusetzen. Die Isolation von RACs verhindert, dass bösartige Benutzer den Internetzugriff missbrauchen, um interne Informationen nach außen zu bringen oder das interne Netzwerk durch infektiöse Downloads kontaminieren. Die Netzwerkflusskontrolle von RACs stellt sicher, dass nur der Webbrowser das Internet erreichen kann. Wenn der Datenverkehr des RACs verschlüsselt ist, zum Beispiel bei DNS-Anfragen und Websitedaten, können Netzwerksteuerungselemente immer noch eine Paketfilterung basierend auf der IP-Adresse des RAC durchführen.
Des Weiteren wird auf Anwendungen eingegangen, welche mit vertraulichen Daten arbeiten, zum Beispiel betreffend Forschungsaktivitäten, medizinische Dokumentation oder öffentliche Stellen. Dabei muss häufig auf vertrauliche Daten von Servern zugegriffen werden. Wenn derartige Anwendungen als RACs auf verwalteten Hosts wie hierin beschrieben bereitgestellt werden, können nur legitime Benutzer auf diese Server zugreifen. Das Isolationsmerkmal des RACs verhindert, dass entfernte Hacker auf den Server zugreifen. Normalerweise bekommen sie einen Systemzugriff durch Gateways, welche durch einen Virus oder ein Trojanisches Pferd bereitgestellt werden, wobei derartige Schadsoftware üblicherweise über Browserdownloads oder E-Mail-Anhänge eingefangen wird, was mit RACs nicht möglich ist. Ferner können bösartige Benutzer von legitimen Anwendungen Hacker-Tools verwenden, um einen Zugriff zu dem Server zu erhalten und um Informationen davon preiszugeben, was nicht möglich ist in der digitalen Domäne mit einer isolierten Anwendung. Die Isolation von RACs verhindert, dass bösartige Benutzer oder Anwendungen den Server angreifen. Die
Netzwerkflusskontrolle stellt sicher, dass der Server nur durch legitime RACs und Benutzer erreicht werden kann, jedoch nicht durch andere RACs oder den verwalteten Host selbst. xRAC erweitert die Vorteile, welche allgemein von Virtualisierung und
Containervirtualisierung bekannt sind und weiter oben beschrieben wurden. Zusätzlich kann xRAC garantieren, dass nur valide Container auf verwalteten Hosts ausgeführt werden, und dass sie nur durch legitime Benutzer verwendet werden können. Somit führt xRAC AA (Authentifizierung und Autorisierung) für Anwendungen ohne den Bedarf zur Modifizierung derselben aus, was ein besonderer Vorteil für ältere Anwendungen ist. Ferner kann der Containerauthentifikator 802.1X CA Netzwerksteuerungselemente derart konfigurieren, dass autorisierte RACs Zugriff auf geschützte Netzwerkressourcen haben. RACs ermöglichen diese Steuerung, weil jeglicher Netzwerkverkehr eines RAC durch eine einzige IPv6-Adresse identifiziert wird. Dies ist ein besonderer Vorteil, da in heutigen Netzwerken keine Information über legitimen Fluss besteht und zahlreiche Anwendungsflüsse die gleiche IP-Adresse haben können. Anwendungen können sogar aufgrund von Verschlüsselung unsichtbar sein. Somit wird durch xRAC eine Lösung für das gravierende Problem der Steuerung von legitimem Verkehr gegeben. xRAC ist dabei flexibel, da es softwaredefinierte Netzwerkzugriffssteuerung durch Interaktion mit anderen Netzwerksteuerungselementen implementiert. Insbesondere ist es nicht abhängig von spezifischen Technologien oder darauf eingeschränkt.
Nachfolgend wird ein Prototyp von Implementierungen von xRAC diskutiert.
Fig. 1 1 zeigt eine Testumgebung. Der verwaltete Host führt RACs aus. Ein SDN-Switch verbindet den verwalteten Host, einen geschützten Webserver und einen öffentlichen Webserver und ist durch einen SDN-Controller gesteuert. Auf dem SDN-Controller läuft der 802.1X CA als SDN-Anwendung, welche mit einem 802.1X AS kommuniziert.
Dabei kann eine verschachtelte Virtualisierung eingesetzt werden, d.h. eine virtuelle Maschine (VM) verkapselt alle Teile der Testumgebung einschließlich des verwalteten Hosts. Dieser Ansatz erlaubt es, dass die gesamte Testumgebung auf andere
Hardware Plattformen migriert wird. Vorliegend wurde für einen Test KVM-Hypervisor mit QEMU für hardwareassistierte Virtualisierung und libvirt für die Orchestrierung eingesetzt. Der verwaltete Host, beide Webserver und ein RADIUS-Server laufen als verschachtelte VMs mit Ubuntu 17.04. Ein Open vSwitch dient als SDN-Switch, welcher durch einen Ryu-SDN-Controller gesteuert wird. Es wird vorliegend Docker in Version 17.05 als Containervirtualisierungsplattform zum Implementieren von RACs verwendet. Der Docker-CMD wird derart konfiguriert, dass jedes RAC eine weltweit eindeutige IPv6-Adresse bekommt, welche durch andere Netzwerkhosts erreichbar ist. Fig. 12 zeigt die angewandte Netzwerkkonfiguration. Es ist voreingestellt, dass RACs nur eine Link-Local-IPv6-Adresse erhalten. Deshalb wird ein festes IRnd-Subnetz mit routbaren Adressen für RACs aufgesetzt. Der verwaltete Host ist vorliegend mit dem IPv6-Subnetz 2001 :db8::1 1 : 0/ 1 16 konfiguriert und die RACs erhalten eine IPv6-Adresse aus diesem Bereich. Der erste RAC erhält 2001 :db8: : 1 1 : 1 und der zweite RAC erhält 2001 :db8::1 1 :2. Der Dockerdaemon fügt automatisch Routen zu einer Routing-Tabelle des Systems hinzu und ermöglicht IPv6-Forwarding, so dass jeglicher Verkehr zu dem IPv6-Subnetz über ein dockerO-lnterface geroutet werden kann. Um die RACs von anderen Netzwerk-Hosts erreichbar zu machen, wird vorliegend ein NDP Proxy Daemon verwendet. Er leitet L2-Adressauflösung für IPv6- Adressen der RACs weiter, d.h. er überwacht benachbarte Anfragen auf RAC-Adressen und antwortet mit einer MAC-Adresse des verwalteten Hosts. Danach werden Pakete empfangen, welche einen RAC adressieren, und durch den Docker-Host über das dockerO-Gerät zu dem bestimmten RAC weitergeleitet.
Der 802.1X CS ist vorliegend als Plug-in für das Docker Authorization Framework implementiert, welches weiter oben beschrieben wurde. Das Plug-in ist in Python programmiert und verwendet eine Flask-Bibliothek zum Implementieren eines REST- Interfaces. Fig. 13 zeigt den Autorisierungsvorgang. In (1 ) frägt der Benutzer den CMD an, einen Container zu starten. Die Anfrage beinhaltet UAND, zum Beispiel bestehend aus einem Benutzernamen und einem Passwort. Das Docker Authorization Framework definiert einen zweistufigen Autorisierungsvorgang, wobei vorliegend lediglich der zweite Schritt benötigt wird. Die erste Autorisierungsanfrage (2) beinhaltet nur minimale Daten, zum Beispiel den Namen des RAC-Bilds. Da die vorliegende Implementierung lediglich auf dem zweiten Autorisierungsschritt basiert, korrespondiert der 802.1X CS zu einer Erlaubnis als Voreinstellung. Die zweite Autorisierungsanfrage (3) beinhaltet UAND und CAND. Der 802.1X CS führt Authentifizierung mit dem 802.1X AS durch den 802.1X CA wie obenstehend beschrieben durch (3). In (4) gibt der 802.1X AS CAZD zurück, welches zu dem 802.1X CS im Fall einer erfolgreichen AA weitergeleitet wird.
Der 802.1X CA ist vorliegend als SDN-Anwendung für den Ryu-SDN-Controller programmiert. Der 802.1X A, welcher aus dem Stand der Technik bekannt ist, wird durch das Hinzufügen einer Unterstützung für Authentifizierung mit dem 802.1X CS unter Verwendung von EAPoUDP erweitert. Der 802.1X CA öffnet einen UDP-Socket auf Port 5995 und wartet auf Verbindungen von dem 802.1X CS. Der 802.1X CA kann immer noch als älterer 802.1X A fungieren, welcher AA für Netzwerk-Hosts in altem 802.1X über EAPoL ausführt. Als Beispiel für eine Netzwerksteuerung mit xRAC wird ein eingeschränkter MAC-Iernender Switch implementiert. Er lernt MAC-Adressen von verbundenen Hosts, leitet jedoch Pakete lediglich weiter, wenn die IP-Adressen von Sender und Empfänger in einer Whitelist sind. Die Whitelist beinhaltet statische
Einträge, zum Beispiel für öffentliche Server, und dynamische Einträge, welche durch den 802.1X CA nach dem Empfang von CAZD von dem 802.1X AS modifiziert werden können. Der eingeschränkte MAC-Iernende Switch wird durch Erweiterung der L2 schaltenden SDN-Anwendung von dem Ryu SDN Controller Framework implementiert.
Des Weiteren wird die häufig verwendete Software FreeRADIUS als 802.1X AS verwendet, wobei ein AA-Datenmodell erweitert wird, um CAND und CAZD zu implementieren. In FreeRADIUS können zusätzliche Attribute für AA und einfache Merkmale unter Verwendung von spezifischen Attributen implementiert werden, welche in der unlang-Verarbeitungssprache definiert sind. Das definierte AA-Datenmodell kann einfach erweitert werden und kann durch Hinzufügen von mehreren Vendor-Specific Attributes (VSAs) modifiziert werden.
Zwei Webserver VMs in der Testumgebung betreiben einen Python-Webserver, welcher HTML-Dateien über HTTP liefert. Der geschützte Webserver mit der statischen IPv6- Adresse 2001 :db8::aa:0 liefert eine HTML-Seite mit dem Satz„protected content“. Der öffentliche Webserver mit der statischen IPv6-Adresse 2001 :db8::bb:0 liefert eine HTML-Seite mit dem Satz„public content“.
Zum Nachweis der Funktionalität wurden mit der beschriebenen Testumgebung
Experimente durchgeführt.
Die Experimente betrachten insbesondere die Kommunikation zwischen dem
verwalteten Host, einem bestimmten RAC, dem geschützten Webserver und dem öffentlichen Webserver. Dabei wird ein wget-Tool als RAC verkapselt, um Dateien unter Verwendung von HTTP zu empfangen. In den folgenden Experimenten wird der RAC verwendet, um eine HTML-Datei von sowohl dem geschützten wie auch dem
öffentlichen Webserver anzufragen. Es werden UAND, CAND und CAZD auf dem RADIUS-Server hinzugefügt, um einem bestimmten Benutzer zu erlauben, den RAC auszuführen und auf den geschützten Webserver zuzugreifen.
Es werden die in Fig. 14 dargestellten Experimente durchgeführt. Vor dem Ausführen des RAC wird gezeigt, dass der verwaltete Host die Öffentlichkeit erreichen kann, jedoch nicht den geschützten Webserver. Deshalb wird eine ICMP-Echoanfrage von dem geschützten Host zu der IRnd-Adresse von sowohl dem öffentlichen Webserver wie auch dem geschützten Webserver gesendet. Der öffentliche Webserver ist ohne Autorisierung erreichbar (1 a), jedoch schlägt ein Versuch, den geschützten Webserver zu erreichen, fehl (1 b). Nun wird demonstriert, dass die Integrität von RACs während einer Authentifizierung verifiziert wird, d.h. dass ein RAC mit einer divergierenden Prüfsumme nicht gestartet werden kann. Es wird ein weiteres RAC-Bild erzeugt, welches eine gepatchte Version von wget verkapselt und versucht, dies zu starten, und zwar unter Verwendung der Benutzerzugangsdaten wie auf dem RADIUS-Server definiert. Die Autorisierung schlägt fehl, d.h. der RAC kann nicht auf dem verwalteten Host gestartet werden. Nun wird demonstriert, dass der korrekte RAC gestartet werden kann und dass er den geschützten Webserver nach erfolgreichem AA erreichen kann. Nach dem Eingeben eines Kommandos zum Starten des RAC wird dieser authentifiziert und autorisiert, wie zuvor beschrieben (2a). Der SDN-Controller empfängt CAZD und programmiert den SDN-Switch zum Erlauben von Forwarding von Paketen zwischen dem RAC und dem geschützten Webserver (2c). Nun ist der RAC dazu in der Lage, die empfangene HTML-Datei von dem geschützten Webserver zu empfangen. Ein Versuch, die gleiche HTML-Datei mit wget direkt von dem verwalteten Host abzurufen, schlägt fehl (2e), d.h. der geschützte Webserver kann durch den RAC, jedoch nicht durch den verwalteten Host erreicht werden.
Zusammengefasst ist festzustellen, dass xRAC vorgeschlagen wird, ein Konzept für die Ausführung von Zugriffskontrolle von Restricted Application Containers (RACs) auf verwalteten Clients. Es beinhaltet Authentifizierung und Autorisierung (AA) für RACs derart, dass nur aktuelle RAC-Bilder durch zugelassene Benutzer ausgeführt werden können. Ferner wird die Autorisierung erweitert auf geschützte Netzwerkressourcen, und zwar derart, dass autorisierte RACs auf diese zugreifen können.
Datenverkehrsteuerung wird durch die Tatsache vereinfacht, dass jeglicher Verkehr eines RAC durch seine IPv6-Adresse identifiziert wird. Die Architektur von xRAC wird vorgestellt und es wird durch eine Prototypenimplementierung gezeigt, dass xRAC mithilfe von standardisierter Technologie, Protokollen und Infrastruktur aufgebaut werden kann. Ein Prototyp von xRAC verwendet Docker als
Containervirtualisierungsplattform zum Verteilen und Ausführen von RACs, und eine Signalisierung basiert auf 802.1 X-Komponenten. Modifikationen können vorgenommen werden an einem Supplicant, einem Authentifikator und einem Autorisierungsserver, so dass sowohl Benutzer- wie auch Container-AA-Daten ausgetauscht werden können. Ferner wird der Containerauthentifikator erweitert, um benötigte
Netzwerksteuerungselemente über autorisierte RACs zu informieren. xRAC unterstützt softwaredefinierte Netzwerksteuerung und verbessert die Netzwerksicherheit ohne Modifizierung von Kernkomponenten von Anwendungen, Hosts und Infrastruktur.
Erwähnte Schritte des erfindungsgemäßen Verfahrens können bevorzugt in der angegebenen Reihenfolge ausgeführt werden. Auch eine andere Reihenfolge ist jedoch möglich, sofern dies technisch sinnvoll ist. Das erfindungsgemäße Verfahren kann in einer seiner Ausführungen, beispielsweise mit einer bestimmten Zusammenstellung von Schritten, in der Weise ausgeführt werden, dass keine weiteren Schritte ausgeführt werden. Es können jedoch grundsätzlich auch weitere Schritte ausgeführt werden, auch solche welche nicht erwähnt sind.
Es sei darauf hingewiesen, dass in den Ansprüchen und in der Beschreibung Merkmale in Kombination beschrieben sein können, beispielsweise um das Verständnis zu erleichtern, obwohl diese auch separat voneinander verwendet werden können. Der Fachmann erkennt, dass solche Merkmale auch unabhängig voneinander mit anderen Merkmalen oder Merkmalskombinationen kombiniert werden können.
Rückbezüge in Unteransprüchen können bevorzugte Kombinationen der jeweiligen Merkmale kennzeichnen, schließen jedoch andere Merkmalskombinationen nicht aus.

Claims

Patentansprüche
1. Verfahren zum selektiven Ausführen eines Containers (RAC), der eine
Anwendung beinhaltet, wobei das Verfahren folgende Schritte aufweist:
Empfangen von Benutzerauthentisierungsdaten (UAND) durch eine
Containermanagementkomponente (CMD),
Weiterleiten der Benutzerauthentisierungsdaten (UAND) an einen
Containerantragsteller (CS),
Senden, durch den Containerantragsteller (CS), einer Autorisierungsanforderung an einen Autorisierungsserver (AS), wobei die Autorisierungsanforderung zumindest die Benutzerauthentisierungsdaten (UAND) beinhaltet,
Empfangen, durch den Containerantragsteller (CS), einer Autorisierungsantwort (CAZD) von dem Autorisierungsserver (AS), wobei die Autorisierungsantwort (CAZD) zumindest eine Freigabeinformation beinhaltet, welche entweder einen positiven oder einen negativen Wert annehmen kann,
Weiterleiten der Autorisierungsantwort (CAZD) an die
Containermanagementkomponente (CMD),
Entscheiden, durch die Containermanagementkomponente (CMD), ob der Container (RAC) auszuführen ist, wobei der Container (RAC) auszuführen ist wenn die Freigabeinformation einen positiven Wert hat, und wobei der Container (RAC) nicht auszuführen ist wenn die Freigabeinformation einen negativen Wert hat,
nur wenn der Container (RAC) auszuführen ist, Starten und Ausführen des Containers (RAC).
2. Verfahren nach Anspruch 1 ,
wobei der Autorisierungsserver (AS) die Freigabeinformation zumindest basierend auf den Benutzerauthentisierungsdaten (UAND) bestimmt.
3. Verfahren nach einem der vorhergehenden Ansprüche,
wobei der Autorisierungsserver (AS) die Benutzerauthentisierungsdaten (UAND) mit einer Anzahl von Benutzervorgabewerten vergleicht und die
Freigabeinformation nur dann auf einen positiven Wert setzt, wenn die
Benutzerauthentisierungsdaten (UAND) zu einem der Benutzervorgabewerte entsprechen.
4. Verfahren nach einem der vorhergehenden Ansprüche,
wobei der Containerantragsteller (CS) ein 802.1X Supplicant ist,
und/oder
wobei der Autorisierungsserver (AS) ein 802.1X Autorisierungsserver (AS) ist, und/oder
wobei die Containermanagementkomponente (CMD) ein Container Management Daemon ist.
5. Verfahren nach einem der vorhergehenden Ansprüche,
welches ferner folgenden Schritt aufweist:
Erzeugen von Containerauthentisierungsdaten (CAND) in Abhängigkeit von dem Container (RAC) oder einem Containerbild des Containers (RAC).
6. Verfahren nach Anspruch 5,
welches ferner folgenden Schritt aufweist:
Senden der Containerauthentisierungsdaten (CAND) an den
Autorisierungsserver (AS).
7. Verfahren nach einem der Ansprüche 5 oder 6,
wobei die Autorisierungsanforderung die Containerauthentisierungsdaten (CAND) beinhaltet.
8. Verfahren nach einem der Ansprüche 5 oder 6,
wobei die Containerauthentisierungsdaten (CAND) in einer zur
Autorisierungsanforderung separaten Nachricht an den Autorisierungsserver (AS) gesendet werden.
9. Verfahren nach einem der Ansprüche 5 bis 8,
welches ferner folgende Schritte aufweist:
Empfangen einer Nonce von dem Autorisierungsserver (AS), und
Verändern der Containerauthentisierungsdaten (CAND) basierend auf der Nonce, bevor die Containerauthentisierungsdaten (CAND) an den
Autorisierungsserver (AS) gesendet werden.
10. Verfahren nach einem der Ansprüche 5 bis 9,
wobei die Containerauthentisierungsdaten (CAND) als Prüfsumme des
Containers (RAC) oder des Containerbilds bestimmt werden.
1 1 . Verfahren nach Anspruch 10,
wobei die Prüfsumme nach dem Empfangen der Benutzerauthentisierungsdaten (UAND) berechnet wird.
12. Verfahren nach einem der Ansprüche 5 bis 9,
wobei die Containerauthentisierungsdaten (CAND) eine Identifikationsnummer des Containers (RAC) sind.
13. Verfahren nach Anspruch 12,
wobei die Containermanagementkomponente (CMD) dazu konfiguriert ist, eine eindeutige Zuordnung zwischen Identifikationsnummer und Container (RAC) sicherzustellen.
14. Verfahren nach einem der Ansprüche 5 bis 13,
wobei der Autorisierungsserver (AS) die Freigabeinformation zumindest basierend auf den Containerauthentisierungsdaten (CAND) bestimmt.
15. Verfahren nach einem der Ansprüche 5 bis 14,
wobei der Autorisierungsserver (AS) die Containerauthentisierungsdaten (CAND) mit einer Anzahl von Containervorgabewerten vergleicht und die
Freigabeinformation nur dann auf einen positiven Wert setzt, wenn die
Containerauthentisierungsdaten (CAND) zu einem der Containervorgabewerte entsprechen.
16. Verfahren nach einem der vorhergehenden Ansprüche,
wobei die Autorisierungsantwort (CAZD) eine Berechtigungsinformation beinhaltet,
wobei die Anwendung mit Rechten ausgeführt wird, welche basierend auf der Berechtigungsinformation festgelegt werden.
17. Verfahren nach einem der vorhergehenden Ansprüche,
welches ferner folgenden Schritt aufweist:
Zuweisen einer Netzwerkadresse zu dem Container (RAC).
18. Verfahren nach Anspruch 17,
wobei die Netzwerkadresse von der Containermanagementkomponente (CMD) zugewiesen wird.
19. Verfahren nach einem der Ansprüche 17 oder 18,
wobei die Autorisierungsanforderung die Netzwerkadresse beinhaltet.
20. Verfahren nach einem der Ansprüche 17 oder 18,
wobei die Containermanagementkomponente (CMD) die Netzwerkadresse separat zur Autorisierungsanforderung versendet.
21 . Verfahren nach einem der vorhergehenden Ansprüche,
wobei die Autorisierungsanforderung über einen Containerauthentifikator (CA) zu dem Autorisierungsserver (AS) gesendet wird,
und/oder
wobei die Autorisierungsantwort (CAZD) über einen Containerauthentifikator (CA) von dem Autorisierungsserver (AS) empfangen wird.
22. Verfahren nach Anspruch 21 ,
wobei der Containerauthentifikator (CA) ein 802.1X Authenticator ist.
23. Verfahren nach einem der Ansprüche 21 oder 22,
welches ferner folgende Schritte aufweist:
Erzeugen, durch den Containerauthentifikator (CA), einer
Netzwerkfreigabeinformation basierend auf der Autorisierungsantwort (CAZD), und
Senden, durch den Containerauthentifikator (CA), der
Netzwerkfreigabeinformation an eine Netzwerksteuerungskomponente (FW), wobei die Netzwerksteuerungskomponente (FW) Datenverkehr zu und/oder von dem Container (RAC) basierend auf der Netzwerkfreigabeinformation freigibt oder blockiert.
24. Verfahren nach Anspruch 23,
wobei der Autorisierungsserver (AS) die Autorisierungsantwort mit
Netzwerkfreigabedaten erzeugt, und
wobei der Containerauthentifikator (CA) die Netzwerkfreigabeinformation basierend auf den Netzwerkfreigabedaten erzeugt.
25. Verfahren nach Anspruch 24,
wobei der Autorisierungsserver die Netzwerkfreigabedaten abhängig von den Benutzerauthentisierungsdaten (UAND) und/oder den
Containerauthentisierungsdaten (CAND) erzeugt.
26. Verfahren nach einem der Ansprüche 23 bis 25,
wobei die Netzwerksteuerungskomponente (FW) so angeordnet ist, dass jeglicher Datenverkehr zu und von dem Container (RAC) und/oder zu und von einem geschützten Server durch die Netzwerksteuerungskomponente (FW) geleitet wird.
27. Verfahren nach einem der Ansprüche 23 bis 26,
wobei die Netzwerksteuerungskomponente (FW) ein Gateway ist, welcher zwei Netzwerke verbindet.
28. Verfahren nach einem der Ansprüche 17 bis 20 und einem der Ansprüche 23 bis 27,
wobei der Containerauthentifikator (CA) die dem Container (RAC) zugewiesene Netzwerkadresse an die Netzwerksteuerungskomponente (FW) sendet, und wobei die Netzwerksteuerungskomponente (FW) den Datenverkehr basierend auf der Netzwerkadresse freigibt oder blockiert.
29. Verfahren nach Anspruch 28,
wobei die Netzwerkadresse von der Containermanagementkomponente (CMD) an den Containerauthentifikator (CA) gesendet wird.
30. Verfahren nach einem der Ansprüche 23 bis 29,
wobei zwischen dem Container (RAC) und einem Netzwerkelement ein durch die Netzwerksteuerungskomponente (FW) verlaufender geschützter
Kommunikationskanal ausgebildet wird.
31 . Verfahren nach Anspruch 30,
wobei der geschützte Kommunikationskanal Ende-zu-Ende-verschlüsselt ist.
32. Verfahren nach einem der Ansprüche 30 oder 31 ,
wobei der geschützte Kommunikationskanal ein VPN-Kanal ist.
33. Verfahren nach einem der Ansprüche 30 bis 32,
wobei der Autorisierungsserver (AS) Informationen und/oder Schlüssel zum Aufbau des geschützten Kommunikationskanals an den Containerantragsteller (CS) liefert.
34. Verfahren nach Anspruch 33,
wobei die Informationen und/oder Schlüssel zum Aufbau des geschützten Kommunikationskanals in der Autorisierungsantwort (CAZD) enthalten sind.
35. Verfahren nach einem der Ansprüche 23 bis 34,
wobei die Netzwerkfreigabeinformation die Netzwerksteuerungskomponente dazu konfiguriert, dass ausschließlich Datenverkehr zu und von dem Container (RAC) oder mehreren Containern (RAC) durchgelassen wird.
36. Verfahren nach einem der vorhergehenden Ansprüche,
wobei Datenverkehr zwischen dem Container (RAC) und einem oder mehreren anderen Netzwerkelementen über ein geschütztes und/oder verschlüsseltes Netzwerk erfolgt.
37. Verfahren nach Anspruch 36,
wobei das geschützte und/oder verschlüsselte Netzwerk mittels MACsec verschlüsselt ist.
38. Verfahren nach einem der vorhergehenden Ansprüche,
wobei der Container (RAC) dazu konfiguriert ist, nur eine Anwendung
auszuführen.
39. Verfahren nach einem der vorhergehenden Ansprüche,
welches ferner folgenden Schritt aufweist:
Herunterladen der Anwendung und/oder des Containers (RAC) von einem Bereitstellungsserver.
40. Verfahren nach Anspruch 39,
wobei der Container (RAC) dazu konfiguriert ist, ausschließlich von dem
Bereitstellungsserver heruntergeladene Anwendungen auszuführen.
41 . Verfahren nach einem der vorhergehenden Ansprüche,
wobei die Autorisierungsanforderung und/oder die Autorisierungsantwort (CAZD) EAP-Nachrichten oder EAPoUDP-Nachrichten sind.
42. Netzwerkanordnung, welche zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche konfiguriert ist, aufweisend
eine erste Computereinheit, die zur Ausführung der
Containermanagementkomponente (CMD), des Containers (RAC) und des Containerantragstellers (CS) konfiguriert ist, und
eine zweite Computereinheit, die zur Ausführung des Autorisierungsservers (AS) konfiguriert ist,
wobei die Computereinheiten miteinander zum Datenverkehr vernetzt sind.
43. Netzwerkanordnung nach Anspruch 42,
welche zur Ausführung des Verfahrens nach Anspruch 21 oder einem davon abhängigen Anspruch konfiguriert ist, und
welche ferner eine dritte Computereinheit aufweist, die zur Ausführung des Containerauthentifikators (CA) konfiguriert ist.
44. Netzwerkanordnung nach Anspruch 43,
welche zur Ausführung eines Verfahrens nach Anspruch 23 oder einem davon abhängigen Anspruch konfiguriert ist, und
welche ferner eine vierte Computereinheit aufweist, die zur Ausführung einer Netzwerksteuerungskomponente (FW) konfiguriert ist.
45. Netzwerkanordnung nach Anspruch 44,
wobei die Netzwerksteuerungskomponente (FW) ein Gateway zwischen der Netzwerkanordnung und einem dazu separaten Netzwerk ist.
46. Netzwerkanordnung nach einem der Ansprüche 44 oder 45,
welche ferner einen geschützten Server aufweist, der ausschließlich über die Netzwerksteuerungskomponente (FW) ansprechbar ist.
EP20726745.1A 2019-05-13 2020-05-13 Verfahren zum selektiven ausführen eines containers und netzwerkanordnung Pending EP3970337A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019112485.9A DE102019112485A1 (de) 2019-05-13 2019-05-13 Verfahren zum selektiven Ausführen eines Containers
PCT/EP2020/063328 WO2020229537A1 (de) 2019-05-13 2020-05-13 Verfahren zum selektiven ausführen eines containers und netzwerkanordnung

Publications (1)

Publication Number Publication Date
EP3970337A1 true EP3970337A1 (de) 2022-03-23

Family

ID=70775339

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20726745.1A Pending EP3970337A1 (de) 2019-05-13 2020-05-13 Verfahren zum selektiven ausführen eines containers und netzwerkanordnung

Country Status (4)

Country Link
US (1) US20230006988A1 (de)
EP (1) EP3970337A1 (de)
DE (1) DE102019112485A1 (de)
WO (1) WO2020229537A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220027778A1 (en) * 2020-07-22 2022-01-27 International Business Machines Corporation Runtime environment determination for software containers
US20230131132A1 (en) * 2021-10-21 2023-04-27 Nokia Solutions And Networks Oy Securing containerized applications
CN115242528A (zh) * 2022-07-26 2022-10-25 明阳产业技术研究院(沈阳)有限公司 Kubernetes集群管理面板的登录方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9256467B1 (en) * 2014-11-11 2016-02-09 Amazon Technologies, Inc. System for managing and scheduling containers
US20180082053A1 (en) * 2016-09-21 2018-03-22 Telefonaktiebolaget Lm Ericsson (Publ) Application token through associated container
US10182076B2 (en) * 2016-09-27 2019-01-15 Red Hat, Inc. Method of managing system utilities access control
US10599499B2 (en) * 2017-09-30 2020-03-24 Oracle International Corporation API registry in a container platform providing property-based API functionality

Also Published As

Publication number Publication date
US20230006988A1 (en) 2023-01-05
DE102019112485A1 (de) 2020-11-19
WO2020229537A1 (de) 2020-11-19

Similar Documents

Publication Publication Date Title
AU2015328628B2 (en) Systems and methods for protecting network devices
US9258308B1 (en) Point to multi-point connections
AU2015381737B2 (en) Multi-tunneling virtual network adapter
DE102016124383B4 (de) Computersystem-Architektur sowie Computernetz-Infrastruktur, umfassend eine Mehrzahl von solchen Computersystem-Architekturen
EP3077952B1 (de) Verfahren zum zugriff auf einen datenspeicher eines cloud-computersystems
EP3970337A1 (de) Verfahren zum selektiven ausführen eines containers und netzwerkanordnung
US20170169225A1 (en) Methods and systems for providing and controlling cryptographic secure communications terminal operable in a plurality of languages
US20160142914A1 (en) Method of authenticating a terminal by a gateway of an internal network protected by an access security entity providing secure access
EP3078177B1 (de) Verfahren zum zugriff auf einen datenspeicher eines cloud-computersystems mit hilfe eines modifizierten domain name systems (dns)
EP3152874A1 (de) Routing-verfahren zur weiterleitung von task-anweisungen zwischen computersystemen, computernetz-infrastruktur sowie computerporgamm-produkt
DE102017212474A1 (de) Verfahren und Kommunikationssystem zur Überprüfung von Verbindungsparametern einer kryptographisch geschützten Kommunikationsverbindung während des Verbindungsaufbaus
DE60300661T2 (de) Initialisierung der Sicherheitsinformation in einem Netzwerkgerät
CN111628960B (zh) 用于连接至专用网络上的网络服务的方法和装置
Cisco Configuring Policy Enforcement Points
Cisco Configuring Policy Enforcement Points
Cisco Configuring Policy Enforcement Points
DE10107883B4 (de) Verfahren zur Übertragung von Daten, Proxy-Server und Datenübertragungssystem
Cisco Setting Up Devices for the VPN Solutions Center IPsec Environment
Hauser et al. xRAC: Execution and Access Control for Restricted Application Containers on Managed Hosts
KR102150484B1 (ko) 보안 강화를 위한 일회성 비밀번호 기반 접속 인증 시스템
DE102020129226B4 (de) Datenverarbeitungsvorrichtung und mobiles Kommunikationsgerät zum Aufbauen einer sicheren Kommunikationsverbindung über einen Zugangspunkt
DE102005050336B4 (de) Verfahren und Anordnung zum Betreiben eines Sicherheitsgateways
Carthern et al. Management Plane
Wu et al. RFC 9105 A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)
DE112021006422T5 (de) Deperimeterisierter zugriffssteuerdienst

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211213

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)