CN105069353A - 一种基于Docker的可信容器安全加固方法 - Google Patents
一种基于Docker的可信容器安全加固方法 Download PDFInfo
- Publication number
- CN105069353A CN105069353A CN201510488809.8A CN201510488809A CN105069353A CN 105069353 A CN105069353 A CN 105069353A CN 201510488809 A CN201510488809 A CN 201510488809A CN 105069353 A CN105069353 A CN 105069353A
- Authority
- CN
- China
- Prior art keywords
- container
- docker
- credible
- mirror image
- file
- 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.)
- Granted
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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
-
- 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
Abstract
本发明公开了一种基于Docker的可信容器安全加固方法，用于对Docker容器系统进行安全增强，实现基于Docker的可信容器，应用于基于Docker的服务器集群中；该基于Docker的可信容器包含容器程序Docker、容器可信度量模块、进程监控模块和网络通信监控模块，其中容器可信度量模块包括可信启动子模块与文件度量子模块；本发明重点关注Docker容器的可信性，利用可信计算、完整性度量技术，配合实时监控模块对基于Docker的容器系统进行加固，保护容器及镜像不被篡改，同时限制容器的网络通信行为并监控容器内部进程，从而实现一个安全加强的可信容器。
Description
技术领域
本发明属于互联网技术领域，特别是涉及一种基于Docker的可信容器安全加固方法。
背景技术
Docker作为时下最流行的轻量级虚拟化技术，正在给业界带来一场颠覆性的技术革命，随着Docker技术应用规模越来越大，领域越来越广，其暴露出的安全问题也显得日趋严重，诸如隔离机制不完善、特权过于集中、混乱的共享机制等，这些安全隐患已经成为阻碍着Docker发展的关键因素。从Docker已经被发现的各类安全问题可以看出，Docker镜像及容器均存在被篡改的风险，同时不完全的隔离性允许容器之间的非授权通信，容器内部的恶意进程或恶意数据同样给Docker系统甚至宿主机带来风险。
目前，针对Docker系统的防护方案主要有以下几种：
（1）Docker系统本身依赖Linux内核的安全性，目前主要依赖的机制有Namespace和Cgroups，分别实现容器的隔离性和资源限制，但上述两种机制并不能做到完整的隔离，Docker系统仍然面临被穿透的风险；
（2）Docker官方推荐使用GRSEC内核补丁以提高安全性，这是一种Linux内核安全增强补丁，该补丁从宿主机的角度提高Docker整体安全性，对容器内部的防护却无能为力；
（3）DanielWalsh等人在2014年提出使用访问控制系统加强Docker安全，以RedHat开发的SElinux系统为例，该系统在每个容器创建时为其打上唯一的标签，不同容器标签不同，容器之间以及容器和宿主机间默认无法互联，也就是说，标签不同的主客体之间所有操作都是被禁止的，这样就极大地提高了Docker容器的隔离性，但这种方法仍然没有关心Docker容器内部的安全性，Docker容器和镜像仍然面临被篡改的可能。
发明内容
针对上述问题，本发明提出一种基于Docker的可信容器安全加固方法。该方法利用可信计算、完整性度量技术，配合实时监控模块对基于Docker的容器系统进行加固，从Docker配置文件、镜像、容器三个层面保护容器完整性，同时能对容器内运行的进程及容器通信行为进行监控，如此一来便可规避大部分安全风险，极大地提高Docker容器的安全性。
本发明所采用的技术方案是：一种基于Docker的可信容器安全加固方法，用于对Docker容器系统进行安全增强，实现基于Docker的可信容器，应用于基于Docker的服务器集群中；该基于Docker的可信容器包含容器程序Docker、容器可信度量模块、进程监控模块和网络通信监控模块，其中容器可信度量模块包括可信启动子模块与文件度量子模块；其中Docker为容器程序主体，用于对各个进程监控模块的调用以及对容器镜像的可信度量，可信启动子模块用于实现镜像的完整性度量和容器的可信启动；文件系统监控模块用于对各个容器的文件系统的监控；进程监控模块用于通过设置黑白名单实现对容器内的进程的监控；网络通信监控模块用于对容器的网络连接的细粒度控制，限制容器对外连接和容器间的连接；
其特征在于，包括以下步骤：
步骤1：容器的可信启动，其具体实现包括以下子步骤：
步骤1.1：BIOS加电启动搜索到MBR，读取配置信息，将控制权转给TrustedGRUB；
步骤1.2：TrustedGRUB加载系统内核，对Docker程序的可执行文件及关键配置文件进行完整性度量，完整性度量通过之后，将度量结果存入PCR，将控制权转给操作系统；
步骤1.3：操作系统启动之后，启动Docker程序；
步骤1.4：Docker程序启动之后，可信启动子模块启动，随即监控Docker关于镜像获取的命令；当Docker获取到新镜像后，度量程序开始计算镜像的HASH基准值并加密存储；
步骤1.5：接收到用户发出的启动容器命令时，首先读入存有HASH基准值的文件，用密钥将其解密，得到40位HASH值；然后再依据步骤1.4中所述的计算镜像HASH基准值的方法再计算一遍镜像的HASH值；
步骤1.6：将步骤1.5中新计算得到的HASH值与步骤1.4中的HASH基准值进行对比，若两值相等则启动容器，否则不启动将弹框报告用户，提示镜像已被损坏；
步骤2：容器启动后的文件系统监控，其具体实现包括以下子步骤：
步骤2.1：启动容器之后，Docker对文件系统监控程序可执行文件进行度量，验证完文件系统监控程序可执行文件的完整性后启动文件系统监控程序；
步骤2.2：文件系统监控程序启动之后计算容器的文件系统的读写层的HASH值；
步骤2.3：对容器的文件系统的读写层的HASH进行加密作为基准值存储在以容器ID为文件名的文件中；
步骤2.4：当经过预设的时间以后，文件系统监控模块对文件系统的读写层的HASH值进行解密，然后重新计算容器的文件系统的HASH值作为实时度量值；
步骤2.5：将步骤2.4中的两个HASH值进行对比；如果两个HASH值相等，则等待下一次度量文件系统直到删除容器；如果两个HASH值不相等，则说明度量值与基准值不一样，容器文件系统的读写层被篡改；如果管理员是合法更新了读写层文件，则可输入管理员用户名和密码更新基准值；如果密码输入错误则身份认证失败，并报告管理员为非法修改，本流程结束；如果密码输入正确则身份认证通过，更新基准值，并回转执行所述的步骤2.3；
步骤3：容器启动后的进程监控，其具体实现包括以下子步骤：
步骤3.1：用户输入指定容器的管理策略，即进程白名单；白名单中为可在容器中正常运行的程序；由于本发明是针对大规模集群服务器应用场景提出的安全加固方法，而在该应用场景下，各Docker容器分工明确，内部运行的进程类别单一，一般每个容器仅提供一种服务。因此，管理员可根据实际情况设置每个容器的进程白名单，这样进程监控模块就可以有针对性的对每个容器实时监控，确保容器内部运行的都是合法进程。
步骤3.2：进程监控模块读入对应容器的进程白名单；
步骤3.3：进程监控模块开始实时监控，若发现容器内部存在白名单中未曾出现的进程，即刻拦截并提示管理员；
步骤4：容器启动后的网络监控，其具体实现包括以下子步骤：
步骤4.1：用户输入指定容器的通信管理策略，即IP及端口白名单；白名单中为允许容器与之通信的主机IP及端口，其中包括外界主机和本地其他容器；主要目的是限制容器非授权的通信行为。
步骤4.2：网络通信监控模块读入白名单，将白名单中的IP及端口转换成iptables规则文件；
步骤4.3：网络通信监控模块将步骤4.2中产生的规则文件载入iptables防火墙；
步骤4.4：用户自定义规则生效，容器只能和指定主机进行通信，若出现非授权通信行为，网络通信监控模块将立即阻止。
作为优选，步骤1.2中所述的可执行文件及关键配置文件包括：
/etc/bash_completion.d/docker；/etc/init.d/docker；/etc/default/docker；/var/lib/docker/init/dockerinit-1.6.0；/var/lib/docker/init/dockerinit-1.7.0-dev；/etc/init/docker.conf；/lib/systemd/system/docker.service；/lib/systemd/system/docker.socket；
作为优选，步骤1.4中所述的Docker获取镜像的方式有三种，包括从Registry下载镜像、将当前活动容器封装成镜像、从tar包读取镜像存于本地，这三种方式对应的Docker命令分别是pull、commit、load与save。
作为优选，步骤1.4中所述度量程序所度量的内容包括镜像的rootfs层、镜像配置信息以及层间关系文件。
作为优选，步骤1.4中所述的度量程序开始计算镜像的HASH基准值并加密存储，其具体实现过程是度量程序通过调用TPM提供的SHA-1引擎分别计算得到与镜像有关的各部分HASH值，并将他们连接起来再进行一次SHA-1，计算得到最后的HASH值，将此HASH值作为基准值，对其进行加密存储；所述的加密存储利用的是TPM提供的RSA密钥将hash值加密为512位密文最后将密文存入以镜像id命名的文件中。
作为优选，步骤2.2中所述的文件系统监控程序启动之后计算容器的文件系统的HASH值，Docker对文件系统监控程序可执行文件进行度量，度量的内容包括容器当前可读写层、读写层对应的init层以及层间关系文件。由于Docker采用AUFS文件系统，故只有容器层是可读写的，容器所依赖的各层都是只读的，而可信启动子模块中的镜像度量模块可以确保这些只读层的完整性，故文件系统度量模块只需关注容器读写层即可。
本发明的有益效果为：
（1）构造可信链，确保容器可信启动；
本发明引入TrustedGRUB可信引导工具，并对Docker自身可执行文件、关键配置文件、Docker容器的镜像进行完整性度量，从而构造一条完整的从BIOS、Grub、OS内核、DockerDaemon，再到最后容器启动的信任链，确保Docker容器的可信启动，防止容器本身及其运行的环境被篡改。
（2）对容器文件系统进行度量，确保容器运行时文件系统的完整性；
基于“可信”的核心理念，本发明不仅对Docker可执行程序、镜像进行了完整性度量，确保了容器的可信启动，还对容器运行时的文件系统进行了实时的监控，以确保容器运行时的可信和安全。容器启动时会创建容器文件系统的哈希基准值，每隔特定时间会进行检查核对。当文件系统改变时，提醒管理员输入密码更新基准值。
（3）设置白名单监控容器内部进程，确保容器进程安全；
通过HOOK主机的相关系统调用函数来实现容器内进程实时监控的功能。当容器内的某个进程创建运行前，判断该容器内的这个进程是否为被预设的进程，然后再进行相应的操作。并且可以通过预先设置白名单到达对不同容器内对不同可信进程的实时保护。如果是为可信进程，则操作如常，如果是可疑进程，则在创建运行前就拦截。通过容器内进程实时监控这个模块的保护，可以保证多容器运行多进程的安全。
（4）实现细粒度的网络访问控制，确保容器网络安全；
通过运用IPtable技术，设置容器通信规则，改进了Docker本身只能开启或关闭网络功能和容器间通信功能，可对容器与外部的通信进行监控，实现了细粒度的网络访问控制。
附图说明
图1：是本发明实施例的基于Docker的可信容器系统架构示意图。
图2：是本发明实施例的可信启动子模块示意图。
图3：是本发明实施例的容器文件系统监控模块示意图。
图4：是本发明实施例的容器进程监控模块示意图。
图5：是本发明实施例的容器网络监控示意图。
具体实施方式
为了便于本领域普通技术人员理解和实施本发明，下面结合附图及实施例对本发明作进一步的详细描述，应当理解，此处所描述的实施示例仅用于说明和解释本发明，并不用于限定本发明。
本发明提供的一种基于Docker的可信容器安全加固方法，用于对Docker容器系统进行安全增强，实现基于Docker的可信容器，应用于基于Docker的服务器集群中。
请见图1，本实施例的基于Docker的可信容器包含容器程序Docker、容器可信度量模块、进程监控模块和网络通信监控模块，其中容器可信度量模块包括可信启动子模块与文件度量子模块；其中Docker为容器程序主体，用于对各个进程监控模块的调用以及对容器镜像的可信度量，可信启动子模块用于实现镜像的完整性度量和容器的可信启动；文件系统监控模块用于对各个容器的文件系统的监控；进程监控模块用于通过设置黑白名单实现对容器内的进程的监控；网络通信监控模块用于对容器的网络连接的细粒度控制，限制容器对外连接和容器间的连接。
可信启动子模块是非常重要的一个模块。在确保容器能否安全启动非常关键。当Docker获取新镜像后，会自动对镜像进行HASH值计算。同时在容器启动前对镜像进行完整性度量确保容器启动时的安全。
文件度量子模块是另一个关键的一个模块。它确保了容器在运行过程中的文件系统的安全性。由于Docker采用分层结构组织其文件系统，而只有最上面一层是可读写的，所以本发明认为确保容器文件系统的完整性主要是确保该读写层的完整性。至于其所依赖的只读层则交由可信启动子模块中的镜像度量模块进行度量。
在实例中本发明基于TPM芯片和可信计算技术实现了对容器HASH基准值的计算和加密存储。
进程监控模块是确保容器运行时的安全性的另一重要模块。当容器启动时，将触发该模块，根据用户自定义的管理策略开始监控容器内部运行的进程，一旦发现非法进程，将立即发出警告。
实施例中，本发明基于HOOK技术和内核模块加载技术实现了对Proc文件系统下白名单文件进行改写，容器内进程监控模块根据白名单进行操作，从而对容器内部可疑进程的限制和可信进程的信赖。
网络通信监控模块主要负责限制容器的非授权通信行为，以提高容器在网络方面的安全性。当容器启动时，将触发该模块，根据用户自定义的管理策略开始监控容器的网络通信行为，只允许容器与可信主机进行通信，一旦出现非授权通信行为将立即阻止。
实施例中，本发明将用户自定义的策略转换成iptables规则，并将规则文件载入生效，实现对容器网络通信的监控和限制。
本发明提供的一种基于Docker的可信容器安全加固方法，包括以下步骤：
步骤1：容器的可信启动；请见图2，其具体实现包括以下子步骤：
步骤1.1：BIOS加电启动搜索到MBR，读取配置信息，将控制权转给TrustedGRUB；
步骤1.2：TrustedGRUB加载系统内核，对Docker程序的可执行文件及关键配置文件进行完整性度量，完整性度量通过之后，将度量结果存入PCR，将控制权转给操作系统；
可执行文件及关键配置文件包括：
/etc/bash_completion.d/docker/etc/init.d/docker/etc/default/docker/var/lib/docker/init/dockerinit-1.6.0/var/lib/docker/init/dockerinit-1.7.0-dev/etc/init/docker.conf/lib/systemd/system/docker.service/lib/systemd/system/docker.socket
步骤1.3：操作系统启动之后，启动Docker程序；
步骤1.4：Docker程序启动之后，可信启动子模块启动，随即监控Docker关于镜像获取的命令；当Docker获取到新镜像后，度量程序开始计算镜像的HASH基准值并加密存储；
Docker获取镜像的方式有三种，包括从Registry下载镜像、将当前活动容器封装成镜像、从tar包读取镜像存于本地，这三种方式对应的Docker命令分别是pull、commit、load与save。
当Docker获取到新镜像后，度量程序开始计算镜像的HASH基准值并加密存储；所度量的内容包括镜像的rootfs层、镜像配置信息以及层间关系文件。度量程序通过调用TPM提供的SHA-1引擎分别计算得到与镜像有关的各部分hash值并将他们连接起来再进行一次SHA-1计算得到最后的hash值，将此HASH值作为基准值，对其进行加密存储，这里利用的是TPM提供的RSA密钥将hash值加密为512位密文最后将密文存入以镜像id命名的文件中。
步骤1.5：接收到用户发出的启动容器命令时，首先读入存有HASH基准值的文件，用密钥将其解密，得到40位HASH值；然后再依据步骤1.4中所述的计算镜像HASH基准值的方法再计算一遍镜像的HASH值；
步骤1.6：将步骤1.5中新计算得到的HASH值与步骤1.4中的HASH基准值进行对比，若两值相等则启动容器，否则不启动将弹框报告用户，提示镜像已被损坏；
当镜像被删除时，同时也删除存有该镜像hash基准值的文件。
通过以上操作就可以确保容器启动时是从一个安全的可信的没有被篡改的镜像中启动的。
步骤2：容器启动后的文件系统监控；请见图3，其具体实现包括以下子步骤：
步骤2.1：启动容器之后，Docker对文件系统监控程序可执行文件进行度量，验证完文件系统监控程序可执行文件的完整性后启动文件系统监控程序；
度量的内容包括容器当前可读写层、读写层对应的init层以及层间关系文件。由于Docker采用AUFS文件系统，故只有容器层是可读写的，容器所依赖的各层都是只读的，而可信启动子模块中的镜像度量模块可以确保这些只读层的完整性，故文件系统度量模块只需关注容器读写层即可。
步骤2.2：文件系统监控程序启动之后计算容器的文件系统的读写层的HASH值；
步骤2.3：对容器的文件系统的读写层的HASH进行加密作为基准值存储在以容器ID为文件名的文件中；
步骤2.4：当经过预设的时间以后，文件系统监控模块对文件系统的读写层的HASH值进行解密，然后重新计算容器的文件系统的HASH值作为实时度量值；
步骤2.5：将步骤2.4中的两个HASH值进行对比；如果两个HASH值相等，则等待下一次度量文件系统直到删除容器；如果两个HASH值不相等，则说明度量值与基准值不一样，容器文件系统的读写层被篡改；如果管理员是合法更新了读写层文件，则可输入管理员用户名和密码更新基准值；如果密码输入错误则身份认证失败，并报告管理员为非法修改，本流程结束；如果密码输入正确则身份认证通过，更新基准值，并回转执行所述的步骤2.3；
如果销毁容器，则该容器的文件监控模块自行退出，并删除掉该容器的文件系统的hash基准值文件。
步骤3：容器启动后的进程监控；请见图4，其具体实现包括以下子步骤：
步骤3.1：用户输入指定容器的管理策略，即进程白名单；白名单中为可在容器中正常运行的程序；由于本发明是针对大规模集群服务器应用场景提出的安全加固方法，而在该应用场景下，各Docker容器分工明确，内部运行的进程类别单一，一般每个容器仅提供一种服务。因此，管理员可根据实际情况设置每个容器的进程白名单，这样进程监控模块就可以有针对性的对每个容器实时监控，确保容器内部运行的都是合法进程。
步骤3.2：进程监控模块读入对应容器的进程白名单；
步骤3.3：进程监控模块开始实时监控，若发现容器内部存在白名单中未曾出现的进程，即刻拦截并提示管理员；
步骤4：容器启动后的网络监控，请见图5，其具体实现包括以下子步骤：
步骤4.1：用户输入指定容器的通信管理策略，即IP及端口白名单；白名单中为允许容器与之通信的主机IP及端口，其中包括外界主机和本地其他容器；主要目的是限制容器非授权的通信行为。
步骤4.2：网络通信监控模块读入白名单，将白名单中的IP及端口转换成iptables规则文件；
步骤4.3：网络通信监控模块将步骤4.2中产生的规则文件载入iptables防火墙；
步骤4.4：用户自定义规则生效，容器只能和指定主机进行通信，若出现非授权通信行为，网络通信监控模块将立即阻止。
本发明将可信计算的思想及相关技术应用于Docker安全，构造了从底层操作系统到Docker程序再到镜像最后到容器内应用的信任链，实现了对容器的完整性度量，防止对于容器的非法篡改。
本发明通过自定义的安全策略，对容器内运行的进程和容器的通信行为进行监控，防止容器内程序入侵容器和容器间的非授权通信。当出现恶意进程或容器进行非授权通信时，系统将感知到异常并发出警告。
本发明与Daniel等人的工作不同，本发明重点关注Docker容器的可信性，利用可信计算、完整性度量技术，配合实时监控模块对基于Docker的容器系统进行加固，保护容器及镜像不被篡改，同时限制容器的网络通信行为并监控容器内部进程，从而实现一个安全加强的可信容器。
应当理解的是，本说明书未详细阐述的部分均属于现有技术。
应当理解的是，上述针对较佳实施例的描述较为详细，并不能因此而认为是对本发明专利保护范围的限制，本领域的普通技术人员在本发明的启示下，在不脱离本发明权利要求所保护的范围情况下，还可以做出替换或变形，均落入本发明的保护范围之内，本发明的请求保护范围应以所附权利要求为准。
Claims (6)
1.一种基于Docker的可信容器安全加固方法，用于对Docker容器系统进行安全增强，实现基于Docker的可信容器，应用于基于Docker的服务器集群中；该基于Docker的可信容器包含容器程序Docker、容器可信度量模块、进程监控模块和网络通信监控模块，其中容器可信度量模块包括可信启动子模块与文件度量子模块；其中Docker为容器程序主体，用于对各个进程监控模块的调用以及对容器镜像的可信度量，可信启动子模块用于实现镜像的完整性度量和容器的可信启动；文件系统监控模块用于对各个容器的文件系统的监控；进程监控模块用于通过设置黑白名单实现对容器内的进程的监控；网络通信监控模块用于对容器的网络连接的细粒度控制，限制容器对外连接和容器间的连接；
其特征在于，包括以下步骤：
步骤1：容器的可信启动，其具体实现包括以下子步骤：
步骤1.1：BIOS加电启动搜索到MBR，读取配置信息，将控制权转给TrustedGRUB；
步骤1.2：TrustedGRUB加载系统内核，对Docker程序的可执行文件及关键配置文件进行完整性度量，完整性度量通过之后，将度量结果存入PCR，将控制权转给操作系统；
步骤1.3：操作系统启动之后，启动Docker程序；
步骤1.4：Docker程序启动之后，可信启动子模块启动，随即监控Docker关于镜像获取的命令；当Docker获取到新镜像后，度量程序开始计算镜像的HASH基准值并加密存储；
步骤1.5：接收到用户发出的启动容器命令时，首先读入存有HASH基准值的文件，用密钥将其解密，得到40位HASH值；然后再依据步骤1.4中所述的计算镜像HASH基准值的方法再计算一遍镜像的HASH值；
步骤1.6：将步骤1.5中新计算得到的HASH值与步骤1.4中的HASH基准值进行对比，若两值相等则启动容器，否则不启动将弹框报告用户，提示镜像已被篡改；
步骤2：容器启动后的文件系统监控，其具体实现包括以下子步骤：
步骤2.1：启动容器之后，Docker对文件系统监控程序可执行文件进行度量，验证完文件系统监控程序可执行文件的完整性后启动文件系统监控程序；
步骤2.2：文件系统监控程序启动之后计算容器的文件系统的读写层的HASH值；
步骤2.3：对容器的文件系统的读写层的HASH进行加密作为基准值存储在以容器ID为文件名的文件中；
步骤2.4：当经过预设的时间以后，文件系统监控模块对文件系统的读写层的HASH值进行解密，然后重新计算容器的文件系统的HASH值作为实时度量值；
步骤2.5：将步骤2.4中的两个HASH值进行对比；如果两个HASH值相等，则等待下一次度量文件系统直到删除容器；如果两个HASH值不相等，则说明度量值与基准值不一样，容器文件系统的读写层被篡改；如果管理员是合法更新了读写层文件，则可输入管理员用户名和密码更新基准值；如果密码输入错误则身份认证失败，并报告管理员为非法修改，本流程结束；如果密码输入正确则身份认证通过，更新基准值，并回转执行所述的步骤2.3；
步骤3：容器启动后的进程监控，其具体实现包括以下子步骤：
步骤3.1：用户输入指定容器的管理策略，即进程白名单；白名单中为可在容器中正常运行的程序；
步骤3.2：进程监控模块读入对应容器的进程白名单；
步骤3.3：进程监控模块开始实时监控，若发现容器内部存在白名单中未曾出现的进程，即刻拦截并提示管理员；
步骤4：容器启动后的网络监控，其具体实现包括以下子步骤：
步骤4.1：用户输入指定容器的通信管理策略，即IP及端口白名单；白名单中为允许容器与之通信的主机IP及端口，其中包括外界主机和本地其他容器；
步骤4.2：网络通信监控模块读入白名单，将白名单中的IP及端口转换成iptables规则文件；
步骤4.3：网络通信监控模块将步骤4.2中产生的规则文件载入iptables防火墙；
步骤4.4：用户自定义规则生效，容器只能和指定主机进行通信，若出现非授权通信行为，网络通信监控模块将立即阻止。
2.根据权利要求1所述的基于Docker的可信容器安全加固方法，其特征在于，步骤1.2中所述的可执行文件及关键配置文件包括：
/etc/bash_completion.d/docker；/etc/init.d/docker；/etc/default/docker；/var/lib/docker/init/dockerinit-1.6.0；/var/lib/docker/init/dockerinit-1.7.0-dev；/etc/init/docker.conf；/lib/systemd/system/docker.service；/lib/systemd/system/docker.socket；
3.根据权利要求1所述的基于Docker的可信容器安全加固方法，其特征在于，步骤1.4中所述的Docker获取镜像的方式有三种，包括从Registry下载镜像、将当前活动容器封装成镜像、从tar包读取镜像存于本地，这三种方式对应的Docker命令分别是pull、commit、load与save。
4.根据权利要求1所述的基于Docker的可信容器安全加固方法，其特征在于，步骤1.4中所述度量程序所度量的内容包括镜像的rootfs层、镜像配置信息以及层间关系文件。
5.根据权利要求1所述的基于Docker的可信容器安全加固方法，其特征在于，步骤1.4中所述的度量程序开始计算镜像的HASH基准值并加密存储，其具体实现过程是度量程序通过调用TPM提供的SHA-1引擎分别计算得到与镜像有关的各部分HASH值，并将他们连接起来再进行一次SHA-1，计算得到最后的HASH值，将此HASH值作为基准值，对其进行加密存储；所述的加密存储利用的是TPM提供的RSA密钥将hash值加密为512位密文最后将密文存入以镜像id命名的文件中。
6.根据权利要求1所述的基于Docker的可信容器安全加固方法，其特征在于，步骤2.2中所述的文件系统监控程序启动之后计算容器的文件系统的HASH值，Docker对文件系统监控程序可执行文件进行度量，度量的内容包括容器当前可读写层、读写层对应的init层以及层间关系文件。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510488809.8A CN105069353B (zh) | 2015-08-11 | 2015-08-11 | 一种基于Docker的可信容器安全加固方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510488809.8A CN105069353B (zh) | 2015-08-11 | 2015-08-11 | 一种基于Docker的可信容器安全加固方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105069353A true CN105069353A (zh) | 2015-11-18 |
| CN105069353B CN105069353B (zh) | 2017-10-24 |
Family
ID=54498716
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510488809.8A Active CN105069353B (zh) | 2015-08-11 | 2015-08-11 | 一种基于Docker的可信容器安全加固方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105069353B (zh) |
Cited By (54)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105704458A (zh) * | 2016-03-22 | 2016-06-22 | 北京邮电大学 | 基于容器技术的视频监控云服务的平台实现方法及系统 |
| CN105763670A (zh) * | 2016-04-08 | 2016-07-13 | 北京搜狐新媒体信息技术有限公司 | 一种为容器分配ip地址的方法及装置 |
| CN105824688A (zh) * | 2016-03-16 | 2016-08-03 | 合网络技术（北京）有限公司 | 一种解决docker容器启动并发瓶颈的方法 |
| CN106293875A (zh) * | 2016-08-04 | 2017-01-04 | 中国联合网络通信集团有限公司 | 一种Docker容器的创建方法和创建系统 |
| CN106878343A (zh) * | 2017-04-18 | 2017-06-20 | 北京百悟科技有限公司 | 一种云计算环境下提供网络安全即服务的系统 |
| CN107015995A (zh) * | 2016-01-28 | 2017-08-04 | 华为技术有限公司 | 一种镜像文件的修改方法和装置 |
| CN107239688A (zh) * | 2017-06-30 | 2017-10-10 | 平安科技（深圳）有限公司 | Docker镜像仓库的权限认证方法和系统 |
| CN107247910A (zh) * | 2017-08-11 | 2017-10-13 | 郑州云海信息技术有限公司 | 一种文件完整性度量检测方法、系统及检测设备 |
| CN107329792A (zh) * | 2017-07-04 | 2017-11-07 | 北京奇艺世纪科技有限公司 | 一种Docker容器启动方法及装置 |
| CN107368339A (zh) * | 2017-07-25 | 2017-11-21 | 上海携程商务有限公司 | 容器入口程序运行方法、系统、设备及存储介质 |
| CN107426152A (zh) * | 2017-04-07 | 2017-12-01 | 西安电子科技大学 | 云平台虚实互联环境下多任务安全隔离系统及方法 |
| CN107577937A (zh) * | 2017-09-01 | 2018-01-12 | 深信服科技股份有限公司 | 一种应用程序保护方法及系统 |
| CN107634951A (zh) * | 2017-09-22 | 2018-01-26 | 携程旅游网络技术（上海）有限公司 | Docker容器安全管理方法、系统、设备及存储介质 |
| WO2018040914A1 (zh) * | 2016-08-29 | 2018-03-08 | 阿里巴巴集团控股有限公司 | 生成容器的方法、装置、终端、服务器与系统 |
| CN107888708A (zh) * | 2017-12-25 | 2018-04-06 | 山大地纬软件股份有限公司 | 一种基于Docker容器集群的负载均衡算法 |
| WO2018076699A1 (zh) * | 2016-10-25 | 2018-05-03 | 西安中兴新软件有限责任公司 | 一种应用程序运行方法、装置及存储介质 |
| CN108021608A (zh) * | 2017-10-31 | 2018-05-11 | 赛尔网络有限公司 | 一种基于Docker的轻量级网站部署方法 |
| CN108156246A (zh) * | 2017-12-27 | 2018-06-12 | 北京星河星云信息技术有限公司 | 一种文件分发方法、系统、服务器及客户端 |
| CN108228842A (zh) * | 2018-01-08 | 2018-06-29 | 平安科技（深圳）有限公司 | Docker镜像库文件存储方法、终端、设备以及存储介质 |
| CN108241558A (zh) * | 2016-12-27 | 2018-07-03 | 中移(苏州)软件技术有限公司 | 一种镜像仓库备份装置和方法 |
| CN108319872A (zh) * | 2018-01-16 | 2018-07-24 | 湖北省楚天云有限公司 | 一种封闭容器生成方法、装置及设备 |
| CN108471420A (zh) * | 2018-03-29 | 2018-08-31 | 上交所技术有限责任公司 | 基于网络模式识别和匹配的容器安全防御方法与装置 |
| CN108958981A (zh) * | 2018-07-24 | 2018-12-07 | 广东浪潮大数据研究有限公司 | 一种基于docker的镜像保存方法及相关装置 |
| CN109155782A (zh) * | 2016-05-27 | 2019-01-04 | 华为技术有限公司 | 容器之间的进程间通信 |
| CN109190386A (zh) * | 2018-04-04 | 2019-01-11 | 中国电子科技网络信息安全有限公司 | 基于Device Mapper的容器镜像分层加密存储方法 |
| CN109416718A (zh) * | 2015-12-24 | 2019-03-01 | 英特尔公司 | 云数据中心中应用容器的可信部署 |
| WO2019128984A1 (zh) * | 2017-12-29 | 2019-07-04 | 华为技术有限公司 | 容器的安全策略的处理方法和相关装置 |
| US10360410B2 (en) | 2016-11-14 | 2019-07-23 | International Business Machines Corporation | Providing containers access to container daemon in multi-tenant environment |
| CN110046505A (zh) * | 2019-04-28 | 2019-07-23 | 联想(北京)有限公司 | 容器安全加固方法、系统及存储介质 |
| CN110069921A (zh) * | 2019-04-12 | 2019-07-30 | 中国科学院信息工程研究所 | 一种面向容器平台的可信软件授权验证系统及方法 |
| CN110187955A (zh) * | 2019-05-27 | 2019-08-30 | 四川大学 | 一种动静态结合的Docker容器内容安全性检测方法和装置 |
| CN110572288A (zh) * | 2019-11-04 | 2019-12-13 | 河南戎磐网络科技有限公司 | 一种基于可信容器的数据交换方法 |
| CN110647740A (zh) * | 2018-06-27 | 2020-01-03 | 复旦大学 | 一种基于tpm的容器可信启动方法及装置 |
| CN110851824A (zh) * | 2019-11-13 | 2020-02-28 | 哈尔滨工业大学 | 一种针对恶意容器的检测方法 |
| US10666443B2 (en) | 2016-10-18 | 2020-05-26 | Red Hat, Inc. | Continued verification and monitoring of application code in containerized execution environment |
| CN111562970A (zh) * | 2020-07-15 | 2020-08-21 | 腾讯科技（深圳）有限公司 | 容器实例的创建方法、装置、电子设备及存储介质 |
| CN111581654A (zh) * | 2020-05-08 | 2020-08-25 | 苏州深信达网络科技有限公司 | 一种加密芯片性能放大的方法 |
| CN111625834A (zh) * | 2020-05-15 | 2020-09-04 | 深圳开源互联网安全技术有限公司 | Docker镜像文件漏洞检测系统及检测方法 |
| CN111796904A (zh) * | 2020-05-21 | 2020-10-20 | 北京中软华泰信息技术有限责任公司 | 一种基于命名空间的Docker文件访问控制方法 |
| CN111857967A (zh) * | 2020-07-29 | 2020-10-30 | 中科方德软件有限公司 | 一种容器完整性校验方法 |
| CN111859468A (zh) * | 2020-08-05 | 2020-10-30 | 杭州安恒信息技术股份有限公司 | 一种容器网页防篡改方法、装置、设备及介质 |
| US10853090B2 (en) | 2018-01-22 | 2020-12-01 | Hewlett Packard Enterprise Development Lp | Integrity verification of an entity |
| CN113037467A (zh) * | 2021-05-24 | 2021-06-25 | 杭州海康威视数字技术股份有限公司 | 视频物联网设备密钥证书管理方法、装置和系统 |
| CN113221103A (zh) * | 2021-05-08 | 2021-08-06 | 山东英信计算机技术有限公司 | 一种容器安全防护方法、系统及介质 |
| CN113391880A (zh) * | 2021-06-21 | 2021-09-14 | 西安超越申泰信息科技有限公司 | 一种分层双重哈希验证的可信镜像传输方法 |
| CN114048485A (zh) * | 2021-11-12 | 2022-02-15 | 四川大学 | 一种针对Docker容器内进程代码段完整性动态监测方法 |
| US11269537B2 (en) | 2018-06-29 | 2022-03-08 | Seagate Technology Llc | Software containers with security policy enforcement at a data storage device level |
| US11307980B2 (en) | 2018-04-20 | 2022-04-19 | Seagate Technology Llc | Distributed data storage system with passthrough operations |
| CN114546598A (zh) * | 2022-02-25 | 2022-05-27 | 北京小佑网络科技有限公司 | 一种容器内进程、文件和网络访问控制方法 |
| CN115017504A (zh) * | 2022-04-15 | 2022-09-06 | 国网河南省电力公司电力科学研究院 | 一种智能物联终端容器安全管控方法 |
| CN116561811A (zh) * | 2023-07-11 | 2023-08-08 | 北京智芯微电子科技有限公司 | 文件可信防篡改方法、装置及电子设备 |
| CN116796331A (zh) * | 2023-04-26 | 2023-09-22 | 之江奇安科技有限公司 | 一种在podman中实现进程监控和白名单机制的自动化hook方法 |
| US11775655B2 (en) | 2021-05-11 | 2023-10-03 | International Business Machines Corporation | Risk assessment of a container build |
| US11874926B2 (en) | 2020-12-07 | 2024-01-16 | Hewlett Packard Enterprise Development Lp | Measuring containers |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103455756A (zh) * | 2013-08-02 | 2013-12-18 | 国家电网公司 | 一种基于可信计算的进程控制方法 |
| US20140007087A1 (en) * | 2012-06-29 | 2014-01-02 | Mark Scott-Nash | Virtual trusted platform module |
| CN104573507A (zh) * | 2015-02-05 | 2015-04-29 | 浪潮电子信息产业股份有限公司 | 一种安全容器及其设计方法 |
-
2015
- 2015-08-11 CN CN201510488809.8A patent/CN105069353B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140007087A1 (en) * | 2012-06-29 | 2014-01-02 | Mark Scott-Nash | Virtual trusted platform module |
| CN103455756A (zh) * | 2013-08-02 | 2013-12-18 | 国家电网公司 | 一种基于可信计算的进程控制方法 |
| CN104573507A (zh) * | 2015-02-05 | 2015-04-29 | 浪潮电子信息产业股份有限公司 | 一种安全容器及其设计方法 |
Cited By (80)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109416718A (zh) * | 2015-12-24 | 2019-03-01 | 英特尔公司 | 云数据中心中应用容器的可信部署 |
| CN109416718B (zh) * | 2015-12-24 | 2023-05-12 | 英特尔公司 | 云数据中心中应用容器的可信部署 |
| US11042643B2 (en) * | 2015-12-24 | 2021-06-22 | Intel Corporation | Trusted deployment of application containers in cloud data centers |
| CN107015995A (zh) * | 2016-01-28 | 2017-08-04 | 华为技术有限公司 | 一种镜像文件的修改方法和装置 |
| CN107015995B (zh) * | 2016-01-28 | 2021-01-05 | 华为技术有限公司 | 一种镜像文件的修改方法和装置 |
| CN105824688B (zh) * | 2016-03-16 | 2019-05-28 | 合一网络技术(北京)有限公司 | 一种解决docker容器启动并发瓶颈的方法 |
| CN105824688A (zh) * | 2016-03-16 | 2016-08-03 | 合网络技术（北京）有限公司 | 一种解决docker容器启动并发瓶颈的方法 |
| CN105704458A (zh) * | 2016-03-22 | 2016-06-22 | 北京邮电大学 | 基于容器技术的视频监控云服务的平台实现方法及系统 |
| CN105763670B (zh) * | 2016-04-08 | 2019-01-29 | 北京搜狐新媒体信息技术有限公司 | 一种为容器分配ip地址的方法及装置 |
| CN105763670A (zh) * | 2016-04-08 | 2016-07-13 | 北京搜狐新媒体信息技术有限公司 | 一种为容器分配ip地址的方法及装置 |
| CN109155782A (zh) * | 2016-05-27 | 2019-01-04 | 华为技术有限公司 | 容器之间的进程间通信 |
| CN106293875A (zh) * | 2016-08-04 | 2017-01-04 | 中国联合网络通信集团有限公司 | 一种Docker容器的创建方法和创建系统 |
| WO2018040914A1 (zh) * | 2016-08-29 | 2018-03-08 | 阿里巴巴集团控股有限公司 | 生成容器的方法、装置、终端、服务器与系统 |
| US10846073B2 (en) | 2016-08-29 | 2020-11-24 | Alibaba Group Holding Limited | Methods, apparatuses, terminals, servers, and systems for container generation |
| US10666443B2 (en) | 2016-10-18 | 2020-05-26 | Red Hat, Inc. | Continued verification and monitoring of application code in containerized execution environment |
| WO2018076699A1 (zh) * | 2016-10-25 | 2018-05-03 | 西安中兴新软件有限责任公司 | 一种应用程序运行方法、装置及存储介质 |
| US10360410B2 (en) | 2016-11-14 | 2019-07-23 | International Business Machines Corporation | Providing containers access to container daemon in multi-tenant environment |
| CN108241558A (zh) * | 2016-12-27 | 2018-07-03 | 中移(苏州)软件技术有限公司 | 一种镜像仓库备份装置和方法 |
| CN107426152B (zh) * | 2017-04-07 | 2019-11-26 | 西安电子科技大学 | 云平台虚实互联环境下多任务安全隔离系统及方法 |
| CN107426152A (zh) * | 2017-04-07 | 2017-12-01 | 西安电子科技大学 | 云平台虚实互联环境下多任务安全隔离系统及方法 |
| CN106878343B (zh) * | 2017-04-18 | 2019-09-20 | 北京百悟科技有限公司 | 一种云计算环境下提供网络安全即服务的系统 |
| CN106878343A (zh) * | 2017-04-18 | 2017-06-20 | 北京百悟科技有限公司 | 一种云计算环境下提供网络安全即服务的系统 |
| CN107239688B (zh) * | 2017-06-30 | 2019-07-23 | 平安科技（深圳）有限公司 | Docker镜像仓库的权限认证方法和系统 |
| CN107239688A (zh) * | 2017-06-30 | 2017-10-10 | 平安科技（深圳）有限公司 | Docker镜像仓库的权限认证方法和系统 |
| CN107329792B (zh) * | 2017-07-04 | 2020-05-22 | 北京奇艺世纪科技有限公司 | 一种Docker容器启动方法及装置 |
| CN107329792A (zh) * | 2017-07-04 | 2017-11-07 | 北京奇艺世纪科技有限公司 | 一种Docker容器启动方法及装置 |
| CN107368339A (zh) * | 2017-07-25 | 2017-11-21 | 上海携程商务有限公司 | 容器入口程序运行方法、系统、设备及存储介质 |
| CN107368339B (zh) * | 2017-07-25 | 2020-06-12 | 上海携程商务有限公司 | 容器入口程序运行方法、系统、设备及存储介质 |
| CN107247910A (zh) * | 2017-08-11 | 2017-10-13 | 郑州云海信息技术有限公司 | 一种文件完整性度量检测方法、系统及检测设备 |
| CN107577937B (zh) * | 2017-09-01 | 2021-05-04 | 深信服科技股份有限公司 | 一种应用程序保护方法及系统 |
| CN107577937A (zh) * | 2017-09-01 | 2018-01-12 | 深信服科技股份有限公司 | 一种应用程序保护方法及系统 |
| CN107634951A (zh) * | 2017-09-22 | 2018-01-26 | 携程旅游网络技术（上海）有限公司 | Docker容器安全管理方法、系统、设备及存储介质 |
| CN108021608A (zh) * | 2017-10-31 | 2018-05-11 | 赛尔网络有限公司 | 一种基于Docker的轻量级网站部署方法 |
| CN107888708A (zh) * | 2017-12-25 | 2018-04-06 | 山大地纬软件股份有限公司 | 一种基于Docker容器集群的负载均衡算法 |
| CN108156246A (zh) * | 2017-12-27 | 2018-06-12 | 北京星河星云信息技术有限公司 | 一种文件分发方法、系统、服务器及客户端 |
| CN108156246B (zh) * | 2017-12-27 | 2020-12-04 | 北京微网通联股份有限公司 | 一种文件分发方法、系统、服务器及客户端 |
| WO2019128984A1 (zh) * | 2017-12-29 | 2019-07-04 | 华为技术有限公司 | 容器的安全策略的处理方法和相关装置 |
| CN108228842A (zh) * | 2018-01-08 | 2018-06-29 | 平安科技（深圳）有限公司 | Docker镜像库文件存储方法、终端、设备以及存储介质 |
| CN108228842B (zh) * | 2018-01-08 | 2020-09-25 | 平安科技（深圳）有限公司 | Docker镜像库文件存储方法、终端、设备以及存储介质 |
| CN108319872A (zh) * | 2018-01-16 | 2018-07-24 | 湖北省楚天云有限公司 | 一种封闭容器生成方法、装置及设备 |
| CN108319872B (zh) * | 2018-01-16 | 2020-05-22 | 湖北省楚天云有限公司 | 一种封闭容器生成方法、装置及设备 |
| US10853090B2 (en) | 2018-01-22 | 2020-12-01 | Hewlett Packard Enterprise Development Lp | Integrity verification of an entity |
| CN108471420B (zh) * | 2018-03-29 | 2021-02-09 | 上交所技术有限责任公司 | 基于网络模式识别和匹配的容器安全防御方法与装置 |
| CN108471420A (zh) * | 2018-03-29 | 2018-08-31 | 上交所技术有限责任公司 | 基于网络模式识别和匹配的容器安全防御方法与装置 |
| CN109190386A (zh) * | 2018-04-04 | 2019-01-11 | 中国电子科技网络信息安全有限公司 | 基于Device Mapper的容器镜像分层加密存储方法 |
| US11307980B2 (en) | 2018-04-20 | 2022-04-19 | Seagate Technology Llc | Distributed data storage system with passthrough operations |
| CN110647740B (zh) * | 2018-06-27 | 2023-12-05 | 复旦大学 | 一种基于tpm的容器可信启动方法及装置 |
| CN110647740A (zh) * | 2018-06-27 | 2020-01-03 | 复旦大学 | 一种基于tpm的容器可信启动方法及装置 |
| US11269537B2 (en) | 2018-06-29 | 2022-03-08 | Seagate Technology Llc | Software containers with security policy enforcement at a data storage device level |
| CN108958981A (zh) * | 2018-07-24 | 2018-12-07 | 广东浪潮大数据研究有限公司 | 一种基于docker的镜像保存方法及相关装置 |
| CN110069921A (zh) * | 2019-04-12 | 2019-07-30 | 中国科学院信息工程研究所 | 一种面向容器平台的可信软件授权验证系统及方法 |
| CN110069921B (zh) * | 2019-04-12 | 2021-01-01 | 中国科学院信息工程研究所 | 一种面向容器平台的可信软件授权验证系统及方法 |
| CN110046505A (zh) * | 2019-04-28 | 2019-07-23 | 联想(北京)有限公司 | 容器安全加固方法、系统及存储介质 |
| CN110187955A (zh) * | 2019-05-27 | 2019-08-30 | 四川大学 | 一种动静态结合的Docker容器内容安全性检测方法和装置 |
| CN110572288A (zh) * | 2019-11-04 | 2019-12-13 | 河南戎磐网络科技有限公司 | 一种基于可信容器的数据交换方法 |
| CN110851824A (zh) * | 2019-11-13 | 2020-02-28 | 哈尔滨工业大学 | 一种针对恶意容器的检测方法 |
| CN111581654A (zh) * | 2020-05-08 | 2020-08-25 | 苏州深信达网络科技有限公司 | 一种加密芯片性能放大的方法 |
| CN111581654B (zh) * | 2020-05-08 | 2023-10-24 | 苏州深信达网络科技有限公司 | 一种加密芯片性能放大的方法 |
| CN111625834A (zh) * | 2020-05-15 | 2020-09-04 | 深圳开源互联网安全技术有限公司 | Docker镜像文件漏洞检测系统及检测方法 |
| CN111796904A (zh) * | 2020-05-21 | 2020-10-20 | 北京中软华泰信息技术有限责任公司 | 一种基于命名空间的Docker文件访问控制方法 |
| CN111796904B (zh) * | 2020-05-21 | 2024-02-20 | 北京中软华泰信息技术有限责任公司 | 一种基于命名空间的Docker文件访问控制方法 |
| CN111562970A (zh) * | 2020-07-15 | 2020-08-21 | 腾讯科技（深圳）有限公司 | 容器实例的创建方法、装置、电子设备及存储介质 |
| CN111857967B (zh) * | 2020-07-29 | 2022-04-12 | 中科方德软件有限公司 | 一种容器完整性校验方法 |
| CN111857967A (zh) * | 2020-07-29 | 2020-10-30 | 中科方德软件有限公司 | 一种容器完整性校验方法 |
| CN111859468A (zh) * | 2020-08-05 | 2020-10-30 | 杭州安恒信息技术股份有限公司 | 一种容器网页防篡改方法、装置、设备及介质 |
| US11874926B2 (en) | 2020-12-07 | 2024-01-16 | Hewlett Packard Enterprise Development Lp | Measuring containers |
| CN113221103A (zh) * | 2021-05-08 | 2021-08-06 | 山东英信计算机技术有限公司 | 一种容器安全防护方法、系统及介质 |
| CN113221103B (zh) * | 2021-05-08 | 2022-09-20 | 山东英信计算机技术有限公司 | 一种容器安全防护方法、系统及介质 |
| US11775655B2 (en) | 2021-05-11 | 2023-10-03 | International Business Machines Corporation | Risk assessment of a container build |
| CN113037467B (zh) * | 2021-05-24 | 2021-08-24 | 杭州海康威视数字技术股份有限公司 | 视频物联网设备密钥证书管理方法、装置和系统 |
| CN113037467A (zh) * | 2021-05-24 | 2021-06-25 | 杭州海康威视数字技术股份有限公司 | 视频物联网设备密钥证书管理方法、装置和系统 |
| CN113391880A (zh) * | 2021-06-21 | 2021-09-14 | 西安超越申泰信息科技有限公司 | 一种分层双重哈希验证的可信镜像传输方法 |
| CN114048485B (zh) * | 2021-11-12 | 2023-04-07 | 四川大学 | 一种针对Docker容器内进程代码段完整性动态监测方法 |
| CN114048485A (zh) * | 2021-11-12 | 2022-02-15 | 四川大学 | 一种针对Docker容器内进程代码段完整性动态监测方法 |
| CN114546598B (zh) * | 2022-02-25 | 2022-10-21 | 北京小佑网络科技有限公司 | 一种容器内进程、文件和网络访问控制方法 |
| CN114546598A (zh) * | 2022-02-25 | 2022-05-27 | 北京小佑网络科技有限公司 | 一种容器内进程、文件和网络访问控制方法 |
| CN115017504A (zh) * | 2022-04-15 | 2022-09-06 | 国网河南省电力公司电力科学研究院 | 一种智能物联终端容器安全管控方法 |
| CN116796331A (zh) * | 2023-04-26 | 2023-09-22 | 之江奇安科技有限公司 | 一种在podman中实现进程监控和白名单机制的自动化hook方法 |
| CN116796331B (zh) * | 2023-04-26 | 2024-04-05 | 之江奇安科技有限公司 | 一种在podman中实现进程监控和白名单机制的自动化hook方法 |
| CN116561811A (zh) * | 2023-07-11 | 2023-08-08 | 北京智芯微电子科技有限公司 | 文件可信防篡改方法、装置及电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105069353B (zh) | 2017-10-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105069353A (zh) | 一种基于Docker的可信容器安全加固方法 | |
| Regenscheid et al. | Recommendations of the national institute of standards and technology | |
| US10176330B2 (en) | Global platform health management | |
| US10181037B2 (en) | Secure creation of encrypted virtual machines from encrypted templates | |
| US7506380B2 (en) | Systems and methods for boot recovery in a secure boot process on a computer with a hardware security module | |
| US8028172B2 (en) | Systems and methods for updating a secure boot process on a computer with a hardware security module | |
| US8566815B2 (en) | Mechanism for updating software | |
| US10915632B2 (en) | Handling of remote attestation and sealing during concurrent update | |
| US8689318B2 (en) | Trusted computing entities | |
| NZ540356A (en) | System and method for protected operating system boot using state validation | |
| US11416604B2 (en) | Enclave handling on an execution platform | |
| TW201944241A (zh) | 基本輸入輸出系統活動之本地監督及供應 | |
| CN111177708A (zh) | 基于tcm芯片的plc可信度量方法、系统及度量装置 | |
| EP3338214B1 (en) | Secure computation environment | |
| CN112446029A (zh) | 可信计算平台 | |
| Yao et al. | Building Secure Firmware | |
| Regenscheid et al. | BIOS Integrity Measurement Guidelines (Draft) | |
| Sisinni | Verification of Software Integrity in Distributed Systems | |
| Yao et al. | Trusted Boot | |
| Yao et al. | Proactive Firmware Security Development | |
| Liu et al. | Penetrating Machine Learning Servers via Exploiting BMC Vulnerability | |
| Mancini et al. | Ephemeral classification of mobile terminals | |
| Guo-qing et al. | Analysis and application for integrity model on trusted platform | |
| CN114662092A (zh) | 一种容器安全执行方法、设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |