A high-value data encryption system and method in a localization environment

Abstract

This invention discloses a domestically developed encryption system and method for high-value data in the field of data encryption technology, comprising: environment preparation: installing a Docker runtime environment on a Kylin operating system and ensuring that the SELinux security subsystem is in forced mode; encrypted volume preparation: after completing the environment preparation, creating a LUKS encrypted volume for physical storage space on the host machine, initializing the volume using an encryption key, and creating a file system; security policy configuration: after completing the encrypted volume preparation, creating and loading a custom SELinux policy module, wherein the defined security rules are configured to: deny access operations of the host machine process domain to the LUKS encrypted volume device file, while allowing access operations of the Docker container process domain to the LUKS encrypted volume device file. This invention achieves high-value data encryption based on Docker containers and LUKS encrypted volumes in a Kylin operating system environment, realizing strong encrypted data storage.

Description

Technical Field

[0001] This invention relates to an encryption system and method for high-value data in a domestically produced environment, belonging to the field of data encryption technology. Background Technology

[0002] With the development of information security technologies, domestically developed operating systems have been widely deployed across various fields. Meanwhile, container technologies such as Docker, due to their lightweight and portable characteristics, are widely used in application deployment. Installing and using Docker on the Kylin operating system has become a common requirement, and related technologies have matured.

[0003] While existing technologies achieve container-based data encryption and access control, they primarily rely on RBAC (Restricted Access Control) and fail to provide complete encryption isolation at the storage layer. The host machine can still potentially bypass access controls to access encrypted data, posing a security risk. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide an encryption system and method for high-value data in a domestic environment, realizing the encryption of high-value data based on Docker containers and LUKS encrypted volumes in the Kylin operating system environment, and achieving strong encrypted storage of data.

[0005] To achieve the above objectives, the present invention is implemented using the following technical solution:

[0006] Firstly, this invention provides a method for encrypting high-value data in a domestically produced environment, comprising:

[0007] Environment preparation: Install the Docker runtime environment on the Kylin operating system and ensure that the SELinux security subsystem is in forced mode;

[0008] Encrypted Volume Preparation: After completing the environment preparation, a LUKS encrypted volume is created on the host machine for the physical storage space. The volume is initialized using an encryption key, and a file system is created. Before creating the LUKS encrypted volume, encryption parameters are selected through an evaluation model, which is as follows:

[0009]

[0010] In the formula: T estimated For the estimated total I / O operation latency; S data C represents the average size of the data blocks expected to be processed; encryption T represents the computational complexity coefficient of the selected encryption algorithm. throughput This refers to the raw throughput of the underlying storage device; O luks A fixed empirical estimate of the overhead of the LUKS layer; O dockerEmpirical estimates of the fixed overhead of the Docker storage driver layer;

[0011] Security policy configuration: After the encrypted volume preparation is completed, a custom SELinux policy module is created and loaded, in which the defined security rules are configured to: deny the host process domain from accessing the LUKS encrypted volume device file, while allowing the Docker container process domain to access the LUKS encrypted volume device file;

[0012] Secure container startup: After the security policy configuration takes effect, a Docker container is started as a secure container, and the LUKS encrypted volume device file of the host machine is mapped into the secure container at startup;

[0013] Decryption and mounting within the container: After the secure container starts, the encryption key is used inside the secure container to open the LUKS encrypted volume mapped into the container, decrypt it into a block device, and mount the block device to a specified directory inside the container;

[0014] Secure data access: Authorized applications within the secure container can read and write the high-value data by accessing the designated directory; during this process, processes on the host machine are restricted by the SELinux policy and cannot access the data within the LUKS encrypted volume.

[0015] Furthermore, the installation of the Docker runtime environment specifically includes: obtaining the Docker Community Edition installation package through a software source compatible with Ubuntu, and performing installation and service startup verification.

[0016] Furthermore, the encryption key is managed in one of the following ways: injected via environment variables when the container starts, passed via the Docker Secrets mechanism, or dynamically generated and obtained by a key management service started within the container.

[0017] Furthermore, the rule definitions of the custom SELinux policy module include:

[0018] Deny the host process domain unconfined_t from performing block device operations and file operations on device type block_device_t;

[0019] Allows the container process domain container_t to perform block device operations and file operations on device type block_device_t.

[0020] Furthermore, the LUKS encrypted volume device file is mapped into the secure container via the `--device` parameter of the Docker command.

[0021] Furthermore, the encryption algorithm used in the LUKS encrypted volume is the national cryptographic algorithm SM4, which conforms to the standards of the State Cryptography Administration.

[0022] Furthermore, the method also includes a container stop and cleanup phase: unloading the mounted decrypted volume and closing the LUKS encryption mapping inside the secure container, and then stopping and removing the secure container.

[0023] Secondly, this invention provides an encryption system for high-value data in a domestically developed environment, comprising:

[0024] Environment preparation module: Used to install the Docker runtime environment on the Kylin operating system and ensure that the SELinux security subsystem is in forced mode;

[0025] Encrypted Volume Preparation Module: After completing the environment preparation, this module creates a LUKS encrypted volume for the physical storage space on the host machine, initializes the volume using an encryption key, and creates a file system. Before creating the LUKS encrypted volume, encryption parameters are selected through an evaluation model, which is as follows:

[0026]

[0027] In the formula: T estimated For the estimated total I / O operation latency; S data C represents the average size of the data blocks expected to be processed; encryption T represents the computational complexity coefficient of the selected encryption algorithm. throughput This refers to the raw throughput of the underlying storage device; O luks A fixed empirical estimate of the overhead of the LUKS layer; O docker Empirical estimates of the fixed overhead of the Docker storage driver layer;

[0028] Security policy configuration module: After the encrypted volume preparation is completed, it is used to create and load a custom SELinux policy module, in which the defined security rules are configured to: deny the host process domain from accessing the LUKS encrypted volume device file, while allowing the Docker container process domain to access the LUKS encrypted volume device file;

[0029] Secure container startup module: After the security policy configuration takes effect, it starts a Docker container as a secure container, and maps the LUKS encrypted volume device file of the host machine into the secure container at startup;

[0030] Container decryption and mounting module: After the secure container starts, it is used to open the LUKS encrypted volume mapped into the container using the encryption key inside the secure container, decrypt it into a block device, and mount the block device to a specified directory inside the container;

[0031] Data security access module: This module is used by authorized applications within the secure container to read and write high-value data by accessing the specified directory. During this process, processes on the host machine are restricted by the SELinux policy and cannot access the data within the LUKS encrypted volume.

[0032] Thirdly, the present invention provides an encryption device for high-value data in a domestically produced environment, including a processor and a storage medium;

[0033] The storage medium is used to store instructions;

[0034] The processor is configured to operate according to the instructions to perform the steps of the method according to any of the foregoing.

[0035] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0036] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0037] 1. This solution completely restricts the mounting and access of the LUKS encrypted volume to within the Docker container, and key management is also completed within the container. Compared to the RBAC access control patented by ZhongAn Wangmai, this solution achieves data isolation at the storage layer, completely eliminating the possibility of host programs accessing encrypted data, resulting in higher security. Compared to the K8s logical volume encryption solution patented by JD Technology, this solution directly combines the LUKS encrypted volume with the Docker container, leveraging Docker's isolation features to enhance data security. The lifecycle of the encrypted volume is closely linked to the container, improving the overall security and management efficiency of the solution. In addition, this solution is specifically optimized for the Kylin operating system, fully utilizing its system features and security mechanisms. Compared to the general design of existing solutions, this solution offers better performance and security in a domestic environment.

[0038] II. This solution employs LUKS encryption technology, supporting multiple strong encryption algorithms. Compared to simple file encryption or partition encryption, it provides a higher level of data protection. Furthermore, this solution can flexibly integrate national cryptographic algorithms to meet compliance requirements in specific fields. This solution does not rely on a specific container orchestration platform, is suitable for single-machine Docker environments, is simple to deploy, and is suitable for small to medium-sized application scenarios. It can also be extended to container cluster environments. Combining the characteristics of Docker containers and file system permission management, this solution enables fine-grained access control of encrypted data, ensuring that only specific programs can access high-value data. Compared to network storage-based encryption solutions, this solution's local LUKS encrypted volume solution reduces network transmission and protocol processing overhead, providing higher performance while ensuring security. Attached Figure Description

[0039] The accompanying drawings, which form part of this specification, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0040] Figure 1 This is a flowchart illustrating a method for encrypting high-value data in a domestically produced environment, as provided in Embodiment 1 of the present invention. Detailed Implementation

[0041] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0042] The following detailed description is exemplary and intended to provide further detailed explanation of the invention. Unless otherwise specified, all technical terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this invention is for describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention.

[0043] Example 1:

[0044] Please see Figure 1 This embodiment provides a method for encrypting high-value data in a domestically produced environment, which mainly includes the following steps:

[0045] (1) Environmental preparation stage

[0046] a. Ensure the system is updated to the latest version:

[0047] sudo apt update && sudo apt upgrade -y

[0048] b. Uninstall the old version of Docker (if any):

[0049] sudo apt remove docker docker-engine docker.io containerd runc

[0050] c. Install the dependencies required by Docker to support HTTPS repository and container functionality:

[0051] sudo apt install -y apt-transport-https ca-certificates curlsoftware-properties-common gnupg lsb-release

[0052] d. Add the official Docker GPG key:

[0053] curl -fsSL https: / / download.docker.com / linux / ubuntu / gpg | sudo gpg --dearmor -o / usr / share / keyrings / docker-archive-keyring.gpg

[0054] e. Add a stable Docker repository:

[0055] echo "deb [arch=$(dpkg --print-architecture) signed-by= / usr / share / keyrings / docker-archive-keyring.gpg] https: / / download.docker.com / linux / ubuntu$(lsb_release -cs) stable" | sudo tee / etc / apt / sources.list.d / docker.list > / dev / null

[0056] Note: Kylin OS is typically compatible with Ubuntu's software repositories. $(lsb_release -cs) will automatically retrieve the system codename (such as focal, bionic, etc.).

[0057] f. Install the latest version of Docker CE (Community Edition) and related components.

[0058] sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

[0059] g. Start the Docker service:

[0060] sudo systemctl start docker

[0061] h. Verify that Docker is installed successfully:

[0062] # Check Docker version

[0063] docker --version

[0064] # Run the hello-world image test

[0065] sudo docker run hello-world

[0066] If the output shows "Hello from Docker!", the installation was successful.

[0067] i. Prepare a physical storage device or partition (such as / dev / sdb3) for storing high-value data, and ensure that the device can be recognized in the Kylin operating system.

[0068] (2) LUKS Encrypted Volume Creation Phase

[0069] a. Use the cryptsetup tool to create a LUKS encrypted volume on the specified storage device:

[0070] cryptsetup luksFormat / dev / sdb3

[0071] This command will perform encryption initialization on the specified device and set parameters such as the encryption key.

[0072] b. Open the LUKS encrypted volume and create a mapped device:

[0073] cryptsetup open / dev / sdb3 my-luksdisk

[0074] Executing this command will create the / dev / mapper / my-luksdisk mapped device, which can be used to access the encrypted volume later.

[0075] c. Create a file system on the encrypted volume:

[0076] mkfs.ext4 / dev / mapper / my-luksdisk

[0077] d. Temporarily mount the encrypted volume and perform initial configuration:

[0078] mkdir / mnt / my-luksdisk

[0079] mount / dev / mapper / my-luksdisk / mnt / my-luksdisk

[0080] e. After initialization is complete, unmount the encrypted volume and disable the LUKS mapping:

[0081] umount -l / mnt / my-luksdisk

[0082] cryptsetup close my-luksdisk

[0083] Additionally, before creating the encrypted volume, the system administrator can perform a pre-evaluation to select the optimal encryption parameters. The evaluation model is as follows:

[0084]

[0085] In the formula: T estimated This is the estimated total I / O operation latency, used to predict performance under different configurations; a lower value indicates better performance. data C represents the average size of the data blocks expected to be processed; encryption T represents the computational complexity coefficient of the selected encryption algorithm. throughput This refers to the raw throughput of the underlying storage device; O luks A fixed empirical estimate of the overhead of the LUKS layer; O docker This provides an empirical estimate of the fixed overhead of the Docker storage driver layer. System administrators use this formula, inputting the planned algorithm coefficients and device throughput, to calculate the estimated latency T. estimated By comparing different algorithms (C encryption ) or different storage devices (T throughput T under ) estimated Administrators can choose the optimal encryption configuration that meets application performance requirements (such as choosing SM4 instead of AES-256, or using a higher-performance SSD) to achieve a balance between security and performance.

[0086] (3) Docker container configuration phase

[0087] a. Create and start a Docker container with privileged permissions, while mapping the encrypted device inside the container:

[0088] docker run --privileged --device / dev / sdb3 -itd --name secure_container [image name]

[0089] The `--privileged` parameter ensures that the container has sufficient permissions to operate the encrypted device, while the `--device` parameter maps the physical encrypted device into the container.

[0090] b. Enter a running container:

[0091] docker exec -it secure_container / bin / bash

[0092] c. Install the cryptsetup tool and related dependencies inside the container:

[0093] apt update && apt install -y cryptsetup

[0094] d. Load the dm_mod kernel module to ensure LUKS functionality is working correctly:

[0095] modprobe dm_mod

[0096] (4) Encrypted volume mounting stage within the container

[0097] a. Open the LUKS encrypted volume inside the container:

[0098] cryptsetup open / dev / sdb3 my-luksdisk

[0099] To automatically enter the key, use the `--key-file` parameter:

[0100] cryptsetup open --key-file / path / to / keyfile / dev / sdb3 my-luksdisk

[0101] The key file should exist only inside the container to ensure that the host machine cannot access it.

[0102] b. Create a mount point within the container and mount the encrypted volume:

[0103] mkdir / container / my-luksdisk

[0104] mount / dev / mapper / my-luksdisk / container / my-luksdisk

[0105] (5) Access Control Phase

[0106] a. Install permission management tools within the container:

[0107] # Execute within the container: Update software sources and install ACL tools

[0108] apt update && apt install -y acl

[0109] b. Create separate user groups (such as secure_app_group) and users (such as secure_app_user) for authorized programs to avoid running programs directly as root and reduce the risk of permission leaks:

[0110] # 1. Create an authorized user group (the GID can be customized, such as 1001, to avoid conflicts with other user groups within the container)

[0111] groupadd -g 1001 secure_app_group

[0112] # 2. Create an authorized user (UID 1001, belonging to secure_app_group, no home directory created, only for running the application)

[0113] useradd -u 1001 -g secure_app_group -M -s / sbin / nologin secure_app_user

[0114] # Note: -M prevents the creation of a home directory; -s / sbin / nologin disables direct user login and is only used for program execution authentication.

[0115] c. Set the owner of the encrypted data directory to root (to prevent ordinary users from tampering with the directory itself), set the group to secure_app_group (only authorized groups have access), and restrict other users to no permissions:

[0116] # 1. Change directory owner and group

[0117] chown root:secure_app_group / mount / point

[0118] # 2. Set directory permissions: Owner (root) has read, write, and execute permissions; Group (secure_app_group) has read, write, and execute permissions; other users have no permissions.

[0119] chmod 770 / mount / point

[0120] # Permission Description: 7 (rwx) - Owner permissions, 7 (rwx) - Group permissions, 0 (---) - Permissions for other users

[0121] d. If the authorization program needs to run as the secure_app_user, append recursive permissions to the directory for that user via ACL (ensuring that newly added files in the directory also inherit permissions), while denying access to other users (even those belonging to the same group):

[0122] setfacl -R -mu:secure_app_user:rwx / mount / point

[0123] # Option descriptions: -R recursively process subdirectories, -m add a new ACL rule, u:username:permissions specify user permissions.

[0124] # 2. Deny access to this directory to all other users within the container (except root and secure_app_user).

[0125] setfacl -R -mo::--- / mount / point

[0126] # Option explanation: o::--- indicates that "other users" have no permissions (overriding the default permissions for other users set by chmod).

[0127] # 3. (Optional) Prevent ACL permissions from being inherited and tampered with: Set the default ACL for the directory (new files will automatically inherit the rules).

[0128] setfacl -R -d -mu:secure_app_user:rwx / mount / point

[0129] setfacl -R -d -mo::--- / mount / point

[0130] # Option explanation: -d indicates "default ACL", which applies to subsequently added files / directories.

[0131] e. Ensure that authorized applications can only be launched as the secure_app_user account (avoid running as root or other users, which could lead to permission overflow):

[0132] # Execute within the container: Switch to the secure_app_user identity to run the authorized program (e.g., / opt / secure_app / run.sh)

[0133] su -s / bin / bash secure_app_user -c " / opt / secure_app / run.sh"

[0134] # Note: -s / bin / bash specifies the shell, -c is followed by the program startup command to ensure the program accesses the directory as an authorized user.

[0135] f. Verify the validity of the permission configuration. Execute the following command to confirm whether the permissions are effective and ensure that unauthorized users / programs cannot access the site:

[0136] # 1. View the basic permissions and owner of the directory

[0137] ls -ld / mount / point

[0138] # Expected output: drwxrwx---+ 2 root secure_app_group 4096 Oct 10 10:00 / mount / point

[0139] # Note: The "+" at the end indicates that ACL permissions are enabled.

[0140] # 2. View the detailed ACL rules of the directory

[0141] getfacl / mount / point

[0142] # Expected output includes:

[0143] # user::rwx (root privileges)

[0144] # user:secure_app_user:rwx (grant user permissions)

[0145] # group::rwx (secure_app_group permission)

[0146] # other::--- (Other users do not have permission)

[0147] # default:user:secure_app_user:rwx (Default ACL rule)

[0148] # 3. Test unauthorized user access (e.g., switch to the default "guest" user within the container).

[0149] su - guest

[0150] # Attempt to access the directory, expected to be denied.

[0151] ls / mount / point

[0152] # Expected output: ls: cannot access ' / mount / point': Permission denied

[0153] (6) Key Management Phase

[0154] Implement a secure key management mechanism, for example:

[0155] The key is injected via a secure channel when the container starts.

[0156] Automatic key rotation periodically

[0157] Encrypt the key using national cryptographic algorithms (such as SM4).

[0158] The following example illustrates how to achieve secure key management, using the injection of a key through a secure channel during container startup as an example.

[0159] a. Install Vault. Vault is an open-source key management tool that supports TLS encrypted transmission, dynamic key generation, and fine-grained access control. It can be integrated with the Kylin operating system to achieve "on-demand key injection," leaving no key residue on the host machine.

[0160] # Download the Vault binary package (Kylin system is x86_64 architecture)

[0161] wget https: / / releases.hashicorp.com / vault / 1.15.0 / vault_1.15.0_linux_amd64.zip

[0162] unzip vault_1.15.0_linux_amd64.zip

[0163] mv vault / usr / local / bin /

[0164] chmod +x / usr / local / bin / vault

[0165] # Start Vault development mode (for testing purposes; TLS and persistent storage need to be configured for production).

[0166] vault server -dev -dev-listen-address=0.0.0.0:8200

[0167] # Record the "Root Token" (e.g., hvs.xxxxxx) in the startup log for later authorization.

[0168] b. Store the LUKS key in Vault (Operation on the Kylin host machine). Create a key storage path using the Vault CLI and write the encrypted LUKS key (it is recommended to encrypt the key using SM4 on the Kylin system first):

[0169] # 1. Configure Vault environment variables (specify Vault service address and Root Token)

[0170] export VAULT_ADDR=http: / / 192.168.1.100:8200 # Vault service IP address for Kylin system

[0171] export VAULT_TOKEN=hvs.xxxxxx # Replace with the actual Root Token

[0172] # 2. Create a key storage path (e.g., "kylin / luks") and enable the KV storage engine.

[0173] vault secrets enable -path=kylin kv-v2

[0174] # 3. Write the LUKS key (the example key is encrypted with SM4, and the value is base64 encoded to avoid special characters).

[0175] vault kv put kylin / luks volume_key="$(echo -n 'KylinLuks_SecretKey_SM4' | base64)"

[0176] # Verify write results: vault kv get kylin / luks

[0177] c. Create a Vault policy file kylin_luks_policy.hcl, restricting it to reading only keys from the kylin / luks path:

[0178] # Contents of the Kylin System Vault Policy File

[0179] path "kylin / data / luks" {

[0180] capabilities = ["read"] # Allow reading only, disable writing / deletion

[0181] }

[0182] d. Load the strategy and create a container-specific "AppRole" identity (avoid using the Root Token):

[0183] # 1. Load the policy into Vault

[0184] vault policy write kylin_luks_policy kylin_luks_policy.hcl

[0185] # 2. Enable AppRole authentication (the container obtains permissions via RoleID / SecretID)

[0186] vault auth enable approle

[0187] # 3. Create an AppRole and bind a policy

[0188] vault write auth / approle / role / kylin_luks_role \

[0189] policies=kylin_luks_policy \

[0190] secret_id_ttl=1h # SecretID expires automatically after 1 hour.

[0191] token_ttl=30m # The token obtained by the container is valid for 30 minutes.

[0192] # 4. Obtain RoleID (Required when starting the container; can be public)

[0193] vault read auth / approle / role / kylin_luks_role / role-id

[0194] # Output example: role_id 123e4567-e89b-12d3-a456-426614174000

[0195] # 5. Obtain the SecretID (temporarily valid, generated before container startup)

[0196] vault write -f auth / approle / role / kylin_luks_role / secret-id

[0197] # Output example: secret_id 789f0123-e456-78d9-b012-345678901234

[0198] e. The key is injected via the Vault secure channel during container startup. The Vault CLI is installed inside the container, and a TLS request is initiated to Vault via RoleID / SecretID to obtain the key. No plaintext key is ever stored on the host machine throughout the process.

[0199] # 1. Start the container (map the encrypted device, pass in the Vault connection parameters and AppRole credentials)

[0200] docker run --name secure_container \

[0201] --privileged \

[0202] --device / dev / sdb3: / dev / sdb3 \

[0203] -e VAULT_ADDR=http: / / 192.168.1.100:8200 \ # Vault service address (encrypted transmission via environment variable)

[0204] -e VAULT_ROLE_ID=123e4567-e89b-12d3-a456-426614174000 \ #AppRole's RoleID

[0205] -e VAULT_SECRET_ID=789f0123-e456-78d9-b012-345678901234 \ # Temporary Secret ID

[0206] -itd debian:latest

[0207] # 2. Enter the container, install the Vault CLI, and obtain the key.

[0208] docker exec -it secure_container / bin / bash

[0209] # Execute within the container:

[0210] apt update && apt install -y wget unzip base64

[0211] wget https: / / releases.hashicorp.com / vault / 1.15.0 / vault_1.15.0_linux_amd64.zip

[0212] unzip vault_1.15.0_linux_amd64.zip && mv vault / usr / local / bin /

[0213] # 3. Log in to Vault using your AppRole credentials and obtain the key (channel TLS encryption).

[0214] vault login -method=approle role_id=$VAULT_ROLE_ID secret_id=$VAULT_SECRET_ID

[0215] # Read and decode the key (base64 decoded to the original LUKS key)

[0216] vault kv get -field=volume_key kylin / luks | base64 -d > / tmp / luks_key.tmp

[0217] chmod 400 / tmp / luks_key.tmp # Restrict permissions on the key file

[0218] # 4. Use the key to unlock the LUKS encrypted volume

[0219] cryptsetup open / dev / sdb3 myluksdisk --key-file / tmp / luks_key.tmp

[0220] `rm -f / tmp / luks_key.tmp` # Delete the temporary key file immediately after unlocking.

[0221] (7) Security policy configuration phase

[0222] Configure additional security policies at the Kylin operating system level, such as SELinux rules, to further restrict access to encrypted devices. The specific steps are as follows:

[0223] a. The Kylin operating system enables SELinux by default, but you need to first confirm that its status and dependent tools are complete to avoid invalid rule configurations. Check SELinux running status:

[0224] # 1. Check the current SELinux mode (Enforcing = enforced, Permissive = tolerant mode, Disabled = disabled)

[0225] getenforce

[0226] # 2. Check the detailed SELinux configuration (confirm whether it is enabled in the configuration file).

[0227] sestatus

[0228] If the output is Disabled: You need to enable SELinux first (edit / etc / selinux / config, set SELINUX=enforcing, and restart the system for the changes to take effect).

[0229] If the output is Permissive: You can temporarily switch to forced mode (setenforce 1), and then permanently configure it after the test rule takes effect.

[0230] b. The Kylin system requires the installation of policycoreutils (basic tools) and policycoreutils-devel (module compilation tools). The commands are as follows:

[0231] yum install -y policycoreutils policycoreutils-devel

[0232] c. Verify the SELinux label of the encrypted device. SELinux identifies resources (such as devices and files) through "labels." First, obtain the default label of the encrypted device (such as / dev / sdb3) to ensure the rules match accurately:

[0233] # Check the SELinux labels on encrypted devices (pay special attention to the label information in the last column).

[0234] ls -Z / dev / sdb3

[0235] Example of expected output: brw-rw----. root disk system_u:object_r:block_device_t:s0 / dev / sdb3

[0236] Key tags: block_device_t (default type for block devices), system_u:object_r (user / role). Subsequent rules must be based on these tags.

[0237] d. Directly modifying the system's default SELinux policy carries significant risk. It is recommended to create a custom module (e.g., named docker_luks_device) to implement permission control that "denies access to host processes but allows access to Docker containers." Create a new file named docker_luks_device.te and write the following content:

[0238] # 1. Declare module name and version

[0239] module docker_luks_device 1.0;

[0240] # 2. Depend on system-level policies (ensure modules can recognize SELinux built-in types)

[0241] require {

[0242] type unconfined_t; # The default domain for host user processes (such as terminal commands and non-container processes).

[0243] type container_t; # The default domain for Docker container processes (this domain also applies to privileged containers).

[0244] type block_device_t; # SELinux type of the encrypted device (obtained from step 1)

[0245] class block_device { open read write ioctl getattr}; # Device operations to be managed (open, read, write, control, etc.)

[0246] class file { read write open getattr}; # Basic operation permissions for the device file

[0247] };

[0248] # 3. Core Rule 1: Deny host processes (unconfined_t domain) access to encrypted devices

[0249] deny unconfined_t block_device_t:block_device { open read write ioctlgetattr};

[0250] deny unconfined_t block_device_t:file { open read write getattr};

[0251] # 4. Core Rule 2: Allow Docker container processes (container_t domain) to access encrypted devices.

[0252] allow container_t block_device_t:block_device { open read write ioctlgetattr};

[0253] allow container_t block_device_t:file { open read write getattr};

[0254] Rule logic explanation:

[0255] `unconfined_t` is the domain of the vast majority of processes on the host machine (such as the root terminal and system services), denying them access to encrypted devices and completely blocking direct operation by the host machine;

[0256] container_t is the default domain for Docker container processes, allowing them to access encrypted devices and ensuring that LUKS volumes can be mounted correctly within the container.

[0257] e. Compile and load the custom SELinux module. SELinux modules must be compiled into .pp format to be loaded. Use the checkmodule (compile) and semodule (load) tools:

[0258] # 1. Compile .te files into intermediate modules (.mod)

[0259] checkmodule -M -m -o docker_luks_device.mod docker_luks_device.te

[0260] # Option descriptions: -M generates a modular strategy, -m generates modules, -o specifies the output file

[0261] # 2. Package the intermediate modules into a loadable strategy package (.pp).

[0262] semodule_package -o docker_luks_device.pp -m docker_luks_device.mod

[0263] # Option description: -o specifies the output strategy package, -m specifies the input intermediate module

[0264] # 3. Load the policy package into the SELinux kernel (takes effect immediately)

[0265] semodule -i docker_luks_device.pp

[0266] # 4. Verify whether the module has been loaded successfully (view the loaded custom modules)

[0267] semodule -l | grep docker_luks_device

[0268] f. Configure persistent encryption device labels. If the SELinux label for the encryption device ( / dev / sdb3) is reset after a Kylin system reboot, you need to use `semanage` to fix the label and ensure the rule remains effective.

[0269] # 1. Add a persistent tag to the encrypted device (matching the block_device_t type from step 1)

[0270] semanage fcontext -a -t block_device_t " / dev / sdb3"

[0271] # Option descriptions: -a Add rule, -t Specify label type, " / dev / sdb3" Target device

[0272] # 2. Application Tag Configuration (Effective immediately, no restart required)

[0273] restorecon -v / dev / sdb3

[0274] # Option description: -v Displays the execution process, ensuring labels are applied correctly.

[0275] g. Verify the validity of SELinux rules. After configuration, you need to test access on both the host machine and the Docker container to confirm that the rules are effective:

[0276] Host machine testing (access should be denied)

[0277] # Attempt to read an encrypted device (simulating host process access)

[0278] cat / dev / sdb3

[0279] # Expected result: SELinux denies access, outputting an error similar to the following:

[0280] # cat: / dev / sdb3: Permission denied

[0281] # Check the SELinux audit logs (to confirm the reason for rejection)

[0282] ausearch -m AVC -ts recent

[0283] # Expected log contains: type=AVC msg=audit(xxx): avc: denied { open} forpid=xxx comm="cat" path=" / dev / sdb3" dev="sd b" ino=xxx scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:block_device_t:s0 tclass=block_device

[0284] Docker container testing (should be accessible)

[0285] # Start the specified container (with --privileged and device mapping, refer to the original technical solution)

[0286] docker run --privileged --device / dev / sdb3 -itd --name secure_container debian:latest

[0287] # Enter the container and attempt to read the encrypted device (simulating operations inside the container).

[0288] docker exec -it secure_container bash

[0289] cat / dev / sdb3 # Execute inside the container

[0290] # Expected result: No Permission denied error (if the device is not mounted, garbled characters will be output, which is normal).

[0291] h. Persistent configuration: Ensure rules are not lost after a reboot. Edit ` / etc / selinux / config`, set SELinux to mandatory mode, and make it take effect at boot:

[0292] # Edit configuration file

[0293] vi / etc / selinux / config

[0294] # Modify the following content (ensure it matches the example)

[0295] SELINUX=enforcing # Enforced mode (rules strictly enforced)

[0296] SELINUXTYPE=targeted # Targeted strategy (only manages critical processes, performance-friendly)

[0297] # Save and exit, then restart the system (or temporarily apply: setenforce 1)

[0298] (8) Container shutdown and cleanup phase

[0299] a. Unmount the encrypted volume within the container and disable the LUKS mapping:

[0300] umount -l / container / my-luksdisk

[0301] cryptsetup close my-luksdisk

[0302] b. Stop and remove the container (optional):

[0303] docker stop secure_container

[0304] docker rm secure_container

[0305] In addition, security administrators can evaluate the effectiveness of the policy before it is loaded:

[0306]

[0307] In the formula: R effectiveness The policy effectiveness is scored (scalar value), indicating that the more effective the policy (the smoother the container access and the more thoroughly the host machine access is blocked); N allowed_containerN represents the number of times the container process was successfully granted access to the encrypted device in the test case. total_container W represents the total number of times the container process in the test case attempted to access the encrypted device. container The weight of container access permissions; N allowed_host N represents the number of times the host process was incorrectly granted access to the encrypted device in the test cases. total_host W represents the total number of times the host process attempted to access the encrypted device in the test case. host This refers to the weight of host machine access permissions. Before deploying the policy, the security administrator first runs automated test scripts in the test environment to obtain N. allowed_container Calculate the parameter values ​​and R. effectiveness If R effectiveness Approaching the theoretical maximum value of 1 (i.e., N) allowed_container =N total_container And N allowed_host If the score is 0, it proves that the strategy is written correctly and is effective. If the score is too low, the strategy rules need to be adjusted according to the test logs.

[0308] Through the above steps, the goal of protecting high-value data using Docker's LUKS encrypted volumes in the Kylin operating system was achieved. Since the encrypted volume key exists only within the container, and mounting and accessing the encrypted volume are all completed within the container, the host machine cannot obtain the decryption key or access the mounted encrypted data, thus ensuring the security of high-value data.

[0309] It should be noted that, for the technical solution of this patent, the following alternative solutions exist, which can achieve similar technical effects:

[0310] (1) Alternatives to Encrypted File System

[0311] Replace LUKS with an encrypted file system such as eCryptfs or EncFS. Specific implementation steps include:

[0312] a. Create an eCryptfs encrypted directory on the Kylin operating system.

[0313] b. Mount the encrypted directory into the container using Docker's volume mechanism.

[0314] c. Provide the decryption key via environment variables or security injection when the container starts.

[0315] d. Ensure that the key is only visible inside the container and cannot be accessed by the host machine.

[0316] The advantage of this approach is that it does not require a dedicated partition and can create encrypted directories on existing file systems. However, compared to LUKS, its performance is slightly lower and its encryption strength is slightly weaker.

[0317] (2) Container Storage Interface (CSI) Encryption Scheme

[0318] Leveraging Docker's CSI plugin mechanism, integrate storage plugins that support encryption. Specifically, this includes:

[0319] a. Deploy encryption-enabled CSI plugins, such as Vault CSI Provider, on the Kylin operating system.

[0320] b. Configure the plugin to use national cryptographic algorithms (such as SM4) for data encryption.

[0321] c. When the container starts, dynamically create an encrypted storage volume via a plugin and mount it into the container.

[0322] d. The key is managed by an external Vault service, and the container obtains a temporary key through authentication.

[0323] The advantage of this solution is its high level of integration, making it suitable for large-scale container cluster environments, but its deployment and management complexity is relatively high.

[0324] (3) Scheme based on the built-in encryption function of Kylin system

[0325] Data isolation is achieved by leveraging the disk encryption features provided by the Kylin operating system and combining them with container technology:

[0326] a. Use the "Protective Box" function or partition encryption function of the Kylin system to create encrypted storage.

[0327] b. Mount the encrypted partition into the container using Docker's --mount parameter, but do not allow the host machine to mount the partition.

[0328] c. Configure the security policy of the Kylin system to restrict access to the encrypted partition to only the Docker process.

[0329] d. Configure access control within the container to restrict access to encrypted data to only authorized programs.

[0330] The advantage of this solution is that it makes full use of the system's built-in functions and has good compatibility, but its isolation relies on system-level access control, which is not as thorough as the LUKS solution.

[0331] (4) Virtual machine-based encryption schemes

[0332] Using virtualization technologies such as KVM on the Kylin operating system to replace Docker containers:

[0333] a. Create a virtual machine and configure a separate virtual disk.

[0334] b. Encrypt the virtual disk using LUKS or Kylin system encryption features.

[0335] c. Deploy applications inside virtual machines to process high-value data.

[0336] d. Perform necessary data interaction with the host machine through the virtual machine's network interface, and strictly limit direct disk access.

[0337] This solution offers stronger isolation, but it incurs higher resource costs and lower flexibility, making it suitable for scenarios with extremely high security requirements but low sensitivity to resource consumption.

[0338] (5) Hybrid Encryption Algorithm Scheme

[0339] Replace the encryption algorithm while keeping the overall architecture unchanged:

[0340] a. Replace the default AES algorithm in LUKS with the national cryptographic algorithm SM4 to enhance compatibility with domestic technologies.

[0341] b. Integrate the SM4 algorithm with the LUKS framework, or directly use encryption tools that support SM4.

[0342] c. The key management system uses the SM2 asymmetric algorithm for key exchange and signature verification.

[0343] The advantage of this approach is that it better meets domestic cryptographic standards, but it may require custom development of existing tools.

[0344] Example 2:

[0345] An encryption system for high-value data in a domestically produced environment, which can implement the encryption method for high-value data in a domestically produced environment described in Embodiment 1, includes:

[0346] Environment preparation module: Used to install the Docker runtime environment on the Kylin operating system and ensure that the SELinux security subsystem is in forced mode;

[0347] Encrypted Volume Preparation Module: After completing the environment preparation, this module creates a LUKS encrypted volume for the physical storage space on the host machine, initializes the volume using an encryption key, and creates a file system. Before creating the LUKS encrypted volume, encryption parameters are selected through an evaluation model, which is as follows:

[0348]

[0349] In the formula: T estimated For the estimated total I / O operation latency; Sdata C represents the average size of the data blocks expected to be processed; encryption T represents the computational complexity coefficient of the selected encryption algorithm. throughput This refers to the raw throughput of the underlying storage device; O luks A fixed empirical estimate of the overhead of the LUKS layer; O docker Empirical estimates of the fixed overhead of the Docker storage driver layer;

[0350] Security policy configuration module: After the encrypted volume preparation is completed, it is used to create and load a custom SELinux policy module, in which the defined security rules are configured to: deny the host process domain from accessing the LUKS encrypted volume device file, while allowing the Docker container process domain to access the LUKS encrypted volume device file;

[0351] Secure container startup module: After the security policy configuration takes effect, it starts a Docker container as a secure container, and maps the LUKS encrypted volume device file of the host machine into the secure container at startup;

[0352] Container decryption and mounting module: After the secure container starts, it is used to open the LUKS encrypted volume mapped into the container using the encryption key inside the secure container, decrypt it into a block device, and mount the block device to a specified directory inside the container;

[0353] Data security access module: This module is used by authorized applications within the secure container to read and write high-value data by accessing the specified directory. During this process, processes on the host machine are restricted by the SELinux policy and cannot access the data within the LUKS encrypted volume.

[0354] Example 3:

[0355] This invention also provides an encryption device for high-value data in a domestically produced environment, which can implement the encryption method for high-value data in a domestically produced environment described in Embodiment 1, including a processor and a storage medium;

[0356] The storage medium is used to store instructions;

[0357] The processor is configured to operate according to the instructions to perform the steps of the following method:

[0358] Environment preparation: Install the Docker runtime environment on the Kylin operating system and ensure that the SELinux security subsystem is in forced mode;

[0359] Encrypted Volume Preparation: After completing the environment preparation, a LUKS encrypted volume is created on the host machine for the physical storage space. The volume is initialized using an encryption key, and a file system is created. Before creating the LUKS encrypted volume, encryption parameters are selected through an evaluation model, which is as follows:

[0360]

[0361] In the formula: T estimated For the estimated total I / O operation latency; S data C represents the average size of the data blocks expected to be processed; encryption T represents the computational complexity coefficient of the selected encryption algorithm. throughput This refers to the raw throughput of the underlying storage device; O luks A fixed empirical estimate of the overhead of the LUKS layer; O docker Empirical estimates of the fixed overhead of the Docker storage driver layer;

[0362] Security policy configuration: After the encrypted volume preparation is completed, a custom SELinux policy module is created and loaded, in which the defined security rules are configured to: deny the host process domain from accessing the LUKS encrypted volume device file, while allowing the Docker container process domain to access the LUKS encrypted volume device file;

[0363] Secure container startup: After the security policy configuration takes effect, a Docker container is started as a secure container, and the LUKS encrypted volume device file of the host machine is mapped into the secure container at startup;

[0364] Decryption and mounting within the container: After the secure container starts, the encryption key is used inside the secure container to open the LUKS encrypted volume mapped into the container, decrypt it into a block device, and mount the block device to a specified directory inside the container;

[0365] Secure data access: Authorized applications within the secure container can read and write the high-value data by accessing the designated directory; during this process, processes on the host machine are restricted by the SELinux policy and cannot access the data within the LUKS encrypted volume.

[0366] Example 4:

[0367] This invention also provides a computer-readable storage medium that can implement the encryption method for high-value data in a domestically produced environment as described in Embodiment 1. The medium stores a computer program that, when executed by a processor, performs the steps of the following method:

[0368] Environment preparation: Install the Docker runtime environment on the Kylin operating system and ensure that the SELinux security subsystem is in forced mode;

[0369] Encrypted Volume Preparation: After completing the environment preparation, a LUKS encrypted volume is created on the host machine for the physical storage space. The volume is initialized using an encryption key, and a file system is created. Before creating the LUKS encrypted volume, encryption parameters are selected through an evaluation model, which is as follows:

[0370]

[0371] In the formula: T estimated For the estimated total I / O operation latency; S data C represents the average size of the data blocks expected to be processed; encryption T represents the computational complexity coefficient of the selected encryption algorithm. throughput This refers to the raw throughput of the underlying storage device; O luks A fixed empirical estimate of the overhead of the LUKS layer; O docker Empirical estimates of the fixed overhead of the Docker storage driver layer;

[0372] Security policy configuration: After the encrypted volume preparation is completed, a custom SELinux policy module is created and loaded, in which the defined security rules are configured to: deny the host process domain from accessing the LUKS encrypted volume device file, while allowing the Docker container process domain to access the LUKS encrypted volume device file;

[0373] Secure container startup: After the security policy configuration takes effect, a Docker container is started as a secure container, and the LUKS encrypted volume device file of the host machine is mapped into the secure container at startup;

[0374] Decryption and mounting within the container: After the secure container starts, the encryption key is used inside the secure container to open the LUKS encrypted volume mapped into the container, decrypt it into a block device, and mount the block device to a specified directory inside the container;

[0375] Secure data access: Authorized applications within the secure container can read and write the high-value data by accessing the designated directory; during this process, processes on the host machine are restricted by the SELinux policy and cannot access the data within the LUKS encrypted volume.

[0376] As is known from common technical knowledge, this invention can be implemented through other embodiments that do not depart from its spirit or essential characteristics. Therefore, the disclosed embodiments described above are merely illustrative and not exhaustive. All modifications within the scope of this invention or its equivalents are included in this invention.

[0377] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0378] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0379] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0380] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0381] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for encrypting high-value data in a domestically developed environment, characterized in that, include: Environment preparation: Install the Docker runtime environment on the Kylin operating system and ensure that the SELinux security subsystem is in forced mode; Encrypted Volume Preparation: After completing the environment preparation, a LUKS encrypted volume is created on the host machine for the physical storage space. The volume is initialized using an encryption key, and a file system is created. Before creating the LUKS encrypted volume, encryption parameters are selected through an evaluation model, which is as follows: ； In the formula: T estimated For the estimated total I / O operation latency; S data C represents the average size of the data blocks expected to be processed; encryption T represents the computational complexity coefficient of the selected encryption algorithm. throughput This refers to the raw throughput of the underlying storage device; O luks A fixed empirical estimate of the overhead of the LUKS layer; O docker Empirical estimates of the fixed overhead of the Docker storage driver layer; Security policy configuration: After the encrypted volume preparation is completed, a custom SELinux policy module is created and loaded, in which the defined security rules are configured to: deny the host process domain from accessing the LUKS encrypted volume device file, while allowing the Docker container process domain to access the LUKS encrypted volume device file; Secure container startup: After the security policy configuration takes effect, a Docker container is started as a secure container, and the LUKS encrypted volume device file of the host machine is mapped into the secure container at startup; Decryption and mounting within the container: After the secure container starts, the encryption key is used inside the secure container to open the LUKS encrypted volume mapped into the container, decrypt it into a block device, and mount the block device to a specified directory inside the container; Secure data access: Authorized applications within the secure container can read and write the high-value data by accessing the designated directory; during this process, processes on the host machine are restricted by the SELinux policy and cannot access the data within the LUKS encrypted volume.

2. The encryption method for high-value data in a domestically produced environment according to claim 1, characterized in that, The installation of the Docker runtime environment specifically includes: obtaining the Docker Community Edition installation package through a software source compatible with Ubuntu, and performing installation and service startup verification.

3. The encryption method for high-value data in a domestically produced environment according to claim 1, characterized in that, The encryption key is managed in one of the following ways: injected via environment variables when the container starts, passed via the Docker Secrets mechanism, or dynamically generated and obtained by a key management service started within the container.

4. The encryption method for high-value data in a domestically produced environment according to claim 1, characterized in that, The rule definitions of the custom SELinux policy module include: Deny the host process domain unconfined_t from performing block device operations and file operations on device type block_device_t; Allows the container process domain container_t to perform block device operations and file operations on device type block_device_t.

5. The encryption method for high-value data in a domestically produced environment according to claim 1, characterized in that, The LUKS encrypted volume device file is mapped into the secure container using the `--device` parameter of the Docker command.

6. The encryption method for high-value data in a domestically produced environment according to claim 1, characterized in that, The encryption algorithm used in the LUKS encrypted volume is the national cryptographic algorithm SM4, which conforms to the standards of the State Cryptography Administration.

7. The encryption method for high-value data in a domestically produced environment according to claim 1, characterized in that, The method also includes a container stop and cleanup phase: unloading the mounted decrypted volume and closing the LUKS encryption mapping inside the secure container, and then stopping and removing the secure container.

8. An encryption system for high-value data under a domestically developed environment, characterized in that, include: Environment preparation module: Used to install the Docker runtime environment on the Kylin operating system and ensure that the SELinux security subsystem is in forced mode; Encrypted Volume Preparation Module: After completing the environment preparation, this module creates a LUKS encrypted volume for the physical storage space on the host machine, initializes the volume using an encryption key, and creates a file system. Before creating the LUKS encrypted volume, encryption parameters are selected through an evaluation model, which is as follows: ； In the formula: T estimated For the estimated total I / O operation latency; S data C represents the average size of the data blocks expected to be processed; encryption T represents the computational complexity coefficient of the selected encryption algorithm. throughput This refers to the raw throughput of the underlying storage device; O luks A fixed empirical estimate of the overhead of the LUKS layer; O docker Empirical estimates of the fixed overhead of the Docker storage driver layer; Security policy configuration module: After the encrypted volume preparation is completed, it is used to create and load a custom SELinux policy module, in which the defined security rules are configured to: deny the host process domain from accessing the LUKS encrypted volume device file, while allowing the Docker container process domain to access the LUKS encrypted volume device file; Secure container startup module: After the security policy configuration takes effect, it starts a Docker container as a secure container, and maps the LUKS encrypted volume device file of the host machine into the secure container at startup; Container decryption and mounting module: After the secure container starts, it is used to open the LUKS encrypted volume mapped into the container using the encryption key inside the secure container, decrypt it into a block device, and mount the block device to a specified directory inside the container; Data security access module: This module is used by authorized applications within the secure container to read and write high-value data by accessing the specified directory. During this process, processes on the host machine are restricted by the SELinux policy and cannot access the data within the LUKS encrypted volume.

9. An encryption device for high-value data under domestic production conditions, characterized in that, Including processor and storage media; The storage medium is used to store instructions; The processor is configured to operate according to the instructions to perform the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method according to any one of claims 1 to 7.

Images