Medical Web service multilayer dynamic protection method and system

Abstract

The invention relates to the technical field of information security, and particularly provides a medical Web service multilayer dynamic protection method and system, and the method comprises the steps: obtaining access source information, terminal equipment information and user behavior information when a user initiates a data access request; obtaining an access risk score for representing a current access risk level according to the access source information, the terminal equipment information and the user behavior information; querying a pre-constructed mapping relation table about the risk score and the risk strategy according to the risk score, so as to obtain an access permission and a data display strategy for the current data access request; performing data processing on medical data which is prepared to be returned and corresponds to the data access request according to the access permission and the data display strategy, and then sending the medical data to the user terminal; the method can effectively solve the problems that high data leakage risk events cannot be processed and medical data leaks due to the fact that real-time and dynamic data leakage risk assessment cannot be carried out.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and more specifically, to a multi-layer dynamic protection method and system for medical Web services. Background Art

[0002] Existing medical institutions typically use medical web service systems to store medical data containing large amounts of sensitive personal health information and provide users with convenient access and processing capabilities for this data. The security of existing medical web service systems primarily relies on static identity authentication and role-based access control (RBAC) or attribute-based access control (ABAC). These mechanisms only assign access rights based on user identity or pre-set attributes, but are unable to dynamically detect and assess the data leakage risk of the current access session in real time. This is due to the diversity of user access sources and terminal device types. For example, users may access from a secure and controlled hospital internal network or from uncontrolled networks such as the public network. Users may access from a high-security computer issued by the hospital or a personal laptop. These variations in user access sources and terminal device types affect data leakage risk. Furthermore, anomalous user behavior (such as accessing medical data unrelated to their responsibilities during off-hours or batch querying or downloading large amounts of patient data) may indicate a data leakage incident. Therefore, existing technologies, due to their inability to perform real-time and dynamic data leakage risk assessment, are unable to handle high-risk data leakage incidents and medical data leaks, resulting in poor security protection capabilities for medical web service systems.

[0003] There is no effective technical solution to the above problems. It should be noted that the above information disclosed in this section is only used to understand the background of the present invention, and therefore may contain information that does not constitute prior art. Summary of the Invention

[0004] The purpose of this application is to provide a multi-layer dynamic protection method and system for medical Web services, which can effectively solve the problem of medical data leakage caused by the inability to handle high data leakage risk events due to the inability to perform real-time and dynamic data leakage risk assessment.

[0005] In a first aspect, the present application provides a multi-layer dynamic protection method for medical Web services, which includes the following steps: S1. When a user initiates a data access request, obtain access source information, terminal device information, and user behavior information; S2. Obtaining an access risk score representing the current access risk level based on access source information, terminal device information, and user behavior information; S3. Query a pre-built mapping table of risk scores and risk policies based on the risk scores to obtain access rights and data display policies for the current data access request; S4. Process the medical data to be returned and corresponding to the data access request according to the access permission and data display policy, and then send the medical data to the user terminal.

[0006] The present application provides a multi-layer dynamic protection method for medical Web services, which first obtains an access risk score based on access source information, terminal device information and user behavior information, then determines the access permission and data display strategy for the current data access request based on the risk score, and finally processes the medical data to be returned and corresponding to the data access request based on the access permission and data display strategy, and sends the processed medical data to the user terminal. That is, the present application can perform real-time and dynamic data leakage risk assessment based on user access source, terminal device type and user behavior, and dynamically adjust data access permission and data display strategy based on the assessment results to effectively reduce the risk of medical data leakage. Therefore, the present application can effectively solve the problem of medical data leakage caused by the inability to handle high data leakage risk events due to the inability to perform real-time and dynamic data leakage risk assessment, thereby effectively improving the security protection capabilities of the medical Web service system.

[0007] In a second aspect, the present application also provides a multi-layer dynamic protection system for medical Web services, which includes: The information acquisition module is used to obtain access source information, terminal device information and user behavior information when a user initiates a data access request; A risk assessment module is used to obtain an access risk score representing the current access risk level based on access source information, terminal device information, and user behavior information; The policy decision module is used to query the pre-built mapping relationship table between risk scores and risk policies based on the risk scores to obtain the access rights and data display policies for the current data access request; The data processing module is used to process the medical data to be returned and corresponding to the data access request according to the access permission and data display policy, and then send the medical data to the user terminal.

[0008] The present application provides a multi-layer dynamic protection system for medical Web services, which first obtains an access risk score based on access source information, terminal device information and user behavior information, then determines the access permission and data display strategy for the current data access request based on the risk score, and finally processes the medical data to be returned and corresponding to the data access request based on the access permission and data display strategy, and sends the processed medical data to the user terminal. That is, the present application can perform real-time and dynamic data leakage risk assessment based on user access source, terminal device type and user behavior, and dynamically adjust data access permission and data display strategy based on the assessment results to effectively reduce the risk of medical data leakage. Therefore, the present application can effectively solve the problem of medical data leakage caused by the inability to handle high data leakage risk events due to the inability to perform real-time and dynamic data leakage risk assessment, thereby effectively improving the security protection capabilities of the medical Web service system.

[0009] From the above, it can be seen that the present application provides a multi-layer dynamic protection method and system for medical Web services, which first obtains an access risk score based on access source information, terminal device information and user behavior information, and then determines the access permission and data display strategy for the current data access request based on the risk score. Finally, the medical data to be returned and corresponding to the data access request is processed according to the access permission and data display strategy, and the processed medical data is sent to the user terminal. That is, the present application can perform real-time and dynamic data leakage risk assessment based on user access source, terminal device type and user behavior, and dynamically adjust data access permission and data display strategy based on the assessment results to effectively reduce the risk of medical data leakage. Therefore, the present application can effectively solve the problem of medical data leakage caused by the inability to handle high data leakage risk events due to the inability to perform real-time and dynamic data leakage risk assessment, thereby effectively improving the security protection capabilities of the medical Web service system. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 This is a flowchart of a multi-layer dynamic protection method for medical Web services provided in an embodiment of the present application.

[0011] Figure 2 A schematic diagram of the structure of a multi-layer dynamic protection system for medical Web services provided in an embodiment of the present application.

[0012] Figure numerals: 1. Information acquisition module; 2. Risk assessment module; 3. Strategy decision module; 4. Data processing module. DETAILED DESCRIPTION

[0013] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work fall within the scope of protection of the present application.

[0014] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0015] First, as Figure 1 As shown, the present application provides a multi-layer dynamic protection method for medical Web services, which includes the following steps: S1. When a user initiates a data access request, obtain access source information, terminal device information, and user behavior information; S2. Obtaining an access risk score representing the current access risk level based on access source information, terminal device information, and user behavior information; S3. Query a pre-built mapping table of risk scores and risk policies based on the risk scores to obtain access rights and data display policies for the current data access request; S4. Process the medical data to be returned and corresponding to the data access request according to the access permission and data display policy, and then send the medical data to the user terminal.

[0016] When a user initiates a data access request, step S1 will obtain access source information, terminal device information and user behavior information. That is, step S1 is equivalent to actively collecting real-time context information related to the data access request each time a data access request occurs. Specifically, the access source information of this embodiment can reflect where the data access request comes from. Since the user access sources are diverse, the user access sources will affect the data leakage risk. For example, the data leakage risk of using the hospital's internal controlled network to access data is less than the data leakage risk of using an uncontrolled environment to access data. Therefore, this embodiment can use the access source information to evaluate the data leakage risk brought by the user access source. The terminal device information of this embodiment can reflect what terminal device the user uses to access data. Since the terminal devices used by users when accessing data are also diverse, the terminal devices used when accessing data will also affect the data leakage risk. For example, the data leakage risk of using a high-security computer distributed by the hospital to access data is less than the data leakage risk of using a personal laptop to access data. Therefore, this embodiment can evaluate the data leakage risk brought by the terminal device used by the user by using the terminal device information to evaluate the security of the device itself. The user behavior information of this embodiment can reflect what behaviors the user needs to perform when performing data methods and the user's operation mode. This embodiment can evaluate the data leakage risk brought by the user behavior by analyzing whether the user's behavior or operation mode is abnormal based on the user behavior information.

[0017] The specific process of step S2 for obtaining an access risk score representing the current access risk level based on the access source information, terminal device information, and user behavior information can be as follows: querying a pre-built mapping relationship table of access source information and data leakage risk score based on the access source information to obtain the access source risk score; querying a pre-built mapping relationship table of terminal device information and data leakage risk score based on the terminal device information to obtain the device risk score; querying a pre-built mapping relationship table of user behavior information and data leakage risk score based on the user behavior information to obtain the behavior risk score; and summing the access source risk score, device risk score, and behavior risk score to obtain the access risk score representing the current access risk level. The access risk score of this embodiment can reflect the level of data leakage risk faced by the current data access. This embodiment is equivalent to integrating multiple dynamic, real-time contextual information to assess the data leakage risk, so as to perceive abnormal or high-risk data access (such as access from an untrusted network, access using an unsecured device, or abnormal user behavior), thereby effectively solving the problem that existing technologies cannot perform real-time, dynamic data leakage risk assessment.

[0018] The mapping relationship table between risk scores and risk strategies in step S3 stores risk strategies corresponding to different risk scores. The risk strategies include access permissions and data display strategies. Step S3 is equivalent to dynamically determining the specific security control measures to be taken for the current data access request based on the data leakage risk of the current data access request. For example, when the risk of data leakage is high, the access permission is set to deny access and the data display strategy is set to not display medical data. When the risk of data leakage is medium, the access permission is set to allow access to medical data within a smaller range and the data display strategy is set to display desensitized medical data. When the risk of data leakage is low, the access permission is set to allow access to medical data within a larger range and the data display strategy is set to display original medical data. Specifically, the access rights of this embodiment refer to the level of access granted to the user to the requested data, which may include intermediate levels such as full access, denied access, or read-only. The data display strategy of this embodiment refers to the way of presenting the requested data to the user, which may include displaying desensitized data, fully displaying the original data, partially shielding information, or completely hiding certain data fields. That is, this embodiment is equivalent to adjusting the visibility of medical data according to the assessed data leakage risk by determining the data display strategy based on the access risk score to ensure the security of the medical data.

[0019] The data processing in step S4 refers to the operations performed on the medical data to be returned according to the determined access rights and data display policy before the medical data requested by the user (the medical data corresponding to the data access request) is sent to the user terminal. The data processing may include filtering data, masking fields, desensitizing data, or formatting data.

[0020] The working process and principle of this application is that when a user initiates a data access request, this application obtains access source information, terminal device information and user behavior information related to the current request. This information is obtained in real time and dynamically and can reflect the context of the current data access.

[0021] After obtaining access source information, terminal device information and user behavior information, this application calculates an access risk score based on the obtained access source information, terminal device information and user behavior information to characterize the current access risk level. The access risk score can reflect the level of data leakage risk that the current data access may face, thereby realizing real-time assessment of data leakage risk based on a combination of multiple dynamic factors.

[0022] After obtaining the access risk score, this application queries the pre-built mapping relationship table of risk scores and risk policies based on the access risk score to dynamically determine the specific security control measures that should be taken for the current data access request (access rights and data display are omitted).

[0023] After determining the access rights and data display policy, this application performs corresponding data processing on the medical data to be returned and corresponding to the data access request based on the access rights and data display policy. The data processing may include operations such as filtering, desensitizing, encryption, or limiting the amount of returned data to ensure that the returned medical data complies with the access rights and data display policy corresponding to the current data leakage risk. After completing the data processing, this application sends the processed medical data to the user terminal to achieve dynamic security protection of medical data and reduce the risk of data leakage based on the data leakage risk.

[0024] As a preferred embodiment, the solution of this application is specifically implemented as follows: In a medical Web service system, when a user requests access to a patient's electronic medical record data through a browser, this embodiment obtains the access source information of the request (the IP address that issues the data access request), terminal device information (for example, the user uses a personal laptop to access data), and user behavior information (for example, the user needs to download a patient's electronic medical record data).

[0025] Next, this embodiment uses a preset risk scoring algorithm or risk assessment model to calculate an access risk score based on the access source information, terminal device information and user behavior information. For example, if the data access request comes from a high-risk IP address, the device security status is poor, and the user requests a large amount of data unrelated to his or her duties during non-working hours, the calculated access risk score will be higher.

[0026] Then, this embodiment compares and queries the calculated access risk score with a pre-built mapping relationship table of risk scores and risk policies. The mapping relationship table may define different risk levels (such as low, medium, and high) and their corresponding access rights and data display policies. For example, if the risk score belongs to the "high risk" level, the risk policy is "deny access" or "only allow access to some desensitized data". This embodiment will determine the access rights and data display policy for the current data access request based on the query results.

[0027] Finally, this embodiment processes the electronic medical record data to be returned to the user according to the access permission and data display policy, and then sends the processed medical data to the user terminal. For example, if the access permission and data display policy jointly indicate "only allow access to some desensitized data", then this embodiment will desensitize the sensitive fields in the electronic medical record (such as patient name, ID number), and then send the desensitized electronic medical record data to the user terminal or only return some non-sensitive information; if the access permission and data display policy jointly indicate "deny access", no data will be returned.

[0028] The present application provides a multi-layer dynamic protection method for medical Web services, which first obtains an access risk score based on access source information, terminal device information and user behavior information, then determines the access permission and data display strategy for the current data access request based on the risk score, and finally processes the medical data to be returned and corresponding to the data access request based on the access permission and data display strategy, and sends the processed medical data to the user terminal. That is, the present application can perform real-time and dynamic data leakage risk assessment based on user access source, terminal device type and user behavior, and dynamically adjust data access permission and data display strategy based on the assessment results to effectively reduce the risk of medical data leakage. Therefore, the present application can effectively solve the problem of medical data leakage caused by the inability to handle high data leakage risk events due to the inability to perform real-time and dynamic data leakage risk assessment, thereby effectively improving the security protection capabilities of the medical Web service system.

[0029] In some preferred embodiments, the data access request includes medical data that the user requests access to, and step S2 includes: S21, determining the type of data requested for access based on the data requested for access by the user; S22. Querying a pre-built mapping relationship table between access source information and data leakage risk scores based on the access source information to obtain an access source risk score; querying a pre-built mapping relationship table between terminal device information and data leakage risk scores based on the terminal device information to obtain a device risk score; and querying a pre-built mapping relationship table between user behavior information and data leakage risk scores based on the user behavior information to obtain a behavior risk score; S23. Querying a pre-built mapping relationship table of data types and weighted weight combinations based on the requested access data type to determine weighted weights corresponding to the access source risk score, the device risk score, and the behavior risk score; S24. Calculate an access risk score representing the current access risk level based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight.

[0030] Step S21 can utilize a pre-built classifier to determine the type of data requested based on the data requested by the user. For example, if the data requested by the user is a patient's electronic medical record, the data type determined is "patient medical record data." If the user requests access to a hospital's public research report, the data type determined is "public research data." The mapping table for data types and weighted weight combinations in this embodiment stores the weighted weights that should be used for the access source risk score, device risk score, and user behavior risk score for different data types. For example, for the "patient medical record data" type, the weighted weight corresponding to the device risk score is 0.5, the weight corresponding to the access source risk score is 0.3, and the weighted weight corresponding to the user behavior risk score is 0.2. For the "public research data" type, the weighted weight corresponding to the device risk score is 0.2, the weight corresponding to the access source risk score is 0.4, and the weight corresponding to the user behavior risk score is 0.4. In other words, step S23 is equivalent to dynamically adjusting the importance of each risk factor based on the type of data requested by the user. Step S24 can be achieved by multiplying each risk score with its corresponding weighted weight and then summing up the calculated access risk score used to characterize the current access risk level based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight. That is, the calculation formula for the access risk score is: access risk score = (access source risk score × weighted weight corresponding to the access source risk score) + (device risk score × weighted weight corresponding to the device risk score) + (behavior risk score × weighted weight corresponding to the behavior risk score). The data leakage risks faced by different types of medical data may have different emphases due to differences in access sources, terminal devices, or user behaviors. For example, accessing highly sensitive patient medical records and accessing publicly available hospital information should have different potential data leakage risk levels, even if the access sources, terminal devices, and user behaviors are the same. Furthermore, the risk contribution of different risk factors (access source, terminal device, user behavior) to different data types should also vary. Because this embodiment can first determine the weighted weights corresponding to the access source risk score, device risk score, and behavior risk score based on the requested access data type, and then calculate the access risk score based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight, this embodiment can enable the calculated access risk score to more accurately reflect the actual data leakage risk faced when accessing different types of data, thereby effectively improving the accuracy and reliability of data leakage risk assessments, and thus effectively improving the accuracy and reliability of subsequently determined access rights and data display policies.

[0031] In some preferred embodiments, step S24 includes: S241. Obtain user role information, and then query a pre-built mapping table of user roles and data access permission ranges based on the user role information to obtain the user-accessible data range; S242: Analyze whether the medical data requested by the user exceeds the user's accessible data range. If so, execute step S244; if not, execute step S243; S243. Calculate an access risk score representing the current access risk level based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight; S244. Calculate a preliminary risk score based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight; S245. Obtain a first risk score compensation amount based on the degree of deviation between the medical data requested by the user and the range of data accessible to the user, and then calculate an access risk score for representing the current access risk level based on the preliminary risk score and the first risk score compensation amount.

[0032] Step S241 can obtain user role information by querying the user role in the user management system based on the credentials provided by the user when logging in. The mapping relationship between user roles and data access permission ranges in this embodiment stores the type, range or sensitivity level of medical data (data access permission range) that different user roles (for example, doctors, nurses, administrators, patients) can access. That is, the user-accessible data range in this embodiment is the data range that the current user is authorized to access under normal circumstances. For example, for a doctor role, the data range that the doctor can access may include the medical records, examination reports, etc. of the patients he is responsible for; for a patient role, the data range that the patient can access may be limited to his own medical records.

[0033] Step S242 compares the medical data actually requested by the user with the user's accessible data range to determine whether the medical data the user requested exceeds the user's accessible data range. If so, step S244 is executed; if not, step S243 is executed to continue using the basic access risk score calculation method. Specifically, this comparative analysis may include checking whether the type of data requested, the range of patients involved, the sensitivity of the data, etc. are within the user's authorized access range (the user's accessible data range). For example, if a user in the nurse role attempts to access the detailed medical records of a patient they are not responsible for, or if a user in the patient role attempts to access the data of another patient, the medical data requested by the user is considered to exceed the user's accessible data range.

[0034] Step S244 calculates a preliminary risk score based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight. The calculation method of the preliminary risk score is the same as that of step S243. The preliminary risk score reflects the risk level of the access environment and the user's basic behavior, but does not include the additional risks brought by unauthorized access.

[0035] Step S245 obtains a first risk score compensation amount based on the degree of deviation between the medical data requested by the user and the range of data accessible to the user. This embodiment can calculate the degree of deviation between the medical data requested by the user and the range of data accessible to the user based on the number of data entries beyond the authority range, the sensitivity level of the data beyond the authority range and / or the correlation between the type of data requested for access and the user role. This embodiment can obtain the first risk score compensation amount based on the degree of deviation between the medical data requested by the user and the range of data accessible to the user by querying a pre-built mapping relationship table of data deviation degree and risk score compensation amount according to the degree of deviation. Specifically, the degree of deviation in this embodiment is positively correlated with the first risk score compensation amount, that is, the greater the degree of deviation, the greater the first risk score compensation amount. For example, if the data the user attempts to access is extremely sensitive and completely irrelevant to the user role, the calculated value of the degree of deviation may be high, resulting in a larger compensation amount. After obtaining the first risk score compensation amount, this embodiment adds the first risk score compensation amount to the preliminary risk score calculated in step S244 to calculate a final access risk score representing the current access risk level. Specifically, the access risk score is calculated as follows: Final Access Risk Score = Preliminary Risk Score + First Risk Score Compensation Amount. Because this embodiment introduces a first risk score compensation amount determined based on the degree of deviation between the medical data requested by the user and the range of data accessible to the user, even if the risk scores of the access source, device, and user behavior are not high, unauthorized access can significantly increase the final access risk score. This is equivalent to incorporating the scope of user role permissions into the risk assessment system. Therefore, this embodiment can effectively detect potential data leakage risks arising from unauthorized access, avoiding situations where the failure to detect potential data leakage risks resulting from unauthorized access leads to an inability to address unauthorized access and medical data leakage. This further improves the accuracy and reliability of data leakage risk assessments, and thus further improves the accuracy and reliability of subsequently determined access rights and data display policies.

[0036] In some preferred embodiments, step S24 further includes the following steps performed before step S242: S246. Obtain user historical behaviors and calculate behavior similarity based on the user historical behaviors and user behavior information; Step S243 includes: A1. When the behavior similarity is greater than or equal to the preset similarity threshold, an access risk score representing the current access risk level is calculated based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight; A2. When the behavior similarity is less than the preset similarity threshold, a preliminary risk score is calculated based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight. A second risk score compensation amount is obtained based on the degree of deviation between the behavior similarity and the preset similarity threshold. An access risk score representing the current access risk level is then calculated based on the preliminary risk score and the second risk score compensation amount. Step S245 includes: B1. When the behavior similarity is greater than or equal to a preset similarity threshold, a first risk score compensation amount is obtained based on the degree of deviation between the medical data requested by the user and the range of data accessible to the user, and then an access risk score representing the current access risk level is calculated based on the preliminary risk score and the first risk score compensation amount; B2. When the behavior similarity is less than a preset similarity threshold, a first risk score compensation amount is obtained based on the degree of deviation between the medical data requested by the user and the range of data accessible to the user, and a second risk score compensation amount is obtained based on the degree of deviation between the behavior similarity and the preset similarity threshold. Then, an access risk score used to characterize the current access risk level is calculated based on the preliminary risk score, the first risk score compensation amount, and the second risk score compensation amount.

[0037] Step S246 can obtain the user's historical behavior by retrieving the user's past access time, access data volume, access data type, access pattern and other information from the system log or behavior database. Step S246 can quantify the degree of fit between the user's historical behavior and the user behavior information by comparing the statistical characteristics of the current behavior pattern (user behavior information) and the historical behavior pattern (historical user behavior) (such as average access volume, access frequency distribution) or using a machine learning model (such as cluster analysis, sequence alignment algorithm) to obtain the behavioral similarity between the user's historical behavior and the user behavior information. The higher the behavioral similarity, the more consistent the user's current data access behavior is with the user's historical behavior pattern; the lower the behavioral similarity, the more the user's current data access behavior deviates from the user's historical behavior pattern, that is, the more abnormal the user's current data access behavior is. The preset similarity threshold of this embodiment is used to define the normal and abnormal nature of the user's current data access behavior. When the medical data requested by the user does not exceed the scope of the user's accessible data and the behavior similarity is greater than or equal to the preset similarity threshold, it means that no unauthorized access behavior has occurred and the user's current data access behavior is normal. Therefore, step A1 only needs to access the source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight to calculate the access risk score. When the medical data requested by the user does not exceed the scope of the user's accessible data and the behavioral similarity is less than the preset similarity threshold, it indicates that no unauthorized access has occurred and the user's current data access behavior is abnormal. Therefore, after the initial risk score, step A2 needs to obtain a second risk score compensation amount based on the degree of deviation between the behavioral similarity and the preset similarity threshold. Specifically, step A2 can obtain the second risk score compensation amount based on the degree of deviation between the behavioral similarity and the preset similarity threshold by querying a pre-constructed mapping relationship table of similarity deviation and risk score compensation amount based on the degree of deviation between the behavioral similarity and the preset similarity threshold. The degree of deviation is positively correlated with the second risk score compensation amount, that is, the more abnormal the behavior (the lower the behavioral similarity, the greater the degree of deviation between the behavioral similarity and the preset similarity threshold), the greater the second risk score compensation amount. The principles of steps B1 and B2 are similar to those of steps A1 and A2 and will not be discussed in detail here.The above embodiment performs data leakage risk assessment based solely on the user's current data access behavior. This data leakage risk assessment may not identify potentially risky behaviors that superficially conform to certain rules but actually deviate from the user's normal behavior patterns. For example, if a user suddenly accesses a large amount of data late at night that they rarely access, even if this data is within their role permissions, this change in behavior pattern may indicate risk. Because this embodiment can identify and quantify the abnormality of user behavior by introducing behavioral similarity and adjusting the risk score calculation based on its comparison with a threshold, it can capture the potential risks of the user's current behavior pattern even when the data access range is normal. In other words, this embodiment is equivalent to incorporating the degree of similarity between the user's current data access behavior and the user's historical behavior pattern into the risk assessment system. Therefore, this embodiment can effectively perceive the potential data leakage risks brought about by data access behaviors that deviate from the user's normal behavior patterns, thereby avoiding the possibility that medical data may be leaked due to data access behaviors that do not deviate from the user's normal behavior patterns. This further improves the accuracy and reliability of data leakage risk assessment, and further improves the accuracy and reliability of subsequently determined access rights and data display strategies.

[0038] In some preferred embodiments, the data access request includes medical data that the user requests access to, and step S3 includes: S31. Querying a pre-built mapping relationship table between risk scores and risk policies based on the risk scores to obtain preliminary access rights and preliminary data display policies for the current data access request; S32. Obtain user role information and determine the type of data requested for access based on the data requested for access by the user; S33. Query a pre-built mapping relationship table of user roles, data access types, permission adjustment policies, and display adjustment policies based on the user role information and the requested access data type to obtain the permission adjustment policy and the data display adjustment policy. S34. Adjust the preliminary access permission according to the access permission adjustment policy, and adjust the preliminary data display policy according to the data display adjustment policy to obtain the access permission and data display policy for the current data access request.

[0039] The process of obtaining user role information in step S32 is similar to the process of obtaining user role information in step S241. The process of determining the type of data requested for access in step S32 is similar to the process of determining the type of data requested for access in step S21, and will not be discussed in detail here. The mapping relationship table of user role, data access type, permission adjustment policy and display adjustment policy in step S33 stores the permission adjustment policy and display adjustment policy corresponding to different combinations of user role and data access type. That is, the mapping relationship table defines how the preliminary access rights and data display policy should be adjusted when a specific user role accesses a specific data type. For example, when the user role is a doctor, the requested data type is the medical record of the patient under his / her responsibility, and the preliminary access rights and preliminary data display policy jointly indicate that access is denied, the access rights adjustment policy and data display adjustment policy of this embodiment indicate that access is adjusted from denied to allowed but downloading is prohibited; when the user role is an ordinary user, the requested data type is a sensitive examination report, and the preliminary access rights and preliminary data display policy jointly indicate that access is allowed to all requested medical data, the access rights adjustment policy and data display adjustment policy of this embodiment indicate that access is adjusted from only allowing access to all requested medical data to allowing access to the desensitized data in the requested medical data. This embodiment can determine the access permission adjustment policy and data display adjustment policy based on user role information and the type of access requested, and then adjust the preliminary access permission according to the access permission adjustment policy and adjust the preliminary data display policy according to the data display adjustment policy to achieve the consideration of the influence of user role and requested data type in determining the access permission and data display policy, so as to generate more refined access permission and data display policy that better meets actual needs. Therefore, this embodiment can effectively avoid the situation where the user identity and data sensitivity are not fully considered due to relying solely on risk scores to determine access permission and data display policies, and the obtained access permission and data display policies are too loose (for example, patients can access other patients' medical data when the access risk score is low) or too strict (for example, doctors cannot access the medical data of patients they are responsible for when the access risk score is high).

[0040] In some preferred embodiments, the access source information includes an IP address and geographic location information. This embodiment can directly obtain the IP address from the network communication protocol. This embodiment can obtain the geographic location information by querying a pre-built mapping database of IP addresses and geographic locations based on the obtained IP address. Specifically, different IP addresses correspond to different access source risk scores. For example, data access requests from known malicious IP addresses are assigned a higher access source risk score. Data access requests from non-user resident geographic locations are assigned an access source risk score that is greater than the access source risk score of data access requests from user resident geographic locations. Data access requests from controlled internal networks are assigned a lower access source risk score.

[0041] In some preferred embodiments, the terminal device information includes the device type and device security status. The device type of this embodiment can indicate the hardware form and usage environment of the terminal device. For example, the device type can be used to distinguish whether the terminal device is a desktop computer, a mobile device, or a dedicated medical terminal. This embodiment can obtain the device type by reading the user agent string or identifying it through an agent program installed on the terminal. Specifically, different device types correspond to different device risk scores. For example, the device risk score for access from a personal device is higher than the device risk score for access from a controlled medical terminal. The device security status of this embodiment can reflect the current security configuration and operating status of the terminal device. Specifically, the device security status can include the operating system version, security patch installation status, antivirus software operating status, firewall configuration, and the presence of known malware signatures. This embodiment can obtain the device security status by using a security agent program running on the terminal to collect security status information or by using network scanning and security policy compliance checks. Different device security statuses correspond to different device risk scores. For example, the device risk score of a terminal device with an out-of-date operating system, no antivirus software installed, or malware is higher than the device risk score of a terminal device with an out-of-date operating system, installed antivirus software, and no malware.

[0042] In some preferred embodiments, user behavior information includes the time of access request, the amount of data requested for access, and the data access pattern. The time of access request in this embodiment can reflect whether the user's access behavior occurs during an abnormal period (such as non-working hours), which helps to identify potential malicious access or illegal operations by insiders. The amount of data requested for access in this embodiment can reflect the total amount of data requested for access by the user. An excessive amount of data requested for access may indicate bulk data downloading or theft. The data access pattern in this embodiment can reflect the operations performed by the user on the data requested for access (such as querying, modifying, or downloading), which helps to identify abnormal access patterns (such as a patient wanting to modify medical data).

[0043] From the above, it can be seen that the present application provides a multi-layer dynamic protection method for medical Web services, which first obtains an access risk score based on access source information, terminal device information and user behavior information, and then determines the access permission and data display strategy for the current data access request based on the risk score. Finally, the medical data to be returned and corresponding to the data access request is processed according to the access permission and data display strategy, and the processed medical data is sent to the user terminal. That is, the present application can perform real-time and dynamic data leakage risk assessment based on user access source, terminal device type and user behavior, and dynamically adjust data access permission and data display strategy based on the assessment results to effectively reduce the risk of medical data leakage. Therefore, the present application can effectively solve the problem of medical data leakage caused by the inability to handle high data leakage risk events due to the inability to perform real-time and dynamic data leakage risk assessment, thereby effectively improving the security protection capabilities of the medical Web service system.

[0044] Second, as Figure 2 As shown, the present application also provides a multi-layer dynamic protection system for medical Web services, which includes: Information acquisition module 1, used to obtain access source information, terminal device information and user behavior information when a user initiates a data access request; Risk assessment module 2, used to obtain an access risk score representing the current access risk level based on access source information, terminal device information, and user behavior information; Policy decision module 3, used to query the pre-built mapping relationship table between risk scores and risk policies based on the risk scores to obtain the access rights and data display policies for the current data access request; The data processing module 4 is configured to process the medical data to be returned and corresponding to the data access request according to the access permission and the data display policy, and then send the medical data to the user terminal.

[0045] The multi-layer dynamic protection system for medical Web services provided in this application includes an information acquisition module 1, a risk assessment module 2, a policy decision module 3 and a data processing module 4. The multi-layer dynamic protection system for medical Web services provided in this embodiment is used to execute the steps in the multi-layer dynamic protection method for medical Web services provided in the first aspect above. The principle of the multi-layer dynamic protection system for medical Web services provided in this embodiment is the same as the principle of the multi-layer dynamic protection system for medical Web services provided in the first aspect above, and will not be discussed in detail here.

[0046] In some preferred embodiments, the data access request includes medical data requested by the user, and the process of obtaining an access risk score representing the current access risk level based on access source information, terminal device information, and user behavior information includes: Determining the type of data requested for access based on the data requested for access by the user; Querying a pre-built mapping relationship table between access source information and data leakage risk scores based on the access source information to obtain an access source risk score; querying a pre-built mapping relationship table between terminal device information and data leakage risk scores based on the terminal device information to obtain a device risk score; and querying a pre-built mapping relationship table between user behavior information and data leakage risk scores based on the user behavior information to obtain a behavior risk score; Query a pre-built mapping table of data types and weighted weight combinations based on the requested access data type to determine the weighted weights corresponding to the access source risk score, device risk score, and behavior risk score; An access risk score representing the current access risk level is calculated based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight.

[0047] From the above, it can be seen that the present application provides a multi-layer dynamic protection method and system for medical Web services, which first obtains an access risk score based on access source information, terminal device information and user behavior information, and then determines the access permission and data display strategy for the current data access request based on the risk score. Finally, the medical data to be returned and corresponding to the data access request is processed according to the access permission and data display strategy, and the processed medical data is sent to the user terminal. That is, the present application can perform real-time and dynamic data leakage risk assessment based on user access source, terminal device type and user behavior, and dynamically adjust data access permission and data display strategy based on the assessment results to effectively reduce the risk of medical data leakage. Therefore, the present application can effectively solve the problem of medical data leakage caused by the inability to handle high data leakage risk events due to the inability to perform real-time and dynamic data leakage risk assessment, thereby effectively improving the security protection capabilities of the medical Web service system.

[0048] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the above-mentioned units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another robot, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interface, the indirect coupling or communication connection of the device or unit can be electrical, mechanical or other forms.

[0049] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0050] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any actual relationship or order between these entities or operations.

[0051] The above are merely examples of the present application and are not intended to limit the scope of protection of the present application. Those skilled in the art will appreciate that various modifications and variations are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A multi-layer dynamic protection method for medical Web services, characterized in that: The multi-layer dynamic protection method for medical Web services includes the following steps: S1. When a user initiates a data access request, obtain access source information, terminal device information, and user behavior information; S2. Obtaining an access risk score for representing a current access risk level based on the access source information, the terminal device information, and the user behavior information; S3. Querying a pre-built mapping relationship table between risk scores and risk policies based on the risk scores to obtain access rights and data display policies for the current data access request; S4. Process the medical data to be returned and corresponding to the data access request according to the access permission and the data display policy, and then send the medical data to the user terminal.

2. The multi-layer dynamic protection method for medical Web services according to claim 1 is characterized in that: The data access request includes the medical data that the user requests to access, and step S2 includes: S21, determining the type of data requested for access according to the data requested for access by the user; S22. Querying a pre-built mapping relationship table between access source information and data leakage risk scores based on the access source information to obtain an access source risk score; querying a pre-built mapping relationship table between terminal device information and data leakage risk scores based on the terminal device information to obtain a device risk score; and querying a pre-built mapping relationship table between user behavior information and data leakage risk scores based on the user behavior information to obtain a behavior risk score; S23. Querying a pre-built mapping relationship table of data types and weighted weight combinations according to the requested access data type to determine weighted weights corresponding to the access source risk score, the device risk score, and the behavior risk score; S24. Calculate an access risk score representing the current access risk level based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight.

3. The multi-layer dynamic protection method for medical Web services according to claim 2 is characterized in that: Step S24 includes: S241: Obtain user role information, and then query a pre-built mapping relationship table of user roles and data access permission ranges based on the user role information to obtain the user-accessible data range; S242, analyzing whether the medical data requested by the user exceeds the range of data accessible to the user, if so, executing step S244, if not, executing step S243; S243. Calculate an access risk score representing the current access risk level based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight; S244. Calculate a preliminary risk score based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight; S245. Obtain a first risk score compensation amount based on the degree of deviation between the medical data requested by the user and the range of data accessible to the user, and then calculate an access risk score for representing the current access risk level based on the preliminary risk score and the first risk score compensation amount.

4. The multi-layer dynamic protection method for medical Web services according to claim 3 is characterized in that: Step S24 also includes the following steps performed before step S242: S246. Obtain user historical behaviors, and calculate behavior similarity based on the user historical behaviors and the user behavior information; Step S243 includes: A1. When the behavior similarity is greater than or equal to a preset similarity threshold, calculate an access risk score representing the current access risk level based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight; A2. When the behavior similarity is less than the preset similarity threshold, a preliminary risk score is calculated based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight, and a second risk score compensation amount is obtained based on the degree of deviation between the behavior similarity and the preset similarity threshold. Then, an access risk score representing the current access risk level is calculated based on the preliminary risk score and the second risk score compensation amount. Step S245 includes: B1. When the behavior similarity is greater than or equal to a preset similarity threshold, obtaining a first risk score compensation amount based on the degree of deviation between the medical data requested by the user and the range of data accessible to the user, and then calculating an access risk score representing the current access risk level based on the preliminary risk score and the first risk score compensation amount; B2. When the behavior similarity is less than a preset similarity threshold, a first risk score compensation amount is obtained based on the degree of deviation between the medical data requested by the user and the range of data accessible to the user, and a second risk score compensation amount is obtained based on the degree of deviation between the behavior similarity and the preset similarity threshold. Then, an access risk score used to characterize the current access risk level is calculated based on the preliminary risk score, the first risk score compensation amount, and the second risk score compensation amount.

5. The multi-layer dynamic protection method for medical Web services according to claim 1 is characterized in that: The data access request includes the medical data that the user requests to access, and step S3 includes: S31. Querying a pre-built mapping relationship table between risk scores and risk policies based on the risk scores to obtain preliminary access rights and preliminary data display policies for the current data access request; S32: Obtain user role information, and determine the type of data requested for access based on the data requested for access by the user; S33: querying a pre-built mapping relationship table of user roles, data access types, permission adjustment policies, and display adjustment policies based on the user role information and the requested access data type to obtain the permission adjustment policy and the data display adjustment policy; S34: Adjust the preliminary access permission according to the access permission adjustment policy, and adjust the preliminary data display policy according to the data display adjustment policy to obtain the access permission and data display policy for the current data access request.

6. The multi-layer dynamic protection method for medical Web services according to claim 1 is characterized in that: The access source information includes IP address and geographic location information.

7. The multi-layer dynamic protection method for medical Web services according to claim 1 is characterized in that: The terminal device information includes device type and device security status.

8. The multi-layer dynamic protection method for medical Web services according to claim 1 is characterized in that: The user behavior information includes the requested access time, the requested access data volume and the data access mode.

9. A multi-layer dynamic protection system for medical Web services, characterized in that: The medical Web service multi-layer dynamic protection system includes: The information acquisition module is used to obtain access source information, terminal device information and user behavior information when a user initiates a data access request; a risk assessment module, configured to obtain an access risk score representing a current access risk level based on the access source information, the terminal device information, and the user behavior information; A policy decision module is used to query a pre-built mapping relationship table of risk scores and risk policies based on the risk scores to obtain access rights and data display policies for the current data access request; The data processing module is used to process the medical data to be returned and corresponding to the data access request according to the access permission and the data display policy, and then send the medical data to the user terminal.

10. The multi-layer dynamic protection system for medical Web services according to claim 9, characterized in that: The data access request includes medical data that a user requests to access, and the process of obtaining an access risk score for representing a current access risk level based on the access source information, the terminal device information, and the user behavior information includes: Determining the type of data requested for access based on the data requested for access by the user; querying a pre-built mapping relationship table between access source information and data leakage risk scores based on the access source information to obtain an access source risk score, querying a pre-built mapping relationship table between terminal device information and data leakage risk scores based on the terminal device information to obtain a device risk score, and querying a pre-built mapping relationship table between user behavior information and data leakage risk scores based on the user behavior information to obtain a behavior risk score; Querying a pre-built mapping relationship table of data types and weighted weight combinations according to the requested access data type to determine weighted weights corresponding to the access source risk score, the device risk score, and the behavior risk score; An access risk score representing the current access risk level is calculated based on the access source risk score and its corresponding weighted weight, the device risk score and its corresponding weighted weight, and the behavior risk score and its corresponding weighted weight.

Images