Dynamic access control method and system for communication information security

Abstract

The application provides a kind of dynamic access control method and system for communication information security, it is related to communication information security technical field, and original access request message is captured in the deployment policy enforcement gateway of communication network access layer, and is parsed and converged as initial request context object.According to application layer service uniform resource name and transmission layer protocol port number, security policy center database is inquired, and basic security policy configuration unit is matched.It is inputted into dynamic authority arbitration logic model with initial request context object, and certificate chain validity verification and function conflict analysis are carried out, and access risk comprehensive measurement vector is generated.Real-time authorization authority set is obtained through real-time authority synthesizer, and response message is generated back to policy enforcement gateway.The application can dynamically adapt to communication environment, and improve the security and flexibility of access control.

Description

Technical Field

[0001] This application relates to the field of communication and information security technology, and more specifically, to a dynamic access control method and system for communication and information security. Background Technology

[0002] In the field of communication and information, with the rapid development and widespread application of network technology, information exchange within communication networks is becoming increasingly frequent and complex. Data transmission between the initiating and receiving ends of a communication session involves numerous critical pieces of information, such as network protocol addresses and application layer service resources. To ensure the security of communication information, access control has become a crucial element.

[0003] Most existing access control methods employ static permission allocation mechanisms, which pre-define fixed access permissions for different users or devices. The limitation of this approach is its inability to dynamically adjust permissions based on real-time communication environments and user behavior. For example, in complex network environments, user actions may change due to evolving business needs, but static permission allocation cannot respond promptly to these changes. This could lead to legitimate users being unable to complete necessary operations due to insufficient permissions, or unauthorized users using fixed permissions to gain unauthorized access. Furthermore, existing methods lack effective dynamic analysis and conflict detection mechanisms when handling complex constraints such as role exclusivity, making it difficult to comprehensively guarantee the security of communication information. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a dynamic access control method and system for communication information security.

[0005] According to a first aspect of this application, a dynamic access control method for communication information security is provided, the method comprising: A policy enforcement gateway is deployed at the communication network access layer. The policy enforcement gateway captures the original access request message transmitted from the communication session initiator to the communication session receiver in real time. The original access request message encapsulates the initiator's network protocol address, transport layer protocol port number, application layer service unified resource name to be accessed, and initiator's digital identity certificate file. The original access request message is parsed, the Media Access Control layer header and Internet Protocol layer header are stripped, the transport layer payload data segment is extracted, and the temporary session identifier string, the cipher suite negotiation list and the description text of the set of operation permissions requested to be granted submitted by the initiator are parsed from the transport layer payload data segment and aggregated into an initial request context object. Based on the application layer service unified resource name and the transport layer protocol port number requested, the system queries the pre-set security policy center database, and matches the basic security policy configuration unit corresponding to the current access request from the security policy center database. The basic security policy configuration unit contains a static permission allocation list and a set of function mutual exclusion constraint rules. The initial request context object and the basic security policy configuration unit are simultaneously input into the dynamic permission arbitration logic model. The certificate chain validity verification operation is performed on the digital identity certificate file of the initiating end to obtain the identity credibility score. Based on the functional mutual exclusion constraint rule set, the degree of conflict between the description text of the operation permission set granted by the request and the historical operation behavior record of the initiating end is analyzed to obtain the functional conflict intensity coefficient. The identity credibility score and the functional conflict intensity coefficient are combined into a comprehensive access risk measurement vector. The access risk comprehensive metric vector is transmitted to the real-time permission synthesizer in the dynamic permission arbitration logic model to obtain a real-time authorization permission set. The real-time authorization permission set is then sent back to the policy execution gateway. The policy execution gateway generates a corresponding access allow response message or access deny response message based on the real-time authorization permission set and forwards it to the communication session initiator.

[0006] According to a second aspect of this application, a dynamic access control system for communication information security is provided. The dynamic access control system for communication information security includes a machine-readable storage medium and a processor. The machine-readable storage medium stores machine-executable instructions. When the processor executes the machine-executable instructions, the dynamic access control system for communication information security implements the aforementioned dynamic access control method for communication information security.

[0007] Based on any of the above aspects, the technical effect of this application is as follows: By deploying a policy enforcement gateway at the access layer of the communication network, raw access request messages can be captured in real time. These messages are then parsed, processed, and aggregated into an initial request context object. Based on the application layer service unified resource name and transport layer protocol port number, the security policy center database is queried to match the basic security policy configuration unit. The initial request context object and the basic security policy configuration unit are then input into the dynamic permission arbitration logic model to perform operations such as certificate chain validity verification and functional conflict analysis, generating a comprehensive access risk measurement vector. Finally, a real-time authorization permission set is obtained through a real-time permission synthesizer, and an access allow or deny response message is generated based on it. This achieves dynamic and precise access control, effectively adapting to dynamic changes in the communication environment and promptly handling complex constraint rules, greatly improving the security and flexibility of communication information access control. Attached Figure Description

[0008] Figure 1 A flowchart illustrating the dynamic access control method for communication information security provided in an embodiment of this application is shown. Figure 2 A schematic diagram of the component structure of the dynamic access control system for communication information security provided in an embodiment of this application is shown. Detailed Implementation

[0009] Figure 1 This application provides a flowchart illustrating a dynamic access control method and system for communication information security, with detailed steps including: Step S110: Deploy a policy enforcement gateway at the communication network access layer. The policy enforcement gateway captures the original access request message transmitted from the communication session initiator to the communication session receiver in real time. The original access request message encapsulates the initiator's network protocol address, transport layer protocol port number, application layer service unified resource name to be accessed, and initiator's digital identity certificate file.

[0010] The technical solution of this invention will be described in detail below using the specific application scenario of a smart government intranet. In this scenario, various government staff members initiate access requests to core databases or application servers through internal network terminals. It is necessary to ensure that each access undergoes strict authentication and dynamic permission allocation to prevent data leakage and unauthorized operations.

[0011] In this embodiment, a policy enforcement gateway is deployed between the core switch and the server cluster of the smart government intranet, either via physical bypass or in series. This policy enforcement gateway is configured to monitor all network traffic entering and leaving the core government application server. When a government employee's terminal device (the initiator of the communication session) attempts to access the government approval system deployed on the server (the receiver of the communication session), the terminal constructs and sends an initial access request message. The policy enforcement gateway captures this message in real time at the data link layer through its network interface card.

[0012] The captured raw access request message is a complete protocol data unit, starting from its outermost Ethernet frame header, and encapsulating key information required for subsequent processing layer by layer inside. Specifically, the network layer header encapsulates the initiator's network protocol address, which is represented as a 32-bit binary number in IPv4 address format, typically in dotted decimal notation, or as a 128-bit binary number in IPv6 address format, typically in colon-hexadecimal notation. The transport layer header encapsulates the transport layer protocol port number, a 16-bit binary integer, such as TCP port number 443 used for secure access via Hypertext Transfer Protocol. The data portion of the application layer protocol encapsulates the Uniform Resource Name (URI) of the requested application layer service, a string conforming to URI standards, such as the URL "https: / / gov-approval.internal / " representing the login portal for the government approval system. Furthermore, the application layer payload of the message also includes the initiator's digital identity certificate file, which is a digital certificate conforming to ITU-T X.509 version 3, containing core identity attributes such as the employee's name, department, public key information, and the certificate authority's digital signature.

[0013] Step S120: Perform message parsing processing on the original access request message, strip the Media Access Control layer header and Internet Protocol layer header, extract the transport layer payload data segment, parse the temporary session identifier string submitted by the initiator, the cipher suite negotiation list and the description text of the set of operation permissions requested to be granted from the transport layer payload data segment, and aggregate them into an initial request context object.

[0014] Upon capturing the original access request packet, the policy enforcement gateway immediately triggers the packet parsing processing logic. First, starting from the Ethernet frame header, it strips the 14-byte MAC layer header according to the IEEE 802.3 standard. This MAC layer header contains the source and destination MAC addresses, each consisting of 48 bits. Next, according to the IPv4 or IPv6 protocol specifications, it strips the IP layer header, which contains information such as fragmentation offset, time to live, source IP address, and destination IP address.

[0015] After stripping the headers of the two layers mentioned above, the remaining portion is the transport layer payload data segment. This data segment is then deeply parsed to locate the beginning of the application layer data based on the TCP or UDP header format. From the application layer data, three key information elements are further extracted: First, a temporary session identifier string randomly generated by the initiating terminal and included in the HTTP request header. This temporary session identifier string is a meaningless random sequence of letters and numbers used to uniquely identify a continuous session. Second, a list of cipher suites supported by the terminal. This is an array of cipher suites ordered by priority, including entries such as "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" and "TLS_RSA_WITH_AES_128_CBC_SHA" defined by IANA. Third, a description text of the requested set of permissions, which is typically structured using XML or JSON format.

[0016] In a specific government approval scenario, the description text might include the following: the requested operation type is "file read," the target resource is " / approval / documents / 2023 / report.pdf," and the requested permission level is "read-only." The policy enforcement gateway will encapsulate the parsed temporary session identifier string, cipher suite negotiation list, and description text of the requested set of granted operation permissions, along with the previously parsed initiator network protocol address, transport layer protocol port number, application layer service unified resource name, and initiator digital identity certificate file, into a single data structure. This data structure is the initial request context object. This initial request context object exists in memory as key-value pairs; for example, the key "session_id" corresponds to the value of the temporary session identifier string, and the key "cipher_suites" corresponds to an array of cipher suite negotiation lists.

[0017] Step S130: Based on the application layer service unified resource name and the transport layer protocol port number requested for access, query the preset security policy center database, and match the basic security policy configuration unit corresponding to the current access request from the security policy center database. The basic security policy configuration unit has a static permission allocation list and a set of function mutual exclusion constraint rules embedded inside.

[0018] After constructing the initial request context object, the policy enforcement gateway uses the key fields in this object as query conditions and sends them to the pre-configured security policy center database. This security policy center database is a separately deployed high-performance key-value store or relational database that stores security policy configurations for different application services.

[0019] Specifically, the gateway extracts the application-layer service's unified resource name and transport layer protocol port number from the initial request context object, combining these two fields into a composite query key. For example, if the application-layer service's unified resource name is "https: / / gov-approval.internal / " and the transport layer protocol port number is "443", then the combined query key is "gov-approval.internal_443". After receiving this query key, the security policy center database quickly searches its index to find the basic security policy configuration unit that uniquely corresponds to the composite key.

[0020] This basic security policy configuration unit is a structured data packet that internally embeds two types of core policy information. The first type is a static permission allocation list, a pre-configured permission matrix that defines the baseline permissions for a specific role or user under normal circumstances. It consists of multiple entries, each containing a permission type code field and a corresponding baseline permission value field. The permission type code is a string; for example, "FILE_READ" represents file read permission, and "DB_QUERY" represents database query permission. The baseline permission value field is a pre-set quantitative value representing a fixed level of permission openness. For example, for the "FILE_READ" permission, its baseline permission value might be set to 80, indicating the weight by which this operation is allowed by default.

[0021] The second category is a set of functional mutual exclusion constraint rules, which defines the combinations of permissions that cannot appear simultaneously in permission allocation. Each functional mutual exclusion constraint rule entry consists of a mutual exclusion role group identifier and a blacklist of permission type codes within the mutual exclusion role group. For example, a rule might stipulate that the roles of "financial approver" and "financial executor" cannot be held by the same user in the same session; its corresponding permission type code blacklist might contain permission codes representing "approval payment" and "execution payment." The security policy center database returns the matched basic security policy configuration units as a whole to the policy enforcement gateway.

[0022] Step S140: Input the initial request context object and the basic security policy configuration unit into the dynamic permission arbitration logic model simultaneously, perform certificate chain validity verification on the initiator's digital identity certificate file to obtain an identity credibility score, analyze the degree of conflict between the description text of the request-granted operation permission set and the initiator's historical operation behavior records based on the set of functional mutual exclusion constraint rules to obtain a functional conflict intensity coefficient, and merge the identity credibility score and the functional conflict intensity coefficient into a comprehensive access risk measurement vector.

[0023] The policy enforcement gateway passes the initial request context object generated in step S120 and the basic security policy configuration unit obtained in step S130 as two input parameters to the dynamic permission arbitration logic model. This dynamic permission arbitration logic model is a software module deployed on a separate security server, responsible for executing complex permission arbitration logic. Upon receiving the input, the dynamic permission arbitration logic model initiates two core computational subprocesses in parallel or sequentially.

[0024] The first sub-process involves performing a certificate chain validity verification operation on the initiating digital identity certificate file to obtain a quantified identity trust score. The specific implementation logic of this sub-process will be described in detail in steps S141 to S1413.

[0025] The second sub-process analyzes the degree of conflict between the description text of the requested set of operational permissions and the historical operational behavior records of the initiating end, based on the set of functional mutual exclusion constraint rules, to obtain a functional conflict intensity coefficient. The specific implementation logic of this sub-process will be described in detail in steps S142 to S14213.

[0026] After obtaining the identity credibility score and the functional conflict intensity coefficient, the dynamic access arbitration logic model merges these two scalar values ​​to form a two-dimensional vector, namely the access risk comprehensive metric vector. This access risk comprehensive metric vector is represented in memory as an array containing two floating-point elements, such as [identity credibility score, functional conflict intensity coefficient], which comprehensively reflects the risk level of this access request in the current context.

[0027] Step S141: Extract the initiating digital identity certificate file from the initial request context object, perform certificate chain hierarchical splitting on the initiating digital identity certificate file, and parse out the root certificate node, intermediate certificate node and terminal entity certificate node according to the subordinate relationship of the certificate issuing authority.

[0028] In the first sub-process described in step S140, the dynamic authorization arbitration logic model first extracts the initiating digital identity certificate file from the initial request context object. This file is a data block conforming to the ITU-T X.509 standard. The model calls the certificate parsing library to deserialize and split the file into its hierarchical components.

[0029] Specifically, the parsing library starts from the header of the certificate file, reading its version, serial number, signature algorithm, and other information. Then, according to the hierarchy of Certificate Authorities (CAs), it breaks down the certificate chain into three logical nodes. The first node is the root certificate node, located at the top of the certificate chain. Its issuer and subject are usually the same well-known CA, such as the "Government Root CA." The second node is the intermediate certificate node, issued by the root certificate. Its subject is usually a lower-level CA, such as the "Government Approval System CA." The third node is the end-entity certificate node, located at the bottom of the certificate chain. It is issued by the intermediate certificate, and its subject is the initiating user or device, such as a certificate containing the employee's identity information. Through this hierarchical breakdown, a complete certificate trust chain is constructed.

[0030] Step S142: Extract the certificate subject name field, certificate issuer name field, certificate validity start time field, certificate validity end time field, and certificate signature value field from the terminal entity certificate node.

[0031] After decomposing the certificate chain hierarchically, the model first focuses on the terminal entity certificate nodes, extracting a series of key fields. The Certificate Subject Name field, i.e., the Subject field in an X.509 certificate, contains the certificate holder's unique name, such as "CN=Zhang San, OU=Finance Department, O=Government Affairs Center, C=CN". The Certificate Issuer Name field, i.e., the Issuer field, specifies the name of the entity that issued the certificate, such as "CN=Government Approval System CA, O=Government Affairs Center, C=CN". The Certificate Effective Start Time field, i.e., the notBefore field, records the precise time the certificate begins to take effect in a Universally Reconciled Time (URT) format. The Certificate Effective Expiration Time field, i.e., the notAfter field, records the precise time the certificate expires. The Certificate Signature Value field, i.e., the signature field, is the digital signature value generated by the certificate authority using its private key to sign the entire certificate content; it is a fixed-length binary large object.

[0032] Step S143: Extract the intermediate certificate issuer name field, the intermediate certificate subject public key information field, and the intermediate certificate signature value field from the intermediate certificate node.

[0033] Next, the model moves to the intermediate certificate nodes to extract necessary verification information. The intermediate certificate issuer name field, also known as the Issuer field, should match the subject name of the root certificate. The intermediate certificate subject public key information field, also known as the SubjectPublicKeyInfo field, contains the public key algorithm identifier and the public key itself, crucial information for verifying the signature of the next-level certificate. The intermediate certificate signature value field, also known as the signature field, is the digital signature value generated by the root certificate authority using its private key to sign the intermediate certificate content.

[0034] Step S144: Extract the root certificate issuer name field, the root certificate subject public key information field, and the root certificate self-signature value field from the root certificate node.

[0035] Finally, the model processes the root certificate node. The root certificate issuer name field typically has the same values ​​for both the Issuer and Subject fields, since root certificates are self-signed. The root certificate subject public key information field contains the root certificate's own public key information. The root certificate self-signed value field is the digital signature value generated by the root certificate signing its own content using its private key.

[0036] Step S145: Access the preset root certificate trust anchor repository, obtain the trust anchor public key that matches the root certificate issuer name field from the root certificate trust anchor repository, use the trust anchor public key to decrypt the root certificate self-signature value field to obtain the root certificate original hash value, and at the same time perform a hash operation on the certificate content body of the root certificate node to obtain the root certificate calculated hash value.

[0037] To verify the authenticity of the root certificate, access to a pre-built, absolutely secure root certificate trust anchor repository is required. This root certificate trust anchor repository is a storage area protected at the operating system or application level, containing multiple trusted root certificates and their corresponding public keys. The model uses the root certificate issuer name field extracted in step S144 as the query condition, performs an exact match in this repository, and retrieves the pre-trusted trust anchor public key corresponding to that name.

[0038] After obtaining the trust anchor public key, the model initiates a dual hash verification process. First, it uses the trust anchor public key to decrypt the self-signed numerical field of the root certificate. Since the root certificate self-signature is the result of encrypting a hash value using the root certificate private key, decrypting it with the corresponding public key should yield a hash value, which is the original hash value of the root certificate. Simultaneously, the model uses a hash function consistent with the certificate signing algorithm, such as SHA-256, to hash the certificate content body of the root certificate node—that is, all certificate fields except the signature value—to obtain a calculated hash value for the root certificate.

[0039] Step S146: Compare the original hash value of the root certificate with the calculated hash value of the root certificate bit by bit. If the two are completely consistent, it is determined that the root certificate node has passed the self-signature verification and a root certificate valid flag is generated.

[0040] In this embodiment, the two hash values ​​obtained in step S145—the original hash value of the root certificate and the calculated hash value of the root certificate—are compared bit by bit in memory. If the two values ​​are exactly the same, it means that the hash value obtained from decryption is consistent with the hash value we recalculated from the certificate content. This proves that the content of the root certificate has not been tampered with after issuance, and that the certificate was indeed issued by the entity holding the private key corresponding to the public key. After successful verification, the model generates a root certificate validity flag in memory and sets its value to "True" or a predefined byte value representing validity. If the comparison fails, the flag is set to "False".

[0041] Step S147: Use the public key information field of the root certificate body to decrypt the signature value field of the intermediate certificate to obtain the original hash value of the intermediate certificate, and at the same time perform a hash operation on the certificate content body of the intermediate certificate node to obtain the calculated hash value of the intermediate certificate.

[0042] After confirming the trustworthiness of the root certificate, the model uses the root certificate's public key to verify the signature of the next level, namely the intermediate certificate. The model extracts the root certificate body public key information field obtained in step S144 from the root certificate node, and uses this public key to decrypt the intermediate certificate signature value field, obtaining a hash value, which is the original hash value of the intermediate certificate. Simultaneously, the model uses a hash function consistent with the certificate signing algorithm to hash all fields in the certificate content body of the intermediate certificate node—that is, all fields in the intermediate certificate except the signature value—to obtain a hash value for the intermediate certificate.

[0043] Step S148: Compare the original hash value of the intermediate certificate with the calculated hash value of the intermediate certificate bit by bit. If the two are completely consistent, it is determined that the intermediate certificate node has passed the issuance signature verification and an intermediate certificate valid flag is generated.

[0044] The model compares the original hash value of the intermediate certificate obtained in step S147 with the calculated hash value of the intermediate certificate bit by bit. If they match perfectly, it proves that the intermediate certificate was indeed issued by the private key holder corresponding to the root certificate and that its content has not been tampered with. After successful verification, an intermediate certificate validity flag is generated and its value is set to "True". If the comparison fails, the flag is set to "False".

[0045] Step S149: Use the public key information field of the intermediate certificate body to decrypt the signature value field of the terminal entity certificate node to obtain the original hash value of the terminal certificate, and at the same time perform a hash operation on the certificate content body of the terminal entity certificate node to obtain the calculated hash value of the terminal certificate.

[0046] Next, the model uses the public key of the intermediate certificate to verify the terminal entity certificate at the very end. The model extracts the public key information field of the intermediate certificate body obtained in step S143 from the intermediate certificate node, and uses this public key to decrypt the signature value field of the terminal entity certificate node, obtaining a hash value, which is the original hash value of the terminal certificate. Simultaneously, the model performs the same hash operation on the certificate content body of the terminal entity certificate node to obtain the calculated hash value of the terminal certificate.

[0047] Step S1410: Compare the original hash value of the terminal certificate with the calculated hash value of the terminal certificate bit by bit. If the two are completely consistent and the current system time is within the time interval formed by the certificate valid start time field and the certificate valid end time field, then the terminal entity certificate node is determined to have passed the validity verification, and a terminal certificate valid flag bit is generated.

[0048] The original hash value of the terminal certificate obtained in step S149 is compared bit by bit with the calculated hash value of the terminal certificate. If they do not match, the verification fails directly. If they match, an additional validity check is performed. The current system time is obtained and compared with the certificate validity start time field and certificate validity end time field extracted in step S142. The terminal entity certificate is considered valid in time only if the current system time is greater than or equal to the certificate validity start time and less than or equal to the certificate validity end time. Only when both signature verification and validity check pass, the model determines that the terminal entity certificate node has passed the validity verification and generates a terminal certificate validity flag with a value of "True". Otherwise, the terminal certificate validity flag is set to "False".

[0049] Step S1411: Generate the identity trustworthiness label based on the logical AND operation result of the root certificate valid flag bit, the intermediate certificate valid flag bit, and the terminal certificate valid flag bit. If all certificate nodes obtain valid flag bits, the identity trustworthiness label is set to the identity fully trustworthy identifier. If any level certificate node is missing a valid flag bit, the identity trustworthiness label is set to the identity untrustworthy identifier.

[0050] The model takes the three valid flags generated in the preceding steps—the root certificate valid flag, the intermediate certificate valid flag, and the terminal certificate valid flag—as input and performs a logical AND operation. This operation follows Boolean algebra rules: the result is "True" only if all three inputs are "True"; if any input is "False", the result is "False".

[0051] Based on the result of the logical AND operation, the model generates the final identity trustworthiness label. If the result is "True", the generated identity trustworthiness label is a preset identifier representing complete trustworthiness, such as a string with the value "TRUSTED" or an enumeration type with the value 1. If the result is "False", indicating a problem in a link of the certificate chain, the generated identity trustworthiness label is a preset identifier representing untrustworthiness, such as "UNTRUSTED" or 0.

[0052] Step S1412: Retrieve a set of historical operation behavior records associated with the network protocol address of the initiating end from the preset operation behavior audit database. The set of historical operation behavior records contains multiple historical operation log entries. Each historical operation log entry records the operation initiation time, the name of the operation target resource, the operation permission type code, and the operation execution result status.

[0053] In the second sub-process described in step S140, the model first needs to obtain the historical behavior data of the initiating party. The model extracts the network protocol address of the initiating party from the initial request context object, that is, the IPv4 address or IPv6 address of the initiating party, and uses this as a query condition to send to the preset operation behavior audit database.

[0054] This database is a dedicated storage system for storing all historical access and operation logs. Upon receiving a query, the database searches its log tables to find all historical operation log entries associated with the initiating network protocol address and combines them into a set of historical operation records, which is returned to the model. This set is a list, where each element is a historical operation log entry. Each log entry is a structured record containing at least four core fields: Operation Initiation Time: A timestamp recording the precise moment the operation occurred. Target Resource Name: A URI specifying the accessed resource, such as " / financial / database / salary_table". Operation Permission Type Code: A string recording the specific permission applied during the operation, such as "FILE_WRITE" indicating file write. Operation Result Status: An enumerated value or status code recording whether the operation was successful, rejected, or encountered an error.

[0055] Step S1413: Sort the historical operation behavior record set by time axis and construct the historical operation behavior time sequence of the initiating end according to the ascending order of the operation initiation time.

[0056] After obtaining the original set of historical operation records, the model needs to preprocess the data for subsequent analysis. Since log entries may be stored out of order in the database, the model first calls a sorting function, using the operation initiation time field of each log entry as the sort key to sort the entire set. The sorting algorithm can use quicksort or mergesort to ensure that the final result is a list strictly arranged in chronological order.

[0057] After sorting, the model constructs a complete time series of historical operation behaviors. The first element in this time series is the earliest operation record in time, and the last element is the most recent operation record. It shows the operation trajectory and habits of the initiating user over a period of time, providing a temporal context for analyzing whether there are conflicts in the current request.

[0058] Step S1414: Extract the nearest operation permission type code contained in the nearest neighbor operation log entry from the historical operation behavior time series.

[0059] To analyze whether there is a conflict between the current request and the operation the user just performed, the model extracts the last element from the historical operation behavior time series constructed in step S1413, namely the nearest neighbor operation log entry. This nearest neighbor operation log entry represents the last operation that the user just completed before this request.

[0060] The model extracts the value of the operation permission type code field from this nearest neighbor operation log entry; this value is the recent operation permission type code. For example, if the user has just completed a query operation on the financial database, the recent operation permission type code might be "DB_QUERY". This code will serve as an important reference for determining the continuity between the current request and historical behavior.

[0061] Step S1415: Parse the current request permission type code list attached to this request from the description text of the set of operation permissions granted in the request.

[0062] At the same time, the model processes another key piece of information in the initial request context object, extracting from the object a description text of the set of operation permissions granted in the request, such as the previously mentioned JSON format text "{"requested_permissions": ["FILE_READ", "FILE_WRITE"]}.

[0063] The model calls a JSON or XML parsing library to deserialize the text and extract the list of permission requests contained within. Finally, it obtains a list of currently requested permission types, which is a string array containing all the permissions requested in this request, such as ["FILE_READ", "FILE_WRITE"].

[0064] Step S1416: Count the number of permission type codes that appear together between the current request permission type code list and the recent operation permission type code, and use the number of permission type codes that appear together as the first conflict calculation factor.

[0065] The model now has two sets of data: a list of permissions representing the current request, and a single permission representing the operation that was just completed. The model compares each code in the list of permission type codes for the current request with the permission type codes for the most recent operation.

[0066] The specific calculation logic is as follows: First, a counter is initialized to zero. Then, each permission code X in the current request permission type code list is iterated over, and each X is checked against the most recently executed permission type code (string matching). If they are identical, the counter is incremented. After the iteration, the final value of the counter is the number of co-occurring permission type codes. This number represents the degree of overlap between the currently requested permission and the permission the user just executed. This value is named the first conflict calculation factor. For example, if the most recently executed permission type code is "FILE_READ", and the current request list is ["FILE_READ", "FILE_WRITE"], then the co-occurrence count is 1, and the first conflict calculation factor is 1.

[0067] Step S1417: Obtain the set of functional mutual exclusion constraint rules fixed in the basic security policy configuration unit. The set of functional mutual exclusion constraint rules contains multiple functional mutual exclusion constraint rule entries. Each functional mutual exclusion constraint rule entry consists of a mutual exclusion role group identifier and a blacklist of permission type codes within the mutual exclusion role group.

[0068] In addition to conflicts with single historical behaviors, the model also needs to check whether the current request's permission combination violates the system's predefined static mutual exclusion rules. Therefore, the model extracts the set of functional mutual exclusion constraint rules from the basic security policy configuration unit obtained in step S130.

[0069] This collection is a list of rules. Each functional mutual exclusion constraint rule entry is a structure containing two main parts. The first part is the mutual exclusion role group identifier, a unique string used to identify a group of mutually exclusive roles, such as "CASHIER_AND_ACCOUNTANT". The second part is the permission type code blacklist within the mutual exclusion role group, a list of strings listing the specific permissions belonging to these mutually exclusive roles. For example, for the mutual exclusion of the "cashier" and "accountant" roles, the permission type code blacklist might be ["EXECUTE_PAYMENT", "APPROVE_PAYMENT"], meaning that these two permissions cannot appear simultaneously in a single request.

[0070] Step S1418: Sequentially traverse each functional mutual exclusion constraint rule entry. For the currently traversed functional mutual exclusion constraint rule entry, extract the permission type code blacklist within the mutual exclusion role group in the current functional mutual exclusion constraint rule entry.

[0071] The model initiates a loop that sequentially traverses the set of functional mutual exclusion constraint rules obtained in step S1417. Each iteration of the loop processes one rule entry, referred to as the current functional mutual exclusion constraint rule entry. For this entry, the model first parses its structure and extracts the blacklist of permission type codes within the mutual exclusion role group, i.e., the list containing the mutual exclusion permission codes.

[0072] Step S1419: Detect whether the current request permission type code list contains any two or more permission type codes from the permission type code blacklist.

[0073] For the permission type encoding blacklist of the current rule entry, the model compares it with the current request permission type encoding list obtained in step S1415. The goal of the comparison is to detect whether the current request permission list contains any pair or set of mutually exclusive permissions from the blacklist.

[0074] The specific algorithm is as follows: Treat the current request permission type encoding list as a set A, and the current rule entry's permission type encoding blacklist as another set B. The model calculates the intersection of set A and set B. Then, it determines the size of this intersection, i.e., the number of elements in the intersection set, whether it is greater than or equal to 2. If the intersection size is greater than or equal to 2, it means that the current request is attempting to simultaneously request two or more permissions that are explicitly prohibited from occurring simultaneously by the rules.

[0075] Step S14110: When it is detected that the current request permission type code list contains at least two permission type codes in the permission type code blacklist, it is determined that the current request violates the current function mutual exclusion constraint rule entry, and a rule violation indicator is generated for the current function mutual exclusion constraint rule entry.

[0076] If the detection result in step S1419 is true, i.e., the intersection size is greater than or equal to 2, the model determines that the current request violates the currently processed functional mutual exclusion constraint rule. Based on this determination, the model generates a rule violation indicator. This indicator can be a Boolean value or a binary bit. For each rule, the model performs the above detection and generates a corresponding indicator based on the result.

[0077] Step S14111: Accumulate the rule violation indicators of all functional mutual exclusion constraint rule entries to obtain the cumulative total number of rule violations as the second conflict calculation factor.

[0078] After traversing all rule entries in the set of functional mutual exclusion constraints, the model summarizes all rule violation indicators. Specifically, the model initializes a total counter to zero. For each rule, if its corresponding rule violation indicator is "True" (indicating a violation), the total counter is incremented by one; if it is "False," the counter remains unchanged.

[0079] After the iteration is complete, the final value of the total counter is the cumulative total of rule violations. This total represents the extent to which this request triggered the system's predefined static mutual exclusion rules. This value is named the second conflict calculation factor. For example, if a request simultaneously requests payment execution and payment approval permissions, triggering the "payment mutual exclusion" rule, and simultaneously requests file read and file delete permissions, triggering the "file operation mutual exclusion" rule, then the cumulative total of rule violations is 2.

[0080] Step S14112: Perform normalized weighted fusion processing on the first conflict calculation factor and the second conflict calculation factor, map the first conflict calculation factor to a first numerical interval to obtain a first normalized value, map the second conflict calculation factor to a second numerical interval to obtain a second normalized value, and perform a weighted summation operation on the first normalized value and the second normalized value to obtain the functional conflict intensity coefficient.

[0081] The model now yields two conflict factors of different dimensions and magnitudes. The first conflict factor is a small-range integer, dependent on the size of the request list. The second conflict factor is an integer, dependent on the number of mutual exclusion rules violated. To combine them into a unified, comparable functional conflict intensity coefficient, these two factors need to be normalized and weighted.

[0082] First, normalization is performed. For the first conflict calculation factor, the model maps it to a first numerical range, such as [0, 1], based on its possible maximum value (e.g., the length L_max of the current request permission type encoding list). The normalization function can be designed as: First normalized value = First conflict calculation factor / L_max. In this way, the first normalized value represents the degree of repetition between the current request and recent historical behavior.

[0083] For the second conflict calculation factor, the model maps it to a second numerical interval, such as [0, 1], based on the total number of rules in the rule set, R_total. The normalization function can be designed as: Second normalized value = Second conflict calculation factor / R_total. Thus, the second normalized value represents the degree to which the current request violates the system's static rules.

[0084] After normalization, the model performs a weighted sum of the two normalized values. The system pre-sets two weight coefficients, α and β, representing the degree of importance placed on "historical behavioral conflicts" and "static rule conflicts," respectively. α and β are pre-configured floating-point numbers and satisfy α + β = 1. The final formula for calculating the functional conflict intensity coefficient is: Functional Conflict Intensity Coefficient = α × First Normalized Value + β × Second Normalized Value. This coefficient's range is also between [0, 1]; the larger the value, the higher the degree of requested functional conflict and the greater the risk.

[0085] Step S1413: Transmit the access risk comprehensive metric vector to the real-time permission synthesizer in the dynamic permission arbitration logic model to obtain a real-time authorization permission set. Send the real-time authorization permission set back to the policy execution gateway. The policy execution gateway generates a corresponding access allow response message or access deny response message based on the real-time authorization permission set and forwards it to the communication session initiator.

[0086] The dynamic permission arbitration logic model takes the two-dimensional access risk comprehensive metric vector generated in step S140 as input parameters and passes it to its internal real-time permission synthesizer module. This real-time permission synthesizer module is the core component responsible for performing dynamic permission calculations. Based on the risk vector, it dynamically adjusts the static baseline permissions, ultimately generating a set of real-time authorized permissions for the current request. After obtaining this set, the model transmits it back to the policy enforcement gateway via the network. The gateway, based on the contents of this set, decides whether to allow or deny the access request and constructs a corresponding response message to send to the initiating terminal. The specific working logic of the real-time permission synthesizer and the detailed process of the gateway generating the response message will be elaborated in subsequent steps S150 and its sub-steps.

[0087] Step S150: Transmit the access risk comprehensive metric vector to the real-time permission synthesizer in the dynamic permission arbitration logic model to obtain a real-time authorization permission set. Send the real-time authorization permission set back to the policy execution gateway. The policy execution gateway generates a corresponding access allow response message or access deny response message based on the real-time authorization permission set and forwards it to the communication session initiator.

[0088] This step describes the final synthesis and execution phase of dynamic permission arbitration. The dynamic permission arbitration logic model sends the access risk comprehensive metric vector generated in step S140, along with the static permission allocation list from the previously used basic security policy configuration unit, to the real-time permission synthesizer. Based on the risk vector, the real-time permission synthesizer dynamically scales or modifies each baseline permission in the static list, generating a completely new set of real-time authorized permissions valid only for this session. This set of real-time authorized permissions is then sent back to the policy enforcement gateway, which is responsible for translating it into specific network access control decisions and notifying the initiating party in the form of a standard network protocol response message. A detailed breakdown of this process is as follows.

[0089] Step S151: Load a pre-established permission adjustment coefficient mapping table from the local storage area of ​​the real-time permission synthesizer. The row index of the permission adjustment coefficient mapping table is composed of the value type of the identity trustworthiness label, and the column index of the permission adjustment coefficient mapping table is composed of the value range division threshold of the functional conflict intensity coefficient. Each table entry cell of the permission adjustment coefficient mapping table stores the permission scaling factor value corresponding to the row index and the column index.

[0090] When the real-time permission synthesizer starts, it first loads a pre-generated permission adjustment coefficient mapping table from its protected local storage area. This permission adjustment coefficient mapping table is a two-dimensional data structure, which can be understood as a special kind of lookup table.

[0091] The row index of this table is defined based on the value type of the identity trust level label. Since the identity trust level label has only two possibilities, "TRUSTED" and "UNTRUSTED", this mapping table has two fixed rows: the first row corresponds to "TRUSTED" and the second row corresponds to "UNTRUSTED".

[0092] The column indexes of this table are defined based on the threshold values ​​for the functional conflict intensity coefficient. The functional conflict intensity coefficient is a floating-point number between 0 and 1. The system pre-sets a series of threshold values, such as thresholds T1, T2, and T3, to divide the [0, 1] interval into multiple consecutive intervals, such as [0, T1), [T1, T2), [T2, T3), and [T3, 1]. Each of these intervals corresponds to a column in the table.

[0093] Each entry in the mapping table—the cell located by the intersection of a specific row (identity label) and a specific column (risk coefficient range)—stores a specific permission scaling factor value. This factor is a floating-point number, such as 0.8, 1.0, or 1.2, used to amplify or reduce the baseline permissions. For example, in the entry corresponding to the "TRUSTED" row and the low-risk coefficient range, the stored scaling factor might be greater than 1, meaning that low-risk requests from trusted users can have their permissions appropriately relaxed; while in the entry corresponding to the "UNTRUSTED" row and the high-risk coefficient range, the stored scaling factor might be much less than 1 or even 0, meaning that high-risk requests from untrusted users must be strictly restricted.

[0094] Step S152: Analyze the identity credibility score contained in the access risk comprehensive measurement vector, compare the specific value of the identity credibility score with the boundary values ​​of multiple preset identity credibility score intervals in sequence, and determine the target row index position to which the identity credibility score belongs.

[0095] The access risk composite metric vector received by the real-time permission synthesizer is a two-dimensional array [ID_Score, Conflict_Coeff]. Here, ID_Score is the identity credibility score. In step S1411, the identity credibility labels “TRUSTED” and “UNTRUSTED” are actually highly diffuse representations of this score. To look up the mapping table, it needs to be mapped to row indices. The model compares ID_Score with a preset threshold. Typically, the identity credibility score is either 1 (representing “TRUSTED”) or 0 (representing “UNTRUSTED”). If it is 1, the target row index is determined to be the first row; if it is 0, the target row index is determined to be the second row.

[0096] Step S153: Synchronously parse the functional conflict intensity coefficient contained in the access risk comprehensive measurement vector, and sequentially compare the specific value of the functional conflict intensity coefficient with the preset boundary values ​​of multiple functional conflict intensity intervals to determine the target column index position to which the functional conflict intensity coefficient belongs.

[0097] Meanwhile, the synthesizer parses the second element of the vector, namely the functional conflict intensity coefficient Conflict_Coeff. This is a floating-point number between 0 and 1. The synthesizer sequentially compares it with the partitioning thresholds T1, T2, T3, etc., mentioned in step S151.

[0098] For example, if the value of Conflict_Coeff is less than T1, it is determined to belong to the first interval, and the target column index is the first column. If the value of Conflict_Coeff is greater than or equal to T1 and less than T2, it is determined to belong to the second interval, and the target column index is the second column. This process continues until it is determined which specific interval defined by the threshold the coefficient value falls into, thus determining the corresponding column index position.

[0099] Step S154: Locate the corresponding target permission scaling factor value in the permission adjustment coefficient mapping table based on the target row index position and the target column index position, and extract the specific target permission scaling factor floating-point value from the target permission scaling factor value.

[0100] With the target row index determined in step S152 and the target column index determined in step S153, the synthesizer can now accurately locate the target column in the two-dimensional permission scaling factor mapping table. It first locates the row, then the column within that row, and reads the value stored in the corresponding table entry. This read value is the final permission scaling factor floating-point value applicable to this access request, denoted as K_factor.

[0101] Step S155: Extract a static permission allocation list from the basic security policy configuration unit. The static permission allocation list contains multiple baseline permission entries. Each baseline permission entry consists of a permission type encoding field and a corresponding baseline permission value field. The baseline permission value field is preset to a fixed permission openness quantification value.

[0102] The synthesizer then extracts a static permission allocation list from the input basic security policy configuration unit. Each baseline permission entry is a key-value pair. The key is the permission type encoding field, such as "FILE_READ". The value is the corresponding baseline permission value field, which is a pre-defined, fixed integer or floating-point number representing the default openness of that permission. For example, the system can set the baseline value for "FILE_READ" to 80, the baseline value for "FILE_WRITE" to 60, and the baseline value for "DB_ADMIN" to 100. The higher the value, the greater the default permission.

[0103] Step S156: Traverse each baseline permission entry in the static permission allocation list. For the current baseline permission entry that is currently being traversed, obtain the baseline permission quantization value stored in the baseline permission value field of the current baseline permission entry.

[0104] The synthesizer initiates a loop that iterates through the static permission allocation list obtained in step S155. In each loop iteration, it processes a base permission entry, called the current base permission entry. First, it parses the base permission value field from this entry and extracts the stored fixed value, denoted as P_base.

[0105] Step S157: Multiply the baseline permission quantization value with the target permission scaling factor floating-point value to obtain the real-time permission intermediate calculation quantization value of the current baseline permission entry.

[0106] The synthesizer multiplies the global scaling factor K_factor obtained in step S154 with the current baseline permission quantization value P_base extracted in step S156. The result is P_intermediate = P_base × K_factor. This P_intermediate is the real-time permission intermediate quantization value dynamically adjusted according to the risk level of this access. Since K_factor is a floating-point number, this calculation achieves scaling of the baseline permission. For example, if the K_factor of a low-risk request is 1.2, then P_intermediate will be 20% larger than P_base, meaning that the permission is appropriately relaxed; if the K_factor of a high-risk request is 0.5, then P_intermediate is only half of P_base, meaning that the permission is tightened.

[0107] Step S158: Compare the real-time intermediate calculated quantized value of the permission with the preset upper limit threshold of the permission value. If the real-time intermediate calculated quantized value of the permission is greater than the upper limit threshold of the permission value, then the upper limit threshold of the permission value is used as the final quantized value of the current baseline permission entry.

[0108] To prevent dynamic adjustments from causing permission values ​​to amplify indefinitely and exceed a safe and controllable range, the system sets a maximum permission value threshold, denoted as P_max, for all permissions. The synthesizer compares P_intermediate, calculated in step S157, with P_max. If P_intermediate > P_max, it means that the dynamically amplified permission value exceeds the system's maximum allowed limit. To ensure security, the system does not allow permissions to exceed this limit. Therefore, in the above case, the final permission quantization value P_final is set to P_max, instead of continuing to use P_intermediate.

[0109] Step S159: Compare the real-time intermediate calculated quantized value of the permission with the preset lower limit threshold of the permission value. If the real-time intermediate calculated quantized value of the permission is less than the lower limit threshold of the permission value, then the lower limit threshold of the permission value is used as the final quantized value of the current baseline permission entry.

[0110] Similarly, to prevent dynamic adjustments from causing permission values ​​to shrink indefinitely, rendering even basic legal operations impossible, the system sets a lower limit threshold for all permissions, denoted as P_min. The synthesizer compares P_intermediate with P_min. If P_intermediate < P_min, it means the dynamically scaled permission value is below the minimum threshold required for any operation. In this case, completely disabling the permission could disrupt business processes. Therefore, the system locks this permission at the minimum feasible level, setting the final permission quantification value P_final to P_min.

[0111] Step S1510: When the real-time permission intermediate calculation quantization value is within the closed interval formed by the lower limit threshold of the permission value and the upper limit threshold of the permission value, the real-time permission intermediate calculation quantization value is directly used as the final permission quantization value of the current baseline permission entry.

[0112] If the value of P_intermediate neither exceeds P_max nor falls below P_min, meaning it falls within the closed interval [P_min, P_max] formed by P_min and P_max, then the dynamically adjusted value is reasonable and safe. In this case, the synthesizer directly uses P_intermediate as the final permission quantization value P_final for the current baseline permission entry.

[0113] Step S1511: Collect the permission type encoding field of all baseline permission entries and the final permission quantization value corresponding to each permission type encoding field, and encapsulate the permission type encoding field and the final permission quantization value in pairs to generate a real-time authorization permission set.

[0114] After the loop in steps S156 to S1510 has traversed all entries in the static permission allocation list, the synthesizer calculates a corresponding final permission quantization value P_final for each permission type. Next, the synthesizer collects these results and creates a new data structure, such as a list or dictionary, encapsulating each permission type code and its corresponding P_final value as a key-value pair. This newly generated data structure is the set of real-time authorized permissions specifically calculated for this access request. Each permission entry in this set of real-time authorized permissions is accompanied by a dynamically risk-adjusted quantization value, representing the degree of openness actually granted to that permission in the current context. Finally, this set of real-time authorized permissions is returned as a result from the real-time permission synthesizer to the dynamic permission arbitration logic model and is prepared to be sent back to the policy enforcement gateway.

[0115] Step S160: The policy execution gateway generates a corresponding access allow response message or access deny response message based on the real-time authorization permission set and forwards it to the communication session initiator.

[0116] After receiving the real-time authorization permission set returned by the dynamic permission arbitration logic model, the policy enforcement gateway is responsible for transforming it into a specific network layer decision and notifying the initiating party. The gateway first parses the set and then determines the final fate of the request based on its content. This determination and message generation process is detailed in steps S161 to S1613.

[0117] Step S161: Receive the real-time authorization permission set returned by the dynamic permission arbitration logic model through the policy execution gateway, perform data structure parsing on the real-time authorization permission set, and extract all permission type encoding fields and corresponding final permission quantification values ​​contained in the real-time authorization permission set.

[0118] The network service module of the policy enforcement gateway receives a response data packet from the dynamic permission arbitration logic model and deserializes the real-time authorization permission set from the packet body. Then, the gateway's decision engine traverses and parses this set, extracting the permission type encoding field for each entry and the associated final permission quantification value P_final. For example, after parsing, it might obtain the key-value pairs (FILE_READ, 85) and (FILE_WRITE, 30).

[0119] Step S162: Iterate through each permission type encoding field sequentially. For the current permission type encoding field that is currently being traversed, obtain the final permission quantization value corresponding to the current permission type encoding field.

[0120] The decision engine starts a loop that iterates through each permission entry parsed in step S161. In each iteration, it obtains a current permission type code and the corresponding final permission quantization value P_final.

[0121] Step S163: Compare the final permission quantization value with the preset permission activation determination threshold. If the final permission quantization value is greater than or equal to the permission activation determination threshold, then determine that the permission entry indicated by the current permission type encoding field is in an active state, and generate a permission activation status flag for the current permission type encoding field.

[0122] For each permission entry, the decision engine compares its P_final value with a globally preset permission activation threshold, denoted as T_active. T_active is a fixed value between P_min and P_max, used to define whether a permission is "available." If P_final >= T_active, it means that the quantified value of the permission has reached the threshold for executable operations. Based on this, the engine determines that the permission is active, i.e., the permission actually granted in this session. Simultaneously, the engine generates a permission activation status flag for this permission, for example, marking it as "ALLOWED" in memory.

[0123] Step S164: Compare the final permission quantization value with the preset permission activation determination threshold. If the final permission quantization value is less than the permission activation determination threshold, determine that the permission entry indicated by the current permission type encoding field is in a suppressed state, and generate a permission suppression state flag for the current permission type encoding field.

[0124] For the same permission entry, if its P_final value is less than T_active, it means that although the permission may exist, its quantification value is insufficient to support the actual operation execution. Based on this, the engine determines that the permission is in a suppressed state, meaning that the permission will not be granted in this session. Simultaneously, the engine generates a permission suppression status flag for this permission, for example, marking it as "DENIED" in memory.

[0125] Step S165: Collect all permission type encoding fields marked as active status flags and construct the final allowed permission type encoding list for this access request.

[0126] After traversing all permission entries, the decision engine collects all permission type codes marked "ALLOWED" and adds them to the final list of allowed permission type codes.

[0127] Step S166: Collect all permission type encoding fields marked with the suppression status flag, and construct the final denied permission type encoding list for this access request.

[0128] At the same time, the decision engine also collects all permission type codes marked "DENIED" and puts them into another new list structure, which serves as the final list of denied permission type codes. This is used to record which requests have had their permissions denied, and can be used for auditing or to provide feedback to users.

[0129] Step S167: Count the total number of entries in the permission type encoding field contained in the final allowed permission type encoding list, compare the total number of entries with zero, if the total number of entries is greater than zero, it is determined that an access allow response message needs to be generated, if the total number of entries is equal to zero, it is determined that an access deny response message needs to be generated.

[0130] The decision engine checks the length of the final list of allowed permission types, i.e., the total number of entries in the list, denoted as N_allowed. N_allowed is compared to 0. This is a final business decision point: if N_allowed > 0, it means the user has been granted at least one permission, and the access request should be allowed overall. If N_allowed == 0, it means the user has not been granted any valid permissions, and the access request should be rejected.

[0131] Step S168: When it is determined that an access permission response message needs to be generated, an access permission response message template is constructed based on the transport layer protocol port number in the original access request message, and a predefined access success status identifier is filled into the protocol status code field of the access permission response message template.

[0132] If step S167 determines that an access permission response message needs to be generated, the gateway calls a protocol stack function to construct a corresponding response message template based on the transport layer protocol port number used by the original access request message parsed in step S120. For example, if the original request used TCP port 443, the gateway constructs an HTTPS response message template. In the protocol status code field of this template, such as the HTTP protocol status code line, a predefined status identifier representing successful access is filled in, such as "200 OK" or its corresponding binary code.

[0133] Step S169: Embed the final allowed permission type encoding list in the extended option field of the access allow response message template, convert the final allowed permission type encoding list into byte stream data blocks according to the encoding rules corresponding to the transport layer protocol port number, and fill the byte stream data blocks into the payload area of ​​the access allow response message template.

[0134] To deliver authorization information to the client, the gateway will ultimately allow the processing of the permission type encoding list. First, it serializes this list into a byte stream data block according to the application layer encoding rules corresponding to the transport layer protocol, such as the HTTP protocol. The serialization format can be JSON or an efficient binary format. Then, this byte stream data block is filled into the payload area (i.e., the HTTP message body) of the previously constructed response message template. Additionally, a custom header field, such as "X-Granted-Permissions: present", can be added to the message's extended options fields, such as the HTTP header, to indicate that the payload contains permission information.

[0135] Step S1610: When it is determined that an access rejection response message needs to be generated, construct an access rejection response message template based on the transport layer protocol port number in the original access request message, and fill the protocol status code field of the access rejection response message template with a predefined access failure status identifier.

[0136] If step S167 determines that an access denial response message needs to be generated, the gateway constructs a denial message template. Similarly, based on the port number of the original request, such as 443, an HTTPS response message template is constructed. In the protocol status code field of the template, a predefined status identifier representing access failure is filled in, such as "403 Forbidden" or its corresponding binary code.

[0137] Step S1611: Embed the final denial permission type encoding list in the extended option field of the access denial response message template, convert the final denial permission type encoding list into byte stream data blocks according to the encoding rules corresponding to the transport layer protocol port number, and fill the byte stream data blocks into the payload area of ​​the access denial response message template.

[0138] Similar to the allow message, the gateway also serializes the final list of denied permission types into byte stream data blocks and populates the payload area of ​​the deny response message template. This provides the client or user with a clear reason for the denial, informing them which requested permissions were not granted. Alternatively, a custom field, such as "X-Rejected-Permissions: present", can be added to the HTTP header to indicate that the payload includes information about the denied permissions.

[0139] Step S1612: Forward the generated access allow response message or access deny response message to the communication session initiator through the communication network access layer to complete this dynamic access control operation process.

[0140] Finally, the policy enforcement gateway forwards the completed response message, containing decision and permission information, along the reverse path obtained from the original access request message, through the communication network access layer (i.e., through network devices such as switches), to the initial requesting terminal. Upon receiving the response, if it's an allow message, the initiating terminal can perform subsequent business operations according to the permission list in the payload; if it's a deny message, its access is blocked. This completes a full dynamic access control operation.

[0141] Step S210: Extract the authoritative information access point field from the terminal entity certificate node of the initiating digital identity certificate file. The authoritative information access point field encapsulates a certificate status online query protocol uniform resource locator.

[0142] After generating the identity trust level label in step S1411, to further improve the real-time performance and accuracy of identity verification, this method also includes an optional online certificate status verification step. The dynamic authorization arbitration logic model re-parses the initiating digital identity certificate file and extracts an extension field named "Authority Information Access" from the certificate extension area of ​​the terminal entity certificate node, i.e., the extensions field defined in the X.509 standard. This extension field encapsulates one or more access method descriptors. The entry corresponding to the Online Certificate Status Protocol (OCSP) is found in the access method descriptor, and a Uniform Resource Locator (URL) string is extracted from it. This URL points to an OCSP response server that provides real-time certificate status query services.

[0143] Step S211: Construct a certificate status online query request data unit based on the certificate status online query protocol Uniform Resource Locator, and embed the certificate serial number field and certificate issuer name field of the terminal entity certificate node in the certificate status online query request data unit.

[0144] Based on the OCSP URL extracted in step S210, the model constructs an OCSP request data unit conforming to RFC 6960. This request is an ASN.1 encoded data structure. When constructing the request, the model extracts the certificate serial number field (a unique integer assigned by the CA) and the certificate issuer name field (i.e., the name of the CA that issued the certificate) from the terminal entity's certificate node, and embeds these two key pieces of information as part of the request body into the OCSP request data unit. These two pieces of information together uniquely identify the specific certificate whose status needs to be queried.

[0145] Step S212: Send the certificate status online query request data unit to the certificate status online response server corresponding to the authoritative information access point field, and receive the certificate status online response data unit returned by the certificate status online response server.

[0146] The model sends the OCSP request data unit constructed in step S211 to the server pointed to by the OCSP URL obtained in step S210 via a secure HTTP connection. This server, the online certificate status response server, upon receiving the request, queries its database to find the current status of the certificate (valid, revoked, or unknown) and generates a digitally signed OCSP response data unit. The model then receives this response data unit.

[0147] Step S213: Parse the certificate status information body in the certificate status online response data unit, and extract the certificate revocation status flag bit and certificate revocation time point field from the certificate status information body.

[0148] The model parses the received OCSP response data units. First, it verifies the digital signature of the response to ensure it originates from a trusted OCSP responder. After successful verification, it parses the body of the response, namely the certificate status information body. From this body, two key fields are extracted. The first is the certificate revocation status flag, which is an enumerated value that can be "good" (valid), "revoked" (revoked), or "unknown". The second is the certificate revocation time point field, which only exists when the certificate status is "revoked," and records the precise time the certificate was revoked.

[0149] Step S214: Compare the certificate revocation status flag with the preset certificate validity status identifier. If the certificate revocation status flag matches the certificate validity status identifier, then generate an online status verification pass flag.

[0150] The model compares the extracted certificate revocation status flag with a pre-defined identifier "good" representing certificate validity. If they match, it indicates that the certificate has not been revoked and is in a good state. Based on this, the model generates an online status verification pass flag, such as a boolean flag with a value of "OCSP_VALID".

[0151] Step S215: Compare the certificate revocation status flag with the preset certificate revocation status identifier. If the certificate revocation status flag matches the certificate revocation status identifier, then generate an online status verification failure flag.

[0152] If the certificate revocation status flag extracted in step S213 matches the preset identifier "revoked" that represents certificate revocation, it indicates that the certificate has been revoked by the CA in advance. Based on this, the model generates an online status verification failure flag, such as "OCSP_REVOKED".

[0153] Step S216: Perform a time sequence analysis on the certificate revocation time point field, the certificate validity start time field, and the certificate validity end time field. If the certificate revocation time point field is after the certificate validity start time field and before the certificate validity end time field, it is determined that the terminal entity certificate node was revoked prematurely within its validity period.

[0154] Even if the certificate status is marked as "revoked," the model will still perform a time-series analysis. It compares the certificate revocation time point field extracted in step S213 with the certificate validity start time and validity end time fields extracted in step S142. If the revocation time point is greater than the validity start time but less than the validity end time, it is determined that the certificate was prematurely revoked by the CA due to reasons such as key leakage or personnel departure within its original valid lifespan. This determination result can be used to generate more granular audit logs or trigger higher-level alerts.

[0155] Step S217: Correct the identity credibility score based on the online status verification pass flag or the online status verification failure flag. If the online status verification failure flag is obtained, adjust the identity credibility score to a preset untrustworthy score threshold.

[0156] Based on the online status verification results, the model corrects the identity credibility score generated in step S1411. If step S214 generates an online status verification pass flag, the original identity credibility score remains unchanged, or a small confidence increment can be added. However, if step S215 generates an online status verification failure flag, regardless of the previous certificate chain verification results, it indicates that the certificate is currently invalid, and therefore the identity is absolutely untrustworthy. The model will force the identity credibility score to be adjusted to a preset minimum score threshold representing untrustworthiness, such as 0.

[0157] Step S218: Re-encapsulate the corrected identity credibility score into the access risk comprehensive metric vector, replacing the original identity credibility score.

[0158] Finally, the model replaces the original identity credibility score element in the access risk comprehensive metric vector generated in step S140 with the corrected identity credibility score from step S217, generating an updated vector. This updated vector will be used in subsequent real-time permission synthesis steps, thereby incorporating the online real-time status of certificates into the final permission decision.

[0159] Step S310: Extract multiple historical operation log entries associated with the operation target resource name from the historical operation behavior record set of the initiating end. The multiple historical operation log entries contain multiple historical access records for the same operation target resource name.

[0160] After obtaining the historical operation behavior record set in step S1412 and sorting it in step S1413, or after generating the functional conflict intensity coefficient in step S14112, this method also includes an optional step for detecting abnormal access frequency. The dynamic permission arbitration logic model performs a secondary filtering from the sorted historical operation behavior time series, extracting all log entries whose target resource name field is the same as the target resource name in the current request. These entries constitute the historical access record set for that specific resource, used to analyze the user's access frequency to that resource.

[0161] Step S311: Reorder the multiple historical operation log entries according to the order of operation initiation time to generate a target resource operation timeline trajectory for the target resource name of the operation.

[0162] Since the filtered entries may come from different time periods, the model again sorts these entries using the operation initiation time field as the key to ensure they are arranged strictly in chronological order. The resulting sequence after sorting is called the target resource operation time-series trajectory for that operation's target resource name. This trajectory clearly shows the user's access patterns to that specific resource over a past period.

[0163] Step S312: Extract the time interval value between two consecutive adjacent historical access records from the target resource operation time sequence trajectory, and compare the time interval value with a preset frequent access time threshold.

[0164] The model iterates through the target resource operation timeline. For every two adjacent entries in the trajectory, such as record A and record B, it calculates the difference between their operation initiation time fields to obtain the time interval between these two adjacent accesses, denoted as Δt. The model then compares this Δt with a preset frequent access time threshold, denoted as T_freq, used to define what is considered "frequent".

[0165] Step S313: If the time interval value is less than the frequent access time threshold, it is determined that the initiating end has frequent access behavior to the target resource name of the operation, and a frequent access marker is generated.

[0166] If the calculated Δt is less than T_freq, it means that the time interval between two accesses to the same resource by a user is very short and is considered "frequent". For each of the above comparison results, the model generates a frequent access marker, such as a label with a value of "HIGH_FREQ".

[0167] Step S314: Count the number of times the time interval between all adjacent historical access records in the target resource operation time sequence trajectory is less than the frequent access time threshold, and obtain the cumulative value of frequent access frequency.

[0168] The model initializes a counter with an initial value of 0. During the traversal of the entire target resource operation timeline, the counter increments by 1 each time the determination described in step S313 occurs, i.e., each time a frequent access marker is generated. After the traversal is complete, the final value of the counter is the cumulative value of the frequent access frequency, denoted as F_count.

[0169] Step S315: Compare the cumulative value of frequent access frequency with a preset abnormal access frequency threshold. If the cumulative value of frequent access frequency is greater than the abnormal access frequency threshold, generate an abnormal access frequency warning sign.

[0170] The model compares the cumulative frequent access frequency value F_count obtained in step S314 with a preset abnormal access frequency threshold, denoted as T_abnormal, used to define what is "abnormal". If F_count > T_abnormal, it means that the frequency of accesses to the resource in the user's historical access history has exceeded the normal range, which may indicate abnormal behavior such as automated script scanning or data crawling. Based on this, the model generates an abnormal access frequency warning flag, such as a boolean flag with the value "FREQ_ABNORMAL".

[0171] Step S316: Based on the comparison result between the cumulative value of frequent access frequency and the threshold value of abnormal access frequency, an abnormal access frequency score is calculated; the abnormal access frequency score is weighted and fused with the functional conflict intensity coefficient to correct the functional conflict intensity coefficient; wherein, the weight of the weighted fusion is dynamically determined according to the identity credibility score.

[0172] To incorporate abnormal access frequency information into the final risk assessment, the model calculates an abnormal access frequency score, denoted as A_score. This score can be calculated based on the deviation of F_count from T_abnormal, for example, A_score = min(1, F_count / T_abnormal). Then, the model weights and fuses this A_score with the original functional conflict intensity coefficient calculated in step S14112 to obtain a new, corrected functional conflict intensity coefficient.

[0173] The weights for fusion are not fixed but dynamically determined based on the identity credibility score. For example, if the identity credibility score is low (indicating the identity itself is suspicious), then the abnormal access frequency score can be assigned a higher weight during fusion; conversely, if the identity is highly credible, it is assigned a lower weight. Assuming the dynamic weight is W_risk, which is inversely proportional to the identity credibility score ID_Score, for example, W_risk = 1 - ID_Score, then the corrected functional conflict intensity coefficient New_Conflict_Coeff = (1 - W_risk) × original conflict coefficient + W_risk × A_score. Thus, for untrustworthy identities, their abnormal access behavior will have a greater impact on the final risk coefficient.

[0174] Step S317: Re-encapsulate the corrected functional conflict intensity coefficient into the comprehensive access risk metric vector.

[0175] Finally, the model replaces the original functional conflict intensity coefficient in the access risk comprehensive metric vector generated in step S140 with the modified functional conflict intensity coefficient New_Conflict_Coeff calculated in step S316, generating an updated vector that integrates multiple risk factors such as authentication, static rule conflicts, and abnormal dynamic behavior frequency.

[0176] Step S410: Extract multiple mutually exclusive role group identifiers associated with the functional mutual exclusion constraint rule set from the basic security policy configuration unit. Each mutually exclusive role group identifier corresponds to a set of mutually exclusive permission type encoding blacklists.

[0177] Before performing dynamic offset correction processing via the real-time permission synthesizer, this method also includes an optional step to check for conflicts in the user roles themselves. The dynamic permission arbitration logic model extracts a set of function mutual exclusion constraint rules from the basic security policy configuration unit, and further extracts all unique mutual exclusion role group identifiers from it. These identifiers, such as "ROLE_CASHIER" and "ROLE_ACCOUNTANT", represent system-predefined role mutual exclusion groups.

[0178] Step S411: Parse the role attribute field in the initiator's digital identity certificate file, and extract the list of current role group identifiers to which the initiator belongs from the role attribute field.

[0179] The model re-parses the initiator's digital identity certificate file, searching for the role definition field in its extended attributes. In some enterprise public key infrastructures, certificates can carry user role information through custom extensions. The model parses this field, extracting one or more role group identifiers to form a list of current role group identifiers to which the initiator belongs. For example, a user's certificate might carry two roles: "ROLE_HR_MANAGER" and "ROLE_PAYROLL_OFFICER".

[0180] Step S412: Perform an intersection operation on the current role group identifier list and the multiple mutually exclusive role group identifiers, and detect whether the current role group identifier list contains two or more role group identifiers belonging to the same mutually exclusive role group identifier.

[0181] The model treats the current role group identifier list obtained in step S411 as a set A, and each mutually exclusive role group identifier obtained in step S410 as a set B (although B usually contains only one identifier, it is logically a set). The core detection logic of the model is to check whether set A contains the opposing role represented by that mutually exclusive role group for each mutually exclusive role group identifier. For example, if a mutual exclusion rule defines that "ROLE_CASHIER" and "ROLE_ACCOUNTANT" cannot coexist, then the model checks whether A contains both of these identifiers.

[0182] Step S413: When it is detected that the current role group identifier list contains two or more role group identifiers belonging to the same mutually exclusive role group identifier, it is determined that the role assignment of the initiating end violates the role mutual exclusion constraint rule, and a role assignment conflict flag is generated.

[0183] If the detection result of step S412 is true, meaning that the user's certificate is indeed granted mutually exclusive roles simultaneously, the model determines that this is a fundamental conflict at the role assignment level. This is a more serious problem than the permission request conflict in step S1410 because it indicates that there is a logical error in the user's identity definition itself. The model generates a role assignment conflict flag for this purpose, such as a flag with a value of "ROLE_CONFLICT".

[0184] Step S414: Input the role assignment conflict flag into the real-time permission synthesizer to trigger the real-time permission synthesizer to call the preset conflict permission zeroing processing program.

[0185] The model takes the role assignment conflict flag generated in step S413 as an exception input and passes it to the real-time permission synthesizer. Upon receiving this flag, the synthesizer does not perform the usual permission scaling based on the mapping table, but immediately invokes a preset, high-priority conflict permission zeroing handler.

[0186] Step S415: Through the conflict permission zeroing process, traverse each base permission entry in the static permission allocation list and force the base permission value field corresponding to the permission type encoding field associated with the mutual exclusion role group identifier to a zero value.

[0187] Once the conflict permission zeroing handler is triggered, it executes a mandatory zeroing logic that iterates through the static permission allocation list loaded from the basic security policy configuration unit. During the iteration, it checks whether the permission type code of each baseline permission entry matches the code in the permission blacklist associated with the mutex role group identifier that caused the conflict. If a match is found, the handler ignores the original baseline permission value and directly forces the baseline permission value field of that entry to be changed to 0.

[0188] Step S416: Use the static permission allocation list after zeroing as the input of the real-time permission synthesizer, replacing the original static permission allocation list in the dynamic offset correction process.

[0189] After step S415, all permissions related to conflicting roles in the original static permission allocation list are cleared to zero. This modified list is used as valid input to the real-time permission synthesizer, completely replacing the original static list. The synthesizer then performs dynamic offset correction processing from steps S156 to S1511 on this "zeroed" list. However, since the baseline value of critical permissions is already 0, regardless of the subsequent scaling factor K_factor, the quantized values ​​of these permissions in the final real-time authorized permission set will remain 0, thus fundamentally eliminating the risk of permission abuse that may result from role conflicts.

[0190] Step S510: The policy execution gateway captures the subsequent service operation request data packet initiated by the communication session initiator after obtaining the access permission response message. The subsequent service operation request data packet encapsulates an operation instruction type field and an operation parameter content field.

[0191] After forwarding the access permission response message to the initiating end in step S1612, the policy enforcement gateway continues to listen for subsequent traffic from the same session initiated by that initiating end. The gateway captures subsequent service operation request data packets sent by the initiating end. This data packet is the request from the initiating end to actually perform a specific service operation after obtaining access permission. It encapsulates two key fields: an operation instruction type field, such as an operation code "OP_FILE_DOWNLOAD" indicating "download file"; and an operation parameter content field, which describes in detail the specific content of the operation, such as a JSON object containing the target file name and the required resource size: "{"filename": "large_dataset.zip", "estimated_size": 1024}".

[0192] Step S511: Extract the operation instruction type field from the subsequent business operation request data packet, and match and retrieve the operation instruction type field with the permission type encoding field in the real-time authorization permission set.

[0193] The gateway parses the captured subsequent business operation request data packets and extracts the operation instruction type field. Then, the gateway queries the locally cached real-time authorization permission set corresponding to the session, checking all permission type encoding fields in the set to see if any encoding matches the extracted operation instruction type. For example, it compares "OP_FILE_DOWNLOAD" with encodings such as "FILE_READ" and "FILE_WRITE" in the set.

[0194] Step S512: If the operation instruction type field exists in the permission type encoding field of the real-time authorization permission set, then obtain the final permission quantization value corresponding to the operation instruction type field.

[0195] If the matching retrieval in step S511 is successful, meaning the operation instruction type is one of the permissions granted to the user, the gateway retrieves the final permission quantification value P_final corresponding to the operation instruction type field (i.e., permission type code) from the real-time authorized permission set. For example, after a successful match, the P_final value corresponding to the "FILE_READ" permission is 85.

[0196] Step S513: Compare the final permission quantification value with the operation resource scale quantification value indicated by the operation parameter content field. If the final permission quantification value is less than the operation resource scale quantification value, it is determined that the current business operation exceeds the authorized permission range.

[0197] The gateway then parses the operation parameter content field in the subsequent business operation request data packet. For file download operations, this field may contain the requested file size. The gateway needs to compare this size value with the permission quantification value obtained in step S512. However, the two have different units: one is an abstract permission value (e.g., 85), and the other is a specific file size (e.g., 1024MB). To make the comparison, the gateway needs to quantize the operation resource scale as well. For example, the system can preset a mapping rule to map different file sizes to a quantization range of 0-100: small files (0-100MB) correspond to a quantization value of 20, large files (100-1000MB) correspond to a quantization value of 50, and very large files (>1000MB) correspond to a quantization value of 90. Based on the requested file size of 1024MB, the gateway finds the operation resource scale quantization value to be 90. Then, it compares the permission quantization value of 85 with the operation resource scale quantization value of 90. Since 85 < 90, the gateway determines that although the user has the "FILE_READ" permission, its permission level (85) is insufficient to support downloading a very large file with a size of 90. Therefore, the current business operation exceeds the scope of the authorized permissions.

[0198] Step S514: When it is determined that the current business operation exceeds the authorized scope, the policy execution gateway generates an operation blocking instruction and embeds the operation blocking instruction into the response message corresponding to the subsequent business operation request data packet.

[0199] Based on the determination result of step S513, the gateway no longer forwards the operation request to the backend server, but directly generates an operation blocking instruction. This operation blocking instruction is an internal control message. The gateway constructs a response message for the operation request and embeds this operation blocking instruction into a specific field or payload of the response message. For example, in an HTTP response, "{"status": "blocked", "reason": "insufficient permission for resource size"} can be added to the payload in JSON format.

[0200] Step S515: Send a response message carrying the operation blocking instruction back to the communication session initiator to interrupt the current service operation execution process of the communication session initiator.

[0201] The gateway sends the response message, which carries the operation blocking instruction and was constructed in step S514, back to the initiating terminal along the original path. Upon receiving the message, the initiating terminal parses the blocking instruction, thereby stopping the current file download operation and displaying a permission deficiency warning to the user. This achieves real-time, dynamic, and fine-grained control over specific user operations during the session, rather than just static access control at session establishment.

[0202] Step S516: Simultaneously, record the event that the operation exceeded the authorized scope in this operation and write it into the preset operation behavior audit database, generating a security audit log entry containing the initiator's network protocol address, operation instruction type field, operation resource scale quantification value, and excess permission quantification difference.

[0203] While generating the blocking command, the gateway is also responsible for recording audit logs. It creates a new log entry that combines the following information: the initiating network protocol address (IPv4 or IPv6 address), the requested operation command type field (such as "OP_FILE_DOWNLOAD"), the calculated operation resource size quantization value (such as 90), and the excess permission quantization difference, which can be calculated by subtracting the permission quantization value from the operation resource size quantization value (such as 90-85=5).

[0204] Step S517: Send the response message carrying the operation blocking instruction back to the communication session initiator to interrupt the current service operation execution process of the communication session initiator.

[0205] The policy enforcement gateway sends the response message, carrying the operation blocking instruction constructed in step S514, back to the communication session initiating terminal device via the communication network access layer, following the return path formed by the source IP address and source port number parsed from the original service operation request data packet. This response message is encapsulated into TCP or UDP data segments at the transport layer, into IPv4 or IPv6 data packets at the network layer, and into Ethernet frames at the data link layer, finally being transmitted to the initiating end via the physical layer. Upon receiving the response message, the initiating terminal's network protocol stack decapsulates it layer by layer, extracting the application layer's response data. The client application on the terminal parses this response data, identifies the embedded operation blocking instruction, and immediately stops the current file download operation, displaying a corresponding insufficient permissions message on the user interface. Thus, the service operation exceeding the authorized scope is successfully blocked, ensuring the security of core data resources.

[0206] Step S518: Simultaneously, record the event that exceeds the authorized scope of this operation in the preset operation behavior audit database, and generate a security audit log entry containing the initiator network protocol address, operation instruction type field, operation resource scale quantification value, and excess permission quantification difference.

[0207] While generating blocking instructions and sending response messages, the audit module of the policy enforcement gateway performs log recording operations in parallel. The audit module first extracts the initiating network protocol address (IPv4 or IPv6 address) from subsequent business operation request packets. Next, it extracts the operation instruction type string, such as "OP_FILE_DOWNLOAD," from the operation instruction type field. Then, it obtains the calculated operation resource scale quantization value from step S513 (e.g., 90 for mapping a 1024MB file) and the calculated excess permission quantization difference, which is obtained by subtracting the permission quantization value from the operation resource scale quantization value (90 minus 85 equals 5). The audit module then assembles these four core data items, along with the current system timestamp, session identifier, and other information, into a structured log entry according to a predefined log format. This security audit log entry is then written to a pre-defined operation behavior audit database via a secure data transmission channel. This operation behavior audit database serves as a centralized log storage and analysis platform.

[0208] For example, in step S610: the generation timestamp field of the real-time authorization permission set is obtained through the policy execution gateway, and the generation timestamp field is compared with the preset permission refresh time period threshold.

[0209] After sending the real-time authorized permission set back to the policy enforcement gateway, this method includes an optional periodic permission refresh step to ensure the timeliness of authorization. The policy enforcement gateway caches the real-time authorized permission set and also stores its associated generation timestamp field. This timestamp precisely records the moment the permission set was calculated and generated in the dynamic permission arbitration logic model. The gateway internally maintains a timer that periodically triggers permission timeliness checks. During each check, the gateway obtains the current system time and calculates the time interval difference between it and the stored generation timestamp field. This difference is compared with a preset permission refresh period threshold in seconds, denoted as T_refresh.

[0210] Step S611: If the time interval between the generated timestamp field and the current system time is greater than the permission refresh time period threshold, the policy execution gateway is triggered to send a permission refresh request signaling to the dynamic permission arbitration logic model, so that after the dynamic permission arbitration logic model receives the permission refresh request signaling, it can re-obtain the current original access request message of the communication session initiator from the policy execution gateway.

[0211] If the comparison result in step S610 is that the time interval difference is greater than T_refresh, it means that the currently cached permission set has expired and needs to be refreshed. The policy enforcement gateway immediately constructs a permission refresh request signaling. This permission refresh request signaling is an internal control protocol data unit containing a session identifier used to uniquely identify the communication session. The gateway sends this permission refresh request signaling to the dynamic permission arbitration logic model. After receiving this signaling, the dynamic permission arbitration logic model recognizes that this is a permission refresh request and then initiates a reverse request to the policy enforcement gateway, requesting to reacquire the latest original access request message associated with the session and sent by the initiator. After receiving the reverse request, the policy enforcement gateway retrieves the latest original access request message sent by the initiator of the communication session from its cache or by recapture and sends it to the dynamic permission arbitration logic model.

[0212] Step S612: Perform protocol parsing processing on the reacquired current original access request message to extract the updated initiator digital identity certificate file and the updated description text of the set of operation permissions granted in the request.

[0213] After receiving the current original access request message resent by the policy enforcement gateway, the dynamic permission arbitration logic model repeats the same message parsing processing logic as step S120. The model strips the MAC and IP layer headers from the message, extracts the transport layer payload data segment, and re-parses two key updated pieces of information from the application layer data: the first is the updated initiator's digital identity certificate file, which may differ from the previous one due to certificate updates, revocations, or other reasons; the second is the updated description text of the requested set of operation permissions, which reflects the latest operation request that the initiator wishes to execute at the current moment.

[0214] Step S613: Re-execute the certificate chain validity verification operation based on the updated initiator digital identity certificate file to obtain the updated identity credibility score; re-analyze the initiator's historical operation behavior records based on the updated request-granted operation permission set description text and associated with the access frequency anomaly score value to obtain the updated functional conflict intensity coefficient; combine the updated identity credibility score and the updated functional conflict intensity coefficient into an updated access risk comprehensive measurement vector.

[0215] Based on the updated information extracted in step S612, the dynamic permission arbitration logic model re-executes the complete risk assessment process. First, based on the updated initiator's digital identity certificate file, steps S141 to S1411 and optional steps S210 to S218 are repeated to perform certificate chain verification and online status checks, calculating an updated identity credibility score. Second, based on the updated description text of the requested set of granted operation permissions, and combined with the abnormal access frequency score calculated and stored in steps S310 to S317, steps S1412 to S14112 and optional steps S310 to S317 are repeated to re-analyze the initiator's historical operation records, calculating an updated functional conflict intensity coefficient. Finally, these two updated scores and coefficients are combined in the same manner as in step S140 to form an updated comprehensive access risk measurement vector.

[0216] Step S614: The real-time permission synthesizer repositions the permission scaling factor based on the updated access risk comprehensive metric vector, and performs dynamic offset correction processing on the static permission allocation list to obtain the updated real-time authorization permission set.

[0217] The dynamic permission arbitration logic model inputs the updated access risk comprehensive metric vector generated in step S613 into the real-time permission synthesizer. The real-time permission synthesizer repeats all the logic from steps S151 to S1511, reloading the permission adjustment coefficient mapping table, locating the new target row and column indices based on the new risk vector, and obtaining the new permission scaling factor floating-point value K_factor_new. Then, it iterates through the static permission allocation list again, multiplies each base permission quantization value P_base by K_factor_new, and performs upper and lower limit truncation processing, finally generating a brand new updated real-time authorization permission set for the current refresh time.

[0218] Step S615: Send the updated real-time authorization permission set back to the policy execution gateway to replace the original real-time authorization permission set on the policy execution gateway.

[0219] The dynamic permission arbitration logic model transmits the updated real-time authorization permission set generated in step S614 back to the policy enforcement gateway via the network. Upon receiving the updated set, the policy enforcement gateway locates the original real-time authorization permission set record corresponding to the session in its local cache and performs an atomic replacement operation with the newly received set. From then on, the policy enforcement gateway will use this updated, more timely permission set to perform access control and decision-making for subsequent business operation requests initiated by the communication session initiator, thereby achieving dynamic and periodic updates of authorization permissions and ensuring that access control policies can adapt to changes in identity status, behavioral patterns, and risk environment in real time. Figure 2 This application illustrates a dynamic access control system 100 for communication information security, comprising a processor 1001, a memory 1003, and program code stored in the memory 1003. The processor 1001 executes the program code to implement the steps of the dynamic access control method for communication information security. The processor 1001 and the memory 1003 are connected, for example, via a bus 1002. Optionally, the dynamic access control system 100 may further include a transceiver 1004, which can be used for data interaction between this dynamic access control system and other dynamic access control systems for communication information security, such as sending and / or receiving data. It should be noted that in actual scheduling, the transceiver 1004 is not limited to one, and the structure of this dynamic access control system 100 does not constitute a limitation on the embodiments of this application. The memory 1003 stores the program code for executing the embodiments of this application, and its execution is controlled by the processor 1001. The processor 1001 executes the program code stored in the memory 1003 to implement the steps shown in the aforementioned method embodiments.

[0220] This application provides a computer-readable storage medium storing program code, which, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0221] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application, without departing from the technical concept of this application, also fall within the protection scope of the embodiments of this application.

Claims

1. A dynamic access control method for communication information security, characterized in that, The method includes: A policy enforcement gateway is deployed at the communication network access layer. The policy enforcement gateway captures the original access request message transmitted from the communication session initiator to the communication session receiver in real time. The original access request message encapsulates the initiator's network protocol address, transport layer protocol port number, application layer service unified resource name to be accessed, and initiator's digital identity certificate file. The original access request message is parsed, the Media Access Control layer header and Internet Protocol layer header are stripped, the transport layer payload data segment is extracted, and the temporary session identifier string, the cipher suite negotiation list and the description text of the set of operation permissions requested to be granted submitted by the initiator are parsed from the transport layer payload data segment and aggregated into an initial request context object. Based on the application layer service unified resource name and the transport layer protocol port number requested, the system queries the pre-set security policy center database, and matches the basic security policy configuration unit corresponding to the current access request from the security policy center database. The basic security policy configuration unit contains a static permission allocation list and a set of function mutual exclusion constraint rules. The initial request context object and the basic security policy configuration unit are simultaneously input into the dynamic permission arbitration logic model. The certificate chain validity verification operation is performed on the digital identity certificate file of the initiating end to obtain the identity credibility score. Based on the functional mutual exclusion constraint rule set, the degree of conflict between the description text of the operation permission set granted by the request and the historical operation behavior record of the initiating end is analyzed to obtain the functional conflict intensity coefficient. The identity credibility score and the functional conflict intensity coefficient are combined into a comprehensive access risk measurement vector. The access risk comprehensive metric vector is transmitted to the real-time permission synthesizer in the dynamic permission arbitration logic model to obtain a real-time authorization permission set. The real-time authorization permission set is then sent back to the policy execution gateway. The policy execution gateway generates a corresponding access allow response message or access deny response message based on the real-time authorization permission set and forwards it to the communication session initiator.

2. The dynamic access control method for communication information security according to claim 1, characterized in that, Performing a certificate chain validity verification operation on the initiating digital identity certificate file to obtain an identity trustworthiness label specifically includes: Extract the initiating digital identity certificate file from the initial request context object, perform certificate chain hierarchical splitting on the initiating digital identity certificate file, and parse out the root certificate node, intermediate certificate node and terminal entity certificate node according to the subordinate relationship of the certificate issuing authority; Extract the certificate subject name field, certificate issuer name field, certificate validity start time field, certificate validity end time field, and certificate signature value field from the terminal entity certificate node; Extract the intermediate certificate issuer name field, the intermediate certificate subject public key information field, and the intermediate certificate signature value field from the intermediate certificate node; Extract the root certificate issuer name field, the root certificate subject public key information field, and the root certificate self-signature value field from the root certificate node; Access the pre-set root certificate trust anchor repository, obtain the trust anchor public key that matches the root certificate issuer name field from the root certificate trust anchor repository, use the trust anchor public key to decrypt the root certificate self-signature value field to obtain the root certificate original hash value, and at the same time perform a hash operation on the certificate content body of the root certificate node to obtain the root certificate calculated hash value. The original hash value of the root certificate is compared bit by bit with the calculated hash value of the root certificate. If the two are completely consistent, the root certificate node is determined to have passed the self-signature verification and a valid root certificate flag is generated. The original hash value of the intermediate certificate is obtained by decrypting the signature value field of the intermediate certificate using the public key information field of the root certificate body, and the calculated hash value of the intermediate certificate is obtained by hashing the certificate content body of the intermediate certificate node. The original hash value of the intermediate certificate is compared bit by bit with the calculated hash value of the intermediate certificate. If the two are completely consistent, the intermediate certificate node is determined to have passed the issuance signature verification and an intermediate certificate valid flag is generated. The signature value field of the terminal entity certificate node is decrypted using the public key information field of the intermediate certificate body to obtain the original hash value of the terminal certificate. At the same time, the certificate content body of the terminal entity certificate node is hashed to obtain the calculated hash value of the terminal certificate. The original hash value of the terminal certificate is compared bit by bit with the calculated hash value of the terminal certificate. If the two are completely consistent and the current system time is within the time interval formed by the certificate's valid start time field and the certificate's valid end time field, then the terminal entity certificate node is determined to have passed the validity verification, and a terminal certificate valid flag is generated. The identity trustworthiness label is generated based on the logical AND operation result of the root certificate valid flag bit, the intermediate certificate valid flag bit, and the terminal certificate valid flag bit. If all certificate nodes obtain valid flag bits, the identity trustworthiness label is set to the identity fully trustworthy identifier. If any level certificate node is missing a valid flag bit, the identity trustworthiness label is set to the identity untrustworthy identifier.

3. The dynamic access control method for communication information security according to claim 1, characterized in that, Based on the set of functional mutual exclusion constraint rules, the degree of conflict between the description text of the requested set of operation permissions and the historical operation records of the initiating end is analyzed to obtain the functional conflict intensity coefficient, which specifically includes: Retrieve a set of historical operation behavior records associated with the network protocol address of the initiating end from the preset operation behavior audit database. The set of historical operation behavior records contains multiple historical operation log entries. Each historical operation log entry records the operation initiation time, the name of the operation target resource, the operation permission type code, and the operation execution result status. The historical operation behavior record set is sorted on a timeline, and a time sequence of the historical operation behavior of the initiating end is constructed according to the ascending order of the operation initiation time. Extract the nearest operation permission type code contained in the nearest neighbor operation log entry from the historical operation behavior time series; Parse the current request permission type encoding list attached to this request from the description text of the set of operation permissions granted in the request; The number of permission type codes that co-occur between the current request permission type code list and the recent operation permission type code is counted, and the number of co-occurring permission type codes is used as the first conflict calculation factor. Obtain the set of functional mutual exclusion constraint rules embedded in the basic security policy configuration unit. The set of functional mutual exclusion constraint rules contains multiple functional mutual exclusion constraint rule entries. Each functional mutual exclusion constraint rule entry consists of a mutual exclusion role group identifier and a blacklist of permission type codes within the mutual exclusion role group. Each functional mutual exclusion constraint rule entry is sequentially traversed. For the current functional mutual exclusion constraint rule entry, the permission type code blacklist within the mutual exclusion role group in the current functional mutual exclusion constraint rule entry is extracted. Detect whether the current request permission type code list contains any two or more permission type codes from the permission type code blacklist simultaneously; When it is detected that the current request permission type code list contains at least two permission type codes from the permission type code blacklist, it is determined that the current request violates the current function mutual exclusion constraint rule entry, and a rule violation indicator is generated for the current function mutual exclusion constraint rule entry; The rule violation indicators of all functional mutual exclusion constraint rule entries are accumulated and counted to obtain the total number of rule violations, which is used as the second conflict calculation factor. The first conflict calculation factor and the second conflict calculation factor are subjected to normalized weighted fusion processing. The first conflict calculation factor is mapped to a first numerical interval to obtain a first normalized value, and the second conflict calculation factor is mapped to a second numerical interval to obtain a second normalized value. The first normalized value and the second normalized value are weighted and summed to obtain the functional conflict intensity coefficient.

4. The dynamic access control method for communication information security according to claim 1, characterized in that, The access risk comprehensive metric vector is transmitted to the real-time permission synthesizer in the dynamic permission arbitration logic model to obtain a real-time authorized permission set, specifically including: The pre-established permission adjustment coefficient mapping table is loaded from the local storage area of ​​the real-time permission synthesizer. The row index of the permission adjustment coefficient mapping table is composed of the value type of the identity trust level label, and the column index of the permission adjustment coefficient mapping table is composed of the value range of the functional conflict intensity coefficient. Each table entry cell of the permission adjustment coefficient mapping table stores the permission scaling factor value corresponding to the row index and the column index. The identity credibility score contained in the comprehensive access risk metric vector is analyzed, and the specific value of the identity credibility score is compared sequentially with the boundary values ​​of multiple preset identity credibility score intervals to determine the target row index position to which the identity credibility score belongs. The functional conflict intensity coefficient contained in the access risk comprehensive measurement vector is parsed synchronously. The specific value of the functional conflict intensity coefficient is compared sequentially with the boundary values ​​of multiple preset functional conflict intensity intervals to determine the target column index position to which the functional conflict intensity coefficient belongs. Based on the target row index position and the target column index position, locate the corresponding target permission scaling factor value in the permission adjustment coefficient mapping table, and extract the specific target permission scaling factor floating-point value from the target permission scaling factor value; A static permission allocation list is extracted from the basic security policy configuration unit. The static permission allocation list contains multiple baseline permission entries. Each baseline permission entry consists of a permission type encoding field and a corresponding baseline permission value field. The baseline permission value field is preset to a fixed permission openness quantification value. Iterate through each baseline permission entry in the static permission allocation list. For the current baseline permission entry that is currently being iterated over, obtain the baseline permission quantization value stored in the baseline permission value field of the current baseline permission entry. The benchmark permission quantization value is multiplied by the target permission scaling factor floating-point value to obtain the real-time intermediate calculation quantization value of the current benchmark permission entry. The real-time intermediate calculated quantized value of the permission is compared with the preset upper limit threshold of the permission value. If the real-time intermediate calculated quantized value of the permission is greater than the upper limit threshold of the permission value, then the upper limit threshold of the permission value is used as the final quantized value of the current baseline permission entry. The real-time intermediate calculated quantized value of the permission is compared with the preset lower limit threshold of the permission value. If the real-time intermediate calculated quantized value of the permission is less than the lower limit threshold of the permission value, then the lower limit threshold of the permission value is used as the final quantized value of the current baseline permission entry. When the real-time permission intermediate calculation quantization value is within the closed interval formed by the lower limit threshold of the permission value and the upper limit threshold of the permission value, the real-time permission intermediate calculation quantization value is directly used as the final permission quantization value of the current baseline permission entry. Collect the permission type encoding fields of all baseline permission entries and the final permission quantization value corresponding to each permission type encoding field. Encapsulate the permission type encoding fields and the final permission quantization values ​​in pairs to generate a real-time authorization permission set.

5. The dynamic access control method for communication information security according to claim 1, characterized in that, The policy execution gateway generates a corresponding access-allow response message or access-deny response message based on the real-time authorization permission set and forwards it to the communication session initiator. Specifically, this includes: The policy execution gateway receives the real-time authorization permission set returned by the dynamic permission arbitration logic model, performs data structure parsing on the real-time authorization permission set, and extracts all permission type encoding fields and corresponding final permission quantification values ​​contained in the real-time authorization permission set. Iterate through each permission type encoding field sequentially. For the current permission type encoding field, obtain the final permission quantization value corresponding to the current permission type encoding field. The final permission quantization value is compared with a preset permission activation determination threshold. If the final permission quantization value is greater than or equal to the permission activation determination threshold, the permission entry indicated by the current permission type encoding field is determined to be in an active state, and a permission activation status flag for the current permission type encoding field is generated. The final permission quantization value is compared with a preset permission activation determination threshold. If the final permission quantization value is less than the permission activation determination threshold, the permission entry indicated by the current permission type encoding field is determined to be in a suppressed state, and a permission suppression state flag for the current permission type encoding field is generated. Collect all permission type encoding fields marked as active and construct the final list of allowed permission type encodings for this access request; Collect all permission type encoding fields marked with the suppressed status flag, and construct the final denied permission type encoding list for this access request; The total number of entries in the permission type code field of the final allowed permission type code list is counted, and the total number of entries is compared with a zero value. If the total number of entries is greater than zero, it is determined that an access allow response message needs to be generated. If the total number of entries is equal to zero, it is determined that an access deny response message needs to be generated. When it is determined that an access permission response message needs to be generated, an access permission response message template is constructed based on the transport layer protocol port number in the original access request message, and a predefined access success status identifier is filled into the protocol status code field of the access permission response message template. The final allowed permission type encoding list is embedded in the extended option field of the access allow response message template. The final allowed permission type encoding list is converted into byte stream data blocks according to the encoding rules corresponding to the transport layer protocol port number. The byte stream data blocks are then filled into the payload area of ​​the access allow response message template. When it is determined that an access denial response message needs to be generated, an access denial response message template is constructed based on the transport layer protocol port number in the original access request message, and a predefined access failure status identifier is filled into the protocol status code field of the access denial response message template. The final denial permission type encoding list is embedded in the extended option field of the access denial response message template. The final denial permission type encoding list is converted into byte stream data blocks according to the encoding rules corresponding to the transport layer protocol port number. The byte stream data blocks are then filled into the payload area of ​​the access denial response message template. The generated access-allow response message or access-deny response message is forwarded to the communication session initiator through the communication network access layer, thus completing this dynamic access control operation process.

6. The dynamic access control method for communication information security according to claim 1, characterized in that, After obtaining the identity trustworthiness label by performing certificate chain validity verification on the initiating digital identity certificate file through the dynamic permission arbitration logic model, the method further includes: Extract the authoritative information access point field from the terminal entity certificate node of the initiating digital identity certificate file. The authoritative information access point field encapsulates a certificate status online query protocol unified resource locator. A certificate status online query request data unit is constructed based on the Uniform Resource Locator (URL) of the certificate status online query protocol. The certificate serial number field and certificate issuer name field of the terminal entity certificate node are embedded in the certificate status online query request data unit. Send the certificate status online query request data unit to the certificate status online response server corresponding to the authoritative information access point field, and receive the certificate status online response data unit returned by the certificate status online response server; Parse the certificate status information body in the online response data unit for certificate status, and extract the certificate revocation status flag bit and the certificate revocation time point field from the certificate status information body; The certificate revocation status flag is compared with the preset certificate validity status identifier. If the certificate revocation status flag matches the certificate validity status identifier, an online status verification pass flag is generated. The certificate revocation status flag is compared with the preset certificate revocation status identifier. If the certificate revocation status flag matches the certificate revocation status identifier, an online status verification failure flag is generated. Perform a time-series analysis on the certificate revocation time point field, the certificate validity start time field, and the certificate validity end time field. If the certificate revocation time point field is located after the certificate validity start time field and before the certificate validity end time field, it is determined that the terminal entity certificate node was revoked prematurely within its validity period. The identity credibility score is corrected based on the online status verification pass flag or the online status verification failure flag. If the online status verification failure flag is obtained, the identity credibility score is adjusted to a preset untrustworthy score threshold. The corrected identity credibility score is then re-encapsulated into the access risk comprehensive measurement vector, replacing the original identity credibility score.

7. The dynamic access control method for communication information security according to claim 1, characterized in that, After analyzing the degree of conflict between the requested set of operation permissions description text and the historical operation behavior records of the initiating end based on the set of functional mutual exclusion constraint rules to obtain the functional conflict intensity coefficient, the method further includes: Extract multiple historical operation log entries associated with the name of the operation target resource from the historical operation behavior record set of the initiating end. The multiple historical operation log entries contain multiple historical access records for the same operation target resource name. The multiple historical operation log entries are reordered according to the order of operation initiation time to generate a target resource operation timeline trajectory for the target resource name of the operation. Extract the time interval value between two consecutive adjacent historical access records from the target resource operation time sequence trajectory, and compare the time interval value with a preset frequent access time threshold; If the time interval value is less than the frequent access time threshold, it is determined that the initiating end has frequent access behavior to the target resource name of the operation, and a frequent access marker is generated. The number of times the time interval between all adjacent historical access records in the target resource operation time sequence trajectory is less than the frequent access time threshold is counted to obtain the cumulative value of frequent access frequency. The cumulative value of frequent access frequency is compared with a preset abnormal access frequency threshold. If the cumulative value of frequent access frequency is greater than the abnormal access frequency threshold, an abnormal access frequency warning sign is generated. Based on the comparison between the cumulative value of frequent access frequency and the threshold value of abnormal access frequency, an abnormal access frequency score is calculated; the abnormal access frequency score is then weighted and fused with the functional conflict intensity coefficient to correct the functional conflict intensity coefficient; wherein, the weight of the weighting and fusion is dynamically determined according to the identity credibility score. The revised functional conflict intensity coefficient is re-encapsulated into the comprehensive access risk metric vector.

8. The dynamic access control method for communication information security according to claim 1, characterized in that, Before the real-time permission synthesizer calls the pre-established permission adjustment coefficient mapping table to perform dynamic offset correction processing on the preset baseline permission entries in the static permission allocation list, the method further includes: Extract multiple mutually exclusive role group identifiers associated with the functional mutual exclusion constraint rule set from the basic security policy configuration unit. Each mutually exclusive role group identifier corresponds to a set of mutually exclusive permission type encoding blacklists. Parse the role attribute field in the initiator's digital identity certificate file, and extract the list of current role group identifiers to which the initiator belongs from the role attribute field; Perform an intersection operation between the current role group identifier list and the multiple mutually exclusive role group identifiers, and detect whether the current role group identifier list contains two or more role group identifiers belonging to the same mutually exclusive role group identifier. When it is detected that the current role group identifier list contains two or more role group identifiers belonging to the same mutually exclusive role group identifier, the role assignment of the initiating end is determined to violate the role mutual exclusion constraint rule, and a role assignment conflict flag is generated. Input the role assignment conflict flag into the real-time permission synthesizer to trigger the real-time permission synthesizer to call the preset conflict permission zeroing processing program; The conflict permission zeroing process iterates through each base permission entry in the static permission allocation list and forces the base permission value field corresponding to the permission type encoding field associated with the mutual exclusion role group identifier to a zero value. The static permission allocation list, after being zeroed out, is used as the input to the real-time permission synthesizer, replacing the original static permission allocation list in the dynamic offset correction process.

9. The dynamic access control method for communication information security according to claim 1, characterized in that, After the policy execution gateway generates the corresponding access allow response message or access deny response message based on the real-time authorization permission set and forwards it to the communication session initiator, it also includes: The policy execution gateway captures the subsequent service operation request data packets initiated by the communication session initiator after obtaining the access permission response message. The subsequent service operation request data packets are encapsulated with an operation instruction type field and an operation parameter content field. The operation instruction type field is extracted from the subsequent business operation request data packet, and the operation instruction type field is matched and retrieved with the permission type encoding field in the real-time authorization permission set; If the operation instruction type field exists in the permission type encoding field of the real-time authorization permission set, then obtain the final permission quantification value corresponding to the operation instruction type field; The final permission quantification value is compared with the operation resource scale quantification value indicated by the operation parameter content field. If the final permission quantification value is less than the operation resource scale quantification value, it is determined that the current business operation exceeds the authorized permission range. When it is determined that the current business operation exceeds the authorized scope, the gateway generates an operation blocking instruction through the policy execution and embeds the operation blocking instruction into the response message corresponding to the subsequent business operation request data packet; The response message carrying the operation blocking instruction is sent back to the communication session initiator to interrupt the current service operation execution process of the communication session initiator. At the same time, the event record of this operation exceeding the authorized scope will be written to the preset operation behavior audit database, generating a security audit log entry containing the initiator's network protocol address, operation instruction type field, operation resource scale quantification value, and excess permission quantification difference.

10. A dynamic access control system for communication information security, characterized in that, The method includes a processor and a computer-readable storage medium storing machine-executable instructions that, when executed by the processor, implement the dynamic access control method for communication information security as described in any one of claims 1-9.

Images