A hierarchical access control system for incubator enterprise files and a method for adjusting permissions.

Abstract

This invention discloses a hierarchical access control system and permission adjustment method for enterprise archives in incubators, relating to the fields of archive information security and access control technology. It addresses the risks of exporting or retrying amplification and unauthorized access caused by cross-version policy fluctuations in enterprise archives within incubator scenarios. The system solidifies enterprise identifiers in enterprise archives, extracts sensitive elements based on archive metadata and text according to rules, and assigns weighted scores to generate archive security levels and upper limits for permission levels. It combines user enterprise affiliation, roles, and attribute sets to generate deterministic access control policies and form an equivalent encrypted access structure. Symmetric encryption is used to protect the text, and attribute-based encryption is used to encapsulate the data key. Upon requesting access, authentication is performed according to the policy. Then, within the same processing cycle, a request window is constructed to calculate process variables such as export aggregation, version jumps, and retry amplification, dynamically downgrading or rejecting the operation. Simultaneously, auditing is recorded, and chain-based summaries are used to prevent tampering and traceability.

Description

Technical Field

[0001] This invention relates to the field of archival information security and access control technology, and more specifically, to an incubator enterprise archive hierarchical access control system and permission adjustment method. Background Technology

[0002] Incubators generate a large number of files for resident companies, including contracts, financial documents, intellectual property records, and personnel files. This involves numerous personnel, rapidly changing roles, and lengthy processing times, requiring both convenient sharing and strict isolation of company boundaries and sensitive information. Current practices often rely on static permission tables or single-request granular authentication: on the one hand, file security levels often lack traceable, rule-based determination, making it difficult to maintain consistency across different sources and formats; on the other hand, permission maintenance records may be frequently updated during the processing period, leading to repeated requests from the same user for the same file crossing policy version switching points, resulting in repeated cycles of allowing export initially, rejecting later due to version inconsistency, and then allowing again after synchronization. This repetition can trigger automatic retries in business systems, clustering of export operations, upward shifting of security level coverage, and jumps in operation sequences. Simply relying on version inconsistency for rejection is insufficient to suppress the amplifying effect of retrying. Furthermore, if only storage encryption is implemented without policy-bound key distribution and verifiable auditing, it is difficult to meet compliance traceability and anti-tampering requirements.

[0003] To address the above problems, this invention proposes a solution. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide an incubator enterprise file hierarchical access control system and permission adjustment method to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: In a preferred embodiment, it includes: When archiving enterprise files, generate an enterprise file identifier, determine the enterprise identifier, file security level and access level limits, and establish enterprise file access control records and user access control records; Based on enterprise file access control records, user access control records, and permission management and maintenance records, an access control policy and policy version number are generated, and encryption binding and key distribution are completed. Upon receiving an access request, the access control policy determination function outputs either "allow" or "deny," and a request sequence window is established under the same session identifier to generate a process status record. Based on the process status record, the clustering degree, version jump rate, retry amplification factor, security level coverage gradient, and operation jump intensity are calculated and analyzed to obtain the process deviation degree, which is then recursively smoothed to obtain the smooth deviation degree. When the access control policy determination function outputs "allow," an executable permission level operation is generated based on the smooth deviation degree, and a version stability constraint is applied when the version jump rate reaches the version stability threshold. Under the premise that the authentication determination result of the access control policy determination function remains unchanged, the actual execution is replaced by the executable permission level operation. An audit log is written after each access request and permission change operation, and an audit verification value is calculated and bound to the storage for the audit log.

[0006] In a preferred embodiment, the enterprise identifier is determined and fixed when the enterprise archives are archived, and sensitive element features are extracted according to the rule base based on the textual results of the enterprise archive metadata and the enterprise archive text, and a sensitivity score is calculated in combination with a weight table. Then, the sensitivity score is compared with a threshold table to determine the archive confidentiality level, and the upper limit of the permission level is determined according to the permission level table.

[0007] In a preferred embodiment, the aforementioned enterprise identifier, file security level, and upper limit of permission level fields are written into the enterprise file access control record. At the same time, the user identity, affiliated enterprise identifier, role and attribute set are collected and solidified and written into the user access control record to form the basis of access control element record.

[0008] In a preferred embodiment, access control policies and their version numbers are generated and solidified based on enterprise file access control records, user access control records, and permission management and maintenance records. The access control policies are then converted into encrypted access structures to bind to decryptable conditions of the file data key. Simultaneously, the file data key is generated to encrypt the enterprise file text data to obtain enterprise file data ciphertext, and the file data key is also encrypted to obtain file data key ciphertext. In this way, user decryption keys are generated and issued to users.

[0009] In a preferred embodiment, upon receiving an access request for an enterprise file, the system obtains the user's identity, the target enterprise file identifier, and the permission level operation. It then reads the user's access control record and the enterprise file's access control record to obtain the enterprise identifier, role, attribute set, enterprise identifier, file security level, maximum permission level, access control policy, and policy version number fields. First, an access control policy judgment function is used to output "allow" or "deny" for each access request. If the version number in the permission management maintenance record is inconsistent with the policy version number, the request is rejected according to the version inconsistency rejection rule, and the inconsistency event is recorded. Upon rejection, the output of file content is terminated, and the decryption of the file data key ciphertext and the enterprise file data ciphertext is not performed. Upon allowing, the system verifies that the master key version number corresponding to the user's decryption key matches the master key version number indicated in the enterprise file access control record. Then, attribute-based decryption is performed on the file data key ciphertext to obtain the file data key, and symmetric decryption is performed on the enterprise file data ciphertext to obtain the enterprise file text data. Finally, according to the permission level operation, the system performs read-only display, editing, writing to the archive version, deletion, or export, and updates the status and version fields.

[0010] In a preferred embodiment, in order to address the repeated allow and deny actions caused by policy version number jumps within the processing cycle, and the amplification effect of decryption processing link triggering aggregation and denial-driven retry, a request sequence window is established under the same session identifier for the most recent access requests before or during the output or writing of enterprise file text data. The timestamp sequence, target enterprise file identifier sequence, file security level sequence, permission level operation sequence, authentication judgment result sequence and policy version number sequence are structurally aggregated to generate a process status record.

[0011] In a preferred embodiment, based on the process state record, the aggregation degree, version jump rate, retry amplification factor, security level coverage gradient, and operation jump intensity are calculated and derived according to deterministic rules to form a process state vector. Combining the role and file security level, the baseline vector and inverse covariance matrix are read from the process baseline parameter table to calculate the process deviation, and the smoothed deviation is obtained by recursion smoothing. The smoothed deviation is then compared with the control threshold table to generate an adjusted executable permission level operation. When the version jump rate reaches the version stability threshold, a version stability constraint is applied to deletion or export to forcibly reduce it to read-only during the period of policy version instability and to be released after continuous version consistency. Thus, without changing the access control policy judgment function, the authentication judgment result is still output with the original permission level operation, and the actual execution is replaced by the executable permission level operation. Controllable constraints are formed for highly sensitive permission level operations such as deletion or export within the same processing cycle. When the file security level field changes, a new policy version number and access control policy logical expression identifier are regenerated, the encrypted access structure is updated, and a new file data key ciphertext is regenerated and overwritten. The update timestamp and operator identifier are recorded to maintain the consistency of security level, policy, and encryption binding.

[0012] In a preferred embodiment, an access audit record is generated after each access request receives an authentication result, and a permission change audit record is generated after each permission change operation. Both types of audit records are written into the audit storage medium, and an audit verification value is calculated and bound to each audit record to support subsequent traceability verification.

[0013] In a preferred embodiment, it includes: an archive classification element acquisition module, a strategy generation and encryption binding module, an authentication dynamic adjustment module, an audit traceability verification module, and signal connections between the modules; The document classification element acquisition module is used to generate enterprise document identifiers when enterprise documents are archived, determine the enterprise identifier, document security level and access level upper limit, and establish enterprise document access control records and user access control records; The policy generation and encryption binding module is used to generate access control policies and policy version numbers based on enterprise file access control records, user access control records, and permission management and maintenance records, and to complete encryption binding and key distribution. The authentication dynamic adjustment module receives access requests and uses the access control policy determination function to output "allow" or "deny". It also establishes a request sequence window under the same session identifier to generate a process status record. Based on the process status record, it calculates and derives the clustering degree, version jump rate, retry amplification coefficient, security level coverage gradient, and operation jump intensity, and analyzes them to obtain the process deviation. It then recursively smooths the deviation to obtain the smooth deviation. When the access control policy determination function outputs "allow", it generates an executable permission level operation based on the smooth deviation and applies version stability constraints when the version jump rate reaches the version stability threshold. Under the premise that the authentication determination result of the access control policy determination function remains unchanged, the actual execution is replaced by the executable permission level operation. The audit traceability and verification module is used to write audit records after each access request and permission change operation, and to calculate and bind audit verification values ​​to the audit records for storage.

[0014] The technical effects and advantages of the hierarchical access control system and permission adjustment method for incubator enterprise files of this invention are as follows: This invention achieves a closed-loop system encompassing hierarchical judgment, policy generation, encryption binding, process constraints, and audit traceability: Security levels and access limits are determined by a versionable rule base, weights, or thresholds, ensuring traceability and reproducibility; access policies are uniformly determined based on enterprise affiliation, role authorization, attribute constraints, and operation levels, reducing ambiguity in manual configuration; keys are bound to policy equivalence structures, ensuring that decryption capability aligns with authorization status, reducing plaintext exposure; window process variables and smoothing deviations are introduced within the processing cycle to deterministically downgrade or reject exported aggregations, version jumps, and retry amplification, significantly suppressing the trigger density of high-risk operations; auditing employs chained summaries, enhancing tamper detection and accountability traceability. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of a hierarchical access control system and permission adjustment method for incubator enterprise files according to the present invention.

[0016] Figure 2 This is a sequence diagram of a hierarchical access control system for incubator enterprise files and a method for adjusting permissions, as described in this invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Example This invention discloses a method for adjusting hierarchical access permissions for incubator enterprise files, such as... Figure 2 As shown, it includes: Step 1: Enterprise file hierarchical labeling and access control element acquisition; First, for each enterprise file, an enterprise ownership determination process is performed: when an enterprise file enters the archiving process, the archiving source registration information of the file is read, the enterprise entity information is extracted, and the enterprise entity information is solidified as a unique enterprise identifier. The source of the enterprise identifier is limited to the enterprise master data established by the incubator for resident enterprises. The enterprise master data must contain at least one of the enterprise registration record and the enterprise's unified social credit code or the incubator's internal enterprise number. When multiple identifiers exist in the enterprise master data, one of them is selected as the enterprise identifier according to a preset priority rule, and the enterprise identifier is written into the metadata field of the enterprise file.

[0019] Subsequently, the process of extracting archival content elements is performed to generate input data for sensitive element features. For structured electronic archives, metadata such as archive title, archive category, department that created it, creation time, and classified information fields are read from the original fields. For unstructured electronic archives or scanned documents, the main text of the archive is first processed to obtain the main text: when the archive is natively selectable text, the main text is extracted directly; when the archive is an image or scanned document, image text recognition is used to obtain the main text. After completing the text processing, sensitive element recognition is performed based on the archive metadata and the main text, and a set of sensitive element feature values ​​is output. The generation method for the sensitive element feature values ​​is limited to deterministic rule extraction, and each feature value can be traced back to its corresponding input source: for example, if a word in the preset sensitive word dictionary is matched in the text, the corresponding feature value is set to 1 according to the rule; if a frequency-based feature is used, the corresponding feature value is normalized according to the number of matches or the length of the text; if the category field in the file metadata is determined by the mapping table to be a sensitive category such as finance, intellectual property, contract, or personnel, the corresponding feature value is written according to the value output by the mapping table. The sensitive word dictionary, mapping table, and rule set are all derived from the incubator file management specifications or the rule base configured by the administrator in the permission management and maintenance interface, and are fixed in the form of version numbers. The rule base corresponding to the version number is used as the standard when extracting features.

[0020] After obtaining the feature values ​​of sensitive elements, the sensitivity score is calculated using a weighted scoring algorithm. The formula is as follows: ; Where n is the number of sensitive feature characteristics; The feature value of the i-th sensitive element is derived from the rule extraction results based on the aforementioned archive metadata or text. The weight coefficient corresponds to the i-th sensitive feature. The source of this weight coefficient is limited to the incubator file management specifications or a weight table configured by the administrator, and is fixed with a version number. When calculating the sensitivity score, the version number of the weight table and the version number of the feature extraction rule base are recorded, and the version number and sensitivity score are written together into the access control record of the enterprise file.

[0021] Subsequently, the file classification mapping process is performed: the sensitivity score S is compared with a set of threshold parameters, and a unique file classification is output. The set of threshold parameters must contain at least... and Its source is limited to incubator file management specifications or threshold tables configured by administrators, and is fixed by version number. The mapping rule is: when At that time, the archive's classification level was determined to be public; when At that time, the file classification was determined to be internal; when At that time, the file classification is determined to be confidential. The determined file classification is written into the metadata field of the enterprise file and simultaneously written into the access control record of the enterprise file.

[0022] After determining the file's security classification, the action of generating the upper limit of the access level is performed: A set of access levels is predefined, which includes at least one or a combination of read-only, edit, delete, or export, and a correspondence table between file security classifications and upper limit access levels is defined. The source of this correspondence table is limited to the incubator file management specifications or an access level table configured by the administrator, and it is fixed with a version number. Based on this correspondence table, for each enterprise file, the upper limit of the access level for that enterprise file is determined according to its security classification, and fields such as enterprise identifier, file security classification, upper limit of access level, file category, creation time, rule base version number, weight table version number, and threshold table version number are written into the access control record of that enterprise file.

[0023] Simultaneously, this step performs user access element collection and binding actions on the user side: for each user identity, its user identity, affiliated enterprise identifier, role, and attribute set are collected and solidified. The source of the user identity is limited to the incubator's unified identity authentication account; the source of the affiliated enterprise identifier is limited to the personnel affiliation registration record of the incubator's resident enterprises or the enterprise's organizational structure registration information; the source of the role is limited to the permission management and maintenance record; the source of the attribute set is limited to deterministic fields such as job position, project, scope of responsibility, and incubation status generated by business registration or organizational information. The aforementioned user identity, enterprise identifier, role, and attribute set are written into the user access control record in the form of a record, and a version number or update timestamp is generated for the record to reflect the latest valid status of the record.

[0024] Step 2: Generate and encrypt hierarchical access control policies; For each enterprise file, the enterprise identifier, file security level, and upper limit of permission level fields are read from the corresponding enterprise file access control record. The values ​​of the enterprise identifier, file security level, and upper limit of permission level are limited to the enterprise file access control record written in step one. Simultaneously, the roles, permission level authorization relationship table, and attribute constraint rule table in the permission management and maintenance record are read. The roles and permission level authorization relationship table are limited to the authorization table formed by the incubator file management specification or administrator configuration and fixed with a version number. Its fields include at least role name, file security level, permission level operation, and authorization flag. The attribute constraint rule table is limited to the rule base formed by the incubator file management specification or administrator configuration and fixed with a version number. Its fields are used to specify the attribute set matching conditions that must be met under a specific file security level or specific file category. Simultaneously, the user identity, affiliated enterprise identifier, role, and attribute set fields in the user access control record related to the user are read. The values ​​of the user identity and affiliated enterprise identifier are limited to the user access control record written in step one. The values ​​of the role and attribute set are limited to the user access control record written in step one and its corresponding permission management and maintenance record and organization registration information. Based on the input fields, an access control policy is generated. The access control policy is expressed using a deterministic decision function, and the logical expression of this decision function, along with the referenced version number field, is written into the enterprise file access control record. The decision function of the access control policy is defined as follows: Wherein, U represents the record object of a certain user identity in the user access control record; A represents the record object of a certain enterprise file in the enterprise file access control record; This indicates the permission level operation the user intends to perform, and its value is limited to the set of permission levels predefined and fixed in step one. Each sub-function in the decision function outputs a Boolean value according to deterministic rules, and the sources of its input fields are all explicitly limited as follows: This indicates the determination of enterprise affiliation, which is defined as follows: ,in Retrieved from the Enterprise Identifier field of the User Access Control record. The enterprise identifier field is taken from the enterprise file access control record. Square brackets indicate that if they are equal, the value is 1, and if they are not equal, the value is 0. This indicates the upper limit constraint determination of the permission level, which is defined as follows: ,in Indicates permission level operation The hierarchical order value is determined solely from the permission level definition table. The value is taken from the upper limit of the permission level field in the enterprise file access control record; This indicates the role authorization determination, which is defined as follows: ,in Taken from the role field of the user access control record. The file security classification field is taken from the enterprise file access control record. This function represents a query function for the authorization relationship table of roles and permission levels. It outputs 1 if the corresponding combination exists in the table and the authorization flag is allowed, otherwise it outputs 0. The property constraint satisfaction determination is defined as follows: ,in The attribute set fields are taken from the user access control record. Taken from the file category field in the enterprise file metadata. This function represents the matching judgment function for the attribute constraint rule table: when the attribute constraint rule table defines constraints for a given file security level and file category, it matches the attribute set according to the rules and outputs 1 or 0; when the combination does not define constraints, it outputs 1 according to the rule of no additional constraints.

[0025] When writing an access control policy into the enterprise file access control record, the policy version number field is written simultaneously. The generation method of the policy version number is limited to a deterministic combination method, which combines the version number of the permission level definition table, the role, the version number of the permission level authorization relationship table, the version number of the attribute constraint rule table, and the version number of the threshold table in a preset order to generate a version string or summary value, which is used as the policy version number of the access control policy and written into the enterprise file access control record.

[0026] Furthermore, the access control policy is converted into an encrypted access structure, which is a logically equivalent structure of the access control policy. It uses enterprise identification conditions, role conditions, file confidentiality conditions, permission level conditions, and attribute set conditions consistent with the access control policy. The permission level conditions are expressed as the permission level operation conditions that must be met to decrypt and obtain the file data key. The source of its value is limited to the permission level definition table and the role and permission level authorization relationship table, without introducing new permission level values.

[0027] For each corporate document, a symmetric key is generated for symmetric encryption, defined as the document data key. The archival data key is generated using a cryptographically secure random number generation algorithm, and the key identifier and generation timestamp are recorded. The archival data key is used to perform symmetric encryption on the enterprise archival text data D, generating the enterprise archival data ciphertext. It is represented as: ; in This represents a symmetric encryption algorithm. The value of D is limited to the archived enterprise file data itself, and external data is not allowed to be concatenated.

[0028] The attribute-based encryption algorithm is used to encrypt the archive data key, generating the archive data key ciphertext. It is represented as: ; in This represents the encryption function of the attribute-based encryption algorithm. This indicates an encrypted access structure, and the attribute fields referenced in the encrypted access structure must come from the attribute set fields in the user access control record and be constrained by the field names and value ranges fixed in step one.

[0029] Next, a corresponding user decryption key is generated based on the attribute set of each user's identity. Its generation process is represented as follows: ; in This represents the key generation function for the attribute-based encryption algorithm. MK represents the master key, which is generated by a cryptographically secure key generation algorithm and managed using a master key version number. This represents a set of attribute fields in the user access control record. It involves the secure issuance and recording of the user's decryption key. The record includes at least the user's identity, master key version number, user decryption key version number, and issuance timestamp. The values ​​for these fields are limited to user access control records and key management records, respectively.

[0030] Finally, encrypt the enterprise file data. Archive data key ciphertext Encrypted access structure The structured description or its reference identifier, the access control policy logical expression identifier, and the policy version number are written into the enterprise file access control record, and the accessible form of the enterprise file text data in the storage medium is replaced with the enterprise file data ciphertext.

[0031] Step 3: Access request authentication and dynamic permission adjustment; When receiving an access request for a specific enterprise file, the system retrieves the user identity, target enterprise file identifier, and the user's intended permission level operation from the access request. The user identity is limited to the account identifier generated by the incubator's unified identity authentication; the target enterprise file identifier is limited to the enterprise file's archive identifier or the file identifier field in the access control record; and the permission level operation value is limited to the permission level set fixed in step one. After obtaining the above input, the system reads the user access control record corresponding to the user identity to obtain the user's enterprise identifier, role, and attribute set. Simultaneously, it reads the enterprise file access control record corresponding to the target enterprise file to obtain the enterprise identifier, file security level, maximum permission level, access control policy, policy version number, encrypted enterprise file data, and encrypted file data key.

[0032] The access request is subjected to authentication calculation, which uses the access control policy determination function solidified in step two. It outputs an allow or deny result in a deterministic manner; where U is the user access control record object and A is the enterprise file access control record object. The permission level operation carried by the access request. Execute. When the system is in operation, it sequentially reads the enterprise identifier field, role field, and attribute set field from the user access control record, and the enterprise identifier field, file security level field, permission level upper limit field, and file category field from the enterprise file access control record. Based on the permission level definition table, role, permission level authorization relationship table, and attribute constraint rule table, it outputs a sub-judgment result. The value sources of the permission level definition table, role, permission level authorization relationship table, and attribute constraint rule table are limited to permission management and maintenance records and are fixed with version numbers. Furthermore, their version numbers must be consistent with the version number referenced by the policy version number fixed in the enterprise file access control record. When it is found that the version number of the permission management and maintenance record read by the access request is inconsistent with the policy version number fixed in the enterprise file access control record, a rejection result is output according to the version inconsistency rejection rule, and the inconsistency event is recorded.

[0033] When the authentication calculation outputs a rejection result, the output of the file content for the access request is terminated, and no decryption operation is performed on the enterprise file data ciphertext and the file data key ciphertext; when the authentication calculation outputs an allow result, the user decryption key corresponding to the user identity is read. The source of the user decryption key is limited to the key record generated and issued in step two based on the attribute set in the user access control record, and the master key version number of the user decryption key is verified to be consistent with the master key version number indicated by the enterprise file access control record; under the condition that the version numbers are consistent, the file data key is encrypted. Perform attribute-based decryption operations to obtain the archive data key. It is represented as: ; in This represents the decryption function for the attribute-based encryption algorithm. Decrypt the key for the user. The archive data is encrypted using the archive data key; subsequently, the enterprise archive data is encrypted using the archive data key. Performing a symmetric decryption operation yields the enterprise file data D, which is represented as follows: ; in This represents the decryption function corresponding to the symmetric encryption algorithm. The enterprise archive data is encrypted. Access control constraints are applied to the decrypted enterprise archive data D: when the access control is read-only, the displayed result of the enterprise archive data is output and writing is prohibited; when the access control is edit, content changes to the enterprise archive data are allowed, and the changes are written as new data to the archived version; when the access control is delete or export, the corresponding delete or export action is allowed, and the status and version fields in the enterprise archive access control record are updated after the delete or export action is completed.

[0034] It should be noted that the access control policy determination function Once a single access request is granted, the request can proceed to the decryption of the encrypted archive data key, decrypt the encrypted enterprise archive data, and execute the permission-level operation. However, in the daily processing of incubator enterprise archives, permission management and maintenance records may be updated within the processing cycle, causing the policy version number corresponding to the same enterprise archive to jump within a short period of time. In actual processing, the following process often occurs: the same user identity alternately performs read-only and delete or export permission-level operations on a group of enterprise archives of the same enterprise within the same processing cycle, and the archive security level of this group of enterprise archives gradually changes from low to high; at the same time, the policy version number changes during the processing, so that two adjacent access requests from the same user identity to the same enterprise archive may cross the version switch point, resulting in a repeated state where the previous request is allowed and considered for export, the next request is rejected due to version inconsistency, and then the request is allowed again after version synchronization. Since each permission may trigger a complete decryption chain, and each denial may be driven by the business process to become a retry request, the above states will form a process characterized by the aggregation of export permission level operation triggers, the increase in request retry density, the upward shift of file security level coverage, and the intertwining of operation sequence jumps within the processing cycle. When the static fields remain unchanged and each request can be satisfied or rejected separately, it is difficult to constrain the aggregation of export triggers and the amplification effect of retry within this processing cycle by relying solely on the judgment of the granularity of a single request and the version inconsistency rejection rule.

[0035] Therefore, in this embodiment, before or during the output or writing of enterprise file text data, a request sequence window is established for access requests associated with the user identity within the same processing cycle, and a process status record is generated. The request sequence window refers to the set of the most recent L access requests obtained by tracing back from the current access request under the same session identifier, where L is the window length parameter, and its value is limited to the window length parameter table in the permission management and maintenance record and fixed with a version number. The process status record refers to the record object obtained by structurally aggregating the calculable fields of each access request within the request sequence window. The process status record includes at least a timestamp sequence, a target enterprise file identifier sequence, a file security level sequence, a permission level operation sequence, an authentication determination result sequence, and a policy version number sequence. The timestamp sequence is limited to the server time; the target enterprise file identifier sequence is limited to the file identifier field in the enterprise file access control record; the file security level sequence is limited to the snapshot value of the file security level field in the enterprise file access control record; the permission level operation sequence is limited to the access request carrying the value and its value domain is constrained by the permission level set in step one; and the authentication determination result sequence is limited to the value of the access request carried in step three. The calculation output of the policy version number sequence is limited to the snapshot value of the policy version number field fixed in the enterprise file access control record; the source of the session identifier is limited to the session association identifier generated by unified identity authentication or the session identifier field carried in the access request and verified.

[0036] Based on the process status record, several process quantities associated with the request sequence window are calculated and written into the process status record. The values ​​of the process quantities are all calculated from the fields in the process status record according to deterministic rules, without introducing any external unknown data. The permission level set in step one is mapped to a level ordinal value function. This allows read-only, edit, delete, or export functions to correspond to preset security classification values; it also maps the archive security classification set from step one to a security classification classification function. This ensures that public, internal, and confidential correspond to preset security classification values; the values ​​for the above mapping relationship are limited to the permission level definition table and the file security classification definition table in the permission management and maintenance records, and are fixed with version numbers.

[0037] Within the request sequence window, the derived clustering degree G is calculated based on the permission level of the operation sequence. The calculation formula is as follows: ; in, The permission level operation for the k-th access request within the window is derived from the permission level operation sequence; This is an indicator function; it takes the value 1 if the condition is true, and 0 otherwise. The timestamp of the k-th access request within the window is derived from a timestamp sequence. τ is the timestamp of the current access request at the end of the window; τ is the decay time constant parameter, whose value is limited to the decay parameter table in the permission management maintenance record and fixed with a version number. Exponential decay ensures that deletion or export operations closer to the current time within the window contribute more to G.

[0038] Within the request sequence window, the version jump rate V is calculated using the policy version number sequence. The calculation formula is as follows: ; in, The policy version number is the snapshot of the enterprise file access control record corresponding to the k-th access request within the window, derived from the policy version number sequence. The version jump rate is used to reflect the frequency of adjacent access requests crossing different policy version numbers.

[0039] Within the request sequence window, the retry amplification factor A is calculated using the authentication result sequence and the target enterprise file identifier sequence. The calculation rule is as follows: Select all access requests with an authentication rejection result within the window. If another access request meets the following criteria: same user identity, same target enterprise file identifier, same permission level operation, and timestamp difference not exceeding the retry interval threshold Δ, then it is counted as one retry. The number of retries within the window is recorded as follows: and order The value of Δ is limited to the retry interval threshold table in the access control maintenance records and is fixed with a version number. The retry amplification factor is determined by the density of repeated requests for the same access after a rejection.

[0040] Within the request sequence window, the security classification coverage gradient S is calculated using the archive security classification sequence. The calculation formula is as follows: ; in, The security classification of the target enterprise file for the k-th access request within the window is derived from the file security classification sequence. The security classification coverage gradient is used to reflect the coverage span of the accessed object in terms of file security classification within the window.

[0041] Within the request sequence window, the operation transition strength J is calculated based on the permission level operation sequence. The calculation formula is as follows: ; in and These represent the permission level operations for two consecutive access requests.

[0042] Then, the above process variables are constructed into a process state vector. Based on the role and attribute set fields in the user access control record, and combined with the file security level field of the target enterprise file of the current access request, the reference vector corresponding to the role and file security level is read from the permission management and maintenance record. The inverse covariance matrix M is used; the source of the baseline vector μ and the inverse covariance matrix M is limited to the process baseline parameter table in the access control maintenance record and fixed with version number, and the process baseline parameter table is indexed by role and file security level key value. The process deviation D is calculated based on Z, μ and M, and the formula is: ; Where M is a positive definite matrix, used to constrain the scale and correlation of different process quantities. Its value comes directly from the process baseline parameter table and is not generated by fitting in this step. The process deviation D is written into the process status record, and the version number of the referenced process baseline parameter table is also recorded.

[0043] The process deviation D is recursively smoothed to obtain the smoothed deviation. Its recursive formula is: ; Where n represents the window number ending with the current access request, and β is the smoothing coefficient parameter, whose value is limited to the smoothing parameter table in the permission management maintenance records and is fixed with a version number. The value can be derived from the process status record that has been written in the previous window under the same session identifier.

[0044] Furthermore, after completing the calculation and writing of the aggregation degree G, version jump rate V, retry amplification factor A, density level coverage gradient S, operation jump intensity J, and smoothing deviation into the process status record, the trust score T in the access audit record is calculated and a trust threshold comparison interval is generated; the trust score T is used to characterize the overall credibility of this access request within the same processing cycle.

[0045] The trust score T is calculated using a weighted summation method, and the formula is as follows: ; Where m is the number of trust indicators. Let j be the weight coefficient corresponding to the j-th trust index. Let j be the input variable corresponding to the j-th trust indicator; The values ​​for both 'm' and 'm' are limited to the trust score parameter table in the permission management and maintenance records, and are fixed with version numbers, and satisfy the following conditions: And for any j, we have ∈[0,1]; the range of the trust score T is limited to [0,1].

[0046] The input variables All are obtained by mapping the process quantities in the sub-decision output or process status record obtained in step three according to deterministic rules, without introducing external unknown data; in this embodiment, m=6 is taken, and... ~ The determination sources and calculation rules are respectively limited to the following: (1) To derive the clustering confidence index, its value is limited to the derived clustering degree G in the process status record, and obtained according to the upper limit normalization and inversion rule: ;in The value is limited to the trust score parameter table in the permission management and maintenance records and is fixed with a version number; (2) This is a version jump reliability metric, whose value is limited to the version jump rate V in the process status record, and obtained by inverting the upper limit normalization rule: ;in The value is limited to the trust score parameter table in the permission management and maintenance records and is fixed with a version number; (3) The retry amplification reliability index is derived from the retry amplification coefficient A in the process status record, and is obtained by inverting the upper limit normalization rule. ;in The value is limited to the trust score parameter table in the permission management and maintenance records and is fixed with a version number; (4) The density level coverage reliability index is derived from the density level coverage gradient S in the process status record, and is obtained by inverting the upper bound normalization rule: ;in The value is limited to the trust score parameter table in the permission management and maintenance records and is fixed with a version number; (5) The reliability index for operation jumps is determined by the operation jump strength J in the process state record, and is obtained by inverting the upper limit normalization rule. ;in The value is limited to the trust score parameter table in the permission management and maintenance records and is fixed with a version number; (6) This is a process deviation reliability index, whose value is limited to the smoothed deviation in the process status records and obtained by inverting the upper limit normalization rule: ;in The value is limited to the trust score parameter table in the permission management and maintenance records and is fixed with a version number.

[0047] When the authentication calculation in step three outputs a rejection result, in order to avoid writing a non-zero trust score for unauthorized access requests, T is directly set to 0; when the authentication calculation in step three outputs an allow result, T is calculated according to the above formula, and T is written into the process status record for direct collection when generating access audit records later.

[0048] The trust threshold comparison interval is generated according to a deterministic rule that compares T with a set of trust threshold parameters; the set of trust threshold parameters contains at least... and The value source is limited to the trust threshold parameter table in the permission management and maintenance records and is fixed with a version number, and satisfies 0 ≤ ≤ ≤1; The trust threshold comparison range is limited to three value ranges: low, medium, and high, and determined according to the following rules: when T < The time interval is denoted as low; when ≤T< The time interval is denoted as the middle; when T≥ The time interval is marked as high; the trust threshold comparison interval and the version number of the referenced trust threshold parameter table are written into the process status record.

[0049] Based on smoothness deviation The access request's permission level is adjusted by comparing it with a set of control thresholds; the set of control thresholds includes at least... The value source is limited to the control threshold table in the permission management and maintenance records, and is fixed with a version number. The control threshold table is indexed by role and file security level. The permission level operation carried in the access request is recorded as... The adjusted executable permission level operation is recorded as And generate according to the following deterministic rules :when season ;when At that time, if =Delete or export, then let Read-only, otherwise make ;when season Read-only; when season If the operation is null, output "Reject". The execution result of the above rules is written to the process status record, and the written fields must include at least the following: The numerical value, control threshold table version number and The value of .

[0050] When the strategy version number sequence changes within the request sequence window and the version change rate V is greater than or equal to the version stability threshold. At that time, version stability constraints are applied to deletion or export permission level operations; where the version stability threshold is... The value is limited to the version stability threshold table in the permission management and maintenance records and is fixed with a version number. The execution rule for version stability constraints is as follows: Under the same session ID, if the policy version number in the enterprise file access control record of the target enterprise file of the current access request is inconsistent with the policy version number fixed in the previous allowed access record under the same session ID, then a mandatory restriction will be imposed in this access request. Read-only; when the policy version number in the access permission record is consistent for C consecutive times, the mandatory read-only constraint on the delete or export permission level operation is lifted; where C is the version consistency count parameter, the value of which is limited to the consistency count parameter table in the permission management maintenance record and is fixed with the version number.

[0051] Operations at the adjusted executable permission level After that, use Replace the permission level operation carried in the access request The actual execution of this access request is involved when: When an operation is empty, the output or writing of the enterprise file text data is terminated; when In read-only mode, only the display results of the enterprise file's main text data are output, and writing, deleting, or exporting are prohibited; when To allow editing of the main text data of enterprise archives and write the changes to the archived version; when Deleting or exporting allows the corresponding deletion or export action to be executed. The replacement and execution process described above remains unchanged. The calculation method The operation will still be performed using the original permission level carried in the access request. Output the authentication result, while the actual execution phase uses... As an executable permission level operation, it creates controllable constraints on the triggering of highly sensitive permission level operations within the same processing cycle.

[0052] Simultaneously, when the file classification field in the enterprise file access control record changes, the execution policy is adjusted synchronously: the changed file classification field is read along with the version numbers of various tables referenced by the original policy version number of the enterprise file, and a new policy version number is generated by re-generating the policy version number according to the deterministic combination method in step two. The new access control policy logical expression identifier and the new policy version number are written into the enterprise file access control record. At the same time, the access control policy is equivalently transformed to obtain a new encrypted access structure, and the file data key is re-encrypted using attribute base encryption to generate a new file data key ciphertext. The new file data key ciphertext is written into the enterprise file access control record, overwriting the original file data key ciphertext, and the update timestamp and operator identifier corresponding to this overwriting action are recorded. The source of the operator identifier is limited to the user identity that triggered the file classification change or the automatic rule execution identifier.

[0053] Step 4: Auditing and tracing verification of access and permission changes; For each access request to the enterprise file, after completing the authentication calculation in step three and obtaining an allow or deny result, an access audit record is generated and written; for each permission change operation that affects the user access control record or the enterprise file access control record, a permission change audit record is generated and written; the access audit record and the permission change audit record are uniformly written to the audit storage medium, and the audit record is subjected to anti-tampering verification to generate an audit verification value. The audit verification value is bound to the identifier of its corresponding audit record for storage to support subsequent traceability verification.

[0054] When generating access audit records, fields are directly collected and written from the access request and the processing in step three. These fields include at least the access audit record identifier, access timestamp, user identity, target enterprise file identifier, permission level operation, authentication result, the version number of the strategy used for authentication, enterprise identifier matching result, permission level upper limit constraint result, role authorization result, attribute constraint satisfaction result, trust score T, trust threshold comparison range, dynamic adjustment action result, and access terminal identifier, access network address, access geographic region identifier, and access behavior characteristics. The access timestamp is limited to server time; the user identity is limited to the account identifier carried in the access request and verified by unified identity authentication; the target enterprise file identifier is limited to the file identifier field in the enterprise file access control record; the permission level operation is limited to what is carried in the access request and its value range is constrained by the permission level set in step one; and the authentication result is limited to the data collected in step three. The calculation output, the policy version number source is limited to the policy version number field fixed in the enterprise file access control record, and the enterprise identifier matching result, the permission level upper limit constraint result, the role authorization judgment result and the attribute constraint satisfy the judgment result source is limited to step three in execution. , , , The sub-decision output obtained at that time, the source of the trust score T is limited to step three according to the formula The calculation output, the source of the trust threshold comparison interval is limited to step three, which compares T with the trust threshold parameter set. The results obtained from the comparison are as follows: the source of the dynamic adjustment action result is limited to the execution result of the downgrade, restriction or maintenance action in step three; the source of the access terminal identifier is limited to the device identifier or session identifier reported by the terminal device; the source of the access network address is limited to the network connection parameters; the source of the access geographical area identifier is limited to the network address resolution or terminal reporting; and the source of the access behavior characteristics is limited to the operation sequence and operation frequency statistics results within this session.

[0055] Furthermore, when generating permission change audit records, fields are directly collected and written from the execution context of the permission change operation. These fields include at least the permission change audit record identifier, change timestamp, operator identifier, change object type, change object identifier, pre-change record snapshot, post-change record snapshot, change reason identifier, change trigger method identifier, and post-change version number. The change timestamp is limited to server time; the operator identifier is limited to the user identity or automatic rule execution identifier that triggered the change; the change object type is limited to either user access control records or enterprise file access control records; the change object identifier is limited to the unique identifier field of the corresponding record; and the pre-change record snapshot and... The sources of the post-change record snapshots are limited to the original record content read before the permission change operation is submitted and the new record content after the write is completed. The source of the change reason identifier is limited to the change reason enumeration in the permission management and maintenance record or the reason field in the workflow approval record. The source of the change trigger method identifier is limited to two value fields: manual maintenance trigger or rule trigger. The source of the post-change version number field is limited to the version number or update timestamp field that is synchronously written when the permission change operation is written to the record. When the permission change involves the policy version number update or the master key version number rotation, the policy version number and the master key version number are written together into the permission change audit record, and their value sources are limited to the enterprise file access control record and the key management record, respectively.

[0056] After writing access audit logs and permission change audit logs to the audit storage medium, an audit checksum is calculated for each audit log, and the checksum is then bound to and stored with that audit log. The audit checksum is calculated using a chained digest algorithm, specifically: for the k-th audit log, the normalized serialization result of its audit log content is recorded as... Take the audit verification value of the previous audit record and record it as . Calculate the audit verification value for this audit record. Its formula is: ; in, Represents a cryptographically secure hash function. This represents the concatenation operator. The value source is limited to the byte sequence obtained by serializing the audit record fields according to the preset field order and preset encoding rules. The value of is limited to the audit verification value of the previous audit record already bound and stored in the audit storage medium; when k=1, The value source is limited to a preset initial constant or a preset initial digest value, and is fixed in the audit storage medium. This value is synchronously written when each audit record is written. and will It is stored in conjunction with the audit record identifier, so that any change in the content or order of any audit record will cause the chain digest validation to fail.

[0057] When audit records need to be traced and verified, the audit record content and its associated audit verification value within the verification range are read in the order they are stored in the audit storage medium, and the verification value is recalculated for each audit record. And according to the formula The recalculated audit verification value is obtained recursively and compared with the audit verification value bound to the audit storage medium. If any comparison is inconsistent, the verification result indicating that the audit record has been tampered with or the order of the audit records has been changed is output, and the identifier of the first inconsistent audit record is located. If all comparisons are consistent, the verification result indicating that the audit record has not been tampered with is output. The audit record content and bound audit verification value used in the traceability verification process are limited to the stored values ​​in the audit storage medium, and no external data is introduced.

[0058] When retrieving and aggregating access audit records, the system uses a combination of fields from the access audit records: user identity, target enterprise file identifier, enterprise identifier, file security level, permission level operation, authentication result, policy version number, and dynamic adjustment action result. The filtered results output the access timestamp, user identity, target enterprise file identifier, permission level operation, authentication result, trust score T, and dynamic adjustment action result for each access audit record. The file security level field value is limited to a snapshot value read from the enterprise file access control record at the time the access audit record is written. When retrieving and aggregating permission change audit records, the system uses a combination of fields from the operator identifier, changed object type, changed object identifier, change trigger method identifier, change timestamp, and version number. The system outputs corresponding snapshots of the record before and after the change to support the traceability of the entire permission change process.

[0059] This invention also proposes a hierarchical access control system for incubator enterprise files, such as... Figure 1 As shown, it includes: a file classification element acquisition module, a policy generation and encryption binding module, an authentication dynamic adjustment module, an audit traceability verification module, and signal connections between the modules; The document classification element acquisition module is used to generate enterprise document identifiers when enterprise documents are archived, determine the enterprise identifier, document security level and access level upper limit, and establish enterprise document access control records and user access control records; The policy generation and encryption binding module is used to generate access control policies and policy version numbers based on enterprise file access control records, user access control records, and permission management and maintenance records, and to complete encryption binding and key distribution. The authentication dynamic adjustment module receives access requests and uses the access control policy determination function to output "allow" or "deny". It also establishes a request sequence window under the same session identifier to generate a process status record. Based on the process status record, it calculates and derives the clustering degree, version jump rate, retry amplification coefficient, security level coverage gradient, and operation jump intensity, and analyzes them to obtain the process deviation. It then recursively smooths the deviation to obtain the smooth deviation. When the access control policy determination function outputs "allow", it generates an executable permission level operation based on the smooth deviation and applies version stability constraints when the version jump rate reaches the version stability threshold. Under the premise that the authentication determination result of the access control policy determination function remains unchanged, the actual execution is replaced by the executable permission level operation. The audit traceability and verification module is used to write audit records after each access request and permission change operation, and to calculate and bind audit verification values ​​to the audit records for storage.

[0060] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0061] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0062] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0063] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0064] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0065] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for adjusting hierarchical access permissions for incubator enterprise files, characterized in that, include: When archiving enterprise files, generate an enterprise file identifier, determine the enterprise identifier, file security level and access level limits, and establish enterprise file access control records and user access control records; Based on enterprise file access control records, user access control records, and permission management and maintenance records, an access control policy and policy version number are generated, and encryption binding and key distribution are completed. Upon receiving an access request, the access control policy determines whether to allow or deny the request, and a request sequence window is created under the same session identifier to generate a process status record. Based on the process state record, the aggregation degree, version jump rate, retry amplification factor, security level coverage gradient and operation jump intensity are calculated and derived, and the process deviation degree is obtained by analysis. The smooth deviation degree is obtained by recursion smoothing. When the access control policy determination function output allows, an executable permission level operation is generated according to the smooth deviation degree. When the version jump rate reaches the version stability threshold, version stability constraint is applied. Under the premise that the authentication determination result of the access control policy determination function remains unchanged, the actual execution is replaced by the executable permission level operation. An audit log is written after each access request and permission change operation, and an audit verification value is calculated and bound to the storage for the audit log.

2. The method for adjusting hierarchical access permissions for incubator enterprise files according to claim 1, characterized in that: When archiving corporate files, the corporate identifier is identified and solidified. Based on the textual results of the corporate file metadata and the corporate file text, sensitive element features are extracted according to the rule base and the sensitivity score is calculated in combination with the weight table. Then, the sensitivity score is compared with the threshold table to determine the file confidentiality level and the upper limit of the permission level is determined according to the permission level table.

3. The method for adjusting hierarchical access permissions for incubator enterprise files according to claim 2, characterized in that: The enterprise identifier, file security level, and maximum access level fields mentioned above are written into the enterprise file access control record. At the same time, the user identity, the enterprise identifier, the role and attribute set are collected and solidified and written into the user access control record to form the basis of the access control element record.

4. The method for adjusting hierarchical access permissions for incubator enterprise files according to claim 3, characterized in that: By generating and solidifying access control policies and their version numbers based on enterprise file access control records, user access control records, and permission management and maintenance records, the access control policies are converted into encrypted access structures to be bound to decryptable conditions of the file data key. At the same time, the file data key is generated to encrypt the enterprise file text data to obtain enterprise file data ciphertext, and the file data key is encrypted to obtain file data key ciphertext, thereby generating and issuing user decryption keys.

5. The method for adjusting hierarchical access permissions for incubator enterprise files according to claim 4, characterized in that: Upon receiving an access request for an enterprise file, the system obtains the user's identity, the target enterprise file identifier, and the permission level. It then reads the user's access control record and the enterprise file's access control record to obtain the enterprise identifier, role, attribute set, enterprise identifier, file security level, maximum permission level, access control policy, and policy version number. The system first uses an access control policy judgment function to output "allow" or "deny" for each access request. If the version number in the permission management maintenance record is inconsistent with the policy version number, the system rejects the request according to the version inconsistency rule and records the inconsistency event. Upon rejection, the system terminates the output of file content and does not decrypt the encrypted file data key or the encrypted enterprise file data. Upon allowing access, the system verifies that the master key version number corresponding to the user's decryption key matches the master key version number indicated in the enterprise file access control record. It then performs attribute-based decryption on the encrypted file data key to obtain the file data key and performs symmetric decryption on the encrypted enterprise file data to obtain the enterprise file text data. Finally, it performs read-only display, editing, writing to the archive version, deletion, or export operations according to the permission level and updates the status and version fields.

6. The method for adjusting hierarchical access permissions for incubator enterprise files according to claim 5, characterized in that: Meanwhile, in response to the repeated allow and deny caused by policy version number jumps within the processing cycle, and the amplification effect of decryption processing link triggering aggregation and denial-driven retry, a request sequence window is established under the same session identifier for the most recent access requests before or during the output or writing of enterprise file text data. The timestamp sequence, target enterprise file identifier sequence, file security level sequence, permission level operation sequence, authentication judgment result sequence and policy version number sequence are structured and aggregated to generate process status records.

7. The method for adjusting hierarchical access permissions for incubator enterprise files according to claim 6, characterized in that: Based on the process state records, the aggregation degree, version jump rate, retry amplification factor, security level coverage gradient, and operation jump intensity are calculated and derived according to deterministic rules to form a process state vector. Combining the role and file security level, the baseline vector and inverse covariance matrix are read from the process baseline parameter table to calculate the process deviation, and the smoothed deviation is obtained by recursion smoothing. The smoothed deviation is then compared with the control threshold table to generate the adjusted executable permission level operation. When the version jump rate reaches the version stability threshold, the deletion or export is subject to version stability constraint to force it to read-only during the period of policy version instability and to be released after the continuous version is consistent. Thus, without changing the access control policy judgment function, the authentication judgment result is still output with the original permission level operation, and the actual execution is replaced with executable permission level operation. Controllable constraints are formed for highly sensitive permission level operations such as deletion or export within the same processing cycle. When the file security level field changes, a new policy version number and access control policy logical expression identifier are regenerated, the encrypted access structure is updated, and a new file data key ciphertext is regenerated and overwritten. The update timestamp and operator identifier are recorded to maintain the consistency of security level, policy, and encryption binding.

8. The method for adjusting hierarchical access permissions for incubator enterprise files according to claim 7, characterized in that: After each access request receives an authentication result, an access audit record is generated, and after each permission change operation, a permission change audit record is generated. Both types of audit records are written to the audit storage medium, and an audit verification value is calculated and bound to the storage for each audit record to support subsequent traceability verification.

9. A hierarchical access control system for incubator enterprise files, used to implement the hierarchical access permission adjustment method for incubator enterprise files as described in any one of claims 1-8, characterized in that, include: The module includes: document classification element acquisition module, strategy generation and encryption binding module, authentication dynamic adjustment module, audit traceability and verification module, and signal connection between modules. The document classification element acquisition module is used to generate enterprise document identifiers when enterprise documents are archived, determine the enterprise identifier, document security level and access level upper limit, and establish enterprise document access control records and user access control records; The policy generation and encryption binding module is used to generate access control policies and policy version numbers based on enterprise file access control records, user access control records, and permission management and maintenance records, and to complete encryption binding and key distribution. The authentication dynamic adjustment module is used to receive access requests and use access control policies to determine whether to allow or deny the request, and to create a request sequence window under the same session identifier to generate a process status record. Based on the process state record, the aggregation degree, version jump rate, retry amplification factor, security level coverage gradient and operation jump intensity are calculated and derived, and the process deviation degree is obtained by analysis. The smooth deviation degree is obtained by recursion smoothing. When the access control policy determination function output allows, an executable permission level operation is generated according to the smooth deviation degree. When the version jump rate reaches the version stability threshold, version stability constraint is applied. Under the premise that the authentication determination result of the access control policy determination function remains unchanged, the actual execution is replaced by the executable permission level operation. The audit traceability and verification module is used to write audit records after each access request and permission change operation, and to calculate and bind audit verification values ​​to the audit records for storage.

Images