Hash digest-based mass file permission consistency detection method and system

Abstract

The application discloses a mass file permission consistency detection method and system based on a hash digest, relates to the technical field of file management, and comprises the following steps: obtaining DACL permission configuration data of a plurality of to-be-detected directories in a target file system; performing standardized processing on the DACL permission configuration data of each directory, removing non-permission information parts containing directory path identifiers, and reserving contents reflecting access control rules only; calculating hash digest values corresponding to each directory based on the standardized permission data; and performing clustering comparison on the hash digest values, identifying normal permission modes with the same hash values, and marking directories with hash values deviating from the normal permission modes as permission abnormal objects. The application improves the permission comparison efficiency of mass file directory DACL permissions.

Description

Technical Field

[0001] This application relates to the field of file management technology, and in particular to a method and system for detecting the consistency of permissions of massive files based on hash digest. Background Technology

[0002] In enterprise-level Windows server environments, especially business systems using the NTFS file system such as medical image archiving and document management platforms, the configuration of DACL (Discretionary Access Control List) permissions for files and directories is crucial for data security and compliance. When the underlying storage (such as SAN) experiences a link failure, volume migration, or abnormal system restart, some directories may suffer from DACL metadata corruption or permission resets, preventing legitimate users from accessing critical resources.

[0003] Currently, operations and maintenance personnel primarily rely on the operating system's graphical interface to manually verify permission status: right-clicking the target directory → opening "Properties" → switching to the "Security" tab → manually comparing the permission items for each user / group. This method is extremely inefficient (each operation takes 3-5 seconds) when dealing with thousands or even tens of thousands of business directories, and is highly susceptible to misjudgments due to visual fatigue or operational oversight. Although some script tools can batch export DACL content (such as icacls), the exported results contain unstructured fields such as path information, and direct text comparison still requires significant manual intervention, making automated difference identification difficult. Existing technologies lack an efficient, accurate, and scalable mechanism for quickly locating nodes with abnormal permission configurations within massive directories. Summary of the Invention

[0004] To address the shortcomings of existing technologies and improve the efficiency of permission comparison for DACL permissions of massive file directories, this application provides a method and system for detecting the consistency of permissions for massive files based on hash digests.

[0005] Firstly, the objective of this invention is achieved through the following technical solution:

[0006] A method for detecting the consistency of permissions in massive files based on hash digests includes:

[0007] Obtain DACL permission configuration data for multiple directories to be inspected in the target file system;

[0008] The DACL permission configuration data for each directory is standardized by removing non-permission information that includes directory path identifiers and retaining only the content that reflects access control rules.

[0009] Based on the standardized permission data, calculate the hash digest value for each directory.

[0010] The hash digest values ​​are clustered and compared to identify normal permission patterns with the same hash value, and directories whose hash values ​​deviate from the normal permission patterns are marked as permission abnormal objects.

[0011] By adopting the above technical solution, this invention achieves automatic consistency detection of massive DACL permission configurations by introducing a hash digest mechanism. Since permission configuration is essentially a set of access control rules, if two directories have completely identical permission policies, their standardized rule content will inevitably be consistent, thus generating the same hash value. This invention first removes non-permission variables such as path identifiers from the DACL data to ensure that the hash calculation only reflects the true access control semantics; then, through cluster analysis of the hash value distribution, high-frequency hash patterns are considered normal benchmarks, while low-frequency or isolated hash values ​​correspond to abnormal configurations. This process does not require preset permission templates or rely on complex parsers; it can complete large-scale comparisons using only a general hash algorithm, significantly improving detection efficiency and accuracy, eliminating human error, and possessing good portability and tool compatibility, making it suitable for permission health checks in various NTFS storage scenarios.

[0012] In a preferred embodiment of this application: the DACL permission configuration data is exported through a built-in tool of the operating system, the hash digest value is generated using the MD5 algorithm, and the hash calculation and result summary are automatically executed by a batch script to form a mapping list containing directory identifiers and corresponding hash values, which is used to quickly locate permission configuration differences.

[0013] By adopting the above technical solution, using operating system built-in tools to export DACL data, and combining the MD5 algorithm with batch scripts to automate hash calculations and result aggregation, the implementation threshold and manual intervention requirements for permission detection are significantly reduced. The generated directory identifier and hash value mapping list has a clear structure and efficient querying, transforming permission difference location from complex log analysis into a simple hash comparison operation.

[0014] In a preferred example of this application: the standardization process includes: using a text processing tool to delete the directory path information in the first line of the DACL exported file; the criterion for determining the permission abnormal object is: the hash digest value of the permission abnormal object appears at a frequency significantly lower than a preset threshold in all directories to be inspected, or is inconsistent with the hash value of a known correct permission template.

[0015] By adopting the above technical solution, the text processing tool removes the first line path information from the DACL exported file, further enhancing the thoroughness of the standardization process. This ensures that the same permission configuration under different paths generates consistent hash values, eliminating misjudgments caused by path differences. Simultaneously, a dual judgment mechanism of "frequency threshold" and "correct template matching" is introduced to improve the efficiency and accuracy of anomaly detection.

[0016] In a preferred example, this application further includes, after marking the permission exception object:

[0017] Using the directory corresponding to the permission exception object as the root node, a hierarchical hash tree structure is constructed, where the leaf nodes correspond to the standardized permission metadata of each file in the directory, and the non-leaf nodes are the aggregated hashes of the child node hash values.

[0018] Based on parallel computing, leaf node hashes are generated in parallel from the permission metadata under the directory, and the root hash of the directory is generated from bottom to top, which serves as the permission digest of the current permission status.

[0019] The permission digest is compared with the baseline permission digest of the directory in the historical version snapshot. If they are inconsistent, the difference subtree is located.

[0020] For nodes suspected of conflict in the differential subtree, a two-level verification mechanism combining fuzzy hash initial screening with precise permission field comparison is used to resolve the conflict;

[0021] Incremental hash recalculation is performed only on files whose permissions have changed and their ancestor path nodes in the hierarchical hash tree, updating the permission digest of the corresponding directory and generating a new version snapshot;

[0022] Based on multiple preset permission risk assessment factors, the permission risk score of the permission-abnormal object is calculated for risk detection.

[0023] By adopting the above technical solution, after initially screening out objects with abnormal permissions, a hierarchical hash tree is constructed for their respective directories, and historical snapshots are compared, achieving a leap from "static pattern deviation" to "dynamic change verification." Parallel computing accelerates digest generation, and the incremental update mechanism recalculates only the changed path, significantly reducing the computational overhead of deep verification. The two-stage conflict resolution mechanism of fuzzy hash initial screening and precise comparison effectively filters false positives caused by minor format changes. Finally, combined with risk scoring, the system can not only confirm whether permissions have changed but also assess the security impact of the changes, thereby improving the response speed to permission anomalies.

[0024] In a preferred embodiment of this application, the construction of the hierarchical hash tree structure includes:

[0025] Massive files are clustered according to the file system directory hierarchy or logical grouping, and each group of files forms a subtree of the hash tree;

[0026] The hash value of each non-leaf node is generated by performing a cryptographic hash operation after concatenating the hash values ​​of its direct child nodes in a preset order;

[0027] The parallel computing adopts a task sharding strategy, which divides the file set into multiple subsets, distributes them to multiple computing units to independently generate local hash trees, and then merges them into a global hierarchical hash tree.

[0028] By adopting the above technical solutions, the generation time of permission digests for massive files is greatly shortened. Subtree structures are constructed according to directory hierarchy or logical grouping, and the hash values ​​of child nodes are concatenated in a preset order and then cryptographically hashed, ensuring the determinism and collision resistance of the hash tree structure, so that the same permission status will inevitably generate the same root hash. At the same time, a task sharding strategy is adopted to distribute the file set to multiple computing units to process the local hash trees in parallel, and then merge them into a global structure, giving full play to the efficiency of multi-core or distributed computing resources.

[0029] In a preferred embodiment of this application, the fuzzy hash initial screening includes:

[0030] Extract key fields from the permission metadata of suspected conflicting nodes to generate simplified hashes;

[0031] If the simplified hashes are the same, it is determined that there is no substantial conflict and the exact comparison is skipped; if they are different, the exact comparison process is triggered.

[0032] The incremental update includes:

[0033] Listen for file system events or periodically scan permission change logs to identify target files whose permissions have been changed;

[0034] Only the leaf node hashes of the changed target files are recalculated and updated level by level up the parent path to the root node. The hash values ​​of the remaining unchanged branches reuse historical snapshot data.

[0035] By adopting the above technical solutions, fuzzy hashing initial screening generates simplified hashes for key permission fields, quickly eliminating nodes with no substantial differences. This avoids time-consuming precise comparisons of a large number of similar permission configurations, thereby optimizing conflict resolution efficiency. The incremental update mechanism accurately identifies files with changed permissions by listening to file system events or scanning change logs, and only recalculates hashes for these files and their ancestor paths. The remaining nodes reuse historical snapshot data, greatly reducing redundant calculations.

[0036] In a preferred embodiment of this application, the step of calculating the permission risk score of the permission-abnormal object based on a plurality of preset permission risk evaluation factors includes:

[0037] Multiple permission risk assessment factors are preset, including: file sensitivity level, permission change type, credibility of the change subject's identity, access control list complexity, and whether privileged users or critical system directories are involved.

[0038] For each file whose permissions have been changed, the risk assessment factors for each permission are quantified and assigned according to the file attributes and the change context to obtain the corresponding risk factor score;

[0039] Based on the scores of each risk factor and their preset weights, the permission risk score of a file whose permissions have been changed is calculated using a weighted composite index method.

[0040] By adopting the above technical solution, and by pre-setting multiple risk assessment factors such as file sensitivity level, permission change type, and subject credibility, and by quantifying and assigning values ​​to each factor in conjunction with file attributes and change context, a multi-dimensional characterization of the security impact of permission changes is achieved. A weighted comprehensive index method is used to integrate the scores of each factor, ensuring that the risk score reflects both objective threats such as granting write permissions and subjective trust such as administrator operations, avoiding the one-sided risk assessment of a single indicator.

[0041] In a preferred embodiment of this application, the quantification and assignment of values ​​to each authority risk assessment factor includes:

[0042] Map the directory path or business tag of the file to be evaluated to a predefined sensitivity level table to determine the file sensitivity level score;

[0043] Based on the type of difference before and after the permission change, the risk rule base is matched, and the change type score is output; the difference type includes adding write permission, opening global read, and removing audit group.

[0044] A subject credibility score is generated by combining the identity of the operator who initiated the permission modification with the credibility of the operator's historical behavior.

[0045] The complexity score of the access control list is dynamically calculated based on the number of ACL entries, the depth of nested groups, and the results of permission conflict detection.

[0046] By adopting the above technical solutions, file paths or business tags are mapped to a sensitivity level table to achieve automated sensitivity determination; permission change types are matched based on a risk rule base to accurately capture high-risk operations; the risk of the subject is assessed by combining the operator's identity and the credibility of their historical behavior; and the complexity score is dynamically calculated through the number of ACL entries and nesting depth to comprehensively reflect the degree of disorder in permission configuration.

[0047] Secondly, the objective of this invention is achieved through the following technical solution:

[0048] A massive file permission consistency detection system based on hash digest executes the massive file permission consistency detection method based on hash digest as described above. The system includes:

[0049] The data acquisition module is used to acquire DACL permission configuration data for multiple directories to be inspected in the target file system;

[0050] The standardization processing module is used to standardize the DACL permission configuration data of each directory, removing non-permission information that contains directory path identifiers and retaining only the content that reflects access control rules;

[0051] The hash calculation module is used to calculate the hash digest value for each directory based on the standardized permission data.

[0052] The anomaly identification module is used to cluster and compare the hash digest values, identify normal permission patterns with the same hash value, and mark directories whose hash values ​​deviate from the normal permission patterns as permission anomaly objects.

[0053] Thirdly, the objective of this invention is achieved through the following technical solution:

[0054] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described xxx method.

[0055] In summary, this application includes at least one of the following beneficial technical effects:

[0056] 1. By acquiring and standardizing DACL permission configuration data, interference from non-permission semantic information such as directory paths on hash calculations is effectively eliminated, ensuring that the hash digest reflects only the actual access control rules. Based on this, hash value clustering and comparison are used to identify frequently occurring normal permission patterns, while directories with low frequency or deviations from the template are marked as abnormal objects, achieving rapid and automated initial screening of permission configuration anomalies in massive file systems.

[0057] 2. Building upon the initial screening of directories with abnormal permissions, a hierarchical hash tree structure based on these directories and a historical snapshot comparison mechanism are introduced, upgrading the capability from "coarse-grained anomaly labeling" to "fine-grained change tracing." Parallel computing accelerates digest generation, and an incremental update strategy recalculates only the path nodes affected by changes, significantly reducing the computational overhead of deep verification. Simultaneously, the two-tier verification mechanism of fuzzy hashing and precise comparison effectively distinguishes between harmless format differences and genuine permission tampering, greatly reducing false positives. Attached Figure Description

[0058] Figure 1 This is a flowchart of a method for detecting the consistency of permissions of massive files based on hash digest in one embodiment of this application;

[0059] Figure 2 This is another flowchart of a method for detecting the consistency of permissions of massive files based on hash digest in one embodiment of this application. Detailed Implementation

[0060] The present application will be further described in detail below with reference to the accompanying drawings.

[0061] In one embodiment, such as Figure 1 As shown, this application discloses a method for detecting the consistency of permissions in massive files based on hash digests, which specifically includes the following steps:

[0062] S1: Obtain DACL permission configuration data for multiple directories to be inspected in the target file system.

[0063] In this embodiment, DACL permission configuration data refers to the original exported content of the Discretionary Access Control List associated with each directory in the Windows operating system, which records which users or groups have what kind of access permissions (such as read, write, execute, etc.) to the directory.

[0064] Specifically, DACL permission configuration data is exported using built-in operating system tools. For example, in this embodiment, the Windows built-in command-line tool icacls is used to batch export permission configurations for all subdirectories under the target path (e.g., W:\image-new_test). For instance, the CONCATENATE function in Excel is used to generate a command sequence in the form of icacls W:\image-new_test\dir001 / saveD:\icacls\dir001.txt, which is then written into a .bat script for automatic execution, ultimately obtaining the DACL configuration files for each of the 2929 subdirectories.

[0065] S2: Standardize the DACL permission configuration data for each directory, removing non-permission information that includes directory path identifiers, and retaining only the content that reflects access control rules.

[0066] In this embodiment, the standardization process includes using a text processing tool to remove the directory path information from the first line of the DACL export file. Standardization eliminates hash value differences caused by different directory names or paths, ensuring that the same permission rules generate consistent digests across different paths. The first line of the DACL export file typically contains the complete directory path (e.g., W:\image-new_test\dir001), but this information is irrelevant to permission semantics and needs to be removed.

[0067] Specifically, using the text processing tool sed, execute the command `sed -i '1d' dir*.txt` to batch delete the first line (i.e., the path identifier) ​​of each DACL file, retaining only the permission entries starting from the second line, such as (A; OICI; FA; ; BA). After this processing, if two directories have exactly the same permissions, their standardized file contents will be completely identical.

[0068] S3: Calculate the hash digest value for each directory based on the standardized permission data.

[0069] In this embodiment, the hash digest value is generated using the MD5 algorithm, and the hash calculation and result aggregation are automated through batch scripts to form a mapping list containing directory identifiers and corresponding hash values, used to quickly locate differences in permission configurations. In practical applications, other cryptographic hash functions can also be used to generate hash digest values. The hash digest value generates a fixed-length unique fingerprint for the standardized permission content, used to quickly compare whether the content is consistent.

[0070] Specifically, the md5sum.exe tool is used to batch calculate the MD5 values ​​of all standardized .txt files. The command is `md5sum dir*.txt>md5sum_image.txt`. The output is a list where each line contains an MD5 value and its corresponding filename, for example, `b079321928dd32d9fce62176ec23f73d dir001.txt`.

[0071] S4: Cluster and compare the hash digest values ​​to identify normal permission patterns with the same hash value, and mark directories whose hash values ​​deviate from the normal permission patterns as permission abnormal objects.

[0072] In this embodiment, the criteria for determining an object with abnormal permissions are: the frequency of the hash digest value of the object with abnormal permissions appearing in all directories to be inspected is significantly lower than a preset threshold, or it is inconsistent with the hash value of a known correct permission template.

[0073] Specifically, clustering comparison refers to counting the frequency of each hash value. High-frequency hash values ​​represent the "normal permission mode" common to most directories, while low-frequency or unique hash values ​​may indicate anomalies.

[0074] Further frequency analysis of md5sum_image.txt revealed that the hash value b079321928dd32d9fce62176ec23f73d appeared 1008 times, and b501b94dc01413bef3e3742ec8a88a82 appeared 427 times. With a preset threshold of 500 occurrences, the latter, due to its significantly lower frequency, was marked as an object with abnormal permissions.

[0075] For example, select a typical directory in the business system with confirmed correct permission configuration (e.g., W:\image-new_test\template_dir), export its DACL configuration using `icacls template_dir / save template_acl.txt`, and normalize it using `sed -i '1d' template_acl.txt`. Then, perform the same `sed` operation to delete the first line in all 2929 subdirectories and the template directory to be inspected, ensuring that all input data contains only pure permission rules. For example, regardless of whether the directory name is patient_001 or report_2024, as long as the order and content of the permission entries are consistent, the normalized file will be exactly the same. Next, run `md5sum template_acl.txt dir*.txt>all_md5.txt` to obtain the template hash and the hashes of all subdirectories. Write a script to iterate through all_md5.txt, comparing the hash of each subdirectory with the template hash c3f8a1d2e4b5... one by one. If there is a discrepancy (e.g., a directory hash is b501b94dc01413bef3e3742ec8a88a82), then immediately mark the directory as an object with abnormal permissions.

[0076] In one embodiment, such as Figure 2 As shown, after marking objects with abnormal permissions, the method for detecting the consistency of permissions in massive files based on hash digests also includes:

[0077] S10: Using the directory corresponding to the permission exception object as the root node, construct a hierarchical hash tree structure, where the leaf nodes correspond to the standardized permission metadata of each file in the directory, and the non-leaf nodes are the aggregated hashes of the child node hash values.

[0078] In this embodiment, the hierarchical hash tree structure is a tree-like data structure used to aggregate file permission information layer by layer, so that permission changes of any subdirectory or file can be accurately located through path hash changes. Leaf nodes store standardized permission metadata for a single file, such as user, group, and read / write / execute bits; non-leaf nodes represent the aggregated state of their subdirectories or file sets.

[0079] Specifically, assume the directory W:\image-new_test\patient_887 has been marked as an object with abnormal permissions. The system uses this directory as the root and recursively traverses all its subdirectories and files (such as report.pdf, images / , etc.). For each file, it calls the operating system API to obtain raw permission data, such as Windows' GetNamedSecurityInfo or Linux's stat+getfacl. It then performs standardized processing steps, such as removing paths and unifying the format, to form the permission metadata for leaf nodes. Subsequently, a tree structure is built from bottom to top; for example, the hash of the images / directory node is generated by aggregating the hashes of all image files under it.

[0080] Specifically, constructing the hierarchical hash tree structure in step S10 includes:

[0081] S101: Cluster massive files according to the file system directory hierarchy or logical grouping, with each group of files forming a subtree of the hash tree.

[0082] In this embodiment, clustering refers to dividing the massive amount of files to be processed into several logical units based on their physical path structure or business semantic tags in the file system. Each unit independently constructs a sub-hash tree, thereby reducing the size of a single tree and improving parallel processing efficiency. Physical path structures include a, b, and c; business semantic tags include image class, log class, and configuration class.

[0083] Specifically, when detecting the directory W:\image-new_test, the system first performs natural clustering by first-level subdirectories, for example, treating patient_001 / , patient_002 / , ..., patient_2929 / as independent groups. If a business scenario involves non-hierarchical logical grouping of all files tagged with "emergency images" in metadata, then clustering can also be performed by that tag. The files within each group form a sub-hash tree; for example, the patient_887 / group contains all its PDFs, JPEGs, and subfolders, forming a subtree rooted at patient_887.

[0084] S102: The hash value of each non-leaf node is generated by performing a cryptographic hash operation after concatenating the hash values ​​of its direct child nodes in a preset order.

[0085] In this embodiment, a preset order, such as lexicographical order or path depth-first order, means that the hashes of child nodes must be sorted according to a uniform rule before concatenation to ensure that the same permission structure generates completely consistent parent node hashes in different execution environments. Cryptographic hash operations employ collision-resistant algorithms such as SHA-256.

[0086] Specifically, for the directory patient_887 / , its direct children include the file report.pdf (hash h1=a1b2...), the subdirectories images / (hash h2=c3d4...), and docs / (hash h3=e5f6...). The system first sorts the child node names in ascending alphabetical order: docs / , images / , report.pdf, corresponding to the hash sequence [e5f6..., c3d4..., a1b2...]. These are then concatenated into the string "e5f6...c3d4...a1b2...", and then the SHA-256 hash of the parent node is calculated as parent_hash=sha256("e5f6...c3d4...a1b2...")=g7h8....

[0087] S103: Parallel computing adopts a task partitioning strategy, which divides the file set into multiple subsets, distributes them to multiple computing units to independently generate local hash trees, and then merges them into a global hierarchical hash tree.

[0088] In this embodiment, the task sharding strategy refers to decomposing the overall construction task into multiple independently executable subtasks, which are processed in parallel by multi-core CPUs, multi-threads, or distributed nodes, and finally assembling the global hash tree by merging the tree structure.

[0089] For example, the 2929 first-level subdirectories are evenly divided into four task shards: shard 1 (patient_001–732), shard 2 (733–1464), shard 3 (1465–2196), and shard 4 (2197–2929). Four Python multi-process worker processes are launched, each independently loading the directory list of its assigned shard and recursively building its own local hash forest, resulting in multiple subtrees. After all processes are complete, the main process collects the root hash sets of each shard and creates a virtual global root node, setting its child nodes as the aggregate representatives of the four shards, generating a complete global hierarchical hash tree. Real-world testing shows that on a 32-core server, the task sharding strategy reduces the hash tree construction time for the 2929 directories from 18 minutes serially to 2.3 minutes, an efficiency improvement of nearly 8 times.

[0090] S20: Based on parallel computing, generate leaf node hashes in parallel for the permission metadata under the directory, and aggregate them from bottom to top to generate the root hash of the directory, which serves as the permission digest of the current permission status.

[0091] In this embodiment, parallel computing is used to accelerate the generation of permission digests for massive files; the permission digest is the root hash value of the entire hash tree, which uniquely represents the current complete permission status of the directory.

[0092] For example, the file list under the patient_887 directory is divided into four equal subsets and assigned to four Python multi-process work units. Each unit independently calculates the normalized permission metadata of the assigned files and generates leaf hashes using the SHA-256 algorithm (e.g., sha256(“user:admin;group:medical;rwx”)→a1b2c3...). Once all leaf hashes are ready, they are merged from bottom to top according to the directory hierarchy: first, the hashes of subdirectories at the same level are aggregated (e.g., the hashes of images / file1.hash and images / file2.hash are concatenated), and finally, the root hash root_hash_current=d4e5f6... is generated as the current permission digest.

[0093] S30: Compare the permission summary with the baseline permission summary of the directory in the historical version snapshot. If they are inconsistent, locate the difference subtree.

[0094] In this embodiment, a historical version snapshot is a snapshot of the directory's permission status saved by the system during a previous successful detection or system deployment, including the root hash and optional intermediate node hashes. The "difference subtree" refers to the smallest common subtree range where permission changes have occurred. Historical version snapshots are stored in a snapshot database, such as Redis or a local JSON file.

[0095] Specifically, the baseline root hash of patient_887 (root_hash_baseline=a1b2c3...) is read from the snapshot database. A comparison reveals that d4e5f6... ≠ a1b2c3..., indicating a change has occurred. Subsequently, the hashes of child nodes are recursively compared: if the current hash of a subdirectory matches the snapshot, its subtree is skipped; if they do not match, the process continues until the smallest difference node is located (e.g., the leaf hash change in images / report.pdf), thus determining the difference subtree as images / .

[0096] S40: For nodes suspected of conflict in the differential subtree, a two-level verification mechanism combining fuzzy hash initial screening with precise permission field comparison is used to resolve the conflict.

[0097] In this embodiment, fuzzy hashing is a lightweight hashing method that is generated only based on key permission fields such as whether or not "write permission" is included. It is used to quickly filter out changes that do not make substantial differences, such as adjusting the order of comments. Precise comparison, on the other hand, requires comparing the complete permission metadata field by field.

[0098] Specifically, for each node in the difference subtree, key fields such as "whether there is global write permission" and "whether it includes an audit group" are first extracted to generate simplified strings, and then MD5 is calculated as a fuzzy hash. If the current fuzzy hash is the same as the snapshot's, and the fuzzy hashes are the same (e.g., both are no_write and has_audit), it is determined to be a risk-free change, and the exact comparison is skipped; if they are different, an exact comparison is triggered: the standardized complete ACL content is compared byte by byte to confirm whether it is a real permission tampering.

[0099] Further, in step S40, the initial screening of fuzzy hashing includes:

[0100] S401: Extract key fields from the permission metadata of suspected conflicting nodes to generate simplified hashes.

[0101] S402: If the simplified hashes are the same, it is determined that there is no substantial conflict and the exact comparison is skipped; if they are different, the exact comparison process is triggered.

[0102] In this embodiment, the key fields refer to the permission attributes that play a decisive role in security impact, rather than all ACL details; the key fields are defined as: (1) whether there is "Write (W)" or "Full Control (F)" permission; (2) whether global groups such as "Everyone" or "AuthenticatedUsers" are included; (3) whether the preset audit group (such as "SecurityAudit") has been removed. For the current permission metadata (A; OICI; FA;; BA)(A; OICI; 0x1200a9;;; S-1-5-21-...-1001) of the file patient_887 / report.pdf, the key feature string is extracted as "has_full_control=True, has_global_group=False, audit_group_present=True".

[0103] Furthermore, comparing the current simplified hash 9f3b2c... with the old simplified hash 9f3b2c... stored in the historical snapshot, they are found to be identical, indicating that although the original ACL text may have differences in line breaks or SID representation, the key security semantics remain unchanged. Therefore, the system directly determines "no substantial conflict" and skips the subsequent precise comparison, saving approximately 80% of the verification time. Conversely, if the current simplified hash changes to d4e5f6..., the precise comparison process is immediately triggered.

[0104] S50: Perform incremental hash recalculation only on files whose permissions have changed and their ancestor path nodes in the hierarchical hash tree, update the permission summary of the corresponding directory and generate a new version snapshot.

[0105] Furthermore, the incremental update in step S50 includes:

[0106] S501: Listens for file system events or periodically scans permission change logs to identify target files whose permissions have been changed.

[0107] In this embodiment, change events can be captured through active listening or passive scanning. Permission change identification is a prerequisite for incremental updates.

[0108] For example, in a Windows Server 2019 environment, the system enables the "Object Access Auditing" policy and listens for event 4670 (Permission Modification) in the Security-Auditing log via ETW (Event Tracing for Windows). When the log shows that user admin modified the DACL of W:\image-new_test\patient_887\report.pdf, the system immediately records that file path as the "Change Target". In log-restricted environments where auditing cannot be enabled, a polling method is used every 5 minutes to scan the icacls / verify output or compare it with the leaf hash list of the last snapshot to identify files whose hash values ​​have changed.

[0109] S502: Only recalculate the leaf node hash for the changed target file and update it level by level up the parent path to the root node. The hash values ​​of the remaining unchanged branches reuse historical snapshot data.

[0110] In this embodiment, incremental hash recalculation avoids a full reconstruction of the hash tree, updating only the paths affected by the changes, thus improving efficiency. The new version snapshot serves as a baseline for the next round of detection. For example, after confirming that the permissions of images / report.pdf have changed from "read-only" to "write," the system only recalculates the leaf hashes of this file, then sequentially updates the hash values ​​of its parent node images / and grandparent node patient_887. The hashes of other unchanged branches, such as docs / , directly reuse the snapshot data. Finally, a new root hash root_hash_new is generated, and the entire updated hash tree is serialized and stored as a version snapshot snapshot_v2 with a timestamp of 2025-12-09T18:00:00.

[0111] S60: Based on multiple preset permission risk assessment factors, calculate the permission risk score of objects with abnormal permissions in order to perform risk detection.

[0112] In this embodiment, the permission risk score is a numerical indicator used to quantitatively assess the security impact of permission changes, distinguishing between high-risk and low-risk anomalies. Multiple permission risk assessment factors are preset, including: file sensitivity level, permission change type, credibility of the changing entity's identity, access control list complexity, and whether privileged users or critical system directories are involved. File sensitivity level reflects the value of data assets; permission change type characterizes the inherent risk of the operation; credibility of the changing entity's identity assesses the operator's reliability; ACL complexity measures the disorder and management difficulty of permission configuration; and whether privileged paths are involved determines whether the change location is in a high-risk area. These five risk assessment factors characterize the security impact of permission changes from different dimensions. For example, in a medical imaging business system, the administrator pre-defines the value rules and weights of each factor in the configuration file risk_config.yaml. For instance, the weight coefficients of the five risk assessment factors are 0.30, 0.40, 0.15, 0.10, and 0.05 respectively; the sum of the weight coefficients of all risk assessment factors is 1.

[0113] Specifically, step S60 includes:

[0114] S601: For each file whose permissions have been changed, the risk assessment factors for each permission are quantified and assigned according to the file attributes and the change context to obtain the corresponding risk factor score.

[0115] In this embodiment, quantization assignment refers to mapping qualitative descriptions such as high sensitivity and new write permissions to a numerical value of 0–100.

[0116] For example, consider the file W:\image-new_test\patient_887\report.pdf:

[0117] The path containing the file with the sensitivity level includes the prefix "patient_", which matches the preset sensitivity label "medical patient data". The table shows a sensitivity level score of 85.

[0118] The permission change type was found to be newly added (A;;WDAC;;;WD) (Everyone can write + delete) after the comparison of ACLs, which matches the high-risk rule "open global write permission", and scores 95 points;

[0119] Trustworthiness of the changed subject identity: The operator is the domain account ops_user03, which has no abnormal operations in the past 30 days and belongs to the operation and maintenance group, with a trustworthiness score of 75;

[0120] ACL complexity: After the change, the number of ACL entries increased from 3 to 7, including 2 levels of nested groups. According to the complexity formula score = 50 + number of entries × 5 + nesting depth × 10, it scored 95 points.

[0121] Does it involve a critical system directory? If image-new_test is marked as a "core business directory", it meets the condition and receives a fixed score of 100.

[0122] Further, in step S601, the risk assessment factors for each authority are quantified and assigned values, including:

[0123] S6011: Map the directory path or business tag of the file to be evaluated to a predefined sensitivity level table to determine the file sensitivity level score.

[0124] In this embodiment, the sensitivity level table is a mapping table pre-configured by the security administrator, used to automatically convert the logical location or business attribute of a file into a numerical sensitivity score. For example, if the path pattern is / patient_* / or the business tag is HPI, the file sensitivity level score is 90 points; if the path pattern is / reports / , the file sensitivity level score is 70 points; if the path pattern is / logs / , the file sensitivity level score is 30 points; and for other path patterns, the file sensitivity level score is 50 points.

[0125] S6012: Match the risk rule base according to the difference type before and after the permission change, and output the change type score; the difference type includes adding write permission, opening global read, and removing audit group.

[0126] In this embodiment, the risk rule base is a structured set of rules, where each rule defines a high-risk ACL change pattern and its corresponding risk score. For example, the change type score for "adding write permissions to Everyone / AuthenticatedUsers" is 95 points; the change type score for "removing the SecurityAudit or Compliance group" is 90 points; the change type score for "granting full control permissions" is 85 points; and the change type score for "only changing the order of ACL entries" is 30 points.

[0127] S6013: Generate a subject credibility score by combining the identity of the operator who initiated the permission modification with the credibility of the operator's historical behavior.

[0128] In this embodiment, the subject credibility comprehensively considers the operator's static identity attributes and dynamic behavioral history, and generates a credibility score of 0-100 through weighting or table lookup.

[0129] For example, extract the operator's SID from the Windows security log and associate it with the enterprise IAM system to obtain their role information. Simultaneously, query the behavior records for the past 30 days:

[0130] If the operator is a regular operations and maintenance account (not a domain administrator), and there is no history of failed logins, unconventional time operations, or batch permission modifications, then the basic trust level is 80%.

[0131] If there are more than 3 instances of operation outside of normal time periods, 15 points will be deducted;

[0132] For automated scripts such as svc_backup@DOMAIN, the confidence level is fixed at 70% because their behavior is predictable.

[0133] If a domain administrator operates directly, although they have high privileges, the risk is high. The default is 60, and additional approval is required.

[0134] In this example, the operator ops_user03 is a regular operations and maintenance user and behaves normally, so the subject's credibility score is 80.

[0135] S6014: The complexity score of the access control list is dynamically calculated based on the number of ACL entries, the depth of nested groups, and the results of permission conflict detection.

[0136] In this embodiment, ACL complexity reflects the manageability of permission configuration and the potential risk of conflicts. The more entries, the deeper the group nesting, and the existence of mutually exclusive permissions, the higher the complexity, and the more likely it is to cause security vulnerabilities or operational errors.

[0137] For example, perform the following calculations on the standardized ACL:

[0138] Entry score: entry_score=min(100, 40+number of entries×6) (maximum 100);

[0139] Nesting depth score: First, parse whether each SID is a group, then recursively query its members. The maximum nesting level is d, then nest_score=min(100, 30+d×20);

[0140] Conflict detection score: If the same subject is found to exist simultaneously as (A;;R;;;User) and (D;;;R;;;User), then a conflict is marked and an additional 20 points are awarded.

[0141] Regarding the modified ACL in report.pdf:

[0142] If the number of items is 7, then 40 + 7 × 6 = 82;

[0143] If the maximum nesting depth is 2, then 30 + 2 × 20 = 70;

[0144] No explicit conflict detected, conflict score = 0;

[0145] The final ACL complexity score is the average of the three factors: (82+70+0) / 3≈75, which is rounded to 75.

[0146] S602: Based on the scores of each risk factor and preset weights, the weighted composite index method is used to calculate the permission risk score of the file whose permissions have been changed.

[0147] In this embodiment, the weighted composite index method generates a single risk score (0–100) by linearly weighting and fusing multidimensional factors, which facilitates threshold determination and priority ranking. If the score exceeds a preset high-risk threshold, such as 80 points, it is marked as "high-risk abnormality".

[0148] For example, the system scores changes under the patient_887 directory based on a preset rule base: because report.pdf is located under the "Medical Imaging" business tag, its sensitivity level score is 80; the change type is "add write permission," matching a high-risk rule, scoring 90 points; the operator is a regular operations account with no history of abnormalities, resulting in a subject credibility score of 70; the number of ACL entries increased from 3 to 8 and nested groups appeared, resulting in a complexity score of 65. The risk score, calculated using weighted averages (sensitivity 0.3, change type 0.4, subject 0.2, complexity 0.1), is: 0.3×80+0.4×90+0.2×70+0.1×65=82.5, exceeding the threshold of 80, thus being classified as "high-risk abnormality," triggering an alarm and recommending automatic rollback.

[0149] In one embodiment, the method further includes:

[0150] S611: Construct a preset permission risk discrimination matrix, with permission risk scores as row vectors and system security policy levels as column vectors.

[0151] In this embodiment, the row vector represents the scoring range, such as 0-100 points divided into several levels; the column vector represents the current security policy level of the system, including: ordinary business, core system, and high-sensitivity data area, such as medical image storage; different policy levels have different risk tolerance for the same score.

[0152] For example, the permission risk judgment matrix is ​​as follows:

[0153] The permission risk discrimination matrix allows for the classification of medium-score (60–79) data as high-risk even in highly sensitive data areas.

[0154] S612: Input the calculated permission risk score into the permission risk discrimination matrix and output the corresponding permission risk level.

[0155] In this embodiment, after completing the permission risk score calculation, the discrimination matrix is ​​automatically queried and a standardized risk level is output by combining the business area tag to which the target file belongs.

[0156] S613: Trigger differentiated response actions based on the permission risk level. Response actions include logging for low risk, sending alarms for medium risk, and automatically rolling back permissions and locking the account for high risk.

[0157] For example, the built-in response engine operates according to the following rules:

[0158] When the risk is low, the event is only written to the security log security_audit.log in the format [INFO] Permissions tweaking: patient_001 / config.ini, score=45, without notifying personnel;

[0159] In cases of medium risk, in addition to logging, an alert is sent to the security operations team via WeChat / email: "[Medium Risk] Core directory permission change detected, please check: patient_555 / data.xlsx";

[0160] In cases of high risk, immediately invoke the icacls command to automatically roll back file permissions to the ACL configuration in the previous version snapshot; and invoke the domain controller API to temporarily lock the operator account ops_user03 (disable login, retain audit privileges); generate a high-risk event work order and push it to the SOC platform.

[0161] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0162] In one embodiment, a massive file permission consistency detection system based on hash digest is provided, which corresponds to the massive file permission consistency detection method based on hash digest in the above embodiment.

[0163] The massive file permission consistency detection system based on hash digests includes a data acquisition module, a standardization processing module, a hash calculation module, and an anomaly detection module. Detailed descriptions of each functional module are as follows:

[0164] The data acquisition module is used to acquire DACL permission configuration data for multiple directories to be inspected in the target file system;

[0165] The standardization processing module is used to standardize the DACL permission configuration data of each directory, removing non-permission information that contains directory path identifiers and retaining only the content that reflects access control rules;

[0166] The hash calculation module is used to calculate the hash digest value for each directory based on the standardized permission data.

[0167] The anomaly detection module is used to cluster and compare hash digest values, identify normal permission patterns with the same hash value, and mark directories whose hash values ​​deviate from the normal permission patterns as permission anomaly objects.

[0168] For specific limitations regarding the hash digest-based massive file permission consistency detection system, please refer to the limitations of the hash digest-based massive file permission consistency detection method above, which will not be repeated here. Each module in the hash digest-based massive file permission consistency detection system can be implemented entirely or partially through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor in the computer device in hardware form, or it can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0169] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of a method for detecting the consistency of permissions for massive files based on hash digests.

[0170] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0171] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0172] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for detecting consistency of permissions in massive files based on hash digests, characterized in that, include: Obtain DACL permission configuration data for multiple directories to be inspected in the target file system; The DACL permission configuration data for each directory is standardized by removing non-permission information that includes directory path identifiers and retaining only the content that reflects access control rules. Based on the standardized permission data, calculate the hash digest value for each directory. The hash digest values ​​are clustered and compared to identify normal permission patterns with the same hash value, and directories whose hash values ​​deviate from the normal permission patterns are marked as permission abnormal objects. The standardization process includes: using a text processing tool to delete the directory path information in the first line of the DACL exported file; the criteria for determining the permission abnormal object is: the hash digest value of the permission abnormal object appears at a significantly lower frequency than a preset threshold in all directories to be inspected, or is inconsistent with the hash value of a known correct permission template; Following the marking of permission exception objects, the following is also included: Using the directory corresponding to the permission exception object as the root node, a hierarchical hash tree structure is constructed, where the leaf nodes correspond to the standardized permission metadata of each file in the directory, and the non-leaf nodes are the aggregated hashes of the child node hash values. Based on parallel computing, leaf node hashes are generated in parallel from the permission metadata under the directory, and the root hash of the directory is generated from bottom to top, which serves as the permission digest of the current permission status. The permission digest is compared with the baseline permission digest of the directory in the historical version snapshot. If they are inconsistent, the difference subtree is located. For nodes suspected of conflict in the differential subtree, a two-level verification mechanism combining fuzzy hash initial screening with precise permission field comparison is used to resolve the conflict; Incremental hash recalculation is performed only on files whose permissions have changed and their ancestor path nodes in the hierarchical hash tree, updating the permission digest of the corresponding directory and generating a new version snapshot; Based on multiple preset permission risk assessment factors, the permission risk score of the permission-abnormal object is calculated for risk detection. The construction of the hierarchical hash tree structure includes: Massive files are clustered according to the file system directory hierarchy or logical grouping, and each group of files forms a subtree of the hash tree; The hash value of each non-leaf node is generated by performing a cryptographic hash operation after concatenating the hash values ​​of its direct child nodes in a preset order; The parallel computing adopts a task sharding strategy, which divides the file set into multiple subsets, distributes them to multiple computing units to independently generate local hash trees, and then merges them into a global hierarchical hash tree.

2. The method for detecting the consistency of permissions in massive files based on hash digests according to claim 1, characterized in that, The DACL permission configuration data is exported through the operating system's built-in tools. The hash digest value is generated using the MD5 algorithm, and the hash calculation and result summary are automatically executed by batch scripts to form a mapping list containing directory identifiers and corresponding hash values, which is used to quickly locate permission configuration differences.

3. The method for detecting the consistency of permissions in massive files based on hash digests according to claim 1, characterized in that, The initial screening of fuzzy hashing includes: Extract key fields from the permission metadata of suspected conflicting nodes to generate simplified hashes; If the simplified hashes are the same, it is determined that there is no substantial conflict and the exact comparison is skipped; if they are different, the exact comparison process is triggered. The incremental update includes: Listen for file system events or periodically scan permission change logs to identify target files whose permissions have been changed; Only the leaf node hashes of the changed target files are recalculated and updated level by level up the parent path to the root node. The hash values ​​of the remaining unchanged branches reuse historical snapshot data.

4. The method for detecting the consistency of permissions in massive files based on hash digests according to claim 1, characterized in that, The calculation of the permission risk score of the permission-abnormal object based on multiple preset permission risk evaluation factors includes: Multiple permission risk assessment factors are preset, including: file sensitivity level, permission change type, credibility of the change subject's identity, access control list complexity, and whether privileged users or critical system directories are involved. For each file whose permissions have been changed, the risk assessment factors for each permission are quantified and assigned according to the file attributes and the change context to obtain the corresponding risk factor score; Based on the scores of each risk factor and their preset weights, the permission risk score of a file whose permissions have been changed is calculated using a weighted composite index method.

5. The method for detecting the consistency of permissions in massive files based on hash digests according to claim 4, characterized in that, The quantitative assignment of values ​​to each authority risk assessment factor includes: Map the directory path or business tag of the file to be evaluated to a predefined sensitivity level table to determine the file sensitivity level score; Based on the type of difference before and after the permission change, the risk rule base is matched, and the change type score is output; the difference type includes adding write permission, opening global read, and removing audit group. A subject credibility score is generated by combining the identity of the operator who initiated the permission modification with the credibility of the operator's historical behavior. The complexity score of the access control list is dynamically calculated based on the number of ACL entries, the depth of nested groups, and the results of permission conflict detection.

6. A massive file permission consistency detection system based on hash digest, characterized in that, The system for implementing the massive file permission consistency detection method based on hash digest as described in any one of claims 1 to 5, wherein the system comprises: The data acquisition module is used to acquire DACL permission configuration data for multiple directories to be inspected in the target file system; The standardization processing module is used to standardize the DACL permission configuration data of each directory, removing non-permission information that contains directory path identifiers and retaining only the content that reflects access control rules; The hash calculation module is used to calculate the hash digest value for each directory based on the standardized permission data. The anomaly identification module is used to cluster and compare the hash digest values, identify normal permission patterns with the same hash value, and mark directories whose hash values ​​deviate from the normal permission patterns as permission anomaly objects.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the massive file permission consistency detection method based on hash digest as described in any one of claims 1 to 5.

Images