Patent Description:
<CIT> discloses creating an instance of a cloud computing environment.

<CIT> discloses securely managing a Docker image.

In various settings, it is beneficial to offer network services such as web applications based on sensitive information over a public network such as the internet. For instance, various services may be offered based on medical information about a patient, such as allowing a patient to inspect electronic medical records, or fill in online assessments, e.g., questionnaires. Services may also be offered based on other kinds of sensitive information, e.g., commercially sensitive information about a company may be used for benchmarking, accounting, or similar.

Offering services over a public network may have various security risks. In particular, attackers may try to compromise the confidentiality and/or integrity of the sensitive information in various ways. For example, attackers may attempt to break into a database server storing the sensitive information, e.g., about the patients or companies to which the services are offered. Or, attackers may attempt to break into a server offering the network service, e.g., the web application. In doing this, attackers may use various known techniques, e.g., using exploits in various software used by the servers and/or or using side channels. For example, the recent Spectre and Meltdown vulnerabilities of modem processors may allow an attacker with non-privileged access to a server to illegitimately obtain data from processes running concurrently at the server. Attackers may be external attackers but could also be insiders and/or legitimate users of the network service, e.g., a user trying to obtain or edit information of another user.

Hence, there may be a need to address various security risks relating to providing network services based on sensitive data.

A known technique to address at least some of these risks is containerization. For example, in <CIT>, techniques are disclosed for generating a virtual private container. The virtual private container defines a self-contained software environment comprising one or more analytic components configured to carry out specified analytic functions on data within the container. The analytic components are isolated to run within the container so as to prevent data sharing between containers. The virtual private container may access user data from external systems such as a HDFS store, for which a user of the service may provide authorization information, e.g., an identity.

A disadvantage of existing systems for offering network service systems based on sensitive data, such as <CIT>, is that they insufficiently address the various security risks relating to providing network services based on sensitive data. For example, sensitive data may be stored in an external storage such as a database. In existing systems, various devices may need to have access to this external storage. For example, virtual private containers deployed at various hosts may each need access to the external storage. Hence, the external storage may need to be publicly or at least widely accessible, and thereby becomes a tempting target for attacks. Moreover, the existing system of <CIT> does not allow writing updated data back to the storage. More generally, in existing systems, sensitive information about multiple users, or potential users, of the system may be stored in a central location that may not be sufficiently secured.

To better address one or more of these concerns, a container builder and/or a cloud service provider are proposed as defined in the independent claims. The container builder builds a container image for providing an individualized network service, e.g., a web application, based on sensitive data in a database. The inventors realized that exposure of the sensitive data may be limited if it is included in the container image. The database can be a private database of the container builder. The container builder retrieves the sensitive data from the database, builds the container image, and provides it for deployment to the cloud service provider. The container image comprises the sensitive data and instructions that, when deployed as a container, cause the container to provide the individualized network service based on the sensitive data. The cloud service provider receives such a container image for deployment and deploys it as a container.

This arrangement improves security, e.g., because the database may be less exposed; e.g., the cloud service provider and/or a container host at which the container is deployed does not need to access the database directly, so the database does not need to be available to them, e.g., it can be deployed at or near the container builder. Moreover, exposure of the container builder is limited, e.g., the container builder does need to accept incoming connections, may be behind a firewall, and/or may connect to the network only for providing the container image. Although the container host is more exposed, e.g., it may accept incoming network connections in order to offer the network service, it only stores a limited amount of data so the impact of a breach is smaller. Also, less network connectivity may be needed from the container host since it does not need to access an external source to obtain the sensitive data.

In an embodiment, the sensitive data comprises personal information about a user to whom the individualized network service is provided. In an embodiment, the personal information comprises an electronic medical record. In such embodiments, protection of sensitive information is particularly beneficial given the high sensitivity of the data.

In an embodiment, the container image terminates after a time limit and/or after use of the individualized network service is completed, further reducing exposure.

In an embodiment, the container builder obtains updated data, updated by the individualized network service, and stores it in the database. This way, the network service may not only use sensitive data from the database but also produce data for the database, without the database needing to be exposed externally. To improve protection, the container may encrypt the updated data. The container builder may also provide authentication information to an intended user of the individualized network service, such as a private address and/or a token, thereby reducing the risk of unauthorized access to the network service.

Further aspects of the invention concern a container builder method and a cloud service provider method. Embodiments of these methods may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both. Executable code for an embodiment of a method may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product comprises non-transitory program code stored on a computer readable medium for performing an embodiment of a method when said program product is executed on a computer.

In an embodiment, the computer program comprises computer program code adapted to perform all the steps of an embodiment of the container builder method or cloud service provider method when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium.

A further aspect of the invention concerns a computer-readable medium comprising data representing a container image for providing an individualized network service. The container image comprises sensitive data and instructions for providing the individualized network service based on the sensitive data, allowing the service to be provided with limited data exposure.

Another aspect of the invention provides a method of making the computer program available for downloading. This aspect is used when the computer program is uploaded into, e.g., Apple's App Store, Google's Play Store, or Microsoft's Windows Store, and when the computer program is available for downloading from such a store.

Further details, aspects, and embodiments of the invention will be described, by way of example only, with reference to the drawings. In the Figures, elements which correspond to elements already described may have the same reference numerals. In the drawings,.

While this invention is susceptible of embodiment in many different forms, there are shown in the drawings and will herein be described in detail one or more specific embodiments, with the understanding that the present disclosure is to be considered as exemplary of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

Further, the invention is not limited to the embodiments, and the invention lies in each and every novel feature or combination of features described herein or recited in mutually different dependent claims.

Before discussing the detailed embodiments of <FIG>, various aspects of the invention are first discussed with respect to <FIG>.

As a motivating example to explain various aspects of embodiments set out below, consider a web-based portal for patient assessment. For example, patients may use such a portal to provide information about their health status after receiving a certain kind of therapy. Such a system is typically based on medical data, e.g., questions asked to the patient may depend on the particular treatment received and/or the user may be able to inspect at least parts of their electronic medical record. Moreover, the system may also produce new data, e.g., information about health status provided by the patient, that needs to be stored and further processed, e.g., provided to healthcare professionals involved in the therapy. Both the medical information used by the portal and the information produced by the portal are typically sensitive personal information about the patient. Apart from this, also the software used, e.g., a clinical decision support algorithm deciding which questions to ask or which advice to give, may be a sensitive asset. Hence, security measures are needed to ensure that the data and/or software does not fall into the wrong hands.

<FIG> shows an implementation of a system based on sensitive data on a cloud server <NUM>, such as the web-based portal for patient assessment discussed above, that does not make use of private databases or container images. A web application may run on such a cloud server <NUM>, e.g., a remote cloud server, and provide network services to clients, e.g., using a request-response pattern. Cloud server <NUM> may comprise, e.g., application software <NUM> providing network service and one or more databases. For instance, the databases may include an authentication database <NUM>, e.g., comprising cryptographic keys, passwords, tokens, etc.; a record database <NUM>, e.g., comprising electronic medical records or other sensitive information; and/or an application database <NUM>, e.g., containing application data. A user may access a web application offered by application software <NUM>, e.g., offered via HTTP interface <NUM>, using a web browser. Application software <NUM> may also provide one or more web services, e.g., REST services, via web API <NUM>. Before accessing the application, a user may need to identify himself to application software <NUM>, e.g., wherein application software <NUM> authenticates credentials given by the user based on information in authentication database <NUM>. Application software <NUM> may retrieve and/or store sensitive information in record database <NUM>, e.g., the user can retrieve and/or update records of record database <NUM> as part of the application.

In a system such as the one of <FIG>, data of multiple users may be stored on cloud server <NUM>, e.g., in databases <NUM> and/or <NUM>. Encryption and/or other security measures may be used to improve data safety, privacy, and/or to prevent data breaches, exploits, or other attempts to get access to user data. Could server <NUM> may have the security risk that, if a hacker is able to compromise cloud server <NUM>, data of all users, potentially thousands or millions of users, may be stolen, used for other attacks, and/or made public.

To minimize the risk of data breaches, access to application software <NUM> may be highly controlled, potentially leading to a degraded user experience. Still, there may be various security-related problems in systems arranged similarly to cloud server <NUM>. For instance, besides the invalidation of single user accounts, for example, due to stolen passwords, also a programming error in application software <NUM> or an exploit may allow an attacker to get access to a large number of accounts and/or large amounts of data from record database <NUM>. The inventors recognized as a cause of this problem that user data, e.g., user data about multiple users comprised in record database <NUM>, and application software <NUM> reside in the same place, or at least that application software <NUM> potentially has access to user data about multiple users. Moreover, cloud server <NUM> may also comprise, for instance, an administration console <NUM>, e.g., accessible via an SSH interface <NUM>, and the presence of such an additional access channel may amount to a further security issue. Various embodiments described below may reduce risk of data breaches and/or avoid the need for additional administration channels.

Various embodiments relate to providing an individualized network service based on sensitive data. The inventors realized that, in order to offer a particular service to a particular user, not all parts of system <NUM> may be needed, e.g., system <NUM> may be individualized to particular user and/or for a particular service. <FIG> shows an example of an embodiment of an individualized network service <NUM>. Individualization may refer to providing a particular service to one or more particular users, e.g., particular persons, systems, or devices, based on sensitive data specific to the one or more particular users, e.g., a subset of data from a database. For example, the data may comprise data that is specific to the particular service and/or particular user or set of users. For example, the data may be data about the user or users, and/or data to which the user or users specifically has access. For example, the individualized network service may use the sensitive data as an input and/or provide updated data as an output.

As an example, the individualized network service may be a web application such as the web-based patient assessment portal that was discussed above, individualized in order to allow a particular patient or group of patients to fill in a dedicated questionnaire. As another example, the individualized web service may be a web service, e.g., a REST web service, individualized for a particular user. The individualized network service does not need to be based on HTTP, in fact, the individualized network service may be any kind of network service that is individualized based on sensitive data, e.g., offered using known protocols such as FTP, IMAP, POP, or non-IP-based protocols, e.g., NetBIOS-based.

Providing an individualized web service to a user based on sensitive data specific to that user according to various embodiments may have as an advantage that data specific to other users may be effectively shielded from the individualized web service, decreasing the risk for a particular user that the data of that user is inadvertently accessed by another user or third party. In an embodiment, the sensitive data may comprise personal information about a user. The individualized network service may be offered to that user. In an embodiment, the personal information comprises an electronic medical record. Individualization is particularly relevant in such settings due to the particular sensitivity of data and/or particular legal requirements on processing personal information and medical data in particular.

As mentioned, an individualized network service <NUM> may not require all data and/or components of cloud server <NUM> to operate. For example, authentication database <NUM> may only need to contain authentication information <NUM> of a particular user, or of a plurality of particular users. Record database <NUM> may only need to contain data <NUM> specific to the user or plurality of users. Similarly, application database <NUM> may only need to contain data <NUM> needed for the particular service, e.g., images, UI elements, or other kinds of data used for the particular service but not for other services that may be offered to the same or other users at another point in time. Application software may also only need to contain components <NUM>, e.g., software modules, libraries and the like, needed for the particular service. To the outside, only interface <NUM> for the particular service may need to be offered, e.g., no web API or SSH interfaces may be needed in this case. Compared to cloud service <NUM>, individualized network service <NUM> may be regarded as a stripped-down version, although in practice the individualized network service may be constructed either by removing components of a full cloud server deployment, or by building up the individualized network service from scratch using only a selection of components, or using a combination of the two. An advantage of making such an individualized network service available as compared to cloud server <NUM> is that a potential data leakage will, at worst, reveal credentials and/or data specific to the user or users for which the network service was individualized. Moreover, less interfaces and/or less software decreases the risk of vulnerabilities being exploited and/or valuable software assets being compromised.

In various embodiments, individualization of network service is provided by means of containerization technology. When using containerization, applications are typically packaged into container images. For instance, a container image may comprise a self-contained package for running an application on a container host, e.g., comprising one or more components, e.g., application components and/or runtime components for running the application. For example, the container image may be for running the application on a container platform. In some embodiments, the runtime components do not comprise an operating system, decreasing image size and improving performance. In other embodiments, the runtime components may comprise an operating system, making the image more self-contained. Components in the container image may comprise, e.g., a web server, a database server, a data analytics toolkit, a simulator, etcetera. Generally, using container images may have as an advantage that they are lightweight yet self-contained, e.g., they contain one or more of application code, runtimes, system tools, libraries, and/or settings to run the application. For example, this may eliminate the need to separately install and/or maintain libraries for applications running on the container host.

Various containerization technologies are available today based on various types of container images. For example, Docker technology allows Docker container images to be built based on a configuration file called a "Dockerfile" and then deployed as containers, e.g., on systems running the Docker Engine or on various cloud providers available on the market such as Heroku, Amazon Elastic Container Service, etcetera. Other types of container images can be JAR files; WAR files; Heroku slug files; disk images, e.g., for running on a hypervisor; archives such as ZIP or TAR files, e.g., for running in a chroot environment, etcetera. Depending on the containerization technology used and software available on the target platform, various software libraries may either be included in the container image or be used as provided by the platform, e.g., a container image for a Ruby on Rails application may include the application itself, but also the Ruby on Rails platform, the web server, system libraries, and/or the operating system, e.g., depending on which of these components are available on the deployment platform. Various cloud service providers are available that implement containerization technology by accepting container images for deployment and deploying them as containers on their infrastructure, e.g., Heroku and Amazon Elastic Container Service are examples of cloud service providers that accept Docker container images among other types of container images.

In particular, various embodiments involve a container builder. A container builder, also known as a container factory or container builder device, may be a device for building container images, e.g., container images that may be deployed using one of the containerization techniques discussed above. An example of an embodiment of such a container builder is schematically shown in <FIG>. Container builder <NUM> in <FIG> builds container images that are for providing an individualized network service based on sensitive data in a database. Container builder <NUM> has access, e.g., through a data interface, to a private database <NUM> comprising sensitive data, e.g., a record database as above. Container builder <NUM> may also have access to various other source of data and/or software, e.g., an authentication database <NUM>, an application database <NUM>, and/or a set of software components <NUM> for offering the individualized network service. At a high level, container builder <NUM> builds container images and provides them for deployment to a cloud service provider, e.g., using a communication interface. The container images, e.g., container image <NUM>, <NUM> or <NUM>, may be based on one or more of databases <NUM>, <NUM>, and <NUM>, and software components <NUM>. For example, container image <NUM> may comprise sensitive data <NUM> based on which the individualized network service is provided, e.g., obtained from private database <NUM> and/or other databases, and instructions that, when deployed as a container, cause the container to provide the individualized network service based on the sensitive data. For instance, the instructions may comprise a subset <NUM> of software components for offering the individualized network service from set <NUM> of software components, and similarly for the other container images. The personal information may for instance be stored in a database within the container image. Various embodiments of container builders are described below.

Interestingly, container builder <NUM> may have access to relatively large amounts of information, e.g., database <NUM> comprising information concerning multiple users, but it may only have a limited network exposure, e.g., it does not need to provide services to users directly. On the other hand, containers deployed from the container images built by container builder <NUM>, e.g., container mages <NUM>, <NUM> and <NUM>, may need to be more exposed than container builder <NUM> since they need to offer the individualized network service to the user. However, they store and/or have access to only a subset, typically only a small portion, of the information that container builder <NUM> has access to. This arrangement provides an overall improvement in data protection since the exposure of sensitive data is decreased.

<FIG> schematically shows an example of an embodiment of a network service system <NUM> for offering an individualized network service. Network service system <NUM> may comprise a container builder <NUM>, e.g., a container builder device. Network service system <NUM> may comprise a cloud service provider <NUM>, e.g., a cloud service provider device, for deploying container images as containers. The containers may be deployed at cloud service provider <NUM> itself and/or at separate container hosts managed by the cloud service provider, e.g., container host devices. Shown in the figure is one such container host <NUM>, but in an embodiment, network service system <NUM> comprises multiple container hosts managed by cloud service provider <NUM>, and in another embodiment network service system <NUM> does not comprise container hosts other than cloud service provider <NUM> itself.

As discussed further below, <FIG> shows functional units, e.g., units <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM>, that may be functional units of processors of the respective devices, e.g., of a processor of container builder <NUM> or cloud service provider <NUM>. For example, container builder <NUM> of <FIG> may be used as a blueprint of a possible functional organization of the processor. The processor is not shown separate from the units in the figures. For example, the functional units of container builder <NUM> may be wholly or partially be implemented in computer instructions that are stored at container builder <NUM>, e.g., in an electronic memory of container builder <NUM>, and are executable by a microprocessor of container builder <NUM>. In hybrid embodiments, functional units are implemented partially in hardware, e.g., as coprocessors, e.g., crypto coprocessors, and partially in software stored and executed on container builder <NUM>, and similarly for the other devices in the various figures.

The various devices of network service system <NUM> may cooperate to provide an individualized network service to a user device <NUM> based on sensitive data <NUM> in a database <NUM>. In an embodiment, the sensitive data comprises personal information about a user; for example, network service system <NUM> may be for providing the individualized network service to this user, e.g., though user device <NUM>. In an embodiment, the personal information comprises an electronic medical record. In an embodiment, the sensitive data does not comprise authentication or authorization information, e.g., the sensitive data does not comprise database credentials. User device <NUM> may be any device with network connectivity, e.g., a laptop, a desktop computer or a mobile device such as a mobile phone or a tablet, e.g., when the individualized service is a web application; or a server, e.g., when the individualized service is a web service.

In an embodiment, the individualized network service is provided to multiple users, e.g., a strict subset of potential users of the service, e.g., corresponding to a strict subset of entries of database <NUM>. For example, the number of users may be configurable. This may allow for a dynamic security/efficiency trade-off between the extremes of a network service individualized to a single user, with higher security and lower efficiency, and a network service offered to all users at the same time, with lower security and higher efficiency.

The various devices of system <NUM> communicate with each other over a computer network <NUM>. The computer network may be an internet, an intranet, a LAN, a WLAN, etc. Computer network <NUM> may be the Internet. The computer network may be wholly or partly wired, and/or wholly or partly wireless. For example, the computer network may comprise Ethernet connections. For example, the computer network may comprise wireless connections, such as Wi-Fi, ZigBee, and the like. The devices comprise a connection interface which is arranged to communicate with other devices of system <NUM> as needed. For example, the connection interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, <NUM> or <NUM> antenna. For example, container builder <NUM> and cloud service provider <NUM> may comprise communication interfaces <NUM> and <NUM>, respectively. Computer network <NUM> may comprise additional elements, e.g., a router, a hub, etc..

Network service system <NUM> may make use of containerization technology to limit exposure of sensitive data. Container builder <NUM> may build a container image <NUM> and provide it to cloud service provider <NUM> for deployment. Cloud service provider <NUM> may deploy container image <NUM>, for example, on a container host <NUM>. Interestingly, container image <NUM> may comprise sensitive data <NUM> and instructions that, when deployed as a container, cause the container to provide the individualized network service based on sensitive data <NUM>. This may enable cloud service provider <NUM> to provide the cloud service on a host that does not itself have access to database of sensitive information <NUM>, thereby limiting exposure of database <NUM>.

Various technologies to operate cloud service providers and/or container hosts per se are known from the literature. Typically, container host <NUM> is configured to run a container platform <NUM> and one or more containers, e.g., containers <NUM>, <NUM>, and <NUM>, on top of this container platform. In an embodiment, container platform <NUM> runs on top of an operating system and containers <NUM>, <NUM>, <NUM> do not comprise an operating system themselves. For example, container platform <NUM> may comprise Docker Engine and containers <NUM>, <NUM>, and <NUM> may be Docker containers. In an embodiment, container platform <NUM> comprises a hypervisor, and one or more containers <NUM>, <NUM>, <NUM> may be virtual machines, e.g., deployed from a container image comprising a disk image. In this case containers <NUM>, <NUM>, <NUM> may comprise an operating system. In an embodiment, container platform <NUM> may comprise a Unix-like operating system, and one or more containers <NUM>, <NUM>, <NUM> may comprise software operating in a chroot jail. For example, a container image for such a chroot jail may comprise a set of files that the software in the chroot jail has access to. In an embodiment, <NUM>, <NUM>, <NUM> are dynos of Heroku platform <NUM>.

As discussed above, cloud service provider <NUM> may deploy the container image on cloud service provider <NUM> itself rather than on a separate container host. In such a case, cloud service provider <NUM> acts as a container host itself, e.g., cloud service provider <NUM> itself may run a container platform and one or more containers on top of this container platform, for instance, as described above. In such embodiments, service provider <NUM> is configured to deploy container <NUM> as a container on top of this container platform.

Cloud service provider <NUM> may also be a management node managing one or more container hosts. For example, cloud service provider <NUM> may be configured as a master node of a Kubernetes cluster, container host <NUM> and/or other container hosts being configured as compute nodes of the Kubernetes cluster. Or, cloud service provider <NUM> may be configured as a swarm manager of a Docker swarm, container host <NUM> and/or other container hosts being configured as nodes of the Docker swarm. Cloud service provider <NUM> may also be, e.g., an OpenStack controller node, container host <NUM> and/or other container hosts being configured as compute nodes of the OpenStack cluster. Using multiple container hosts increases scalability but may also make it less predictable at which host a container image will be deployed as a container and/or which other containers run on the same container host, complicating attacks across containers running in the same infrastructure. In some embodiments, cloud service provider <NUM> may be a conventional cloud service provider <NUM> such as Heroku, Amazon Elastic Container Service, Amazon EC2, and the like.

In particular, cloud service provider <NUM> may comprise a communication interface <NUM> configured for digital communication with container builder <NUM> and/or container host <NUM> and/or other devices of network service system <NUM>, e.g., using computer network <NUM>. Cloud service provider <NUM> also may comprise a builder handling unit <NUM> configured to receive a container image <NUM> using communication interface <NUM>, e.g., from container builder <NUM>. Cloud service provider <NUM> may further comprise a deployment unit <NUM> configured to deploy the container image as a container. For example, cloud service provider may deploy container image <NUM> at a container host such as container host <NUM>, or on a container platform operating on cloud service provider <NUM> itself. This may be transparent to container builder <NUM>, e.g., container builder <NUM> may not know, before and/or after deployment, at which particular host its container images are deployed.

Deployment of container image <NUM> may be initiated by container builder <NUM>. For example, container builder <NUM> may receive an instruction to build a container image for providing an individualized network service based on sensitive data. For instance, the instruction may comprise one or more of an identification of a network service, e.g., from a predefined set of multiple network services, and an identification of one or more intended users of the network service, where the users may for example be persons or other network entities, e.g., users related to which database <NUM> stores sensitive data. The instruction may for example be received from an external network entity, e.g., container builder <NUM> may periodically contact the external network entity to receive instructions; they may be received from a user of container builder <NUM>, for instance, via a user interface of container builder <NUM>; or they may be received from another component of container builder <NUM>, for example, a component that periodically monitors the database and/or the status of any deployed container images to determine that one or more individualized network services should be offered.

In some embodiments, the timeline for offering individualized network services may be relatively predictable. For instance, in a web-based patient assessment portal, a patient may be asked to fill in a survey periodically, e.g., every week or month. Moreover, the individualized network service may not be made available to the same set of users all the time, e.g., a patient is asked to fill in a monthly survey in three days so that, on average, only around a tenth of all patients have a survey waiting for them. Hence, in some embodiments, individualized network services are offered concurrently only to a subset of a set of potential users, e.g., a subset of users about which database <NUM> stores sensitive data. In such cases, offering individualized network services may be especially beneficial since sensitive data of users to which no service of offered, is unexposed.

In order to access database <NUM> comprising the sensitive data <NUM> on which container image <NUM> is based, container builder <NUM> may comprise a data interface <NUM>. Database <NUM> may store sensitive data relating to multiple users, e.g., multiple sensitive records, each record representing sensitive data concerning one or more users. For example, a record may comprise a piece of medical information about a particular person, e.g., a patient. Database <NUM> may be a locally stored database. Database <NUM> may also be an external database, wherein data interface <NUM> connects to the external database. For example, when sensitive information from the database is needed, data interface <NUM> may be asked for it, after which data interface <NUM> may retrieve it, e.g., from the external database. The latter may be transparent to the rest of device <NUM>. Database <NUM> may be configured as a private database of the container builder, e.g., a local database. For example, database <NUM> may be accessible through, or only through, a local area network (LAN), or database <NUM> may be a local database running at container builder <NUM>. In particular, database <NUM> may not be accessible through computer network <NUM>, or at least, may not be accessible by one or more of container host <NUM>, cloud service provider <NUM> and user device <NUM>. This may advantageously decrease exposure of database <NUM>.

Container builder <NUM> may further comprise a data handling unit <NUM> configured to retrieve sensitive data <NUM> from database <NUM> using data interface <NUM>. For example, upon receiving a request to provide a particular individualized network service based on sensitive data relating to a particular user, data handling unit <NUM> may select a subset of data, e.g., records, relating to the user, and retrieve the subset of data from database <NUM>.

Container builder <NUM> may also comprise an image handling unit <NUM> configured to build container image <NUM> for providing the individualized network service. As discussed above, various types of container images <NUM> and tools for building container images, e.g., container images for providing a particular network service, are known and may be applied here. For instance, container image <NUM> may be a Docker container image, image handling unit <NUM> being configured to build container image <NUM> based on a Dockerfile using Docker, e.g., using the "docker build" command or similar. Building container image <NUM> may comprise selecting software components, e.g., modules and/or libraries, needed for providing the particular individualized network service, e.g., as discussed with reference to <FIG> above. Only selecting needed software components may have as an advantage that the amount of possibilities by which a container based on it may be compromised and/or the value of software assets that may be extracted from the container is decreased, e.g., only a limited set of clinical decision support or MRI reconstruction components relevant to the case at hand may need to be included, leaving non-included components unexposed.

Image handing unit <NUM> may be configured to build container image <NUM> based on a configuration, e.g., a configuration file, and optionally also to generate this configuration. For example, in embodiments based on Docker, the configuration may comprise the Dockerfile. Image handling unit <NUM> may for instance generate the configuration by instantiating a template configuration, e.g., by selecting parts of such a template and/or by filling in fields. For instance, this may be based on the particular network service to be offered and/or the particular user or users to whom the network service is to be offered. Image handling unit <NUM> may also re-use the same configuration, e.g., building an individualized container image <NUM> may comprise arranging various files referred to in the configuration based on the particular network service to be offered and/or the particular user or users to whom the service is to be offered. Various other image building tools may be similarly used, e.g., OpenStack's diskimage-builder or the jailkit tool to build a chroot environment.

As mentioned, container image <NUM> comprises sensitive data <NUM>. For instance, sensitive data may be included in container image <NUM> in the form of a local database, e.g., image handling unit <NUM> may add to container image <NUM> database software and instructions and/or data to set up the database software with sensitive data <NUM>. For example, the database software may be serverless database software such as sqlite. The included database may be a subdatabase of database <NUM>. For example, image handling unit <NUM> may set up the included database as a subset of tables, columns, and/or rows of database <NUM> that are needed to provide the individualized network service, e.g., including sensitive data <NUM>. For instance, the data may comprise credentials <NUM>, user data <NUM>, and/or service data <NUM> as discussed with reference to <FIG>. The software in container image <NUM>, e.g., instructions <NUM>, may be set up such that it connects to the local database, e.g., instead of connecting to remote database <NUM>. This may be transparent to the software in container image <NUM> accessing the database, e.g., other than adjusting the database connection parameters, no other adaptation of the software may be needed to make it use sensitive data <NUM> from container image <NUM> instead of from a remote database. However, this is not necessary, e.g., use of local sensitive data may also be achieved by adapting software of container <NUM> such that it makes use of, e.g., text files instead of a database or such that sensitive data <NUM> is hard-coded in the instructions. In an embodiment, container image <NUM> does not contain instructions that, when deployed as a container, cause the container to retrieve sensitive data from an external database. Generally, including sensitive data <NUM> in container image <NUM> may alleviate the need for cloud service provider <NUM> and/or container host <NUM> and/or user device <NUM> to access database <NUM>, improving security.

In an embodiment, container image <NUM> comprises termination instructions <NUM>. Termination instructions <NUM> may, when deployed as a container, cause the container to terminate after a time limit. This may have as an advantage that there is no need for notifications and/or periodic checks for termination. Another advantage may be that exposure of the service is not needlessly prolonged. Termination instructions <NUM> may instead or in addition cause the container to terminate after use of the individualized network service is completed. For example, the container terminates after a predefined number of successful accesses to the individualized network service, e.g., after a single access or after at least or at most three or ten accesses. For example, a container offering a web-based patient assessment portal may terminate after an assessment has been completed. Terminating after use may have as advantages that exposure of the service is not needlessly prolonged and/or that detection may be used as an indication, e.g., by container builder <NUM>, that use of the individualized network service is completed. Termination instructions <NUM> may also comprise instructions to delete certain data from the container, e.g., software modules comprising sensitive software assets or sensitive data that does not need to be kept, which may further reduce exposure of sensitive information.

In an embodiment, image handling unit <NUM> is configured to build container image <NUM> by first preparing the container image, e.g., before receiving a request to build the container image, and, upon receiving the request, customizing the container image based on the sensitive data <NUM>. For example, building container image <NUM> may comprise multiple build steps, preparing the container image comprising a first set of build steps and customizing the container image comprising a second set of build steps, the second set of build steps comprising a step of adding particular user credentials and/or sensitive data to the container image. Image handling unit <NUM> may also build the container image using placeholder data instead of the sensitive data <NUM> and then, after retrieving the sensitive data <NUM> from database <NUM>, replace the placeholder data with the sensitive data <NUM>. For example, the placeholder data may be comprised in one or more particular files of the container image. Image handling unit <NUM> may replace these particular files by individualized files based on sensitive data <NUM>. For example, these particular files may be text files or database files for database software, as discussed above. In any case, the amount of work performed while customizing may be relatively small, improving overall scalability.

Container builder <NUM> may further comprise a communication interface <NUM> configured for digital communication with cloud service provider <NUM> and/or other devices of network service system <NUM>, for example, through computer network <NUM> as explained in more detail above. In an embodiment, container builder <NUM> is connected to cloud service provider <NUM> behind a firewall <NUM>. For example, firewall <NUM> may comprise a network firewall controlling traffic between container builder <NUM> and other devices. In an embodiment, container builder does not accept incoming network connections from container builder <NUM> and/or container host <NUM> and/or user device <NUM>. For example, cloud service provider <NUM> may not be directly accessible at all for incoming connections from computer network <NUM>. Firewall <NUM> may alternatively or in addition comprise a host-based firewall, e.g., a host-based firewall running on container builder <NUM>, e.g., a firewall blocking some or all incoming connections from computer network <NUM>. Using a firewall may lead to further reduction in the exposure of sensitive data, e.g., sensitive data from database <NUM>. Container builder <NUM> may not need to be connected to computer network <NUM> continuously. In an embodiment, container builder <NUM> is configured to connect to computer network <NUM> before providing container image <NUM> for deployment and/or to disconnect from computer network <NUM> after providing container image <NUM>, further reducing its exposure.

Container builder <NUM> may also comprise a cloud handling unit <NUM> configured to provide container image <NUM> for deployment to cloud service provider <NUM> using communication interface <NUM>. For example, cloud handling unit <NUM> may upload container image <NUM> to cloud provider <NUM> and send an instruction to deploy the container image to cloud provider <NUM>, e.g., via SSH, a RESTful API or the like, e.g., when using Docker, using the "docker stack deploy" shell command or corresponding calls of the Docker Engine API. Cloud handling unit <NUM> may also store container image <NUM> in a private registry and instruct cloud service provider <NUM> to pull the image from the private registry and deploy it.

In all, various steps described above may result in an individualized network service being offered to user device <NUM> in such a way that sensitive data is less exposed. Container builder <NUM> may retrieve sensitive data <NUM> from private database <NUM> and put it in container image <NUM>; however, no other device, e.g., neither cloud service provider <NUM> nor container host <NUM> nor user device <NUM> may be able to access database <NUM> directly, e.g., because of firewall <NUM>. Container builder <NUM> provides container image <NUM> to cloud service provider <NUM> and cloud service provider deploys it at container host <NUM> such that container host <NUM> can offer the individualized service to user device <NUM>. Although these steps may result in some exposure of sensitive data <NUM> that is needed for the present individualized network service, other sensitive data in database <NUM>, e.g., relating to other users, may not be exposed, e.g., a compromise occurring during the offering of an individualized network service may have less impact on other users. Moreover, various containerization technologies may allow relatively good scalability, e.g., because an arbitrary number of container hosts may be used and/or its number dynamically adjusted, and/or because container hosts may allow to run similar or partially overlapping containers relatively efficiently.

<FIG> schematically shows an example of an embodiment of a network service system <NUM> involving updated data to be stored in the database. Network service system <NUM> may be network service system <NUM> as described above. For example, network service system <NUM> may comprise a private database <NUM> storing sensitive data <NUM>, e.g., a private database of a container builder <NUM>, and various components that allow to provide an individualized network service based on sensitive data.

In addition to using sensitive data, providing an individualized network service may also involve obtaining updated data updated by the individualized network service. For instance, the updated data <NUM> may comprise an input of a user of the individualized network service and/or a result of data processing by the container. The updated data may comprise sensitive updated data, for example, updates to sensitive data <NUM>. The updated data may comprise information about a user of the individualized network service, e.g., personal information, e.g., medical information. Continuing with the motivating example of the web-based patient assessment portal above, a patient may be presented with various questions relating to their health, where the updated data comprises the answers to these questions. Generally, updated data arising from use of the individualized network service may comprise updates to the existing sensitive data based on which the service as offered and/or new data that was not stored in the database prior to the offering of the service. Various embodiments are discussed here in which updated data <NUM> is obtained by container builder <NUM> and stored in database <NUM>.

Network service system <NUM> may comprise a container host <NUM>, e.g., container host <NUM> of <FIG>. Container host <NUM> may comprise a container <NUM>. Container <NUM> may run on top of a container platform <NUM>. A container image, e.g., container image <NUM>, may be deployed as container <NUM> to provide the individualized network service based on sensitive data <NUM>. Network service system <NUM> may also comprise a user device <NUM> to which the service is offered, e.g., user device <NUM> of <FIG>. Similarly to <FIG>, the present figure shows functional units, e.g., units <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM>, that may be functional units of processors of respective devices.

In particular, network service system <NUM> may comprise a container builder <NUM>, e.g., container builder <NUM> of <FIG>. Container builder <NUM> may be for providing an individualized network service based on sensitive data <NUM>. Container builder <NUM> may comprise data interface <NUM> for accessing database <NUM>. Container builder <NUM> may also comprise a communication interface <NUM> for connecting with a cloud service provider <NUM>, e.g., via a computer network <NUM>. Container builder <NUM> may further comprise a data handling unit configured to retrieve sensitive data <NUM> from database <NUM> using data interface <NUM>; an image handling unit <NUM> configured to build container image <NUM> comprising the sensitive data; and/or a cloud handling unit <NUM> configured to provide container image <NUM> for deployment to cloud service provider <NUM> using communication interface <NUM>. Container image <NUM> may comprise instructions that, when deployed as a container, cause the container to provide the individualized network service based on sensitive data <NUM> comprised in container image <NUM>.

Network service system <NUM> may further comprise a cloud service provider <NUM> for use with a container builder, e.g., cloud service provider <NUM> of <FIG>. Cloud service provider <NUM> may comprise a communication interface <NUM> for connecting with container builder <NUM> and/or container host <NUM>. Cloud service provider <NUM> may further comprise a builder handling unit <NUM> configured to receive from container builder <NUM> using communication interface <NUM> a container image <NUM> for deployment. Cloud service provider <NUM> may also comprise a deployment unit <NUM> configured to deploy container image <NUM> as a container. In the example embodiment shown in <FIG>, container image <NUM> is deployed as a container <NUM> on container host <NUM>, but as discussed above, container host <NUM> may also coincide with cloud service provider <NUM>.

As a consequence of providing the individualized network service, container <NUM> may comprise updated data <NUM>, as discussed above. For example, one or more files deployed in container <NUM> may have been modified and/or deleted, and/or one or more new files may have been created in container <NUM>. For example, the updated data may comprise updates to one or more files comprised in container image <NUM>. Updated data may be stored in a memory and/or in a storage of container <NUM>.

In various embodiments, container builder <NUM> obtains updated data <NUM> of container <NUM>. For example, image handling unit <NUM> may be configured to include in container image <NUM> instructions for container <NUM> to collect updated data <NUM> and provide it to container builder <NUM> and/or cloud service provider <NUM>. For example, container <NUM> may upload the collected updated data <NUM> to a remote storage <NUM>, e.g., a remote database or remote filesystem; container <NUM> may e-mail the collected updated data to an e-mail address accessible by container builder <NUM>, or the like. Remote storage <NUM> is shown here as a separate network entity but may also, e.g., be an externally accessible storage of cloud service provider <NUM>. Container builder <NUM> may be configured to obtain updated data <NUM> accordingly, e.g., by retrieving it from remote storage <NUM>. Updated data <NUM> may also be obtained from container <NUM>, e.g., by container builder <NUM>, cloud service provider <NUM>, or container platform <NUM>. For example, container <NUM> stores updated data <NUM> during processing in an externally accessible storage, e.g., a storage accessible by cloud service provider <NUM> or container platform <NUM>, such as a Docker bind mount or volume, a network share, etcetera. Cloud service provider <NUM> or container platform <NUM> may in such a case be configured to collect updated data <NUM> and provide it to container builder <NUM>, e.g., by uploading it to remote storage <NUM>. For example, collecting the updated data may be performed by a post-processing script performed after termination of the container <NUM>, which may have as an advantage that fewer customizations to software in the container are needed.

Updated data <NUM> may be provided to container builder <NUM> in various formats, e.g., in the form of one or more database files, text files, etcetera. In an embodiment, cloud handling unit <NUM> retrieves an updated container image from cloud service provider <NUM> and image handling unit <NUM> extracts updated data <NUM> from the updated container image. For instance, the updated container image may be of a similar format as container image <NUM>. This may have as an advantage that less customization of the software in the container needed, e.g., providing the updated data <NUM> may be transparent to the software in the container.

In various embodiments, updated data <NUM> is encrypted upon collection with an encryption key <NUM> and cloud handling unit <NUM> is configured to decrypt the obtained updated data <NUM> using a decryption key <NUM> corresponding to the encryption key <NUM>. For instance, image handling unit <NUM> may include in container image <NUM> encryption instructions <NUM> for encrypting collected updated data <NUM> upon collection using encryption key <NUM>, or cloud handling unit <NUM> may provide encryption key <NUM> to cloud service provider <NUM> and/or container host <NUM> for encryption upon collection. Image handling unit <NUM> may be configured to generate encryption key <NUM> and decryption key <NUM> or otherwise obtain them. Using encryption may decrease exposure of updated data <NUM>. In some embodiments, encryption key <NUM> and decryption key <NUM> are both the same symmetric key; in other embodiments, encryption key <NUM> and decryption key <NUM> form a public/private key pair. The latter has as an advantage that not even the party performing the encryption or a party compromising its key material can decrypt updated data <NUM> once it is encrypted.

Typically, cloud handling unit <NUM> obtains updated data <NUM> upon termination of container <NUM>. For example, cloud handling unit <NUM> may be configured to periodically check whether the container has terminated. For example, cloud handling unit <NUM> may contact cloud service provider <NUM> to obtain a status update regarding container <NUM>, builder handling unit <NUM> of cloud service provider <NUM> being configured to provide such status updates to container builder <NUM> upon request. Cloud handling unit <NUM> may also contact container <NUM> directly to obtain a status update, e.g., by attempting to access the individualized network service provided by container <NUM> or by contacting container <NUM> in another way. Presence of the updated data in storage <NUM> may also indicate termination to cloud handling unit <NUM>. Periodic checks by cloud handling unit <NUM> may have as an advantage that container builder <NUM> does not need to accept incoming connections to detect termination, e.g., it does not need to receive notifications. However, other options apart from the periodic checks described here may be used, e.g., cloud service provider <NUM> may be configured to notify container builder <NUM> upon termination of container <NUM>, e.g., using a RESTful API offered by container builder <NUM>, by e-mail, or using any appropriate notification mechanism. However, no checking for termination may be necessary, e.g., container <NUM> may be configured to terminate after a time limit as discussed above, cloud handling unit <NUM> being configured to retrieve updated data <NUM> after the time limit. Also, it may not be needed to wait for termination at all, e.g., cloud handling unit <NUM> may obtain updated data <NUM> from a running container.

Data handling unit <NUM> of container builder <NUM> may be configured to store updated data <NUM> in database <NUM> using data interface <NUM>. Storing updated data <NUM> may comprise checking a validity of updated data <NUM>. Data handling unit <NUM> may only store updated data <NUM> in database <NUM> if it is found valid. For instance, checking the validity may comprise checking that the updated data only comprises data related to an intended user of the individualized network service; checking that updated data <NUM> only comprises data related to the individualized network service; and/or checking that updated data <NUM> has not been tampered with, e.g., by verifying a checksum and/or digital signature on the data. For example, data handling unit <NUM> may assign an identifier to each container image provided for deployment, e.g., a unique identifier, e.g., randomly generated. Such an identifier may be included in container image <NUM>. Data handling unit <NUM> may further keep a list of entries, an entry comprising an identifier of a container image, a user or set of users for which it is individualized, and/or a specification of data fields that are allowed to be modified. Upon retrieval of updated data <NUM>, data handling unit <NUM> may obtain the identifier included in the corresponding container image, e.g., as part of the updated data <NUM>, and check that the updated data <NUM> relates to the user or set of users and/or specification of data fields of the corresponding entry. Checking updated data <NUM> may have as an advantage that even if the container providing the individualized network service is comprised, such a compromise may only affect data relating to the particular user and/or particular network service and/or may not affect the data validity.

Overall, the various embodiments described above and exemplified by the system shown in <FIG> may allow database <NUM> to be updated with updated data <NUM>. Updated data <NUM> may be provided, e.g., inserted or entered by user device <NUM>, to container <NUM>, as shown by a dashed line. The updated data <NUM> may then be obtained by container builder <NUM>, e.g., container <NUM> uploads it to a remote database, as shown by another dashed line, and container builder <NUM> downloads it from the remote database. Finally, container builder <NUM> may store the updated data <NUM> in database <NUM>. Hence database <NUM> may be updated without exposing it to remote access.

<FIG> schematically shows an example of an embodiment of a network service system <NUM> involving user authentication. Network service system <NUM> may comprise one or more of a container builder <NUM>, a cloud service provider <NUM>, a container host <NUM>, and a user device <NUM>.

For example, container builder <NUM> may be a container builder as described above, e.g., container builder <NUM> of <FIG> or container builder <NUM> of <FIG>. In particular, container builder <NUM> may comprise an image handling unit <NUM>, e.g., image handling unit <NUM> or image handling <NUM>. Although not shown, container builder <NUM> may also comprise a data interface, a data handling unit and/or a cloud handling unit, e.g., units <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM>.

Similarly, cloud service provider <NUM> may be a cloud service provider as described above, e.g., cloud service provider <NUM> or <NUM>, e.g., comprising a deployment unit <NUM> such as deployment unit <NUM> or deployment unit <NUM>. Although not shown in the figure, cloud service provider <NUM> may also comprise a builder handling unit, e.g., unit <NUM> or <NUM>.

Container host <NUM> may be container host <NUM> or <NUM>, e.g., comprising container <NUM> such as container <NUM> or <NUM>. User device <NUM> may be user device <NUM> or user device <NUM>. The devices may use a computer network <NUM> to communicate, e.g., computer network <NUM> or <NUM>. Similarly to <FIG>, the present figure shows functional units, e.g., units <NUM> and/or <NUM>, that may be functional units of processors of respective devices.

Image handling unit <NUM> of container builder <NUM> may arrange container <NUM> such that it provides access to the individualized network service only to users possessing certain authentication information. Image handling unit <NUM> may further provide this authentication information to an intended user of the individualized network service, e.g., to user device <NUM> or its owner. This may have the advantage of further restricting data exposure since an attacker may needs to undertake the additional effort of obtaining the authentication information. Various kinds of authentication information, or various combinations thereof, may be used, e.g., multi-factor authentication, e.g., two-factor authentication.

In an embodiment, the authentication information comprises a private address <NUM> for connecting to the container, e.g., a URL, a domain name, or similar. Private address <NUM> may be unique for a given user or set of users. For example, private address <NUM> may be a hidden subdomain. When providing container image <NUM> for deployment, container builder <NUM> may request cloud service provider <NUM> to deploy container image <NUM> at a private address. Cloud service provider <NUM> may deploy container image <NUM> at container host <NUM>, generate private address, e.g., "a0123. networkservice. com", and map the private address to the container, e.g., in a DNS entry. The private address may comprise a random port number, e.g., <NUM>, at which the network service, e.g., web application, may be deployed. Cloud service provider <NUM> may provide the private address to container builder <NUM>, or container builder <NUM> chooses or suggests at least part of the private address. In any case, container builder may instruct user device <NUM> to connect to private address <NUM>, e.g., using an email a link to the private address <NUM>, e.g., "http://a0123. networkservice. com:<NUM>/", e.g., an invitation to fill in a patient assessment. Private addresses are user-friendly while, by being hard to guess, make it harder to compromise the security of the system.

In an embodiment, the authentication information comprises a token <NUM>, e.g., a secret token. Container image <NUM> may comprise instructions <NUM> that, when deployed as a container, cause the container to verify that a connecting user possesses token <NUM>. For example, token <NUM> may be a random string, e.g., a random string with a minimum length or a minimum entropy, e.g., at least <NUM> or at least <NUM> characters or at least <NUM> or <NUM> bits of entropy, e.g., "XHnRRIdykv". For instance, image handling unit <NUM> may generate token <NUM> randomly. The container may be configured, e.g., to provide a web application only if it is accessed using the token, e.g., the token is included in the private address <NUM>, e.g., "http://a0123. networkservice. com:<NUM>/?token=XHnRRIdykv". Or, token <NUM> may be a parameter for an individualized web service/web API. The use of tokens may make it harder to compromise the system without placing a high burden on the user.

The examples of authentication information given above may be combined with each other and with other types of authentication information to further improve security. For instance, a user of a web application may be asked to log in with normal credentials, e.g., as explained with reference to <FIG>. Container image <NUM> may comprise credentials <NUM> of the intended user from an authentication database that would normally also be used for user authentication. Other types of authentication, e.g., using a hardware token, may be used instead or in addition. Interestingly, when normal authentication mechanisms are combined with authentication information provided by container builder <NUM>, the use of a container may be transparent to the user, e.g., the user may use the individualized network service in the same manner as if using a non-individualized network service like in <FIG>.

<FIG> shows an example of an embodiment of a network service system <NUM> in which an individualized network service provided by a container is combined with another network service, e.g., a non-individualized network service. Such embodiments may allow limiting exposure of sensitive data <NUM> without incurring unnecessary overhead, e.g., by applying containerization only if and when sensitive data <NUM> is actually used.

Shown in <FIG> is a cloud server <NUM>, e.g., cloud server <NUM> of <FIG>, e.g., offering a non-individualized network service through application software <NUM>. Cloud server <NUM> can be any traditional server offering a network service <NUM>, e.g., a web application, to a user device. Shown is also a user device <NUM> to which such a service is offered, shown here as a laptop for illustrative purposes only, e.g., user device <NUM>, <NUM>, or <NUM> as discussed above. As a motivating example, application software <NUM> may offer a web shop application to the user of user device <NUM>, which the user may use to select various items for purchase. While browsing, the application may not need sensitive data <NUM> such as the user's address and/or credit card information.

At a certain point, the application being offered may require access to sensitive information <NUM>. At this point, application software <NUM> may provide a redirect <NUM> redirecting user device <NUM> to container <NUM> running at container host <NUM>. Redirect <NUM> may comprise incoming information of application software <NUM> for container <NUM>. Container <NUM> is deployed from a container image built by a container builder <NUM> with access to database <NUM> comprising the sensitive information <NUM> as described above, e.g., container builder <NUM> may be container builder <NUM>, container builder <NUM>, or container builder <NUM>, as described above. For example, cloud server <NUM> may instruct container builder <NUM> to deploy a container, and container builder <NUM> may be configured to provide the container image for deployment. Preparing the container image beforehand and customizing the container image based on sensitive data <NUM>, as described above, may be particularly beneficial in this setting given the desire to minimize waiting time for the user. Having provided the container image for deployment, container builder <NUM> may then provide the address at which the individualized network service can be reached to cloud server <NUM>. Cloud server <NUM> may then redirect <NUM> user device <NUM> to this address. Alternatively, access to container <NUM> may be detected, e.g., by container platform <NUM> of container host <NUM>, at which point container builder <NUM> may provide the container image for deployment.

Being redirected to container <NUM>, user device <NUM> may now make use of the individualized network service provided by the container. Continuing with the example above, the user device <NUM> may be redirected by redirect <NUM> to container <NUM> for checking out the shopping card. Sensitive information <NUM> comprised in the container image in this case may include, for example, credit card information and/or address information about the user. Incoming information comprised in redirect <NUM> may comprise, e.g., the contents of the shopping cart. Container image <NUM> may provide the individualized network service, e.g., process the payment of the user. Having provided the individualized network service, container <NUM> may provide a redirect <NUM> redirecting user device <NUM> to a cloud server, e.g., back to cloud server <NUM>. Redirect <NUM> may comprise a return value of the individualized network service, e.g., in the payment example, indicating whether the payment was successful. User device <NUM> may continue using the web application, while container <NUM> based on sensitive information <NUM> may be cleaned up or terminated.

Hence, various embodiments shown schematically in <FIG> may allow to provide an application to a user device <NUM> that is partly based on information from database <NUM>, and in which the exposure of information from the database <NUM> is limited, while at the same time allowing parts of the application that do not need access to the database to be provided using different techniques such as a more traditional cloud server <NUM>.

<FIG> illustrates an exemplary hardware diagram <NUM> for implementing a container builder, a cloud service provider, a container host, or a user device. The exemplary hardware <NUM> may for instance correspond to any one of container builder <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>; cloud service provider <NUM>, <NUM> or <NUM>; container host <NUM>, <NUM>, <NUM>, or <NUM>; or user device <NUM>, <NUM>, <NUM>, or <NUM>. As shown, device <NUM> includes a processor <NUM>, memory <NUM>, user interface <NUM>, communication interface <NUM>, and storage <NUM> interconnected via one or more system buses <NUM>. It will be understood that Fig. 6a constitutes, in some respects, an abstraction and that the actual organization of the components of the device <NUM> may be more complex than illustrated.

The processor <NUM> may be any hardware device capable of executing instructions stored in memory <NUM> or storage <NUM> or otherwise processing data. As such, the processor may include a microprocessor, field programmable gate array (FPGA), application-specific integrated circuit (ASIC), or other similar devices. Processor <NUM> may be provisioned, e.g., within a cloud computing architecture, etc. Further examples are shown herein. Processor <NUM> may be implemented in a distributed fashion, e.g., as multiple sub-processors, e.g., sub-processor circuits.

The memory <NUM> may include various memories such as, for example L1, L2, or L3 cache or system memory. As such, the memory <NUM> may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read only memory (ROM), or other similar memory devices. It will be apparent that, in embodiments where the processor includes one or more ASICs (or other processing devices) that implement one or more of the functions described herein in hardware, the software described as corresponding to such functionality in other embodiments may be omitted. Part or all of the memory may be an electronic memory, magnetic memory, etc..

The user interface <NUM> may include one or more devices for enabling communication with a user such as an administrator. For example, the user interface <NUM> may include a touch screen, a display, a mouse, and/or a keyboard for receiving user commands. In some embodiments, the user interface <NUM> may include a command line interface or graphical user interface that may be presented to a remote terminal via the communication interface <NUM>.

The communication interface <NUM> may include one or more devices for enabling communication with other hardware devices. The communication interface may be a network interface. For example, the communication interface <NUM> may include a network interface card (NIC) configured to communicate according to the Ethernet protocol. The network interface may be to a local or wide area network, e.g., the Internet. Additionally, the communication interface <NUM> may implement a TCP/IP stack for communication according to the TCP/IP protocols. The communication interface may also be a storage interface to an internal or external data storage, a keyboard, an application interface (API), etc. Various alternative or additional hardware or configurations for the communication interface <NUM> will be apparent.

The storage <NUM> may include one or more machine-readable storage media such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media. Storage <NUM> may comprise multiple discrete memories together making up said storage. Storage <NUM> may also be a temporary memory, say a RAM. In the case of a temporary storage, said storage contains some means to obtain data before use, say be obtaining them over an optional network connection (not shown). In various embodiments, the storage <NUM> may store instructions for execution by the processor <NUM> or data upon with the processor <NUM> may operate. For example, the instructions may have been downloaded and/or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash. For example, the storage <NUM> may store a base operating system <NUM> for controlling various basic operations of the hardware <NUM>. The storage may also store instructions <NUM>-<NUM> for performing the functions of various units described above, e.g., data handling units, image handling units, cloud handling units, builder handling units, or deployment units according to various embodiments described herein. A storage may be distributed over multiple distributed sub-storages. For example, the storage may have volatile and a non-volatile part. Part of the storage may be read-only.

It will be apparent that various information described as stored in the storage <NUM> may be additionally or alternatively stored in the memory <NUM>. In this respect, the memory <NUM> may also be considered to constitute a "storage device" and the storage <NUM> may be considered a "memory. " Various other arrangements will be apparent. Further, the memory <NUM> and storage <NUM> may both be considered to be "non-transitory machine-readable media. " As used herein, the term "non-transitory" will be understood to exclude transitory signals but to include all forms of storage, including both volatile and non-volatile memories.

While device <NUM> is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, the processor <NUM> may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform steps or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where the device <NUM> is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, the processor <NUM> may include a first processor in a first server and a second processor in a second server. Device <NUM> may also be equipped with microprocessors and memories. Alternatively, the devices may, in whole or in part, be implemented in programmable logic, e.g., as field-programmable gate array (FPGA). The devices may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), e.g., an integrated circuit (IC) customized for their particular use.

In an embodiment, the container builder may comprise a data circuit, a processor circuit, and a communication circuit. In an embodiment, the cloud service provider may comprise a communication circuit and a processor circuit. The container builder may comprise one or more of a data handling circuit, an image handling circuit, and a cloud handling circuit. The cloud service provider may comprise one or more of a builder handling circuit and a deployment circuit. The circuits implement the corresponding units described herein. The circuits may be a processor circuit and storage circuit, the processor circuit executing instructions represented electronically in the storage circuits. The circuits may also be, FPGA, ASIC or the like.

The processor may be a processor circuit, which may be implemented in a distributed fashion, e.g., as multiple sub-processor circuits. A storage may be distributed over multiple distributed sub-storages. Part or all of the memory may be an electronic memory, magnetic memory, etc. For example, the storage may have volatile and a non-volatile part. Part of the storage may be read-only.

<FIG>, <FIG>, <FIG>, <FIG> show functional units that may be functional units of the processor <NUM>. For example, container builder <NUM> of <FIG> may be used as a blueprint of a possible functional organization of the processor. The processor is not shown separate from the units in the figures. For example, the functional units of container builder <NUM> may be wholly or partially be implemented in computer instructions that are stored at container builder <NUM>, e.g., in an electronic memory of container builder <NUM>, and are executable by a microprocessor of container builder <NUM>. In hybrid embodiments, functional units are implemented partially in hardware, e.g., as coprocessors, e.g., crypto coprocessors, and partially in software stored and executed on container builder <NUM>, and similarly for the other devices in the various figures.

Typically, the container builder, the cloud service provider, the container host, and the user device each comprise a microprocessor which executes appropriate software stored at the respective devices; for example, that software may have been downloaded and/or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash. The respective devices may also be equipped with microprocessors and memories. Alternatively, the devices may, in whole or in part, be implemented in programmable logic, e.g., as field-programmable gate array (FPGA). The respective devices may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), e.g., an integrated circuit (IC) customized for their particular use. For example, the circuits may be implemented in CMOS, e.g., using a hardware description language such as Verilog, VHDL etc..

<FIG> schematically shows an example of an embodiment of a container builder method <NUM> for building a container image. The container image is for providing an individualized network service based on sensitive data in a database. Container builder method <NUM> comprises:.

<FIG> schematically shows an example of an embodiment of a cloud service provider method <NUM> for use with a container builder according to an embodiment. Cloud service provider method <NUM> comprises:.

Many different ways of executing the methods are possible, as will be apparent to a person skilled in the art. For example, the order of the steps can be varied or some steps may be executed in parallel. Moreover, in between steps other method steps may be inserted. The inserted steps may represent refinements of the method such as described herein, or may be unrelated to the method. For example, steps <NUM> and <NUM> may be executed, at least partially, in parallel. Moreover, a given step may not have finished completely before a next step is started.

Embodiments of the methods may be executed using software, which comprises instructions for causing a processor system to perform method <NUM> or <NUM>. Software may only include those steps taken by a particular sub-entity of the system. The software may be stored in a suitable storage medium, such as a hard disk, a floppy, a memory, an optical disc, etc. The software may be sent as a signal along a wire, or wireless, or using a data network, e.g., the Internet. The software may be made available for download and/or for remote usage on a server. Embodiments of the method may be executed using a bitstream arranged to configure programmable logic, e.g., a field-programmable gate array (FPGA), to perform the method.

It will be appreciated that the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiments of the method. An embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the processing steps of at least one of the methods set forth. These instructions may be subdivided into subroutines and/or be stored in one or more files that may be linked statically or dynamically. Another embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the means of at least one of the systems and/or products set forth.

<FIG> shows a computer readable medium <NUM> having a writable part <NUM> comprising a container image <NUM> for providing an individualized network service based on sensitive data. Container image <NUM> comprises sensitive data <NUM>. Container image <NUM> further comprises instructions <NUM> that, when deployed as a container, cause the container to provide the individualized network service based on sensitive data <NUM>. The container image <NUM> may be embodied on the computer readable medium <NUM> as physical marks or by means of magnetization of the computer readable medium <NUM>. However, any other suitable embodiment is conceivable as well. Furthermore, it will be appreciated that, although the computer readable medium <NUM> is shown here as an optical disc, the computer readable medium <NUM> may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable.

<FIG> shows a computer readable medium <NUM> having a writable part <NUM> comprising a computer program <NUM>, the computer program <NUM> comprising instructions for causing a processor system to perform a container builder method or cloud service provider method according to an embodiment. The computer program <NUM> may be embodied on the computer readable medium <NUM> as physical marks or by means of magnetization of the computer readable medium <NUM>. However, any other suitable embodiment is conceivable as well. Furthermore, it will be appreciated that, although the computer readable medium <NUM> is shown here as an optical disc, the computer readable medium <NUM> may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable. The computer program <NUM> comprises instructions for causing a processor system to perform said container builder method or cloud service provider method.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments.

Claim 1:
A container builder (<NUM>) for building a container image, the container image being for providing an individualized network service based on sensitive data in a database, the container builder comprising:
- a data interface (<NUM>) configured for accessing the database (<NUM>), the database being configured as a private database of the container builder,
- a communication interface (<NUM>) configured for digital communication with a cloud service provider (<NUM>),
- a processor configured to:
- retrieve the sensitive data (<NUM>) from the database (<NUM>) using the data interface,
- build the container image (<NUM>), the container image comprising the sensitive data (<NUM>),
- provide the container image (<NUM>) for deployment to the cloud service provider (<NUM>) using the communication interface (<NUM>), the container image (<NUM>) comprising instructions that, when deployed as a container, cause the container to provide the individualized network service based on the sensitive data (<NUM>) comprised in the container image.