A method and device for implementing Hadoop tenant-level encryption isolation

Abstract

The application discloses a Hadoop tenant-level encryption isolation implementation method, aiming at solving the single key leakage risk, namespace flattening, encryption area unauthorized binding and audit without tenant dimension of the existing Ranger-KMS scheme. The method comprises the following steps: creating an independent master key for each tenant to realize physical isolation; forcing the key alias, encryption area path and policy resource to carry the tenant prefix and verifying consistency; passing the tenant context through a thread local variable; persisting tenant attributes when creating an encryption area and verifying operation consistency; ensuring that the key plaintext only exists in the KMS memory and is safely cleared after use. The application realizes full-dimension isolation of keys, data, policies and audits, single-tenant key leakage does not affect the cluster, prevents unauthorized access and information leakage, meets compliance audit requirements, supports single-cluster multi-tenant safe coexistence, and reduces hardware costs.

Description

Technical Field

[0001] This application belongs to the field of data encryption and isolation technology, and specifically relates to a Hadoop tenant-level encryption isolation implementation method, device, computer-readable storage medium, and electronic device. Background Technology

[0002] With increasing demands for data security, the Hadoop ecosystem introduced the HDFS Transparent Data Encryption (TDE) mechanism starting with version 2.7. Its core design utilizes Ranger-KMS (Key Management Service) to centrally manage keys, supporting tenant-level data encryption requirements. However, the open-source version of Ranger-KMS has inherent limitations in its key management architecture: its underlying key storage files (such as ranger_keystore and ranger_masterkey) lack tenant identification fields, all tenants share the same master key system, and access control isolation is only achieved through Ranger policies. This architecture suffers from the following key deficiencies in terms of security, maintainability, and compliance: 1. A single master key poses a single point of security risk at the cluster level. In the existing scheme, all tenants' Encryption Zone Keys (EZ-Keys) in the cluster are encrypted and protected by a single master key. This design means that a leak of the master key will directly lead to a global data breach risk—attackers can crack the master key to decrypt all tenants' EZ-Keys in batches, and then decrypt the encrypted data of any tenant in the cluster. In addition, the master key rotation operation requires a one-time re-encryption of the EZ-Keys of all tenants, resulting in a lengthy business maintenance window and a highly concentrated risk. It cannot support smooth, batch rotation at the tenant level, forming a single point of failure bottleneck in the cluster security system, where "one key manages everything."

[0003] 2. Flattened key namespaces lead to generalized permissions and information leakage. All tenant key aliases are stored in a flat key table without tenant labels, sharing the same namespace. If the Ranger policy is misconfigured (e.g., mistakenly set to key=*), a tenant with key list (LIST) permissions can brute-force enumerate all key aliases in the database using a script. Since key aliases often embed business semantics (e.g., "payroll", "hr"), the enumeration itself leads to the leakage of sensitive business information, providing attackers with critical intelligence. Furthermore, the flat namespace makes it impossible to quickly categorize and filter audit logs by tenant, increasing the complexity of security incident tracing.

[0004] 3. The lack of mandatory binding between the encrypted zone path and key ownership leads to unauthorized access and lifecycle confusion. When HDFS creates an encrypted zone, it only verifies the tenant's write permissions to the target directory, without strictly verifying the ownership of the referenced keys. This design flaw can lead to cross-tenant key misuse—for example, tenant B binds a key belonging to tenant A, which it does not have access to, to its own encrypted zone, creating an abnormal association of "encrypting its own data with someone else's key." If tenant A subsequently performs a key rotation, tenant B will be unable to decrypt the data due to the lack of a new key; if tenant A deletes the key, tenant B's encrypted zone will experience service interruption due to the expiration of the old key. Because of the lack of a mapping between key ownership and encrypted zone paths, the localization and lifecycle management of such "key misuse" problems are extremely difficult to implement effectively.

[0005] 4. Audit logs lack tenant dimension, resulting in low efficiency in compliance tracing. Due to the lack of tenant differentiation in the key storage design, audit logs for all key-related operations (such as creation, rotation, and deletion) are not directly linked to tenant information. During security audits or compliance reviews, it is necessary to manually parse the resource names in each log entry and deduce the tenant affiliation. This process is time-consuming, labor-intensive, and error-prone, making it difficult to meet the stringent requirements of data security regulations regarding audit timeliness and accuracy.

[0006] In summary, existing Hadoop TDE solutions have significant shortcomings in tenant-level key isolation, security boundary delineation, and compliance auditing capabilities, and there is an urgent need for an enhanced implementation solution that supports tenant-level cryptographic isolation. Summary of the Invention

[0007] To address the aforementioned issues, this application proposes a novel Hadoop tenant-level encrypted isolation implementation method. More specifically, this application relates to a technical solution for achieving dual isolation of multi-tenant keys and data using Ranger-KMS in a transparent encryption scenario of the Hadoop Distributed File System (HDFS).

[0008] This invention addresses the problems of shared keys among Ranger-KMS tenants, lack of ownership binding in encrypted zones, and lack of tenant dimension in auditing in existing Hadoop environments. By introducing tenant-level physical isolation of master keys, mandatory namespace prefix verification, and thread-level tenant context passing mechanism, it achieves full-dimensional isolation of keys, data, policies, and auditing, thereby constructing a multi-tenant data encryption system that can meet high compliance requirements.

[0009] In summary, this invention aims to construct a systematic method for multi-tenant encrypted isolation. This method is a combined implementation scheme of five technical links: tenant-level master key isolation, prefix mandatory verification, tenant context passing, directory attribute binding, and memory security management. The above five links work together to form a complete security system of "physical isolation + logical isolation + lifecycle binding + zero plaintext", which ensures clear security boundaries for multi-tenants.

[0010] To achieve the above objectives, the present invention employs the following technical strategies: 1. Tenant-level master key physical isolation mechanism Technical approach: Create an independent master key ciphertext record for each tenant in the ranger_masterkey database table. The master keys for each tenant are randomly generated and are different from each other.

[0011] Implementation: Use tenant_id as the primary key or unique index to ensure that each tenant's EZ-Key can only be encrypted and decrypted by the tenant's master key.

[0012] Security benefits: Completely eliminates the risk of "single master key leakage leading to full cluster data leakage" in traditional solutions, achieving true physical-level key isolation.

[0013] 2. Multi-dimensional prefix mandatory verification system Technical measures: Enforce tenant prefix verification in three key locations: key alias, encrypted zone path, and Ranger policy resources (add tenant columns to relevant tables in the Ranger database, and enforce tenant identity and resource prefix verification in three key components: Hadoop KeyProvider, HDFSEncryptionZoneManager, and Ranger-Plugin).

[0014] Implementation: The platform layer (without manual intervention) automatically verifies the consistency between the resource prefix and the current tenant context, and rejects all mismatched creation, query and access requests.

[0015] Security benefits: Eliminates key enumeration vulnerabilities and misconfiguration risks at the source, ensuring complete isolation of resource namespaces for each tenant.

[0016] 3. Non-intrusive tenant context passing mechanism Technical approach: Build a tenant context passing link based on ThreadLocal and inject tenant identity information into the gateway or CLI entry point.

[0017] Implementation: Core components such as Hadoop KeyProvider, EncryptionZoneManager, and Ranger-Plugin automatically read tenant information from the thread context.

[0018] Security benefits: Enables end-to-end tenant identity transparency, ensuring strict maintenance of tenant boundaries during request processing and preventing context loss or confusion.

[0019] 4. Encrypted Zone Directory Tenant Binding and Verification Technical approach: Utilize the HDFS extended attribute user.tenant to persistently store the tenant identifier in the encrypted zone directory.

[0020] Implementation: The user.tenant property is automatically set when the encrypted zone is created, and tenant consistency is forcibly verified before operations such as rename, distcp, and snapshot.

[0021] Security benefits: Prevents cross-tenant data movement and unauthorized access, and ensures strict correspondence between the encrypted zone lifecycle and the tenant boundary.

[0022] 5. Key Memory Security Management System Technical means: All key plaintext exists only in the KMS process heap memory and is immediately and securely cleared after use.

[0023] Implementation: The underlying interface Unsafe.setMemory is used to ensure that the plaintext key is completely cleared, and only the ciphertext is stored in the database and logs.

[0024] Security benefits: Meets the stringent requirements of FIPS-140 and national cryptographic standards for key non-disk storage, preventing security risks caused by storage media leakage.

[0025] Specifically, this application provides the following technical solutions: The first aspect of this application provides a method for implementing tenant-level encrypted isolation in Hadoop, such as... Figure 1 As shown, this method includes the following steps: S1. Tenant-level master key isolation: Create an independent master key with a tenant identifier for each tenant. The master key is used to encrypt and decrypt the tenant's exclusive encryption zone key, thereby achieving physical isolation of master keys between different tenants. S2. Forced verification of resource prefixes: In key aliases, encrypted zone paths, and Ranger policy resources, a prefix format containing the tenant identifier is enforced, and during verification, it is ensured that the prefix is ​​consistent with the tenant identity of the creator or visitor of the resource, and mismatched requests are rejected. S3. Tenant Context Passing: Through a thread-level context passing mechanism, tenant identification information is injected at the entry point of request processing, and its tenant context information is automatically passed through during the entire chain processing of the request. S4. Encrypted Zone Lifecycle Binding: When creating an encrypted zone, the tenant identifier of the current tenant is persistently stored in the directory metadata as an extended attribute, and the consistency of the tenant identifier of the source and target directories is verified before renaming, snapshotting, or copying the directory. S5. Memory security management: The plaintext of the key is stored only in the heap memory of the KMS (Key Management Service) process and is cleared by memory zeroing operation after use to prevent the plaintext of the key from being leaked.

[0026] Furthermore, in the method of this application, step S1 further includes: S11. Add a tenant identifier field to the master key storage table for each tenant, and generate a unique, randomly distributed master key ciphertext for each tenant; S12. Add a tenant identifier field to the key storage table for each tenant, so that each tenant's encryption zone key can only be decrypted by that tenant's master key.

[0027] Furthermore, in the method of this application, step S2 further includes: S21. Verify key aliases, enforce their format as <tenant identifier>_<suffix>, and perform dual verification of format and identity when creating or querying keys; S22. Verify the encrypted zone path, forcing it to include the tenant identifier prefix directory, and when creating the encrypted zone, the NameNode verifies the legality of the current tenant's identity and the path prefix; S23. Verify the key resources in the Ranger policy, reject policy requests containing global wildcards, and automatically filter out key resources that do not match the current tenant's prefix.

[0028] Furthermore, in the method of this application, the thread-level context passing mechanism described in step S3 is based on ThreadLocal to implement the injection, reading and clearing of tenant identifiers, and supports cross-thread copying of context in asynchronous thread pool scenarios.

[0029] Furthermore, in the method of this application, step S3 further includes: S31. Inject the tenant identifier into the gateway or command-line client; S32. Use a context holder class to store and retrieve the tenant identifier of the current thread using ThreadLocal; S33. Ensure that the KMS core service components automatically read tenant information from the context holding class to perform permission and logic checks before performing operations.

[0030] Furthermore, in the method of this application, step S4 further includes: S41. Set immutable tenant extended attributes on the encrypted zone directory; S42. When performing directory rename, snapshot, and distcp operations, force verification to check whether the tenant attributes of the directory are consistent before and after the operation. If they are inconsistent, the operation is rejected. S43. Listen for directory deletion events. When a directory is deleted, trigger the process of checking and cleaning up the key associated with that directory.

[0031] Furthermore, in the method of this application, the memory clearing operation described in step S5 is executed in the finally block after the key plaintext has been used by calling the underlying memory operation interface, ensuring that the key plaintext only exists temporarily in the heap memory of the KMS process and is completely cleared in any execution path.

[0032] Furthermore, the method in this application also includes tenant-level management steps for keys and audit logs, specifically including: (1) Provide a management interface for querying, rotating, and deleting the private encryption zone key by tenant identifier; (2) Expand the audit log by adding a tenant identifier field so that all key-related operations can be retrieved and traced by the tenant dimension.

[0033] A second aspect of this application provides a Hadoop tenant-level encrypted isolation implementation apparatus, the apparatus comprising: Master key isolation module: used to create an independent master key with tenant identification for each tenant. The master key is used to encrypt and decrypt the tenant's exclusive encryption zone key, thereby achieving physical isolation of master keys between different tenants; Resource prefix mandatory verification module: used to enforce the prefix format containing the tenant identifier in key aliases, encrypted area paths and Ranger policy resources, and to ensure that it is consistent with the tenant identity of the creator or visitor of the resource during verification, and to reject mismatched requests; Tenant context passing module: It is used to inject tenant identity information at the entry point of request processing through the thread-local variable mechanism, and automatically pass through its tenant context information throughout the entire chain processing of the request; Encrypted Zone Lifecycle Binding Module: When creating an encrypted zone, the current tenant's tenant identifier is persistently stored as an extended attribute in the directory metadata, and the consistency of the tenant identifier between the source and target directories is verified before renaming, snapshotting, or copying the directory. Memory security management module: This module stores the plaintext of the key only in the heap memory of the KMS process and clears it through a memory zeroing operation after use, thus preventing the plaintext of the key from being leaked.

[0034] The device implements the steps of the aforementioned Hadoop tenant-level encrypted isolation implementation method during operation.

[0035] Furthermore, the device in this application is deployed on the Ranger-KMS server of Hadoop, and is implemented by modifying the database schema, service logic and interaction protocol with HDFS NameNode of Ranger-KMS.

[0036] A third aspect of this application provides an electronic device, including: a memory and a processor; Memory: Used to store computer programs; Processor: Used to execute the computer program to implement the steps of the aforementioned Hadoop tenant-level encrypted isolation implementation method.

[0037] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the steps of the aforementioned Hadoop tenant-level encrypted isolation implementation method.

[0038] In summary, this invention achieves true multi-tenant encrypted isolation in the Hadoop ecosystem by introducing three core technologies: tenant-level master key isolation, resource prefix forced mapping, and thread-level tenant context. Compared with traditional single-tenant flattening schemes, this invention has the following significant advantages: (1) Achieve physical-level key isolation with clear security boundaries Each tenant has an independent master key ciphertext line, with keys randomly generated and unique. This design ensures that the leakage of a single key only affects the corresponding tenant and will not affect the entire cluster, fundamentally avoiding the cluster-wide risk of "one key opening all doors" in traditional solutions. Simultaneously, key rotation can be performed online on a tenant-by-tenant basis without cluster downtime, significantly reducing the risk of business interruption. This mechanism complies with the principle of least privilege for high-level compliance requirements in finance, government, and other sectors, and can be further integrated with different HSM encryption slots or cloud KMS instances to achieve hardware-level key security boundaries.

[0039] (2) Forced prefix mapping mechanism, dual risks are controllable By mandating that key aliases, encrypted zone paths, and policy resources must all carry tenant prefixes, this solution eliminates the permission generalization problem caused by misconfiguration of "key=*" in traditional solutions from the source. The results returned by the LIST operation are automatically filtered by prefix, preventing tenants from enumerating other people's key dictionaries and effectively preventing the leakage of sensitive information. The unified naming convention also allows audit logs to be filtered by prefix at the second level, significantly improving operational efficiency. Operational scripts, monitoring alarms, etc., can all be processed in batches by prefix.

[0040] (3) The encrypted zone lifecycle is automatically bound to the tenant, enabling precise access control. When creating an encrypted zone, the NameNode atomically writes the current tenant name into the directory's extended attributes, forming an immutable tenant identifier. Subsequent operations such as rename and snapshots will first verify the tenant attributes, rejecting cross-tenant data movement. When a tenant directory is deleted, the system automatically triggers the retirement process of the relevant keys to prevent "ghost encrypted zones" from remaining. This mechanism ensures the consistency of the directory-tenant-key triple, enabling problem localization to be completed within minutes and completely eliminating the hidden risk of "encrypting one's own data with someone else's key."

[0041] (4) Zero plaintext disk placement design, ensuring thorough security. This scheme ensures that all plaintext keys exist only in the heap memory of the KMS process and are immediately zeroed out securely after use. Only ciphertext keys are stored in the database, disk, backups, and logs, making data decryption impossible even if the storage media is stolen. This design meets the stringent requirements of FIPS-140-2 and the Chinese national cryptographic standard GM / T 0054 for keys not being written to disk, and the memory cleanup logic is placed in a finally block, ensuring its effectiveness even under abnormal paths, fundamentally eliminating the risk of side-channel attacks.

[0042] (5) Secure coexistence of multiple tenants and optimized resource efficiency A single physical cluster can simultaneously support multiple security domains, enabling a "logical private cloud" architecture where computing resources are isolated via queues and storage resources are isolated via encryption. This design significantly reduces hardware procurement and maintenance costs while ensuring complete isolation across four dimensions: keys, permissions, auditing, and data.

[0043] (6) Fully compatible design, smooth and convenient deployment All modifications to this solution are concentrated in three plugin classes, without altering the core Hadoop encryption algorithm, ensuring that risks are completely controllable. The newly added filters and thread variables are entirely transparent to computing engines such as MapReduce and Spark, supporting rolling upgrades without impacting business operations. It seamlessly integrates with existing identity frameworks such as Kerberos, Ranger, and LDAP, allowing tenant information to be directly mapped from existing user group attributes, protecting existing enterprise investments. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings involved in the description of the embodiments will be briefly introduced below.

[0045] Figure 1 This is a flowchart illustrating the overall implementation process of the Hadoop tenant-level encrypted isolation method in this application.

[0046] Figure 2 This is a key system relationship diagram in the embodiments of this application.

[0047] Figure 3 Write the encryption flowchart for the encrypted area file in the native scheme.

[0048] Figure 4 This is a flowchart of the process for reading and decrypting encrypted files in the native solution.

[0049] Figure 5 This is a flowchart illustrating the encryption process for writing encrypted files to the encrypted area in the tenant isolation scheme of this application embodiment.

[0050] Figure 6 This is a flowchart illustrating the process of reading and decrypting encrypted files in the tenant isolation scheme of this application embodiment.

[0051] Figure 7 This is a structural diagram of the Hadoop tenant-level encrypted isolation implementation device in this application. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0053] To more clearly illustrate the technical solution of this application, the following will provide further explanation through specific scenario embodiments.

[0054] Example: A Hadoop tenant-level encrypted isolation implementation method 1. Unified prefix mandatory verification mechanism

[0055] 2. Physical isolation of the key storage layer (1) Improvements to the storage layer: Insert a separate master key ciphertext row for each tenant in the ranger_masterkey table; Add a tenant_id field to the ranger_keystore table to achieve physical storage isolation of the keys; The master key ciphertext of different tenants can be stored in different encryption machines or storage partitions.

[0056] (2) Technical implementation: Database indexes are sharded by tenant_id, supporting tenant-level batch cleanup and data archiving; The tenant's EZ-Key ciphertext can only be decrypted using the tenant's own master key; cross-decryption will fail immediately. Physical isolation is achieved by adding a DAO method with a tenantId parameter, while maintaining compatibility with the original interface; Storage tier backup and recovery can be performed individually on a tenant basis, meeting the requirements of tiered protection.

[0057] (3) Enhanced security: The shared key plaintext is securely erased in the finally block using Unsafe.setMemory(); It supports allocating HSM encryption slots separately for highly sensitive tenants to achieve hardware-level isolation.

[0058] (4) The existing table definitions and modifications in the kms_core_db.sql file are shown in the table below:

[0059] Tenant-level operations are added only to the DAO layer of the ranger_masterkey and ranger_keystore tables, without modifying the original interface signature. Physical isolation is achieved by adding a method with a TenantId parameter.

[0060] Zero intrusion into legacy code: The original findByAlias(alias) / getAllKeys() is retained, and only new tenant scenarios use methods named *Tenant.

[0061] Physical isolation is achieved at the DAO layer: all SQL statements automatically include WHERE tenant_id = ?, and the index idx_tenant (alias) ensures performance.

[0062] Thread tenant injection: The DAO internally calls TenantContext.get() as the default tenant to avoid missing conditions.

[0063] Memory clearing: The shared key plaintext is only erased in the finally block Unsafe.setMemory(), without being written to disk or entered into the log.

[0064] Modification of the ranger_masterkey table at the DAO layer (physical isolation: one master key per tenant):

[0065] Modifications to the ranger_keystore table at the DAO layer (physical isolation: independent key aliases for each tenant):

[0066] 3. Tenant isolation architecture at the computing layer A three-tier tenant isolation architecture is adopted, consisting of "entry point injection - thread passing - computation processing". (1) Tenant information injection mechanism Gateway injection: Extract the tenant identifier from Kerberos credentials or X-Tenant-Id request headers via the Knox gateway; CLI injection: The tenant name is specified through the environment variable HADOOP_TENANT to avoid exposing command-line parameters.

[0067] (2) Thread-level context passing Tenant information is transmitted across the entire link through thread-local variables in TenantContext; Supports context copying in thread pool scenarios to ensure consistency among asynchronous task tenants.

[0068] (3) Unified adaptation of computing components KeyProvider: Automatically verifies the consistency of tenant prefixes for key aliases; EncryptionZoneManager: Forces the encrypted zone path to include the tenant prefix directory; Ranger-Plugin: Compares resource tenant prefixes during the permission verification phase to technically block unauthorized access.

[0069] To inject a thread tenant context, a utility class needs to be created for end-to-end calls; it is usually placed in the common package of hadoop-common or ranger-kms, and its lifecycle is equal to a single request thread.

[0070] 4. Unified governance and runtime protection (1) Unified governance baseline The regular expression pattern ^[a-z0-9]+_[a-zA-Z0-9_-]+$ is fixed as a constant, shared by three validations, and is a two-part expression (the separator can be "_", "@", etc.).

[0071] An AccessDeniedException with error code TENANT_PREFIX_MISMATCH is thrown.

[0072] The audit log AccessType=tenant_prefix_check supports compliance review.

[0073] (2) Three layers of protection during operation Prefix mandatory verification: Key aliases, encrypted zone paths, and policy resources must contain tenant prefixes.

[0074] Whitelist filtering: List operations are first processed by the filter, and the global wildcard * is directly rejected.

[0075] Decoupling of access control data: Policy changes are encrypted zero-time and take effect within 60 seconds, achieving defense in depth.

[0076] 5. The encrypted zone lifecycle is bound to the tenant. (1) Create and bind When creating the encrypted zone, the NameNode writes the current tenant identifier as the user.tenant system property to the directory. This property can only be written by the superuser.

[0077] (2) Move and verify For path change operations such as rename, snapshot, and distcp, verify the consistency of tenant attributes in the source and target paths to prevent cross-tenant data movement.

[0078] (3) Deletion means retirement Monitor directory deletion events and automatically clean up related keys to prevent phantom encryption zones, provided that the key has not been used by other encryption zones; if the key has been used by other encryption zones, it will be retained.

[0079] (4) Auditing is related The audit log extends the tenant_id field to directly output the directory-tenant-key triplet, meeting compliance audit requirements.

[0080] 6. Enhanced management commands Add tenant prefix whitelist verification to all management commands in kmsadmin.sh: All key / encryption zone names must conform to the following: <tenantid> _ <suffix>Format; Commands such as listKeys, describeKey, and deleteKey are limited to operations within the current tenant's prefix range. Super administrators must explicitly use the --cross-tenant parameter to perform cross-tenant operations and force audit logging.

[0081] 7. Operation Process and Internal Implementation Phase 1: Creation of the encrypted zone (tenant identifier mandatory) Core objective: To create dedicated encrypted zones for tenants, with path / key aliases mandatory to include the tenant identifier (e.g., tenantA), and to support the creation of multiple encrypted zones for the same tenant.

[0082] Phase 2: Encrypted Zone Usage (Reading and Writing Data) Core objective: When a tenant accesses its own encrypted zone data, TenantContext automatically passes the tenant identifier without requiring manual specification, supporting access to any encrypted zone under the tenant.

[0083] Phase 3: Encrypted Area Cleanup (Single Path / Batch) Core objective: Delete specified encrypted zones or data under a tenant, allowing only the cleanup of paths containing the current tenant's identifier, without affecting other encrypted zones of the tenant.

[0084] Phase 4: Routine Operations and Maintenance (Tenant-level / Single-path-level) Core objective: To manage the state, keys, and permissions of tenant encrypted zones, and to support both "batch operations for tenants" and "fine-grained operations for single encrypted zones".

[0085] By introducing three core technologies—tenant-level master key isolation, resource prefix mandatory mapping, and thread-level tenant context—this solution achieves true multi-tenant encrypted isolation within the Hadoop ecosystem. Multiple tenants share hardware within a single cluster, but keys, data, policies, and auditing are completely isolated. Hot upgrades and on-demand rolling key rotation are supported, meeting compliance and cloud-based multi-tenant requirements.

[0086] Figure 2 This is a key system diagram of the present invention. In the diagram: Core Key: Master Key: The root key of KMS, used to encrypt / decrypt EZ-Key.

[0087] EZ-Key (Encryption Zone Key): Stored in ciphertext and used after the master key is decrypted. It is used to encrypt / decrypt the DEK.

[0088] DEK (Data Encryption Key): A file-level key stored in ciphertext form (EDEK) on the NameNode.

[0089] EDEK (Encrypted DEK): The ciphertext of the DEK encrypted with EZ-Key is contained in FileEncryptionInfo and managed by the NameNode.

[0090] The Hadoop encryption zone key system uses a master key to protect the encryption zone key (EZ-Key). The EZ-Key is encrypted to generate EDEK, and EDEK is decrypted by KMS to restore DEK. DEK is then used to encrypt or decrypt actual business data. KMS manages the key throughout the process, and the storage medium only stores EDEK and ciphertext, ensuring that the plaintext key is never written to disk and that the entire computation is completed in memory.

[0091] Figure 3 An encryption flowchart is written for the encrypted area files in the native solution, clearly showing the interaction logic and key processing process between the client, NameNode, and KMS, including: 1. The client requests the generation of DEK from KMS. When a client needs to encrypt a file, it first sends a request to KMS, specifying the target encryption area and requesting the generation of a new DEK (data encryption key).

[0092] 2. KMS generates DEK and encrypts it into EDEK. KMS returns the plaintext DEK and EDEK to the client. Generating DEK: KMS randomly generates a plaintext DEK (used for file encryption); Decrypting EZ-Key: KMS retrieves the EZ-Key (stored in ciphertext form) corresponding to the encrypted area from the database and decrypts it using the Master Key to obtain the plaintext EZ-Key; Generating EDEK from DEK: KMS encrypts the DEK using the plaintext EZ-Key to obtain the EDEK (the encrypted DEK, used for persistent storage). KMS returns the generated DEK plaintext (used by the client to encrypt files) and EDEK (used for verification during subsequent decryption) to the client together.

[0093] 3. Encrypt file data on the client side. After receiving the DEK plaintext, the client uses the DEK locally to encrypt the file data, obtaining the encrypted file content.

[0094] 4. The client submits metadata to the NameNode. The client writes the encrypted file data to HDFS and submits the file metadata (FileEncryptionInfo) to the NameNode, which contains the key information EDEK (which is needed to obtain DEK when reading the file later). The NameNode stores FileEncryptionInfo, completing the file encryption and storage process.

[0095] Figure 4 This diagram illustrates the process of reading and decrypting encrypted files in the native solution, clearly showing the interaction logic and key processing between the client, NameNode, and KMS, including: 1. Client obtains file metadata When a client needs to read an encrypted file, it first sends a request to the NameNode to obtain the file's metadata (FileEncryptionInfo). The NameNode returns FileEncryptionInfo, which contains the encrypted DEK (i.e., EDEK).

[0096] 2. The client requests KMS to decrypt the EDEK. The client extracts the EDEK from the FileEncryptionInfo, sends a decryption request to KMS, and attaches the EDEK. After receiving the request, KMS retrieves the corresponding EZ-Key (stored in encrypted form) from the database. KMS uses the master key to decrypt the EZ-Key ciphertext, obtaining the EZ-Key plaintext; KMS uses the plaintext EZ-Key to decrypt the EDEK sent by the client, obtaining the plaintext DEK (data encryption key).

[0097] 3. KMS returns DEK plaintext to the client. KMS sends the decrypted DEK plaintext to the client.

[0098] 4. Client decrypts file data After receiving the DEK plaintext, the client uses the DEK locally to decrypt the encrypted file data and finally obtain the plaintext file content.

[0099] Figure 5 The flowchart for writing encryption process data to the encrypted zone in the tenant isolation scheme of this invention clearly shows the interaction logic and key processing process between the client, NameNode and KMS, including: 1. The client initiates a DEK generation request (carrying the tenant ID). When a tenant client needs to encrypt a file, it sends a request to KMS, which must include its unique tenant ID and specify the encrypted zone to which the file belongs.

[0100] 2. KMS completes tenant verification and key processing. Tenant identity verification: KMS verifies the validity of the tenant ID submitted by the client through the tenant identity verification module (such as whether it is a registered tenant and whether it has permission to access the specified encrypted area). If the verification fails, the request is rejected. After obtaining the plaintext EZ-Key and verifying it, KMS retrieves the corresponding EZ-Key (ciphertext form) from the "tenant-isolated EZ-Key pool" based on the tenant ID, and then decrypts it using the tenant's master key to obtain the tenant's exclusive EZ-Key plaintext. Generating and encrypting DEK: KMS generates a random DEK (plaintext), and then encrypts the DEK in plaintext using the tenant-specific EZ-Key to generate EDEK (encrypted DEK). KMS returns the key to the client: KMS returns the DEK plaintext (used for file encryption) and EDEK (used for subsequent decryption and metadata storage) to the client together.

[0101] 3. The client uses DEK to encrypt file data. After receiving the DEK plaintext, the client performs file encryption locally; Using the DEK plaintext as the key, the original file data is encrypted using a symmetric encryption algorithm (such as AES) to generate the encrypted file content; After encryption is complete, the client immediately destroys the plaintext DEK in memory (e.g., clears the memory) to avoid the risk of key leakage.

[0102] 4. The client submits metadata to the NameNode. The client constructs a FileEncryptionInfo metadata structure, which contains the core information EDEK, and then submits this metadata to the NameNode; After receiving the file, the NameNode associates the FileEncryptionInfo with the file and stores it. When the client reads the file later, it needs to obtain this metadata from the NameNode to decrypt the file.

[0103] Figure 6 This is a flowchart illustrating the file reading and decryption process in the tenant-isolated encrypted area of ​​the present invention, clearly showing the interaction logic and key processing process between the client, NameNode, and KMS, including: 1. The client requests file metadata from the NameNode. When a client needs to read an encrypted file, it sends a request to the NameNode, specifying the target file path (implicitly passing the tenant ID, which is associated through an authentication token or request header in a multi-tenant scenario). After receiving the request, the NameNode queries the file information. If the tenant ID is invalid or the file does not belong to the tenant, it directly returns "AccessDeniedException" to avoid cross-tenant queries.

[0104] 2. The client obtains FileEncryptionInfo and extracts EDEK. After the NameNode retrieves the file metadata, it returns a FileEncryptionInfo containing the EDEK. The client extracts the core parameter EDEK (encrypted DEK) from this structure as the key basis for subsequent decryption.

[0105] 3. The client requests KMS to decrypt the EDEK (carrying the tenant ID and EDEK). The client constructs a KMS decryption request, explicitly carrying the "tenant ID" and the "extracted EDEK", and sends it to KMS to request the plaintext of the DEK. The tenant ID is the core credential for KMS to determine identity. Requests lacking a tenant ID or with an invalid tenant ID will be directly blocked to avoid "decryption requests without identity". KMS verifies, through the tenant identity verification module, whether the tenant ID is a registered and legitimate tenant and whether the tenant has the authority to decrypt the current EDEK. After the verification is successful, KMS extracts the ciphertext of the EZ-Key corresponding to the tenant from the "tenant-isolated EZ-Key pool"; and decrypts the ciphertext of the EZ-Key with the tenant's master key to obtain the tenant's exclusive EZ-Key plaintext.

[0106] 4. KMS decrypts the EDEK in plaintext using the EZ-Key and returns the DEK in plaintext. KMS decrypts the EDEK sent by the client using the tenant-specific EZ-Key plaintext, generates DEK plaintext, and returns it to the client. The EDEK can only be decrypted by the EZ-Key of its owning tenant, and cannot be decrypted by the EZ-Key of other tenants, thus realizing "key chain tenant binding".

[0107] 5. The client uses DEK to decrypt file data in plaintext. After receiving the DEK plaintext, the client uses it locally to decrypt the encrypted file data read from HDFS (e.g., AES reverse decryption) to obtain the original file plaintext. After decryption, the DEK plaintext in memory is immediately destroyed (e.g., memory is zeroed) to prevent key leakage. The DEK plaintext only exists temporarily on the current tenant client and its lifespan is limited to this decryption session. Even if it is leaked, it will only affect a single file of that tenant and there is no risk of spread.

[0108] Furthermore, the implementation of this invention is not limited to the Hadoop and Ranger-KMS systems. In another embodiment, the solution of this invention is also applicable to other centralized key management systems (KMS) or distributed storage platforms, such as Ceph, Object Storage Service, and cloud vendor KMS (e.g., AWS KMS, Alibaba Cloud KMS, etc.).

[0109] Tenant identity information can be transmitted via tenant tokens, HTTP request headers, or access control lists (ACLs); physical isolation between the master key and data key can be achieved through database partitioning, a standalone encryption machine, or a cloud KMS instance.

[0110] Even if the underlying components or encryption algorithms (such as AES, SM4, RSA, etc.) are different, the tenant-level master key isolation, resource prefix mandatory verification and thread-level tenant context passing mechanism described in this invention can still maintain the same technical effect and achieve cross-platform multi-tenant data security isolation.

[0111] Figure 7 The image shows a Hadoop tenant-level encrypted isolation implementation device proposed in this application, the device comprising: Master key isolation module: used to create an independent master key with tenant identification for each tenant. The master key is used to encrypt and decrypt the tenant's exclusive encryption zone key, thereby achieving physical isolation of master keys between different tenants; Resource prefix mandatory verification module: used to enforce the prefix format containing the tenant identifier in key aliases, encrypted area paths and Ranger policy resources, and to ensure that it is consistent with the tenant identity of the creator or visitor of the resource during verification, and to reject mismatched requests; Tenant context passing module: It is used to inject tenant identity information at the entry point of request processing through the thread-local variable mechanism, and automatically pass through its tenant context information throughout the entire chain processing of the request; Encrypted Zone Lifecycle Binding Module: When creating an encrypted zone, the current tenant's tenant identifier is persistently stored as an extended attribute in the directory metadata, and the consistency of the tenant identifier between the source and target directories is verified before renaming, snapshotting, or copying the directory. Memory security management module: This module stores the plaintext of the key only in the heap memory of the KMS process and clears it through a memory zeroing operation after use, thus preventing the plaintext of the key from being leaked.

[0112] The above-mentioned device implements the steps of the Hadoop tenant-level encrypted isolation implementation method disclosed in this application when it is running.

[0113] Embodiments of this application also disclose an electronic device, including: a processor, a communication interface, a memory for storing a processor-executable computer program, and a communication bus. The processor, communication interface, and memory communicate with each other via the communication bus. The processor executes the executable computer program to implement the steps of the aforementioned Hadoop tenant-level encrypted isolation implementation method.

[0114] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.< / suffix> < / tenantid>

Claims

1. A method for implementing tenant-level encrypted isolation in Hadoop, characterized in that, The method includes: S1. Tenant-level master key isolation: Create an independent master key with a tenant identifier for each tenant. The master key is used to encrypt and decrypt the tenant's exclusive encryption zone key, thereby achieving physical isolation of master keys between different tenants. S2. Forced verification of resource prefixes: In key aliases, encrypted zone paths, and Ranger policy resources, a prefix format containing the tenant identifier is enforced, and during verification, it is ensured that the prefix is ​​consistent with the tenant identity of the creator or visitor of the resource, and mismatched requests are rejected. S3. Tenant Context Passing: Through a thread-level context passing mechanism, tenant identification information is injected at the entry point of request processing, and its tenant context information is automatically passed through during the entire chain processing of the request. S4. Encrypted Zone Lifecycle Binding: When creating an encrypted zone, the tenant identifier of the current tenant is persistently stored in the directory metadata as an extended attribute, and the consistency of the tenant identifier of the source and target directories is verified before renaming, snapshotting, or copying the directory. S5. Memory security management: The plaintext of the key is stored only in the heap memory of the KMS process and is cleared by memory zeroing operation after use to prevent the plaintext of the key from being leaked.

2. The method according to claim 1, characterized in that, Step S1 further includes: S11. Add a tenant identifier field to the master key storage table for each tenant, and generate a unique, randomly distributed master key ciphertext for each tenant; S12. Add a tenant identifier field to the key storage table for each tenant, so that each tenant's encryption zone key can only be decrypted by that tenant's master key.

3. The method according to claim 1, characterized in that, Step S2 further includes: S21. Verify key aliases, enforce their format as <tenant identifier>_<suffix>, and perform dual verification of format and identity when creating or querying keys; S22. Verify the encrypted zone path, forcing it to include the tenant identifier prefix directory, and when creating the encrypted zone, the NameNode verifies the legality of the current tenant's identity and the path prefix; S23. Verify the key resources in the Ranger policy, reject policy requests containing global wildcards, and automatically filter out key resources that do not match the current tenant's prefix.

4. The method according to claim 1, characterized in that, The thread-level context passing mechanism described in step S3 is based on ThreadLocal to inject, read and clear tenant identifiers, and supports cross-thread copying of context in asynchronous thread pool scenarios.

5. The method according to claim 1, characterized in that, Step S3 further includes: S31. Inject the tenant identifier into the gateway or command-line client; S32. Use a context holder class to store and retrieve the tenant identifier of the current thread using ThreadLocal; S33. Ensure that the KMS core service components automatically read tenant information from the context holding class to perform permission and logic checks before performing operations.

6. The method according to claim 1, characterized in that, Step S4 further includes: S41. Set immutable tenant extended attributes on the encrypted zone directory; S42. When performing directory rename, snapshot, and distcp operations, force verification to check whether the tenant attributes of the directory are consistent before and after the operation. If they are inconsistent, the operation is rejected. S43. Listen for directory deletion events. When a directory is deleted, trigger the process of checking and cleaning up the key associated with that directory.

7. The method according to claim 1, characterized in that, The memory clearing operation described in step S5 is executed in the finally block after the key plaintext has been used by calling the underlying memory operation interface, ensuring that the key plaintext only exists briefly in the heap memory of the KMS process and is completely cleared in any execution path.

8. The method according to claim 1, characterized in that, The method also includes tenant-level management steps for keys and audit logs, specifically including: (1) Provide a management interface for querying, rotating, and deleting the private encryption zone key by tenant identifier; (2) Expand the audit log by adding a tenant identifier field so that all key-related operations can be retrieved and traced by the tenant dimension.

9. A Hadoop tenant-level encrypted isolation implementation device, characterized in that, The device includes: Master key isolation module: used to create an independent master key with tenant identification for each tenant. The master key is used to encrypt and decrypt the tenant's exclusive encryption zone key, thereby achieving physical isolation of master keys between different tenants; Resource prefix mandatory verification module: used to enforce the prefix format containing the tenant identifier in key aliases, encrypted area paths and Ranger policy resources, and to ensure that it is consistent with the tenant identity of the creator or visitor of the resource during verification, and to reject mismatched requests; Tenant context passing module: It is used to inject tenant identity information at the entry point of request processing through the thread-local variable mechanism, and automatically pass through its tenant context information throughout the entire chain processing of the request; Encrypted Zone Lifecycle Binding Module: When creating an encrypted zone, the current tenant's tenant identifier is persistently stored as an extended attribute in the directory metadata, and the consistency of the tenant identifier between the source and target directories is verified before renaming, snapshotting, or copying the directory. Memory security management module: This module stores the plaintext of the key only in the heap memory of the KMS process and clears it through a memory zeroing operation after use, thus preventing the plaintext of the key from being leaked.

10. An electronic device, characterized in that, include: Memory and processor; Memory: Used to store computer programs; Processor: for executing the computer program to implement the steps of the Hadoop tenant-level encrypted isolation implementation method as described in any one of claims 1-8.

Images