ABAC strategy intelligent mining method for high-speed rail data scene

Abstract

The invention discloses an ABAC strategy intelligent mining method for a high-speed rail data scene, and belongs to the technical field of access control. Comprising the steps of obtaining an access log sample of a high-speed rail business system; according to the access decision labels of the access log samples, the access log samples are clustered, and a permission cluster and a rejection cluster are obtained; generating a permission strategy set based on the attribute with the highest occurrence frequency in the permission cluster; generating a rejection strategy set based on the discriminative power score of the attribute in the rejection cluster and the intra-cluster coverage; and processing the permission policy set and the rejection policy set according to the inclusion relation between the two policies to obtain an ABAC policy set. According to the method, the complex access control requirement in the high-speed rail industry can be effectively met, the cost of manual labeling is reduced, meanwhile, the high efficiency and accuracy of a strategy are ensured, and therefore the safety and management convenience of a high-speed rail data system are improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of access control, and particularly relates to an ABAC policy intelligent mining method for a high-speed rail data scene. BACKGROUND

[0002] With the continuous improvement of the informatization degree of the high-speed rail industry, complex business systems involving dispatching, equipment monitoring, passenger service and other fields have gradually formed, and the demand for data access control is increasing. The traditional role-based access control (RBAC) method cannot meet the complex and variable business needs of the high-speed rail industry due to its shortcomings in fine-grained control and dynamic adaptation. Therefore, attribute-based access control (ABAC) emerged as the times require, as a more flexible and fine-grained access control method, which can define access policies based on user, resource, environment and other attributes, and gradually becomes an important access control technology in information systems.

[0003] However, existing ABAC automatic mining methods either rely on human experience and are prone to omissions and high costs, or rely too much on log analysis and lack of negative attribute policy mining, resulting in incomplete generated policies. In addition, the size and complexity of the policy often expand with the increase of business needs, and the conflict and redundancy problems are serious, making maintenance difficult and difficult to adapt to the complex data access control needs of the high-speed rail industry. SUMMARY

[0004] The purpose of the embodiments of the application is to provide an ABAC policy intelligent mining method for a high-speed rail data scene, which can solve the problems existing in the background art.

[0005] In order to solve the above technical problems, the application is implemented as follows: In a first aspect, the embodiments of the application provide an ABAC policy intelligent mining method for a high-speed rail data scene, comprising: obtaining an access log sample of a high-speed rail business system, the access log sample comprising a plurality of attributes, the plurality of attributes comprising an access decision label; clustering the access log sample according to the access decision label of the access log sample to obtain a permission class cluster and a rejection class cluster; generating a permission policy set based on the attribute with the highest frequency of occurrence in the permission class cluster; generating a rejection policy set based on the discriminant score of the attribute in the rejection class cluster and the intra-cluster coverage, the discriminant score representing the distinguishing ability of the attribute between the rejection class cluster and the permission class cluster, and the intra-cluster coverage representing the frequency of occurrence of the attribute in the rejection class cluster; processing the permission policy set and the rejection policy set according to the inclusion relationship between two policies to obtain an ABAC policy set.

[0006] Optionally, the access log samples are clustered according to access decision labels of the access log samples to obtain a permission cluster and a rejection cluster, comprising: According to the access decision labels of the access log samples, a distribution ratio of permission class decisions and rejection class decisions in the access log samples is determined, the access decision labels including permission class decision labels and rejection class decision labels; According to the distribution ratio of the permission class decision labels and the rejection class decision labels, k cluster centers are initialized, k being an integer greater than or equal to 2; Based on the k cluster centers, semi-supervised label-weighted K-modes clustering is performed on the access log samples to obtain the permission cluster and the rejection cluster.

[0007] Optionally, according to the distribution ratio of the permission class decision labels and the rejection class decision labels, the k cluster centers are initialized, comprising: At least one initial cluster center is assigned to the permission class decision labels, and at least one initial cluster center is assigned to the rejection class decision labels; According to the distribution ratio, the number of remaining cluster centers that the permission class decision labels and the rejection class decision labels should respectively occupy is determined, and access log samples are randomly selected from the corresponding access log samples to obtain the k initial cluster centers; A target function value of a current clustering result is calculated, the target function value representing the sum of weighted Hamming distances of all access log samples to the initial cluster centers of the clusters to which the access log samples belong, wherein the weight of the access decision label is greater than 1, and the weight of other attributes is 1; The above steps are repeated to obtain clustering results generated by multiple initialization processes; Among the clustering results generated by the multiple initialization processes, the k cluster centers are determined according to the clustering result corresponding to the result with the minimum target function value.

[0008] Optionally, based on the k cluster centers, semi-supervised label-weighted K-modes clustering is performed on the access log samples to obtain the permission cluster and the rejection cluster, comprising: The weighted Hamming distance of each access log sample to each cluster center is calculated, wherein the weight of the access decision label is greater than 1, and the weight of other attributes is 1; According to the weighted Hamming distance, each access log sample is assigned to the cluster corresponding to the nearest cluster center; For each cluster, the mode of each attribute is calculated according to the attributes of all access log samples in the cluster, as the new cluster center of the cluster; repeat the above steps until the maximum number of iterations is reached; For each cluster, calculate the distribution of access decision labels within the cluster, and determine the cluster as a permission class cluster if the proportion of permission class decision labels exceeds a preset label threshold, or as a rejection class cluster if the proportion of rejection class decision labels exceeds the preset label threshold.

[0009] Optionally, after each access log sample is assigned to the cluster corresponding to the nearest cluster center, further comprising: determine whether the access decision label of the access log sample to be assigned and the existing access log samples in the cluster to be assigned satisfy the same-cluster constraint condition; the same-cluster constraint condition is that access log samples with different access decision labels cannot exist in the same cluster; In the case that the access decision label of the access log sample to be assigned and the existing access log samples in the cluster to be assigned do not satisfy the same-cluster constraint condition, reassign the access log sample to be assigned to the cluster corresponding to the second nearest cluster center; repeat the above steps until all access log samples are assigned and satisfy the same-cluster constraint condition.

[0010] Optionally, based on the attribute with the highest frequency of occurrence in the permission class cluster, generate a permission policy set, comprising: For each permission class cluster, calculate the mode of each attribute within the permission class cluster, and the frequency of occurrence of each attribute within the permission class cluster; For each attribute within the permission class cluster, if the frequency of occurrence of the attribute exceeds a preset permission frequency threshold and the mode is not a preset missing value marker, take the attribute and the corresponding mode as an attribute value pair; Combine all attribute value pairs in the permission class cluster to obtain a permission policy; Combine the permission policies generated by all permission class clusters to obtain the permission policy set.

[0011] Optionally, based on the attribute discrimination score and the cluster coverage in the rejection class cluster, generate a rejection policy set, comprising: For each attribute within the target permission class cluster, calculate the difference between the frequency of occurrence of the attribute in the target rejection class cluster and the frequency of occurrence in all permission class clusters, and determine the difference as the discrimination score of the attribute within the rejection class cluster; According to the frequency of occurrence of the attribute within the target rejection class cluster, determine the cluster coverage of the attribute within the rejection class cluster; According to the discrimination score and the cluster coverage, calculate the comprehensive score of each attribute within the rejection class cluster; According to the comprehensive score of each attribute in the rejection class cluster, a preset number of attributes are selected from the rejection class cluster to obtain a candidate rejection strategy; For each candidate rejection strategy, the accuracy of the candidate rejection strategy is calculated, and in a case where the accuracy of the candidate rejection strategy reaches a preset rejection accuracy threshold and the number of covered access log samples reaches a minimum coverage requirement, the candidate rejection strategy is added to the rejection strategy set, and the accuracy represents the ability of the candidate rejection strategy to correctly reject access requests.

[0012] Optionally, further comprising: For each candidate rejection strategy, in a case where the accuracy of the candidate rejection strategy does not reach the rejection accuracy threshold but exceeds a preset rollback threshold, the candidate rejection strategy is retained as a supplementary strategy.

[0013] Optionally, the permission strategy set and the rejection strategy set are processed according to the inclusion relationship between two strategies to obtain an ABAC strategy set, comprising: For a first permission strategy and a second permission strategy in the permission strategy set, in a case where the attribute set of the first permission strategy is a true subset of the attribute set of the second permission strategy, the first permission strategy is retained, and the second permission strategy is deleted to obtain a processed permission strategy set; For a first rejection strategy and a second rejection strategy in the permission strategy set, in a case where the attribute set of the first rejection strategy contains the attribute set of the second rejection strategy, one of the first rejection strategy and the second rejection strategy with more attribute items is retained, and one with fewer attribute items is deleted to obtain a processed rejection strategy set; According to the principle that rejection strategies are prior to permission strategies, a strategy determination order is established between the permission strategy set and the rejection strategy set; According to the strategy determination order, the processed permission strategy set and the processed rejection strategy set are integrated to obtain the ABAC strategy set.

[0014] Optionally, after obtaining the ABAC strategy set, further comprising: Receiving an access request, the access request comprising subject attributes, resource attributes, operation attributes and environment attributes; Matching the access request with a strategy in the ABAC strategy set: In a case where the access request meets any rejection strategy in the ABAC strategy set, outputting a rejection decision for the access request; output a deny decision for the access request in a case that the access request does not satisfy any deny policy in the set of ABAC policies and does not satisfy any permit policy in the set of ABAC policies. output a deny decision for the access request in a case that the access request does not satisfy any deny policy in the set of ABAC policies and does not satisfy any permit policy in the set of ABAC policies.

[0015] The technical solutions provided by the embodiments of the present application at least bring the following beneficial effects: The present application can significantly improve the efficiency and accuracy of policy generation by automatically extracting and generating access control policies from access log samples. First, by clustering the access log samples, the permit and deny access decisions can be effectively distinguished, reducing the need for manual intervention. Second, the present application generates a set of permit policies by analyzing the most common attributes in the permit cluster, thereby ensuring that the generated policies can cover the high-frequency access patterns to the greatest extent, improving the effectiveness of the policies. At the same time, in the deny cluster, the policy is generated by combining the discriminative score of the attribute and the coverage within the cluster. Finally, by processing the inclusion relationship between the set of permit policies and the set of deny policies, the structure of the policy set is optimized, reducing the redundancy of the policies and improving the management efficiency. In summary, the present application can effectively cope with the complex access control requirements in the high-speed rail industry, reducing the cost of manual annotation while ensuring the efficiency and accuracy of the policies, thereby improving the security and management convenience of high-speed rail data systems. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is a step schematic diagram of an ABAC policy intelligent mining method for a high-speed rail data scenario provided by an embodiment of the present application; Figure 2 is a clustering initialization and clustering center selection process schematic diagram in an embodiment of the present application; Figure 3 is a semi-supervised label weighted K-modes clustering process schematic diagram in an embodiment of the present application; Figure 4 is a deny policy generation and screening process schematic diagram in an embodiment of the present application. DETAILED DESCRIPTION

[0017] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of the present application.

[0018] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described herein. In addition, "and / or" in the specification and claims indicates at least one of the connected objects, and the character " / ", generally indicates that the front and rear associated objects are in an "or" relationship.

[0019] The application embodiment provides a kind of ABAC policy intelligent mining method for high-speed rail data scene, which will be described in detail below with specific examples and its application scenarios.

[0020] Figure 1 It is one embodiment of the application to provide a kind of ABAC policy intelligent mining method for high-speed rail data scene, as shown in Figure 1 It includes: Step S11, access log samples of high-speed rail service system are acquired, and the access log samples include multiple attributes, and the multiple attributes include access decision label.

[0021] First, collect the original access log data from various business information systems in the high-speed rail industry. High-speed rail business systems include but are not limited to dispatching command systems, ticket sales systems, equipment monitoring platforms, operation and maintenance management systems, and safety detection systems. Access log records all access request events generated when high-speed rail business system runs. Each access log entry can contain: subject attribute, which refers to the user or entity related information initiating the access request, such as user identification, post role, affiliated organization, professional qualification, current shift, job level, etc.

[0022] Resource attribute, which refers to the description of the resource object being accessed, such as resource unique identifier, resource type (such as data file, business function, device interface, etc.), affiliated business area, resource sensitivity level, creation time, etc.

[0023] Operation attribute, which refers to the specific action requested to be executed, such as reading data, writing records, executing approval, deleting content, modifying configuration, etc.

[0024] Environment attribute, which refers to the context conditions when access occurs, such as time period (such as working hours, non-working hours), physical location (such as dispatch center, station site), network domain (such as intranet, extranet), team number, device status, etc.

[0025] Access decision label, which refers to the final decision result of high-speed rail business system on this access request, including "allow" or "reject".

[0026] The original access log contains a large number of irrelevant or low-value fields, and direct use will cause problems such as low data processing efficiency and model overfitting. Therefore, identify and remove those fields whose values are completely consistent in all log records. For example, some system version numbers, fixed configuration parameters, or default identifiers, these fields have no distinguishing ability for access control decisions, so they are removed. Further, through statistical analysis methods (such as value distribution evaluation, information entropy calculation), identify those fields with highly concentrated values and extremely low variation. For example, some status flags are the same value in more than 99% of the records, such fields have low information content and contribute little to policy mining, so they are excluded. Further, remove those fields that are logically or business-wise redundant. For example, when both user number and user name exist, if the name does not participate in the decision logic, only the user number is retained; for example, multiple fields represent the same semantics (such as "region code" and "region name"), and one of them can be retained. Further, for the possible null values, placeholders (such as "NULL", "N / A", "-", etc.) or abnormal filling values in the access log, they are uniformly mapped to the preset semantic label "unknown". "unknown" as a legal discrete value participates in subsequent frequency statistics and clustering calculation, avoiding the information loss caused by directly deleting missing values. At the business level, "unknown" can explicitly indicate that the attribute value is unknown, inapplicable, or not recorded at the time of access, thus more truly reflecting the complexity of the access control scenario. For example, the user "affiliated institution" field is empty in a log, which is mapped to "unknown" after the policy generation, which can be interpreted as an access situation when the institution information is unknown, enhancing the coverage and robustness of the policy.

[0027] On the basis of the cleaned access log sample, further feature selection is performed to determine which attributes should finally be used as input dimensions for policy mining. The screening criteria are based on the strength of the association between the attributes and the access decision label (allow / reject). Specifically, combining expert experience in the high-speed rail business field, identify those attributes that usually play a key role in access control policies. Calculate the mutual information, chi-square test value, or information gain ratio between each attribute value and the decision label, and retain those attributes that are significantly related to the label.

[0028] For categorical attributes, analyze the distribution difference between "allow" and "reject" under different values, and retain those attributes with obvious distribution difference. For example, if the rejection rate is significantly higher when the "operation type" is "write" than when it is "read", the attribute should be retained; otherwise, if the attribute value is almost independent of the decision label, it is removed.

[0029] After the above screening, the attribute set of the access log sample is finally determined. These attributes are all discrete classification variables (including the semanticized "unknown"), covering the four categories of subject, resource, operation and environment, and collectively constituting the feature space for subsequent semi-supervised clustering and policy generation.

[0030] Step S12, clustering the access log samples according to the access decision labels of the access log samples, to obtain the permission class cluster and the rejection class cluster.

[0031] The goal of this step is to use the existing access decision labels (i.e. "allow" or "reject") in the access log samples without relying on large-scale manual annotation, and to automatically group requests with similar access patterns into permission class clusters and rejection class clusters through improved clustering analysis methods.

[0032] In an optional implementation, step S12 specifically includes steps S121 to S123: Step S121, determining the distribution ratio of permission class decisions and rejection class decisions in the access log samples according to the access decision labels of the access log samples, the access decision labels including permission class decision labels and rejection class decision labels.

[0033] Figure 2 is a flowchart of clustering initialization and cluster center selection in an embodiment of the present application, please refer to Figure 2 Statistical analysis is performed on the access decision labels in the access log samples to determine the distribution of permission class decisions and rejection class decisions in the entire data set. Specifically, the access decision label field in the access log sample is scanned, and each record is explicitly classified as "permission" class or "rejection" class. The classification is based on the existing decision results in the log, without human intervention, fully reflecting the access control behavior in the actual business execution process. Further, the number of decisions marked as permission and the number of decisions marked as rejection in all records are counted, and the proportion of the two in the total number of records is calculated. For example, if the total number of records is one hundred thousand, of which seventy thousand are permission class decisions and thirty thousand are rejection class decisions, the proportion of permission class decisions is 70%, and the proportion of rejection class decisions is 30%.

[0034] The distribution ratio is not only a statistical indicator, but also has a profound business meaning. For example, a higher permission ratio may indicate that the system is more lenient in certain business scenarios, while a higher rejection ratio may imply strict access restrictions or abnormal access behavior. By quantifying this distribution, the actual execution of the access control policy can be better understood, and targeted guidance can be provided for the clustering process.

[0035] Step S122, initializing k cluster centers according to the distribution proportion of the permit type decision label and the reject type decision label in the access log sample, k being an integer greater than or equal to 2 According to the distribution proportion of the permit type decision and the reject type decision in the access log sample, a predetermined number of cluster centers (k) are reasonably initialized. By making full use of the existing access decision label information, it is ensured that the initial cluster centers can accurately reflect the real structure characteristics of the data set, providing a high-quality starting point for subsequent semi-supervised clustering analysis. In this way, the sensitivity of the clustering process to the random initial state is effectively reduced, and the stability and repeatability of the clustering results are improved.

[0036] In an optional embodiment, step S122 specifically comprises steps S1221 to S1225: Step S1221, assigning at least one initial cluster center to the permit type decision label, and assigning at least one initial cluster center to the reject type decision label.

[0037] At least one initial cluster center is assigned to the permit type decision label, and at least one initial cluster center is also assigned to the reject type decision label. Even if a certain decision category accounts for a small proportion in the data set (such as the reject type decision accounting for only 5%), it can still have an independent representative center in the clustering process, avoiding the risk of small category access log samples being overwhelmed by large category access log samples.

[0038] First, a random access log sample is selected from all access log samples labeled as permit type decision as the initial cluster center of the permit type, and a random access log sample is selected from all access log samples labeled as reject type decision as the initial cluster center of the reject type. These two initial centers constitute the basic part of the k cluster centers, and the remaining k minus two centers will be allocated in the subsequent steps.

[0039] Step S1222, according to the distribution proportion, determining the number of remaining cluster centers that the permit type decision label and the reject type decision label should occupy respectively, and randomly selecting access log samples from the corresponding access log samples to obtain k initial cluster centers.

[0040] In step S1222, based on the distribution proportion calculated in step S121, the allocation of the remaining cluster centers is completed, thereby constructing a complete set of k initial cluster centers: According to the distribution proportion of the license decision and the reject decision in the data set, the remaining number of cluster centers that should be occupied by the two decisions is calculated. Specifically, the total number of cluster centers k is reduced by two centers (one for each of the license and reject decisions) that have been allocated in step S1221, to obtain the remaining number of centers. Then, these remaining centers are allocated to the two decision categories according to the distribution proportion. For example, if k is equal to ten, the proportion of license decisions is 70%, and the proportion of reject decisions is 30%, then, of the remaining eight centers, the license category will obtain approximately five point six centers (rounded to six), and the reject category will obtain approximately two point four centers (rounded to two), so that the license category finally has seven centers and the reject category has three centers.

[0041] For each decision category, a corresponding number of access log samples are randomly selected from the set of access log samples belonging to the category as the initial cluster centers remaining for the category. This random selection mechanism not only ensures the representativeness of the initial centers, but also introduces the necessary diversity, which helps to explore different regions of the data space.

[0042] In step S1223, the objective function value of the current clustering result is calculated, which represents the sum of the weighted Hamming distances of all access log samples to the initial cluster centers of the clusters to which they belong, wherein the weight of the access decision label is greater than 1, and the weights of other attributes are 1.

[0043] Each access log sample is assigned to the cluster in which the initial cluster center closest to the access log sample is located. The distance calculation is based on the weighted Hamming distance, which is suitable for processing categorical attribute data in the access control scenario.

[0044] In the distance calculation process, different weights are assigned to different attributes. Specifically, the access decision label attribute is assigned a higher weight greater than 1, while the weights of other attributes remain 1. This makes the access decision label have greater influence in distance calculation, and when two access log samples are inconsistent in the access decision label, the distance between them will be significantly magnified. This effectively enhances the sensitivity of the clustering process to the access decision label, prompting access log samples with the same decision label to be more inclined to be clustered together.

[0045] The weighted Hamming distances of all access log samples to the initial cluster centers of the clusters to which they belong are calculated, and the distances are summed to obtain the objective function value of the current clustering result. This objective function value intuitively reflects the overall degree of dissimilarity of all access log samples to their cluster centers under the current initial center configuration. The smaller the objective function value, the closer the average distance of the access log samples to their cluster centers, and the higher the internal consistency of the clustering result.

[0046] It can be understood that by introducing the weighted distance metric, especially the high weight assignment to the access decision labels, the semi-supervised learning mechanism is integrated into the cluster quality assessment, so that the objective function value not only reflects the tightness of the cluster structure, but also reflects the consistency degree of the cluster result and the access decision labels.

[0047] Step S1224, repeat the above steps to obtain the clustering results generated by multiple initialization processes.

[0048] By performing the initialization process multiple times, a diversified initial cluster center configuration is generated to improve the probability of finding a high-quality initial solution. Specifically, steps S1221 to S1223 are repeatedly executed multiple times, each time generating a new set of initial cluster centers based on a different random seed, and calculating the corresponding objective function value. The number of repetitions can be configured according to the data size and processing resources. Since each initialization includes a random selection process, the initial cluster center set generated each time can be different. This diversity helps to explore different regions of the data space and avoid the clustering process from falling into a local optimal solution.

[0049] Record the complete clustering results generated by each initialization process, including the initial cluster center set, the access log sample allocation, and the corresponding objective function value.

[0050] Step S1225, among the clustering results generated by the multiple initialization processes, determine the k cluster centers according to the clustering result corresponding to the result with the minimum objective function value.

[0051] Select the optimal set of initial cluster centers from the results generated by multiple initializations as the starting point for subsequent formal clustering analysis. Specifically, compare the objective function values corresponding to all initialization results, and select the initialization result with the minimum objective function value as the optimal result. This is because the minimum objective function value means that under this initial center configuration, the total distance between the access log samples and their respective centers is the shortest, and the internal consistency of the cluster structure is the highest.

[0052] Determine the k initial cluster centers corresponding to the optimal initialization result as the final cluster center set to be used. These centers not only ensure sufficient representation of the permit class and the reject class decisions, but also reflect the distribution characteristics of the data set, while having the best initial clustering quality under the weighted distance metric.

[0053] Step S123, based on the k cluster centers, perform semi-supervised label-weighted K-modes clustering on the access log samples to obtain the permit class cluster and the reject class cluster.

[0054] On the basis of the traditional K-modes clustering algorithm, the semi-supervised learning mechanism and label weighting strategy are introduced, and the classification attribute data in the access control scene is optimized. Through the iterative optimization process, the access log samples are divided into multiple clusters with high internal consistency, and according to the access decision label distribution in the cluster, an explicit business semantic label (permission class or rejection class) is assigned to each cluster. Not only the efficient grouping of access requests is realized, but more importantly, the structured separation of permission class access mode and rejection class access mode is realized, which lays a solid foundation for subsequent differentiated policy generation.

[0055] In an optional implementation, step S123 specifically includes steps S1231 to S1235: Step S1231, the weighted Hamming distance of each access log sample to each cluster center is calculated, wherein the weight of the access decision label is greater than 1, and the weight of other attributes is 1.

[0056] Figure 3 It is a semi-supervised label weighting K-modes clustering process schematic diagram in an embodiment of the application, please see Figure 3 The similarity between each access log sample and all cluster centers is quantitatively calculated, wherein the Hamming distance is used as the similarity measurement basis. Similar to the initialization process before, in the distance calculation process, a differentiated weight allocation strategy is implemented. Specifically, a higher weight greater than one is assigned to the access decision label attribute, and the weight of all other attributes is kept as one. When two data points are inconsistent in the access decision label, their difference in distance calculation will be significantly magnified; on the contrary, when they are consistent in the access decision label, the distance calculation will focus more on the matching degree of other attributes.

[0057] For each access log sample and each cluster center, the values of their attributes are compared. For the access decision label attribute, if the values of the access log sample and the center are different, a larger distance contribution (multiplied by a weight greater than one) is generated on this attribute; for other attributes, if the values are different, a standard unit distance contribution is generated. The distance contributions on all attributes are summed to obtain the weighted Hamming distance of the access log sample to the cluster center.

[0058] Step S1232, according to the weighted Hamming distance, each access log sample is assigned to the cluster corresponding to the nearest cluster center.

[0059] Based on the weighted distance result calculated in step S1231, the sample to cluster assignment is performed: For each access log sample, compare its weighted Hamming distance to all k cluster centers, select the one with the smallest distance, and assign the sample to the cluster corresponding to the selected cluster center, ensuring that each sample is classified into the cluster that is most similar to it.

[0060] Step S1233, for each cluster, compute the mode of each attribute based on the attribute values of all samples in the cluster, and use the mode as the new cluster center of the cluster.

[0061] For each cluster, process each attribute independently, and count the distribution of the attribute values in all samples in the cluster. Select the value with the highest frequency of occurrence as the value of the attribute in the new cluster center. The mode calculation is suitable for handling categorical attributes in the access control scenario, as it does not rely on numerical calculations, but is based on the frequency statistics of the values.

[0062] In some cases, there can be multiple values of an attribute with the same highest frequency. At this time, various strategies can be used to determine the final mode value: randomly select one of the highest frequency values; or select the one that is the same as the current center value (if there is one); or consider the overall impact of all the highest frequency values.

[0063] For the missing case of the value unknown, it is considered as a legitimate categorical value participating in the mode calculation. If unknown has the highest frequency on an attribute, the new cluster center also takes the value unknown on that attribute.

[0064] Step S1234, repeat the above steps until the maximum number of iterations.

[0065] Repeat steps S1231 to S1233 to form a complete iteration cycle. In each iteration, the samples are re-assigned to the clusters corresponding to the updated cluster centers, and then the cluster centers are updated again based on the new cluster members.

[0066] A maximum number of iterations is preset as a safety guarantee to prevent the algorithm from falling into an infinite loop in some complex cases. When the number of iterations reaches the maximum value, the iteration process is terminated regardless of whether the center is stable. Alternatively, the change of the cluster center is monitored as a convergence criterion. If all attribute values of all cluster centers remain unchanged in two consecutive iterations, it indicates that the clustering result has stabilized, and the iteration process can be terminated in advance. This ensures that the algorithm stops in time when the optimal solution is reached, avoiding unnecessary computational overhead.

[0067] Step S1235, for each cluster, calculate the distribution of access decision labels within the cluster, and determine the cluster as a permission cluster if the proportion of permission decision labels exceeds a preset label threshold, or as a rejection cluster if the proportion of rejection decision labels exceeds the preset label threshold.

[0068] Step S1235 is the last stage of the clustering process, aiming to assign explicit business semantics to each cluster, distinguishing permission clusters from rejection clusters: For each cluster determined finally, count the distribution of access decision labels of all samples within the cluster, and calculate the proportions of permission decision labels and rejection decision labels appearing in the cluster.

[0069] A preset label threshold is used as the criterion for determining the cluster category. The label threshold is set to a high proportion value (such as 70% or 80%), reflecting the strict requirement for the consistency within the cluster. When the proportion of permission decision labels in a cluster exceeds the label threshold, the cluster is determined as a permission cluster; when the proportion of rejection decision labels exceeds the threshold, the cluster is determined as a rejection cluster.

[0070] For a few clusters that do not meet the above threshold conditions (i.e., no single decision label category reaches the preset threshold), they are marked as mixed clusters. Mixed clusters contain samples with complex access patterns or many boundary cases, which need special processing or further analysis.

[0071] Through the above process, each cluster not only has mathematical internal consistency, but also is assigned explicit business semantics: permission clusters represent access patterns that are usually allowed, and rejection clusters represent access patterns that are usually rejected. The explicit business semantics provides directly usable input for subsequent policy generation.

[0072] In an optional implementation, after each access log sample is assigned to the cluster corresponding to the nearest cluster center, it further includes: Step S21, determine whether the access decision label of the access log sample to be assigned and the access log samples already in the cluster to be assigned satisfy the non-clusterable constraint condition; the non-clusterable constraint condition is that access log samples with different access decision labels cannot exist in the same cluster.

[0073] The non-clusterable constraint condition is defined based on the knowledge in the field of access control, which stipulates that access log samples with different access decision labels (i.e., one is permission and the other is rejection) cannot be assigned to the same cluster.

[0074] For each access log sample to be assigned, after performing the regular nearest neighbor assignment, an additional verification process is initiated. All existing samples in the target cluster (i.e. the cluster corresponding to the nearest cluster center) are retrieved, and the distribution of access decision labels of these samples is analyzed.

[0075] The access decision label of the sample to be assigned is compared with the main access decision labels of the existing samples in the target cluster. If there are samples in the target cluster that are different from the access decision label of the sample to be assigned, and the number or proportion of these samples reaches a certain level, it is determined that the constraint condition of non-same-cluster is not met. Specifically, a strict standard can be set: as long as there is any sample in the target cluster that is different from the access decision label of the sample to be assigned, it is considered that the constraint condition is not met.

[0076] The verification process ensures that the access decision mode within each cluster remains highly consistent, either all being permission-type decisions or all being rejection-type decisions, avoiding policy ambiguity or conflict caused by mixed decisions within the cluster.

[0077] Step S22, in the case where the access decision label of the access log sample to be assigned does not meet the non-same-cluster constraint condition with the access log samples already existing in the cluster to be assigned, the access log sample to be assigned is reassigned to the cluster corresponding to the second nearest cluster center.

[0078] The weighted Hamming distance of the sample to be assigned to all other cluster centers is determined, and sorted in ascending order of distance. Then the cluster corresponding to the second nearest cluster center is selected as the new candidate target cluster.

[0079] The constraint condition verification process in step S21 is performed again for the new candidate target cluster, i.e. whether the access decision label of the sample to be assigned is consistent with the access decision labels of the existing samples in the candidate cluster. If the constraint condition is still not met, the third nearest cluster is selected, and so on, until the first cluster that meets the constraint condition is found.

[0080] Step S23, repeat the above steps until all access log samples are assigned and meet the non-same-cluster constraint condition.

[0081] The convergence target is that all access log samples are assigned to a cluster, and the non-same-cluster constraint condition is met within each cluster (i.e. all samples within each cluster have the same access decision label).

[0082] Perform multiple rounds of complete assignment, verification, and reassignment processes. In each iteration, each sample is processed in turn, and the samples that do not meet the constraint condition are reassigned. After completing one iteration, it is checked whether all samples meet the constraint condition. If not, a new iteration is started.

[0083] To improve the efficiency of iteration, various optimization strategies can be adopted: prioritizing the samples with the most serious constraint violations; processing only the samples in the changed clusters in each iteration; or setting a gradually tightening constraint tolerance, gradually increasing the degree of strict constraint enforcement. These strategies significantly accelerate the convergence process.

[0084] Through systematic iterative control, the entire clustering process can converge stably to a stable state that fully satisfies the non-same cluster constraints, laying a solid foundation for generating high-quality, conflict-free ABAC policy sets.

[0085] Step S13, generating a permission policy set based on the most frequently occurring attribute in the permission cluster.

[0086] By analyzing the attribute distribution within each permission cluster, the most representative attribute-value combination is identified based on the most frequently occurring attribute in the permission cluster, and is formalized into an executable access control policy. Not only does this achieve the transformation from data patterns to business rules, but more importantly, it ensures that the generated permission policy is highly representative, accurate, and interpretable.

[0087] In an optional implementation, step S13 specifically includes steps S131 to S134: Step S131, for each permission cluster, calculate the mode of each attribute within the permission cluster, and the frequency of each attribute within the permission cluster.

[0088] For each permission cluster, a detailed internal feature analysis is performed to identify the most representative attribute features. Specifically, for each permission cluster, the value distribution of each attribute within the cluster is analyzed independently. The number of occurrences of each attribute's all possible values within the cluster is counted, and the value with the highest number of occurrences is determined as the mode of that attribute in that cluster. The mode represents the most typical and representative value state of the attribute in the cluster, reflecting the core features of the permission access pattern.

[0089] While determining the mode, the frequency of the mode value of each attribute within the cluster is calculated. The frequency is calculated using the relative frequency method, i.e., the number of occurrences of the mode value divided by the total number of samples in the cluster, resulting in a frequency value between zero and one. The frequency value quantifies the prevalence of the attribute-value pair in the cluster, providing a basis for subsequent threshold screening.

[0090] The above analysis is performed on all attributes involved in policy generation in the cluster, including subject attributes (such as position, institution), resource attributes (such as resource type, sensitivity level), operation attributes (such as read, write), and environment attributes (such as time period, location), etc.

[0091] Step S132, for each attribute in the permission cluster, if the frequency of the attribute exceeds the preset permission frequency threshold and the mode is not the preset missing value mark, the attribute and the corresponding mode are taken as an attribute-value pair.

[0092] The frequency of the mode of each attribute is compared with the preset permission frequency threshold. The permission frequency threshold is a configurable parameter, which can be set to a higher value (such as 0.7 or 0.8), reflecting the strict requirement for policy representation. Only when the frequency of the mode of an attribute exceeds the permission frequency threshold, the attribute-value pair is considered to have sufficient representation and can be used as a component of the policy.

[0093] At the same time, it is checked whether the mode value is the preset missing value mark (unknown). If the mode of an attribute is the missing value mark, even if its frequency exceeds the permission frequency threshold, the attribute-value pair is excluded to avoid the ambiguity of the policy caused by the missing value.

[0094] Step S133, all attribute-value pairs in the permission cluster are combined to obtain a permission policy.

[0095] The high-quality attribute-value pairs screened in step S132 are combined to construct a complete and executable access control policy.

[0096] Specifically, all screened attribute-value pairs are combined in a logical "and" relationship to form a complete conditional expression. That is, only when the access request meets all the conditions specified in the policy, the policy will be triggered and a permission decision will be made.

[0097] Each generated policy is given a clear business semantics and formatted as "when [attribute 1] is [value 1] and [attribute 2] is [value 2] and..., access is allowed". This format not only conforms to the standard expression of access control policy, but also has good readability, which is convenient for administrators to understand and verify.

[0098] Thus, discrete attribute features are converted into structured business rules, realizing the conversion from data patterns to executable policies.

[0099] Step S134, all permission policies generated by the permission clusters are combined to obtain the set of permission policies.

[0100] All the permission cluster generated policies are integrated into a final set of permission policies. During the integration process, duplicate policies are detected and removed. When two or more policies have the same attribute-value combination, only one of them is kept and the coverage information of the policy (i.e. the total number of samples covered by all the duplicate policies) is recorded.

[0101] In step S14, a set of deny policies is generated based on the discriminative score of the attributes in the deny cluster and the intra-cluster coverage, where the discriminative score represents the distinguishing ability of the attribute between the deny cluster and the permission cluster, and the intra-cluster coverage represents the frequency of the attribute in the deny cluster.

[0102] Based on the discriminative score and the intra-cluster coverage of the attributes in the deny cluster, policy extraction is performed for the deny cluster. Unlike the permission policy generation, the generation of deny policies requires more stringent screening criteria and more complex evaluation mechanisms to ensure that the generated deny policies have high discriminative ability and do not excessively restrict normal access. The present application takes into account the particularity of deny decisions in access control scenarios, especially the high requirements for security and accuracy, to ensure that the generated deny policies can effectively implement the principle of least privilege in actual systems while avoiding false denial of legitimate access.

[0103] In an optional embodiment, step S14 specifically includes steps S141 to S145: In step S141, for each attribute in the target permission cluster, the difference between the frequency of the attribute in the target deny cluster and the frequency of the attribute in all permission clusters is calculated, and the difference is determined as the discriminative score of the attribute in the deny cluster.

[0104] Each attribute in the deny cluster is subjected to in-depth discriminative ability analysis to identify those attributes that can effectively distinguish between deny access and permission access.

[0105] Figure 4 is a schematic diagram of the deny policy generation and screening process in an embodiment of the present application, please refer to Figure 4 For each attribute in the target deny cluster, the frequency of the attribute in the deny cluster and the overall frequency of the attribute in all permission clusters are calculated respectively. This cross-cluster frequency comparison analysis aims to identify those attribute features that are significantly frequent in the deny scenario and relatively rare in the permission scenario.

[0106] The degree of difference between the two frequencies is quantified by a precise mathematical method. Specifically, the absolute difference or the relative ratio of the attribute frequency in the rejection cluster to the attribute frequency in the permission cluster is calculated, and the difference degree is determined as the discriminative score of the attribute in the current rejection cluster. The higher the discriminative score, the stronger the ability of the attribute to distinguish between rejection access and permission access.

[0107] Step S142, according to the frequency of the attribute in the target rejection cluster, the in-cluster coverage of the attribute in the rejection cluster is determined.

[0108] The frequency of each attribute in the target rejection cluster is calculated, that is, the proportion of the number of times the attribute takes a specific value in the cluster to the total number of samples in the cluster. The frequency of occurrence reflects the universality and representativeness of the attribute in the rejection cluster. The frequency of occurrence is standardized to convert it to a coverage score between zero and one. Coverage ensures that the selected attribute not only performs well in comparison with the permission cluster, but also has sufficient representativeness within the rejection cluster.

[0109] Step S143, according to the discriminative score and the in-cluster coverage, the comprehensive score of each attribute in the rejection cluster is calculated.

[0110] The discriminative score and the in-cluster coverage are given appropriate weights. Optionally, the discriminative score is given a higher weight because it directly reflects the core ability of the attribute to distinguish between positive and negative samples; and the in-cluster coverage is an important supplement to ensure that the selected attribute has sufficient representativeness in the rejection cluster.

[0111] The product model or the weighted sum model is used to combine the two indicators into a single comprehensive score. In the product model, the comprehensive score is equal to the product of the discriminative score and the in-cluster coverage, emphasizing the balance of the two indicators; in the weighted sum model, the comprehensive score is equal to the discriminative score multiplied by the weight plus the in-cluster coverage multiplied by the weight, allowing the relative importance of the two indicators to be adjusted according to business needs.

[0112] The comprehensive score is normalized to fall within a uniform numerical range (such as zero to one hundred), facilitating comparison and sorting between different attributes. The normalization process is based on the distribution of comprehensive scores of all attributes.

[0113] Step S144, according to the comprehensive score of each attribute in the rejection cluster, a predetermined number of attributes are selected from the rejection cluster to obtain a candidate rejection strategy.

[0114] All attributes in the target rejection cluster are sorted according to the comprehensive score from high to low to form an ordered attribute list.

[0115] The number of attributes included in each candidate rejection strategy is adaptively determined according to a preset number range (e.g., two to five attributes). The determination is based on the sample size of the cluster, the comprehensive score distribution of the attributes, and the complexity requirement of the business scenario. For a cluster with a large sample size and a clear pattern, more attributes can be selected to construct a more accurate strategy; for a cluster with a small sample size and a simple pattern, fewer attributes can be selected to construct a more general strategy.

[0116] From the ranked attribute list, the top-ranked attributes are selected, and these attributes and their mode values in the rejection class cluster are combined into a conditional expression. The expression uses a logical "and" relationship to indicate that when an access request simultaneously meets all these attribute conditions, it should be rejected.

[0117] Each candidate rejection strategy is given a clear business semantics and is formatted as "reject access when [attribute 1] is [value 1] and [attribute 2] is [value 2] and...".

[0118] Step S145, for each candidate rejection strategy, calculate the accuracy of the candidate rejection strategy, and in the case where the accuracy of the candidate rejection strategy reaches a preset rejection accuracy threshold and the number of covered access log samples reaches a minimum coverage requirement, add the candidate rejection strategy to the rejection strategy set, and the accuracy represents the ability of the candidate rejection strategy to correctly reject access requests.

[0119] For each candidate rejection strategy, calculate its accuracy indicator on the historical access log. The accuracy is defined as the proportion of the number of access requests correctly rejected by the strategy to the number of all access requests triggered by the strategy. Compare the calculated accuracy with the preset rejection accuracy threshold, and only the candidate strategy whose accuracy reaches or exceeds the threshold is considered valid.

[0120] Integrate all the verified candidate rejection strategies to form the final rejection strategy set.

[0121] In an optional implementation, it further includes: for each candidate rejection strategy, in the case where the accuracy of the candidate rejection strategy does not reach the rejection accuracy threshold but exceeds a preset fallback threshold, the candidate rejection strategy is retained as a supplementary strategy.

[0122] Set a fallback threshold lower than the rejection accuracy threshold. The fallback threshold can be configured according to the risk tolerance and strategy quality requirement of the specific business scenario, and its value is lower than the rejection accuracy threshold but still within an acceptable quality range.

[0123] When evaluating the candidate rejection strategy, if it is found that the accuracy of a certain strategy does not reach the preset main rejection accuracy threshold but exceeds the fallback threshold, a further evaluation process will be started.

[0124] For the candidate rejection strategy that reaches the fallback threshold but does not reach the primary threshold, analyze whether the candidate strategy can cover the rejection samples that other strategies fail to cover. If the strategy can handle specific rejection scenarios or edge cases, even if its overall accuracy is not high enough, it has unique reservation value.

[0125] The supplementary strategy is lower than the rejection strategy in the execution priority of the strategy. A lower priority weight is assigned to the supplementary strategy to ensure that the decision result of the primary strategy is prioritized over the supplementary strategy in the case of strategy conflict or decision-making process.

[0126] Step S15, according to the inclusion relationship between two strategies, the set of permission strategies and the set of rejection strategies are processed to obtain the ABAC strategy set.

[0127] According to the inclusion relationship between two strategies, the generated set of permission strategies and the set of rejection strategies are structurally optimized, through systematic analysis of the relationship between strategies, redundant strategies are identified and eliminated, potential strategy conflicts are solved, and a clear strategy decision sequence is established, finally forming a high-quality, conflict-free and executable ABAC strategy set. The present application takes into account the actual needs of access control policy management, especially the requirements for policy simplicity, consistency and execution efficiency, to ensure that the generated strategy set has sufficient security coverage and maintains good maintainability and execution performance.

[0128] In an optional embodiment, step S15 specifically includes steps S151 to S154: Step S151, for the first permission strategy and the second permission strategy in the set of permission strategies, if the attribute set of the first permission strategy is a true subset of the attribute set of the second permission strategy, the first permission strategy is retained and the second permission strategy is deleted to obtain the processed set of permission strategies.

[0129] All strategy pairs in the set of permission strategies are traversed, and for each pair of strategies (referred to as the first permission strategy and the second permission strategy), the relationship between their attribute sets is analyzed in detail. Check if the attribute set of the first permission strategy is a true subset of the attribute set of the second permission strategy, that is, all attribute conditions of the first strategy are contained in the second strategy, and the second strategy contains at least one additional attribute condition.

[0130] When determining the true subset relationship, the attribute-value matching principle is adopted. Only when each attribute-value pair in the first strategy can find exactly the same corresponding in the second strategy, and the second strategy contains at least one attribute-value pair that is not in the first strategy, it is confirmed as a true subset relationship.

[0131] When it is confirmed that the first permission policy is a true subset of the second permission policy, a redundancy elimination operation is performed: the first permission policy is kept, and the second permission policy is deleted. This decision is based on the following logic: the first policy, as a more specific condition set, can precisely cover specific permission scenarios; while the second policy, as a more general condition set, covers scenarios that have already been completely contained in the coverage of the first policy, thus keeping the more specific policy neither loses coverage nor simplifies the policy set.

[0132] In step S152, for the first rejection policy and the second rejection policy in the rejection policy set, if the attribute set of the first rejection policy contains the attribute set of the second rejection policy, the one with more attribute items is kept, and the one with less attribute items is deleted, to obtain a processed rejection policy set.

[0133] The inclusion relationship between each pair of policies in the rejection policy set is analyzed, especially focusing on the case where the attribute set of one policy completely contains the attribute set of another policy. Unlike permission policies, the processing of rejection policies needs to consider the special requirements of security.

[0134] When it is found that the attribute set of the first rejection policy contains the attribute set of the second rejection policy, instead of simply keeping one of them, the number of attribute items of the two policies is compared. The policy with more attribute items, i.e., the one with more specific and stricter conditions, is kept, and the policy with less attribute items is deleted. This principle is based on the principle of least privilege in the security field, and more specific rejection conditions can provide more accurate security control. Further, the number of attribute-value pairs contained in each rejection policy is counted as a quantitative indicator of policy specificity. When comparing two policies, if the number of attribute items of one policy is significantly more than the other, the policy with more attribute items is preferred. If the number of attribute items of the two policies is the same, further analysis of their coverage and business importance is performed to make a final decision.

[0135] In step S153, between the permission policy set and the rejection policy set, a policy decision order is established according to the principle that rejection policies take precedence over permission policies.

[0136] The conflict between permission policies and rejection policies is analyzed, especially those cases where both permission policies and rejection policies exist for the same or similar access patterns. This conflict analysis is based on the matching degree of attribute conditions and the relevance of business scenarios.

[0137] The basic principle of rejection policies taking precedence over permission policies is adopted to establish the policy decision order. This principle embodies the core security concept in the field of access control, i.e., when it is not determined whether an access request should be allowed, the default attitude is to reject, to prevent unauthorized access.

[0138] Step S154, according to the policy decision order, the processed permission policy set and the processed rejection policy set are integrated to obtain the ABAC policy set.

[0139] All permission policies and rejection policies are converted into a unified policy expression format, which includes the condition part of the policy (logical combination of attribute-value pairs), the decision part of the policy (allow or reject), and the metadata information of the policy, to obtain the final deployable ABAC policy set.

[0140] The ABAC policy set is output in multiple standard formats, such as XACML, OPA Rego, and other mainstream policy languages, to ensure smooth integration with existing access control systems.

[0141] In an optional implementation, after obtaining the ABAC policy set, the following steps are further included: Step S31, receiving an access request, the access request including subject attributes, resource attributes, operation attributes and environment attributes.

[0142] An access request is received from a high-speed rail business system. The access request contains attribute information of multiple dimensions, including: subject attributes (such as user post, institution, qualification, shift, etc.), resource attributes (such as resource type, region, sensitivity level, etc.), operation attributes (such as read, write, approval, etc. Operation type) and environment attributes (such as time period, location, team, network domain, etc.). These attributes together constitute the context information of the access request.

[0143] Step S32, matching the access request with the policies in the ABAC policy set.

[0144] After receiving the access request, the access request is matched one by one with the ABAC policy set generated by pre-mining. As described earlier, the ABAC policy set includes a permission policy subset and a rejection policy subset, and each policy is composed of a series of attribute conditions. The matching process is completed by comparing the values of the attributes in the access request with the attribute conditions specified in the policy. Specifically, for each policy, the system checks whether the subject attributes of the access request meet the constraint conditions of the subject attributes in the policy, whether the resource attributes meet the constraint conditions of the resource attributes, whether the operation attributes meet the constraint conditions of the operation attributes, and whether the environment attributes meet the constraint conditions of the environment attributes. Only when all attributes of the access request completely meet all conditions specified by a policy, is the access request considered to satisfy the policy.

[0145] Step S33, output a deny decision for the access request if the access request satisfies any deny policy in the ABAC policy set.

[0146] If, in the matching process, it is detected that the current access request satisfies the condition of any deny policy in the ABAC policy set, a deny decision for the access request is immediately generated and output. The generation of the deny decision means that the access request is explicitly prohibited by the system, regardless of whether it also satisfies the condition of some permit policy, embodying the "deny first" principle in access control, that is, once a request is identified as potentially dangerous or not in compliance with security regulations, it is directly denied without further checking of permit policies.

[0147] After the deny decision is output, the denial event can be recorded for subsequent auditing or policy optimization. This step effectively prevents unauthorized access and security vulnerabilities, improving the overall security of the system.

[0148] Step S34, output a permit decision for the access request if the access request does not satisfy any deny policy in the ABAC policy set but satisfies any permit policy.

[0149] If, after completing the matching of the deny policy set, it is confirmed that the current access request does not satisfy any deny policy, the permit policy set is then checked. If the access request satisfies the conditions of at least one permit policy in the permit policy set, a permit decision for the access request is generated and output.

[0150] The permit policy is composed of positive attribute conditions, and a permit decision is only output if the request passes all deny policy checks and matches at least one permit policy, strictly implementing the principle of least privilege, that is, users can only access what they are explicitly authorized to, avoiding the risk of over-authorization.

[0151] Step S35, output a deny decision for the access request if the access request neither satisfies any deny policy in the ABAC policy set nor satisfies any permit policy in the ABAC policy set.

[0152] If, after checking all deny policies and permit policies, it is confirmed that the current access request neither satisfies any deny policy nor satisfies any permit policy, a deny decision for the access request is generated and output. This embodies the default deny principle in access control, that is, unless a request is explicitly allowed, it is always denied. Default denial is a basic security measure in the field of information security, which can effectively deal with unforeseen access scenarios, newly emerging attribute values, or insufficient policy coverage, ensuring that the system remains conservative and secure when facing unknown requests.

[0153] The present application can significantly improve the efficiency and accuracy of policy generation by automatically extracting and generating access control policies from access log samples. First, by clustering the access log samples, the permission class and the rejection class access decisions can be effectively distinguished, reducing the need for human intervention. Second, the present application generates a set of permission policies by analyzing the most common attributes in the permission cluster, thereby ensuring that the generated policies can cover the high-frequency access patterns to the greatest extent, improving the effectiveness of the policies. At the same time, in the rejection cluster, the attribute discriminant score and the cluster coverage are combined to generate policies. Finally, by processing the inclusion relationship between the permission policy set and the rejection policy set, the structure of the policy set is optimized, the redundancy of the policies is reduced, and the management efficiency is improved. In summary, the present application can effectively deal with the complex access control requirements in the high-speed rail industry, reduce the cost of manual annotation, and at the same time ensure the efficiency and accuracy of the policies, thereby improving the security and management convenience of the high-speed rail data system.

[0154] It should be noted that in this paper, the term "include", "contain" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of another identical element in the process, method, article or device including the element. In addition, it should be noted that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, but can also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method can be performed in an order different from that described, and various steps can also be added, omitted or combined. In addition, the features described with reference to certain examples can be combined in other examples.

[0155] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by means of software and the necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes a plurality of instructions for making a terminal (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) execute the methods described in various embodiments of the present application.

[0156] The embodiments of the present application are described above with reference to the accompanying drawings, but the present application is not limited to the above-described specific embodiments, and the above-described specific embodiments are merely illustrative, but not restrictive, and a person of ordinary skill in the art can make many forms under the inspiration of the present application without departing from the purpose of the present application and the scope protected by the claims, and all of them belong to the protection of the present application.

Claims

1. An ABAC policy intelligent mining method for high-speed rail data scenarios, characterized in that, The method comprises the following steps: obtaining an access log sample of a high-speed rail service system, the access log sample comprising a plurality of attributes, the plurality of attributes comprising an access decision label; performing clustering on the access log sample according to the access decision label of the access log sample to obtain a permission cluster and a rejection cluster; generating a permission policy set based on the attribute with the highest frequency of occurrence in the permission cluster; generating a rejection policy set based on the discriminant score of the attribute in the rejection cluster and the cluster coverage, the discriminant score representing the distinguishing ability of the attribute between the rejection cluster and the permission cluster, and the cluster coverage representing the frequency of occurrence of the attribute in the rejection cluster; processing the permission policy set and the rejection policy set according to the inclusion relationship between the two policies to obtain an ABAC policy set.

2. The method of claim 1, wherein, The method comprises the following steps: determining the distribution ratio of permission class decisions and rejection class decisions in the access log sample according to the access decision label of the access log sample, the access decision label comprising a permission class decision label and a rejection class decision label; initializing k cluster centers according to the distribution ratio of the permission class decision label and the rejection class decision label, k being an integer greater than or equal to 2; performing semi-supervised label-weighted K-modes clustering on the access log sample based on the k cluster centers to obtain the permission cluster and the rejection cluster.

3. The method of claim 2, wherein, The method comprises the following steps: allocating at least one initial cluster center to the permission class decision label and at least one initial cluster center to the rejection class decision label; determining the number of remaining cluster centers that the permission class decision label and the rejection class decision label should occupy respectively according to the distribution ratio, and randomly selecting access log samples from the corresponding access log samples to obtain k initial cluster centers; calculating the objective function value of the current clustering result, the objective function value representing the sum of the weighted Hamming distances from all access log samples to the initial cluster center of the cluster to which the access log sample belongs, wherein the weight of the access decision label is greater than 1, and the weight of the other attributes is 1; repeating the above steps to obtain the clustering results generated by multiple initialization processes; determining the k cluster centers according to the clustering result corresponding to the result with the minimum objective function value among the clustering results generated by the multiple initialization processes.

4. The method of claim 2, wherein, The method comprises the following steps: calculating the weighted Hamming distance from each access log sample to each cluster center, wherein the weight of the access decision label is greater than 1, and the weight of the other attributes is 1; allocating each access log sample to the cluster corresponding to the nearest cluster center according to the weighted Hamming distance; for each cluster, calculating the mode of each attribute according to the attributes of all access log samples in the cluster as the new cluster center of the cluster; repeat the above steps until the maximum number of iterations is reached; For each cluster, calculate the distribution of access decision labels within the cluster, and determine the cluster as a permission class cluster if the proportion of permission class decision labels exceeds a preset label threshold, or as a rejection class cluster if the proportion of rejection class decision labels exceeds the preset label threshold.

5. The method of claim 4, wherein, After assigning each access log sample to the cluster corresponding to the nearest cluster center, further comprising: determining whether the access decision label of the access log sample to be assigned and the existing access log samples in the cluster to be assigned satisfy the same-cluster constraint condition; the same-cluster constraint condition is that access log samples with different access decision labels cannot exist in the same cluster; in the case that the access decision label of the access log sample to be assigned and the existing access log samples in the cluster to be assigned do not satisfy the same-cluster constraint condition, reassigning the access log sample to be assigned to the cluster corresponding to the second nearest cluster center; repeat the above steps until all access log samples are assigned and satisfy the same-cluster constraint condition.

6. The method of claim 1, wherein, Based on the attribute with the highest frequency of occurrence in the permission class cluster, generate a permission policy set, including: For each permission class cluster, calculate the mode of each attribute within the permission class cluster, and the frequency of occurrence of each attribute within the permission class cluster; For each attribute within the permission class cluster, if the frequency of occurrence of the attribute exceeds the preset permission frequency threshold and the mode is not the preset missing value marker, take the attribute and the corresponding mode as an attribute value pair; Combine all attribute value pairs in the permission class cluster to obtain a permission policy; Combine the permission policies generated by all permission class clusters to obtain the permission policy set.

7. The method of claim 1, wherein, Based on the discriminant score and the cluster coverage of the attributes in the rejection class cluster, generate a rejection policy set, including: For each attribute within the target permission class cluster, calculate the difference between the frequency of occurrence of the attribute in the target rejection class cluster and the frequency of occurrence in all permission class clusters, and determine the difference as the discriminant score of the attribute within the rejection class cluster; According to the frequency of occurrence of the attribute within the target rejection class cluster, determine the cluster coverage of the attribute within the rejection class cluster; According to the discriminant score and the cluster coverage, calculate the comprehensive score of each attribute within the rejection class cluster; According to the comprehensive score of each attribute within the rejection class cluster, select a preset number of attributes from the rejection class cluster to obtain a candidate rejection policy; For each candidate rejection policy, calculate the accuracy of the candidate rejection policy, and if the accuracy of the candidate rejection policy reaches the preset rejection accuracy threshold and the number of covered access log samples reaches the minimum coverage requirement, add the candidate rejection policy to the rejection policy set, and the accuracy represents the ability of the candidate rejection policy to correctly reject access requests.

8. The method of claim 7, wherein, Further comprising: For each candidate rejection policy, if the accuracy of the candidate rejection policy does not reach the rejection accuracy threshold but exceeds the preset rollback threshold, retain the candidate rejection policy as a supplementary strategy.

9. The method of claim 1, wherein, According to the inclusion relationship between the two strategies, the permission strategy set and the rejection strategy set are processed to obtain an ABAC strategy set, including: For a first permission strategy and a second permission strategy in the permission strategy set, if the attribute set of the first permission strategy is a true subset of the attribute set of the second permission strategy, the first permission strategy is retained, and the second permission strategy is deleted to obtain a processed permission strategy set; For a first rejection strategy and a second rejection strategy in the permission strategy set, if the attribute set of the first rejection strategy contains the attribute set of the second rejection strategy, one of the first rejection strategy and the second rejection strategy with more attribute items is retained, and one with fewer attribute items is deleted to obtain a processed rejection strategy set; Between the permission strategy set and the rejection strategy set, a strategy judgment order is established according to the principle that rejection strategies are prior to permission strategies; According to the strategy judgment order, the processed permission strategy set and the processed rejection strategy set are integrated to obtain the ABAC strategy set.

10. The method of claim 1, wherein, After obtaining the ABAC strategy set, further including: An access request is received, and the access request includes subject attributes, resource attributes, operation attributes and environment attributes; The access request is matched with the strategies in the ABAC strategy set: In the case that the access request meets any rejection strategy in the ABAC strategy set, a rejection decision for the access request is output; In the case that the access request does not meet any rejection strategy in the ABAC strategy set but meets any permission strategy, a permission decision for the access request is output; In the case that the access request neither meets any rejection strategy in the ABAC strategy set nor meets any permission strategy in the ABAC strategy set, a rejection decision for the access request is output.

Images