CN111859428B - 一种基于容器化的密钥存储方法及系统 - Google Patents
一种基于容器化的密钥存储方法及系统 Download PDFInfo
- Publication number
- CN111859428B CN111859428B CN202010711392.8A CN202010711392A CN111859428B CN 111859428 B CN111859428 B CN 111859428B CN 202010711392 A CN202010711392 A CN 202010711392A CN 111859428 B CN111859428 B CN 111859428B
- Authority
- CN
- China
- Prior art keywords
- key
- container
- file system
- memory file
- initializing
- 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.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/188—Virtual file systems
- G06F16/196—Specific adaptations of the file system to access devices and non-file objects via standard file system access operations, e.g. pseudo file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Storage Device Security (AREA)
Abstract
本发明公开了一种基于容器化的密钥存储方法及系统,所述方法将需要使用密钥的应用程序隔离部署在容器内;启动容器,容器内初始化生成密钥;使用容器自身实例ID将密钥加密存储在数据库中;初始化后,在容器内部挂载内存文件系统;将密钥文件使用当前实例ID进行解密,落地在容器内的内存文件系统中。所述系统包括容器镜像模块、容器实例模块、被隔离的虚拟内存文件模块。本发明实现一机一密的密钥文件明文不落地,本发明极大的保证了密钥的安全性,可靠性,并为制止非法利用密钥数据提供了有力的保障。
Description
技术领域
本发明属于密钥存储的技术领域,具体涉及一种基于容器化的密钥存储方法及系统。
背景技术
密钥文件已经逐渐成为网络安全不可或缺的一部分。但是网络的飞速发展,信息的大爆炸,网络骇客入侵逆向,密钥文件难免外泄甚至盗版。更多黑色产业非法出卖信息,出卖技术数据以谋取更多的利益。
创新点:使用容器化技术将加密种子单独设置,容器实例不同则加密种子KEY不同。使用Linux mnt namespace技术将密钥文件落地在不同域的文件系统中,密钥文件系统层隔离。使用Linux内存文件系统技术,将虚拟化的内存文件系统挂载到不同的mntnamespace中进行隔离,将密钥释放到内存文件系统中,密钥不落地存储在任何硬盘,分布式网络文件系统中。使用Linux cgroup技术限定内存文件系统的访问权限,使用大小,将权限固定到应用访问级别。无论从运行时刻的入侵,代码反汇编,到关机拆硬盘,都无法通过任何方法拿到密钥文件,并解决任意时刻掉电密钥落地的风险。
传统的密钥文件往往硬编码在代码中或在运行时刻解密到磁盘、网络集群、网络分布式文件系统中使用,当被入侵者拿到后台或网络文件系统被攻破,意外断电、非法拆盘的情况,密钥文件很容易外泄。密钥文件一旦被互联网公开,任何人得到都可直接解密并利用,原公司产品将受到很大的损失。
发明内容
本发明的目的在于提供一种基于容器化的密钥存储方法,旨在解决现有技术中数据使用时解密在磁盘的临时目录而带来的密钥丢失的巨大风险的问题,使密钥管理更加安全可靠。
本发明的目的还在于提供一种基于容器化的密钥存储系统,旨在解决密钥文件丢失的风险,实现密钥管理更加安全可靠。
本发明主要通过以下技术方案实现:一种基于容器化的密钥存储方法,将需要使用密钥的应用程序隔离部署在容器内;启动容器,容器首次初始化生成密钥;使用容器自身实例ID将密钥加密存储在数据库中;后续启动,在容器内部挂载内存文件系统;将密钥文件使用当前实例ID进行解密,并落地在容器内的内存文件系统中。
为了更好地实现本发明,进一步的,应用程序使用Linux内存文件系统技术,使用Linux mount memory技术虚拟化出一片内存作为内存文件系统使用;应用程序使用LinuxNamespace中mnt namespace技术,将虚拟化出的内存文件系统在容器内进行挂载;使用Linux namespace技术,将虚拟化出的内存文件系统在容器内的mnt namespace中进行安全隔离。
为了更好地实现本发明,进一步的,应用程序使用Linux cgroup技术,将已经挂载并隔离的内存文件系统的读写访问权限限制在应用内访问,并限制虚拟内存文件系统的大小;后续启动应用程序根据容器实例ID生成种子KEY,并对数据库中的密钥文件进行解密,将解密后的密钥放入已经隔离的虚拟内存文件系统中,并配置应用程序密钥路径,让应用程序可以正常访问密钥文件。
为了更好地实现本发明,进一步的,首先构建执行环境,主要包括以下步骤:
步骤S100:构建镜像:使用DockerFile构建应用程序基础rootfs,并将rootfs打成一个tar包文件;
步骤S200:导入镜像:使用docker命令,将rootfs.tar包导入容器,生成容器镜像;
步骤S300:启动实例:使用docker命令,启动容器实例,并在容器实例内初始化。
为了更好地实现本发明,进一步的,首次启动初始化:初始化密钥,根据容器实例ID唯一的特性,初始化加密种子KEY;初始化生成密钥文件,将密钥文件通过加密种子KEY加密存储在数据库表中。
本发明主要通过以下技术方案实现:一种基于容器化的密钥存储系统,包括容器镜像模块、容器实例模块、被隔离的虚拟内存文件模块;所述容器镜像用于打包整个应用程序环境,并生成一个与操作系统完全隔离的独立的应用运行环境;所述容器实例模块通过容器技术启动一个独立的运行环境,且运行环境在启动后整个rootfs与操作系统环境隔离;所述虚拟内存文件模块用于将内存虚拟化为内存文件系统,通过Linux mnt namespace技术将内存文件系统进行域隔离,通过linux cgroup技术将虚拟化的内存文件系统进行访问权限限制,以达到独立自主安全可控。
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的Linux或Windows机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口。
一个完整的Docker有以下几个部分组成:
1. DockerClient客户端
2. Docker Daemon守护进程
3. Docker Image镜像
4. DockerContainer容器
由于Docker已经是一种成熟公开容器方案,这里将不再赘述。
Linux Namespace域控制,Linux Namespace所实现的隔离性主要是来自kernel的namespace,其中pid,net,ipc,mnt,uts等namespace将容器container的进程,网络,消息,文件系统和hostname隔离开。使用Linux Namespace,可以将内存文件系统进行分开隔离控制,对于用户的进程是lxc-start进程的子进程,在kernel的namespace中实现隔离,因此只需要提供kernel的patch就可以保证用户的运行环境不会受到来自host主机的恶意入侵。
一个完整的Linux Namespace提供以下几种隔离:
1.net namespace:每个net namespace有独立的network devices,IPaddresses,IP routing tables,/proc/net目录。这样每个container的网络就能隔离开来。
2.ipc namespace:container中进程交互还是采用linux常见的进程间交互方法。(interprocess communication-IPC),包括常见的信号量、消息队列和共享内存。然而同VM不同,container的进程间交互实际上还是host上具有相同pid namespace中的进程间交互,因此需要在IPC资源申请时加入namespace信息。
3.mnt namespace:类似chroot,将一个进程放到一个特定的目录执行。mntnamespace允许不同namespace的进程看到的文件结构不同,这样每个namespace中的进程所看到的文件目录就被隔离开了。同chroot不同,每个namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。
4.uts namespace:UTS(“UNIX Time-sharing System”)namespace允许每个container拥有独立的hostname和domain name使其在网络上可以被视作一个独立的节点而非Host上的一个进程。
5.user namespace:每个container可以有不同的user和group id,也就是说可以以container内部的用户在container内部执行程序而非Host上的用户。
Linux Namespace是Linux Kernel中成熟的技术,这里将不再赘述。
Control Groups资源管理,不同namespace之间资源还是相互竞争的,仍然需要类似ulimit来管理每个container所能使用的资源,cgroups实现了对资源的配额和度量,cgroups的使用非常简单,提供类似文件的接口,在/cgroup目录下新建一个文件夹即可新建一个group,在此文件夹中新建task文件,并将pid写入该文件,即可实现对该进程的资源控制,具体的资源配置选项可以在该文件夹中新建子subsystem,{子系统前缀}.{资源项}是典型的配置方法,如memory.usage_in_bytes就定义了该group在subsystem memory中的一个内存限制选项。另外,cgroups中的subsystem可以随意组合,一个subsystem可以在不同的group中,也可以一个group包含多个subsystem,也就是说一个subsystem。
我们主要关心cgroups可以限制的资源包括:
1.cpu:在cgroup中,并不能像硬件虚拟化方案一样能够定义CPU能力,但是能够定义CPU轮转的优先级,因此具有较高CPU优先级的进程会更可能得到CPU运算。通过将参数写入cpu.shares,即可定义改cgroup的CPU优先级,这里是一个相对权重,而非绝对值。当然在cpu这个subsystem中还有其他可配置项,手册中有详细说明。cpusets:cpusets定义了有几个CPU可以被这个group使用,或者哪几个CPU可以供这个group使用。在某些场景下,单CPU绑定可以防止多核间缓存切换,从而提高效率。
2.memory:内存相关的限制,这里主要对内存访问权限,内存使用大小做限制。
3.blkio:block IO相关的统计和限制,byte/operation统计和限制(IOPS等),读写速度限制等,但是这里主要统计的都是同步IO。
4.net_cls,cpuacct,devices,freezer等其他可管理项。
Control Groups资源管理是Linux中常用的一种资源管理手段,这里将不再赘述。
在现有技术中,很多程序比如apache,ngnix,haproxy等要求密钥文件必须落地访问。传统的落地方法将密钥硬编码在代码中,或存储在数据库中,在使用时解密在磁盘的临时目录,或存放于网络文件系统中,该方法不解决一旦被非法入侵、突然掉电、拆盘等操作拿到后台文件访问权限,便轻松拿到密钥文件,将会带来严重的密钥丢失的风险。
本发明的有益效果:
(1)在本发明中,Docker容器实例负责对应用整体运行环境进行隔离,保证加密种子唯一性。Linux Namespace中mnt namespace负责对文件系统进行隔离,保证容器内程序的文件系统独立于主机文件系统。内存文件系统负责将内存虚拟化为文件系统,保证文件存储在内存文件系统中,不落地到任何磁盘,网络分布式等文件系统上。无论入侵、掉电、拆盘都无法拿到密钥文件。cgroup负责对内存文件系统访问权限,使用大小做限制约束,从而保证内存文件系统的访问安全性,大小不可控等造成对整个系统稳定性的影响。
(2)本发明有效的避免了密钥文件硬编码在代码中被反汇编,密钥文件采用同一个KEY进行加解密被反汇编,密钥文件通过分布式网络文件系统在网络中传输,密钥文件被入侵得到,密钥文件因为掉电等故障残留在磁盘中,分布式文件系统中,密钥文件被安全人员泄露等,从而实现一机一密的密钥文件明文不落地。本发明极大的保证了密钥的安全性,可靠性,并为制止非法利用密钥数据提供了有力的保障。
具体实施方式
实施例1:
一种基于容器化的密钥存储方法,主要包括以下步骤:
1.构建执行环境:
1)构建镜像:使用DockerFile构建应用程序基础rootfs,并将rootfs打成一个tar包文件;
2)导入镜像:使用docker命令,将rootfs.tar包导入容器,生成容器镜像;
3)创建实例:使用docker命令,将导入的rootfs镜像创建一个容器实例;
4)启动实例:使用docker命令,启动容器实例,并在容器实例内启动应用程序;
2.首次启动初始化:
1)初始化密钥:应用程序启动,根据容器实例ID唯一的特性,初始化加密种子KEY;
2)初始化生成密钥文件,将密钥文件通过加密种子KEY加密存储在数据库表中;
3.应用程序启动:
1 应用程序使用Linux内存文件系统技术,使用docker命令虚拟化出一片内存作为内存文件系统使用;
2 应用程序使用Linux Namespace中mnt namespace技术,将虚拟化出的内存文件系统在容器内进行挂载。使用mount命令,将虚拟化出的内存文件系统挂载在容器内的mntnamespace中进行安全隔离;
3 应用程序使用Linux cgroup技术,将已经挂载并隔离的内存文件系统的读写访问权限限制在应用内访问,并限制虚拟内存文件系统的大小,保证隔离的内存文件系统归应用程序本身,并保证内存占用大小不会对操作系统的正常运行进行干扰;
4 应用程序根据容器实例ID生成种子KEY,并对数据库中的密钥文件进行解密,将解密后的密钥放入已经隔离的虚拟内存文件系统中,并配置应用程序密钥路径,让应用程序可以正常访问密钥文件;
5 启动应用程序,对外提供正常服务,如apache、ngnix、haproxy的https服务等;这里涉及到数据的安全,所有临时算出的数据都在用完后释放,并不驻留在内存中。解密的密钥都在已经隔离的虚拟内存文件系统中,并不真正落地在磁盘或者分布式网络文件系统中。对此无论是被攻击入侵后台,网络截取,突然掉电,磁盘拆卸等都无法访问临时的隔离的虚拟的内存文件系统,拿走任何密钥文件。
一种基于容器化的密钥存储系统,主要的核心部件如下:
1.容器镜像模块:该模块负责打包整个应用程序环境,生成一个与操作系统完全隔离的,独立的应用运行环境。
2.容器实例模块:该模块通过容器技术,启动一个独立的运行环境,该运行环境与启动后整个rootfs与操作系统环境隔离,既不污染操作系统,也不接受操作系统的越权控制。
3.被隔离的虚拟内存文件模块:该模块负责将内存虚拟化为内存文件系统,通过Linux mnt namespace技术将内存文件系统进行域隔离,通过linux cgroup技术将虚拟化的内存文件系统进行访问权限限制,以达到独立自主安全可控的效果。
4.应用程序:使用初始化好的环境,将密钥文件解密并放入安全可靠的环境,并设置应用程序的环境变量,安全的启动应用程序对外提供可靠的服务。
在本发明中,Docker容器实例负责对应用整体运行环境进行隔离,保证加密种子唯一性。Linux Namespace中mnt namespace负责对文件系统进行隔离,保证容器内程序的文件系统独立于主机文件系统。内存文件系统负责将内存虚拟化为文件系统,保证文件存储在内存文件系统中,不落地到任何磁盘,网络分布式等文件系统上。无论入侵、掉电、拆盘都无法拿到密钥文件。cgroup负责对内存文件系统访问权限,使用大小做限制约束,从而保证内存文件系统的访问安全性,大小不可控等造成对整个系统稳定性的影响。
本发明有效的避免了密钥文件硬编码在代码中被反汇编,密钥文件采用同一个KEY进行加解密被反汇编,密钥文件通过分布式网络文件系统在网络中传输,密钥文件被入侵得到,密钥文件因为掉电等故障残留在磁盘中,分布式文件系统中,密钥文件被安全人员泄露等,从而实现一机一密的密钥文件明文不落地。使用本系统,极大的保证了密钥的安全性,可靠性,并为制止非法利用密钥数据提供了有力的保障。
以上所述,仅是本发明的较佳实施例,并非对本发明做任何形式上的限制,凡是依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化,均落入本发明的保护范围之内。
Claims (6)
1.一种基于容器化的密钥存储方法,其特征在于,将需要使用密钥的应用程序隔离部署在容器内;启动容器,容器首次初始化生成密钥;初始化密钥,根据容器实例ID唯一的特性,初始化加密种子KEY;初始化生成密钥文件,将密钥文件通过加密种子KEY加密存储在数据库表中; 使用容器自身实例ID将密钥加密存储在数据库中;后续启动,在容器内部挂载内存文件系统;将密钥文件使用当前实例ID进行解密,并落地在容器内的内存文件系统中;使用Linuxnamespace技术,将虚拟化出的内存文件系统在容器内的mntnamespace中进行安全隔离,应用程序使用Linuxcgroup技术,将已经挂载并隔离的内存文件系统的读写访问权限限制在应用内访问,并限制虚拟内存文件系统的大小。
2.根据权利要求1所述的一种基于容器化的密钥存储方法,其特征在于,应用程序使用Linux内存文件系统技术,使用Linuxmountmemory技术虚拟化出一片内存作为内存文件系统使用;应用程序使用LinuxNamespace中mntnamespace技术,将虚拟化出的内存文件系统在容器内进行挂载;使用Linuxnamespace技术,将虚拟化出的内存文件系统在容器内的mntnamespace中进行安全隔离。
3.根据权利要求2所述的一种基于容器化的密钥存储方法,其特征在于,应用程序使用Linuxcgroup技术,将已经挂载并隔离的内存文件系统的读写访问权限限制在应用内访问,并限制虚拟内存文件系统的大小;后续启动应用程序根据容器实例ID生成种子KEY,并对数据库中的密钥文件进行解密,将解密后的密钥放入已经隔离的虚拟内存文件系统中,并配置应用程序密钥路径,让应用程序可以正常访问密钥文件。
4.根据权利要求1-3任一项所述的一种基于容器化的密钥存储方法,其特征在于,首先构建执行环境,主要包括以下步骤:
步骤S100:构建镜像:使用DockerFile构建应用程序基础rootfs,并将rootfs打成一个tar包文件;
步骤S200:导入镜像:使用docker命令,将rootfs.tar包导入容器,生成容器镜像;
步骤S300:启动实例:使用docker命令,启动容器实例,并在容器实例内初始化。
5.根据权利要求4所述的一种基于容器化的密钥存储方法,其特征在于,首次启动初始化:初始化密钥,根据容器实例ID唯一的特性,初始化加密种子KEY;初始化生成密钥文件,将密钥文件通过加密种子KEY加密存储在数据库表中。
6.一种基于容器化的密钥存储系统,其特征在于,包括容器镜像模块、容器实例模块、被隔离的虚拟内存文件模块;所述容器镜像用于打包整个应用程序环境,并生成一个与操作系统完全隔离的独立的应用运行环境;所述容器实例模块通过容器技术启动一个独立的运行环境,且运行环境在启动后整个rootfs与操作系统环境隔离;所述虚拟内存文件模块用于将内存虚拟化为内存文件系统,通过Linuxmntnamespace技术将内存文件系统进行域隔离,通过linuxcgroup技术将虚拟化的内存文件系统进行访问权限限制,以达到独立自主安全可控;将需要使用密钥的应用程序隔离部署在容器内;启动容器,容器首次初始化生成密钥;初始化密钥,根据容器实例ID唯一的特性,初始化加密种子KEY;初始化生成密钥文件,将密钥文件通过加密种子KEY加密存储在数据库表中;后续启动,在容器内部挂载内存文件系统;将密钥文件使用当前实例ID进行解密,并落地在容器内的内存文件系统中。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010711392.8A CN111859428B (zh) | 2020-07-22 | 2020-07-22 | 一种基于容器化的密钥存储方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010711392.8A CN111859428B (zh) | 2020-07-22 | 2020-07-22 | 一种基于容器化的密钥存储方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111859428A CN111859428A (zh) | 2020-10-30 |
CN111859428B true CN111859428B (zh) | 2022-07-19 |
Family
ID=72949321
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010711392.8A Active CN111859428B (zh) | 2020-07-22 | 2020-07-22 | 一种基于容器化的密钥存储方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111859428B (zh) |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106845584A (zh) * | 2017-02-10 | 2017-06-13 | 北京小米移动软件有限公司 | 收纳容器的识别方法及装置 |
CN108446159A (zh) * | 2017-02-16 | 2018-08-24 | 中标软件有限公司 | 基于Docker容器的移动端双系统实现系统及方法 |
CN108733455A (zh) * | 2018-05-31 | 2018-11-02 | 上海交通大学 | 基于ARM TrustZone的容器隔离性增强系统 |
CN109983732A (zh) * | 2016-12-02 | 2019-07-05 | 古鲁洛吉克微系统公司 | 保护密钥库内容的使用 |
CN110069921A (zh) * | 2019-04-12 | 2019-07-30 | 中国科学院信息工程研究所 | 一种面向容器平台的可信软件授权验证系统及方法 |
CN110531987A (zh) * | 2019-07-30 | 2019-12-03 | 平安科技(深圳)有限公司 | 基于Kubernetes集群的管理方法、装置及计算机可读存储介质 |
CN110581787A (zh) * | 2019-09-11 | 2019-12-17 | 成都安恒信息技术有限公司 | 一种运用于性能测试的应用层数据量倍增方法 |
CN111124956A (zh) * | 2019-11-22 | 2020-05-08 | 海光信息技术有限公司 | 一种容器保护方法、处理器、操作系统及计算机设备 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105893205A (zh) * | 2015-11-20 | 2016-08-24 | 乐视云计算有限公司 | 监控基于docker创建的container的方法及系统 |
US10379835B2 (en) * | 2016-12-19 | 2019-08-13 | International Business Machines Corporation | Optimized creation of distributed storage and distributed processing clusters on demand |
CN107643940A (zh) * | 2017-09-26 | 2018-01-30 | 华为技术有限公司 | 容器创建方法、相关设备及计算机存储介质 |
CN111339034B (zh) * | 2020-05-18 | 2020-08-11 | 湖南天琛信息科技有限公司 | 一种密文存储明文访问的系统、密文存储和明文访问方法 |
-
2020
- 2020-07-22 CN CN202010711392.8A patent/CN111859428B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109983732A (zh) * | 2016-12-02 | 2019-07-05 | 古鲁洛吉克微系统公司 | 保护密钥库内容的使用 |
CN106845584A (zh) * | 2017-02-10 | 2017-06-13 | 北京小米移动软件有限公司 | 收纳容器的识别方法及装置 |
CN108446159A (zh) * | 2017-02-16 | 2018-08-24 | 中标软件有限公司 | 基于Docker容器的移动端双系统实现系统及方法 |
CN108733455A (zh) * | 2018-05-31 | 2018-11-02 | 上海交通大学 | 基于ARM TrustZone的容器隔离性增强系统 |
CN110069921A (zh) * | 2019-04-12 | 2019-07-30 | 中国科学院信息工程研究所 | 一种面向容器平台的可信软件授权验证系统及方法 |
CN110531987A (zh) * | 2019-07-30 | 2019-12-03 | 平安科技(深圳)有限公司 | 基于Kubernetes集群的管理方法、装置及计算机可读存储介质 |
CN110581787A (zh) * | 2019-09-11 | 2019-12-17 | 成都安恒信息技术有限公司 | 一种运用于性能测试的应用层数据量倍增方法 |
CN111124956A (zh) * | 2019-11-22 | 2020-05-08 | 海光信息技术有限公司 | 一种容器保护方法、处理器、操作系统及计算机设备 |
Non-Patent Citations (3)
Title |
---|
Build Minimal Docker Container Using Golang;Biradar Sangam M等;《网页在线公开:https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8663172》;20190311;第1-4页 * |
Mnt_namespace分析;马学;《网页在线公开:https://blog.csdn.net/tanzhe2017/article/details/81001981?》;20180712;第1-9页 * |
基于CTCA的智能卡协调管理器的设计与实现;王汪;《计算机应用》;20050915;第25卷(第8期);第1899-1902页 * |
Also Published As
Publication number | Publication date |
---|---|
CN111859428A (zh) | 2020-10-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11989332B2 (en) | Secure public cloud with protected guest-verified host control | |
US11520611B2 (en) | Secure public cloud using extended paging and memory integrity | |
US11163911B2 (en) | Secure public cloud with protected guest-verified host control | |
Jin et al. | Architectural support for secure virtualization under a vulnerable hypervisor | |
EP2577474B1 (en) | Virtual machine memory compartmentalization in multi-core architectures | |
EP2577449B1 (en) | Method and apparatus for trusted execution in infrastructure as a service cloud environments | |
US8839239B2 (en) | Protection of virtual machines executing on a host device | |
CN110119302B (zh) | 虚拟机监视器以及虚拟可信执行环境构建方法 | |
EP2577543A1 (en) | Secure virtual machine bootstrap in untrusted cloud infrastructures | |
WO2009085977A2 (en) | Virtual computing management systems and methods | |
Zhang et al. | PALM: security preserving VM live migration for systems with VMM-enforced protection | |
JP2001318797A (ja) | 自動データ処理装置 | |
Yao et al. | CryptVMI: A flexible and encrypted virtual machine introspection system in the cloud | |
CN111859428B (zh) | 一种基于容器化的密钥存储方法及系统 | |
US20230236870A1 (en) | Safe entropy source for encrypted virtual machines | |
Inokuchi et al. | Secure VM management with strong user binding in semi-trusted clouds | |
DE102023201819A1 (de) | Vertrauliches auslagern von dauerspeicheroperationen in vertraulichen rechenumgebungen | |
CN108241801B (zh) | 处理系统调用的方法和装置 | |
Lie et al. | Using hypervisors to secure commodity operating systems | |
Brendmo | Live forensics on the Windows 10 secure kernel. | |
aw Ideler | Cryptography as a service in a cloud computing environment | |
US11604673B2 (en) | Memory encryption for virtual machines by hypervisor-controlled firmware | |
Keisuke et al. | Secure VM management with strong user binding in semi-trusted clouds | |
Mitchell | On the Practical Applications of Virtualization Software in Business Operations | |
WO2022187052A1 (en) | Apparatus and method for efficient and secure process formation on secure runtime hardware resources |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |