A method and system for cloud-end coordination conference data management

Abstract

The application relates to the technical field of data management, and discloses a conference data management method and system based on end-cloud cooperation, which comprises the following steps: collecting a participating position, a device state and a conference process, constructing a multi-dimensional environment feature set, and obtaining an initial security level through support vector machine classification. If the level is lower than a threshold value, end-side sensing data containing device operation data and network flow data is obtained from an end-side security agent to detect terminal behavior anomalies. If abnormal behavior features are found, a risk level value is obtained by evaluating a call frequency risk, a downgrade strategy instruction is encapsulated according to the risk level value, and an access matrix mask is trimmed to update a permission boundary. Then, a certificate ciphertext is encapsulated in combination with the conference process, and an offline access certificate is generated. Transmission handshake quality detection is implemented on encrypted transmission messages, local certificate analysis and verification are performed when the transmission handshake quality detection is determined as a weak network state, and according to the result, a token control is performed through fragmented reading, and a dynamic authorization result is output. The method can guarantee the safety of conference data.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and in particular to a method and system for managing meeting data in a cloud-edge collaborative manner. Background Technology

[0002] Currently, the recordings and documents generated by digital meetings carry strategic information, but security management faces continuous challenges in a dynamic environment. Participants often move between locations with different security levels, such as offices, cafes, and subways, and the equipment they use and the stage of the meeting also change. If access permissions cannot be adjusted accordingly, confidential content can still be accessed in public places, or overly strict constraints in routine procedures can lead to leaks or hinder collaboration. Relying on centralized cloud verification methods means that access is immediately interrupted when there is a weak network or when offline, and it is impossible to determine whether the terminal has been jailbroken or infected with malware. Therefore, a data security mechanism is needed that can synchronously sense location, device trust status, and meeting progress, and dynamically adjust access permissions accordingly, so as to balance information protection and workflow continuity.

[0003] In one existing technology, an administrator assigns a fixed document access level (e.g., read-only or downloadable) to each participant before the meeting. When a participant requests meeting recordings or transcripts via a client, the terminal sends an identity token to a cloud authentication service. The server only verifies the token's validity before returning the data. The authentication process does not collect information such as whether the device is jailbroken or has malware, nor does it assess the security attributes of the current location. Once permissions are granted, they are not adjusted for the entire meeting based on agenda progress or changes in sensitive topics. This process relies on a continuous network connection; token verification and data acquisition are both completed in the cloud. When offline or in a weak network state, access requests are directly blocked. This existing technology, which uses fixed pre-meeting authorization and cloud token verification for access control, results in permissions not being dynamically adjusted based on location, device status, and meeting progress, and is blocked when offline.

[0004] Therefore, existing technologies cannot guarantee the security of meeting data. Summary of the Invention

[0005] This invention provides a method and system for managing meeting data in a cloud-edge collaborative manner to ensure meeting data security.

[0006] Firstly, in order to solve the above-mentioned technical problems, the present invention provides a method for managing meeting data in a cloud-edge collaborative manner, comprising: S11, obtain the meeting location, device status and meeting progress, and construct environmental context features based on the meeting location, device status and meeting progress to obtain a multi-dimensional environmental feature set; S12, perform support vector machine security level classification based on the multidimensional environmental feature set to obtain the initial security level of the current environment; S13, when the initial security level is lower than the preset security threshold, obtain end-side perception data containing device operation data and network traffic data from the end-side security agent, and perform terminal behavior anomaly detection on the end-side perception data to obtain abnormal behavior characteristics. S14, when the abnormal behavior feature exists in the edge-side sensing data, a call frequency risk assessment is performed based on the abnormal behavior feature to obtain a risk level value, and a downgrade strategy instruction is encapsulated based on the risk level value to obtain a permission downgrade instruction. An access matrix mask is then truncated based on the permission downgrade instruction to obtain the updated permission boundary. When the abnormal behavior feature is empty, permission range matching is performed in a preset security level permission range table based on the initial security level to obtain the updated permission boundary. S15, based on the updated permission boundaries and the meeting process, the credentials are encrypted to obtain offline access credentials; S16, when the offline access credential is empty, the dynamic authorization result is written as "access denied"; when the offline access credential is not empty, a transmission handshake quality check is performed based on the encrypted transmission message generated by the offline access credential to obtain the network connection status; when the network connection status is a normal access status, the access request and the offline access credential are sent to the conference data service for cloud permission verification to obtain the dynamic authorization result; and when the network connection status is a weak network access status, local credential parsing and verification are performed based on the offline access credential to obtain the local verification result, and fragmented token reading control is performed based on the local verification result to obtain the dynamic authorization result.

[0007] Secondly, the present invention provides an edge-cloud collaborative conference data management system, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0008] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0009] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention collects the location of participants, device status and meeting progress and constructs a multi-dimensional environmental feature set. It uses support vector machine to classify the security level to obtain the initial security level. Since the multi-dimensional environmental feature set integrates the physical location security attributes, the trusted status of the device and the security level requirements of the meeting stage, the support vector machine can effectively divide the multi-dimensional features under small sample conditions. It solves the problem that the permissions are fixed and cannot perceive the dynamic changes of the environment in the prior art. It realizes the accurate matching of access control policy and real-time security situation, and provides a reliable risk judgment basis for subsequent dynamic permission adjustment.

[0010] (2) When the initial security level is lower than the threshold, the present invention obtains perception data from the end side to detect abnormal terminal behavior. Abnormal behavior is identified by matching the behavior deviation vector with the abnormal feature library. The downgrade instruction is encapsulated based on the risk assessment of the call frequency. The access matrix mask is used to cut off only the restricted operation position in the sensitive directory to update the permission boundary. Since the deviation vector eliminates the device baseline difference, the frequency deviation multiple objectively reflects the degree of abnormality, and the matrix cutting realizes fine-grained permission stripping, it solves the problem that the existing technology cannot perceive the trusted status of the terminal and the permission adjustment is coarse-grained. It realizes the accurate identification of abnormal terminals and minimizes permission contraction, and takes into account both high-risk data blocking and non-sensitive collaboration protection.

[0011] (3) This invention combines the updated permission boundaries and conference process to encapsulate offline access credentials, performs transmission handshake quality detection on encrypted transmission messages, and performs local credential parsing and verification when the network is weak. Based on the verification results, it performs fragmented reading of tokens and outputs dynamic authorization results. Since the offline access credentials embed the binding relationship between the core confidential identifier and the hardware identifier of the terminal device and adopt group encryption encapsulation, the fragmented token verification performs consistency comparison of the session period and heartbeat frequency according to the time interval limited by the authorization boundary. This solves the problem that access is directly blocked when relying on centralized verification in the cloud in the existing technology when offline or in a weak network. It realizes the continuous access capability based on local trusted computing in a weak network environment, and ensures the continuity and security of conference collaboration under different network conditions. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the process of the end-to-cloud collaborative meeting data management method provided in the first embodiment of the present invention. Detailed Implementation

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

[0014] Reference Figure 1 The first embodiment of the present invention provides a method for managing meeting data in a cloud-edge collaborative manner, including the following steps: S11, obtain the meeting location, device status and meeting progress, and construct environmental context features based on the meeting location, device status and meeting progress to obtain a multi-dimensional environmental feature set; S12, perform support vector machine security level classification based on the multidimensional environmental feature set to obtain the initial security level of the current environment; S13, when the initial security level is lower than the preset security threshold, obtain end-side perception data containing device operation data and network traffic data from the end-side security agent, and perform terminal behavior anomaly detection on the end-side perception data to obtain abnormal behavior characteristics. S14, when the abnormal behavior features exist in the edge-side sensing data, the call frequency risk is assessed based on the abnormal behavior features to obtain a risk level value, and a downgrade strategy instruction is encapsulated based on the risk level value to obtain a permission downgrade instruction, and the access matrix mask is clipped based on the permission downgrade instruction to obtain the updated permission boundary. S15, based on the updated permission boundaries and the meeting process, the credentials are encrypted to obtain offline access credentials; S16, perform transmission handshake quality detection based on the encrypted transmission message generated by the offline access credential to obtain the network connection status. When the network connection status is a weak network access status, perform local credential parsing and verification based on the offline access credential to obtain the local verification result. Then, perform fragmented reading token control based on the local verification result to obtain the dynamic authorization result.

[0015] In step S11, the meeting location, device status, and meeting progress are obtained. Based on the meeting location, device status, and meeting progress, environmental context features are constructed to obtain a multi-dimensional environmental feature set.

[0016] Specifically, the meeting client obtains participant location, device status, and meeting progress from the location service, the edge security agent, and the meeting management system, respectively, and associates them with participant identifiers, edge device identifiers, and meeting identifiers. Participant location information includes at least coordinate blocks, venue security tags, and data collection time; device status information includes at least system integrity, screen lock, storage encryption, security agent operation, processor load, memory usage, network connection, and data collection time; meeting progress information includes at least the current agenda stage, start and end times, meeting security level, participant identity, and update time. Wireless access device information is only used as supplementary data for location and network verification.

[0017] The conference client synchronizes location acquisition time, status acquisition time, and process update time via the NTP protocol or system clock, using a preset time window as a tolerance, one implementation being 5 seconds. When the maximum time difference exceeds the window, the earliest acquired data item is reread.

[0018] If the preset time window is still exceeded after rereading, the latest record of each data source is retained and the collection time consistency flag is written to 0; if the window is met, it is written to 1. When there are multiple location records in the same collection period, the latest record is retained. When configuring enhanced verification of wireless access devices, records consistent with the registered network are retained first.

[0019] The location security directory is constructed by the conference management system based on conference room registration forms, wireless access device ledgers, office area geofence tables, and remote work address registration forms. It records coordinate blocks, wireless access devices, location security tags, and location risk values. During deployment, incremental risk codes are configured for controlled conference rooms, registered office areas, registered remote areas, and unregistered areas. Conference clients query the directory using coordinate blocks and wireless access device identifiers; if fields are missing or inconsistent, the highest risk code is written.

[0020] The meeting client writes the location risk value, the venue safety label code value, and the location acquisition time validity identifier into the location feature field; when the time is not aligned, the time validity identifier is written as 0, and the aforementioned location code is written as the highest risk value.

[0021] The device status baseline table is built by the endpoint security agent based on the device operation logs of devices that have been operating normally, with complete systems, and successful access over the previous 30 days. It stores the minimum, maximum, and median values ​​of processor load and memory usage, categorized by endpoint device identifier. If the sample size is insufficient, at least 100 log entries under the same conditions during deployment initialization are used. After the meeting, only logs showing successful access without security alerts are appended.

[0022] The conference client uses minimum and maximum value normalization to process processor load and memory usage values, so that the results are between 0 and 1; when the historical maximum and minimum values ​​are the same, 0 is written, and results outside the range are truncated to 0 or 1 respectively.

[0023] The conference client uses a fixed encoding for system integrity, screen lock, storage encryption, security agent operation, and network connection status, with 1 for normal and 0 for abnormal. Processor load and memory usage are normalized using the aforementioned values ​​and are written into the device feature field.

[0024] The process security level directory is constructed by the meeting management system from the meeting agenda, and includes the meeting identifier, agenda stage and start and end times, meeting security level, and participant identity. During deployment, the agenda stage, security level, and identity are configured with encoding mappings; the identity encoding is only used for category queries and does not indicate the level of permissions.

[0025] The meeting client queries the process security level directory based on the meeting identifier and agenda stage, retrieving the stage, security level, and participant identity code. The participant identity is converted into a one-hot code before being input into the classification model. Agenda progress is the ratio of the duration already completed to the total agenda duration, truncated to 0 to 1; a value of 0 is written when the total agenda duration is 0. The above codes and agenda progress are written to the process feature field.

[0026] The multidimensional environmental feature set is encapsulated in a fixed order of location features, device features, process features, and data collection time consistency identifiers. Each record includes field name, field value, field source, and data collection time.

[0027] In step S12, a support vector machine security level classification is performed based on the multidimensional environmental feature set to obtain the initial security level of the current environment.

[0028] Specifically, the support vector machine classification model is trained by the conference management system before deployment based on the system's existing historical conference access logs, edge security agent logs, optional wireless access device logs, and conference agenda logs. Each sample input is a multi-dimensional set of environmental features formed in a fixed order according to step S11, and the output label is a security level from 0 to 3: 3 for successful access with no security alarms, 2 for low-level security alarms, 1 for failed access with medium-level security alarms, and 0 for unauthorized access, abnormal terminal integrity, or access from an unregistered location. A higher label indicates a more secure environment.

[0029] The model employs a linear kernel and a one-to-many structure, with parameters representing the classification weights and biases corresponding to each security level. 0 or 1 encoded fields retain their original values. Codes indicating a level relationship are divided by the maximum value of the corresponding field. Participant identities are encoded using one-hot encoding, and continuous inputs are limited to 0 to 1. For each security level, samples from that level are treated as positive samples, and samples from other levels are treated as negative samples.

[0030] The meeting management system iteratively solves the classification weights and classification biases for each security level by using training samples.

[0031] The k-th binary classification discriminant function is fk(x) = wkTx + bk, where x is the model input after normalization and one-hot encoding of participant identity, and wk and bk are the classification weights and classification biases, respectively. The four functions output real-valued scores, with the highest score corresponding to a security level from 0 to 3. The parameters are solved using a hinge loss objective function with L2 regularization and coordinate descent. Internal parameters include a penalty coefficient C, convergence tolerance ε, and maximum number of iterations N, which in one implementation are 1, 0.0001, and 1000, respectively. The process stops when the difference between two adjacent objective function iterations is no greater than ε or when N iterations have been reached. Only samples with complete required fields, time alignment differences not exceeding the preset time window in step S11, and unique labels are retained. A security level of 0 is output when the input dimensions are inconsistent, contain non-numerical fields, or the discriminant score is invalid.

[0032] After training, the classification weights and biases of each security level are saved; during classification, the same field order and preprocessing are used, and the label with the highest score is selected. If the scores are the same, the lower security level is selected.

[0033] The security threshold is the 5th percentile of the model output of samples with successful access and no security alerts in the previous 30 days; if the sample is insufficient, at least 100 logs under the same conditions during deployment initialization are used. If the initial security level is lower than the threshold, step S13 is executed; otherwise, the currently valid original permission boundary is used as the updated permission boundary and the process proceeds to step S15.

[0034] In step S13, when the initial security level is lower than a preset security threshold, end-side sensing data containing device operation data and network traffic data is obtained from the end-side security agent, and terminal behavior anomaly detection is performed on the end-side sensing data to obtain abnormal behavior characteristics, including: The message fields of the edge-side sensing data are parsed to obtain device operation logs and network traffic records containing resource types; The device operation logs and network traffic records are subjected to adjacent window difference extraction according to the collection time window to obtain a time-series behavior sequence containing load difference, memory difference and connection growth rate; The time-series behavior sequence is compared with the pre-stored edge behavior baseline by the field difference, and the comparison difference is divided by the baseline standard deviation of the corresponding field to obtain the behavior deviation vector. When a vector element in the behavior deviation vector exceeds the deviation range of the corresponding field, the original behavior field corresponding to the vector element is extracted to obtain the behavior feature to be matched. The abnormal behavior features are obtained by performing cosine similarity matching between the behavioral features to be matched and the pre-built abnormal behavior feature library.

[0035] Specifically, the edge-side perception data includes device operation data and network traffic data collected by the edge-side security agent, with wireless access device data serving as an enhancement source. The device-side data includes at least the device, process, load, memory, disk read / write, client call, integrity, and collection time; the network-side data includes at least network access, session, destination address type, connection, retransmission, packet, traffic bytes, and collection time. The conference client parses the data directory type of the invoked conference data from the client call field, records the data directory type as a resource type, and writes the resource type, device identifier, and collection time into the edge-side perception data. The conference client merges the data according to device identifier, resource type, and collection time.

[0036] The conference client parses and obtains device operation logs and network traffic records containing resource types. When multiple records exist within the same collection time window, they are merged by device identifier, and the average value of processor load and memory usage is taken. The number of connections, retransmissions, packets, and traffic bytes are summed. Records with missing required fields are not included in subsequent calculations.

[0037] The conference client extracts the difference between adjacent windows from the device operation logs and network traffic records according to the collection time window, obtaining the load difference, memory difference, and connection growth rate. The window duration is determined based on the median value of the recent normal reporting interval; a default period is used when historical records are insufficient. When the number of connections in the previous window is 0, the denominator of the connection growth rate is set to 1.

[0038] The endpoint security agent calculates the average and standard deviation of load difference, memory difference, and connection growth rate based on the original logs of recent successful accesses, no security alarms, and complete endpoints, according to device identifier and resource type, to form the endpoint behavior baseline; when the standard deviation is 0, 1 is written.

[0039] The conference client subtracts the corresponding baseline average from the current load difference, memory difference, and connection growth rate, and then divides by the baseline standard deviation to obtain the behavior deviation vector. The conference client first converts recent normal samples into standardized deviation values ​​using the same baseline average and standard deviation. Then, it arranges the standardized deviation values ​​of each field from smallest to largest and determines the deviation interval for each field using the 5th percentile and 95th percentile values. If the sample size is insufficient, the client uses intervals generated in the same way for initial samples.

[0040] The endpoint behavior baseline uses the device operation logs and network traffic records of the endpoint devices that meet the above conditions in the previous 30 days as fitting samples. The inputs are the load difference, memory difference, and connection growth rate of adjacent windows. The outputs are the average value, standard deviation, and the deviation interval from the 5th to the 95th percentile obtained by the same standardization method for each field. When there are fewer than 100 valid samples, at least 100 samples with the same conditions during the deployment initialization period are used. When the input is missing or exceeds the collection boundary, the abnormal behavior characteristics are written to null values, and all operations in the updated permission boundary are set to zero before proceeding to step S15.

[0041] When any element in the behavior deviation vector exceeds the corresponding deviation range, the conference client extracts the corresponding original behavior field and encapsulates the behavior feature to be matched according to the field name, field value, device identifier, collection time, and resource type. Load, memory, or connection deviations correspond to the extraction of relevant runtime fields or network fields, respectively. If the deviation range is not exceeded, the abnormal behavior feature is written to a null value. Based on the initial security level, the allowed data directory level and operation type are read from the preset security level permission range table, and operations exceeding the permission range in the original permission boundary are set to zero. After obtaining the updated permission boundary, the process proceeds to step S15. The security level permission range table is constructed by the conference management system during deployment based on the access control list, data classification directory, and conference security level directory. It records the allowed data directory level and operation type according to security levels 0 to 3. If a record in the table is missing or the version is inconsistent, all operations in the updated permission boundary are set to zero.

[0042] The abnormal behavior feature database is constructed by the conference management system by reading historical security alarm logs, endpoint security agent interception logs, and optional abnormal connection logs from wireless access devices. It records the abnormal behavior type, device category, resource type, deviation intervals, destination address category, abnormal behavior vector, similarity center vector, and similarity threshold. Load deviation, memory deviation, and connection deviation are retained as continuous values. The destination address category uses a fixed one-hot encoding based on the network address classification directory, and the resource type uses a fixed one-hot encoding based on the data classification directory. Both the abnormal behavior vector and the vector to be matched are generated in a fixed order: three continuous values, the one-hot encoding of the destination address category, and the one-hot encoding of the resource type. The vector dimension is 3 plus the sum of the number of destination address categories and the number of resource types. The conference management system calculates the average value of the historical abnormal vectors for each abnormal behavior type dimensionally to obtain the similarity center vector. Then, it calculates the cosine similarity between each historical abnormal vector and the similarity center vector, arranges the similarities from smallest to largest, and takes the 5th percentile value as the similarity threshold for that abnormal behavior type. The meeting client calculates the cosine similarity between the vector to be matched and the center vectors of each class, and records the abnormal behavior type that reaches the corresponding similarity threshold and has the largest value as the abnormal behavior feature.

[0043] The abnormal behavior feature database stores system logs where security alarms or interception results are confirmed, the abnormal type is unique, and the fields are complete. The input is the vector to be matched, and the output is the abnormal type that reaches the threshold and its corresponding record. If the vector magnitude is 0, the dimensions are inconsistent, the category coding table is missing, or the highest similarity is below the threshold, a null value is output, and all operations in the updated permission boundaries are set to zero before proceeding to step S15. If there are fewer than 20 valid samples of the same type, the initial threshold is determined using at least 20 similar records that have been manually reviewed during deployment initialization.

[0044] In step S14, when the abnormal behavior characteristics exist in the edge-side sensing data, a call frequency risk assessment is performed based on the abnormal behavior characteristics to obtain a risk level value. Then, a downgrade strategy instruction is encapsulated based on the risk level value to obtain a permission downgrade instruction. Finally, an access matrix mask is pruned based on the permission downgrade instruction to obtain the updated permission boundary, including: The abnormal behavior characteristics are parsed to obtain the abnormal device identifier, abnormal resource type, and abnormal occurrence time; Based on the abnormal device identifier, the abnormal resource type, and the time of the abnormality, extract resource call records from the pre-stored audit log to obtain the target call records within the corresponding time range; Extract the request operation type from the target call record, and count the number of calls within the sliding time window according to the abnormal resource type and the request operation type respectively. Divide the number of calls by the window duration to obtain the resource call frequency. The frequency of resource calls is calculated by comparing it with the pre-stored baseline frequency of resources to obtain the frequency deviation multiple. The risk level value is obtained by performing interval matching in a pre-stored risk level mapping table based on the frequency deviation multiple.

[0045] The risk response level corresponding to the risk level value is obtained by querying the pre-stored risk response level table according to the risk level value. The pre-stored access policy table is queried based on the risk response level to obtain the restricted operation type, target device identifier, and instruction validity period; The restricted operation type, the target device identifier, and the effective period of the instruction are encoded in the order of instruction version field, device field, operation field, and time period field to obtain the downgrade instruction field; The message authentication code is calculated on the downgrade instruction field to obtain the instruction verification field; The downgrade instruction field and the instruction verification field are encapsulated into a message to obtain the permission downgrade instruction.

[0046] The permission downgrade instruction is parsed to obtain the target device identifier, restricted operation type, and instruction verification field; Initial permissions are read from a pre-stored access control list based on the target device identifier, and the initial permissions are converted into an original access control matrix according to the arrangement of device rows and data directory columns. Each element of the original access control matrix contains read, download, copy, forward, and delete operation bits. Based on the restricted operation type, the sensitive data directories that need to be isolated are extracted from the pre-stored data classification directory to obtain a set of sensitive directories; Based on the column position of the sensitive directory set in the data directory column and the restricted operation type, matrix values ​​are assigned to obtain a boundary reconstruction matrix that only sets the operation position corresponding to the restricted operation type in the sensitive directory to zero and keeps the other operation bits to one. The updated permission boundary is obtained by performing a bitwise multiplication operation between the boundary reconstruction matrix and the original access control matrix.

[0047] The meeting management system performs a call frequency risk assessment when abnormal behavior characteristics are not empty. The system parses the abnormal device identifier, abnormal resource type, and abnormal occurrence time, and based on this, filters the target call records within the corresponding time range from the pre-stored audit logs.

[0048] Audit logs are generated by the meeting data service on each access and include at least the fields for device, participant, meeting data, resource type, request operation type, call time, result, and security alarm. The target time range is a continuous sliding window preceding the time of the anomaly. The window duration is the median of the intervals between successful accesses without security alarm reports in the previous 30 days. If there are insufficient records, the default period in the reporting configuration is used. The target call records are then filtered by the abnormal device, resource type, and time range.

[0049] The meeting management system counts the number of window calls based on the abnormal resource type and the request operation type extracted from the target call record, and divides this by the window duration to obtain the resource call frequency. The resource baseline frequency is calculated by grouping the logs of successful access without security alarms in the previous 30 days according to resource type and request operation type, and taking the median value of the historical frequency; if there is no record in the same group, the median value of all resources of the same operation type is used, and if the result is 0, the frequency corresponding to 1 time for each sliding window is written.

[0050] The meeting management system divides the resource call frequency by the corresponding resource baseline frequency to obtain the frequency deviation multiple. The risk level mapping table divides the historical deviation multiples in the normal audit log into four intervals: the 75th, 90th, and 95th percentiles. When the current frequency deviation multiple is not greater than the 75th percentile, it is matched with risk level value 1; when it is greater than the 75th percentile but not greater than the 90th percentile, it is matched with risk level value 2; when it is greater than the 90th percentile but not greater than the 95th percentile, it is matched with risk level value 3; and when it is greater than the 95th percentile, it is matched with risk level value 4.

[0051] The risk response level table establishes a correspondence between risk levels and permission reduction actions during deployment. The access policy table is generated from the data classification directory, meeting agenda, and role permission table, recording the risk response level, meeting security level, participant identity, restricted operations, target device generation rules, and instruction validity period rules. The system queries responses and policies according to risk levels, identifies abnormal devices as target devices, and generates instruction validity periods based on the corresponding response duration from the time the anomaly occurred.

[0052] The meeting management system encodes and restricts the operation type, target device identifier, and effective time period of the instruction according to the order of instruction version, device, operation, and time period, resulting in the downgrade instruction field. The operation field records the allowed or restricted status in the order of read, download, copy, forward, and delete. The system uses the instruction key to calculate the message authentication code for the downgrade instruction field and encapsulates the downgrade instruction field and instruction verification field into a permission downgrade instruction.

[0053] The access control list is constructed from the end-device registration table, the participant role table, and the meeting data authorization record, recording the device, data directory, and read, download, copy, forward, and delete operation bits. The data category directory is constructed from the meeting data directory, meeting security level labels, and confidentiality period. The two are associated by meeting identifier and version. If a record is missing, the version is inconsistent, or the operation type exceeds the above five categories, matrix pruning will stop, and all operation bits in the updated permission boundary will be set to zero.

[0054] In step S15, the credential is encrypted according to the updated permission boundaries and the meeting process to obtain an offline access credential, including: Based on the updated permission boundaries, the accessible data directory is read from the meeting data service, and the object numbers of the accessible data directory are extracted to obtain the set of accessible objects. Based on the meeting process, the current agenda stage and meeting security level label are read from the meeting management system, and the fields of the current agenda stage and meeting security level label are combined to obtain the process security level field; Based on the set of accessible objects and the process security level field, a security level label association and matching is performed to obtain a core confidentiality identifier that includes meeting segment label, data security level label and participant identity label; The key is derived by using the core confidentiality identifier and the terminal device hardware identifier to obtain the credential key; The offline access credential is obtained by grouping and encrypting the core confidentiality identifier, the issuance time, and the terminal device hardware identifier according to the credential key.

[0055] The meeting management system determines the data directories that still have read permissions based on the updated permission boundaries, extracts the object IDs and the data directory identifiers to which each object belongs, and sorts them by object ID. Each set element is composed of the object ID and its corresponding data directory identifier, resulting in a set of accessible objects. Object IDs are assigned by the meeting data service to meeting files, recordings, minutes, and data fragments. The meeting management system only uses the corresponding data directory identifier for security level tag association matching, and then concatenates the sorted object IDs sequentially before performing a digest operation to obtain the digest value of the accessible object set. When the set is empty, credential encapsulation is stopped, and an offline access credential is written to an empty value.

[0056] The meeting management system reads the current agenda stage and meeting security level label from the meeting management system based on the meeting progress. It then combines the fields of the current agenda stage and the meeting security level label to obtain the process security level field. During field combination, the meeting management system concatenates the fields in the order of meeting identifier, current agenda stage code value, meeting security level label code value, agenda start time, and agenda end time. The meeting management system then performs security level label association matching based on the accessible object set and the process security level field to obtain a core confidentiality identifier containing meeting segment labels, data security level labels, and participant identity labels. Security level label association matching relies on a pre-built security level association table, which is generated by the meeting management system from the meeting agenda table, data category directory, and role permission table. Each record contains a meeting identifier, meeting segment label, current agenda stage, data directory identifier, data security level label, participant identity label, and allowed access identifier. The meeting management system compares the data directory identifiers in the accessible object set with the security classification table line by line. When the data directory identifier, current agenda stage, and participant identity label all match, and the allowed access identifier is 1, it reads the corresponding meeting segment label, data security classification label, and participant identity label. The meeting management system then concatenates the fields in the order of meeting segment label, data security classification label, participant identity label, and accessible object set summary value to obtain the core confidentiality identifier.

[0057] The conference management system derives a credential key based on the core confidentiality identifier and the terminal device hardware identifier. The terminal device hardware identifier is generated by the terminal security agent after reading the device serial number, motherboard serial number, and security chip identifier of the terminal device. The terminal security agent encodes the device serial number, motherboard serial number, and security chip identifier in a fixed order, performs a digest operation on the encoding result to obtain the terminal device hardware identifier digest value, and uploads this digest value to the conference management system. The conference management system performs a digest operation on the core confidentiality identifier to obtain its digest value. The conference management system derives a device-level key using the credential master key generated during system initialization and the terminal device hardware identifier, and pre-configures the same device-level key into the corresponding terminal device's trusted execution environment via a secure channel. During key derivation, the conference management system calls the cryptographically secure random number generator in the hardware cryptographic module to generate a unique random number for each credential. Then, it calls the key derivation function, which was fixed during deployment initialization, using the device-level key as input key material and the unique random number as salt. The core confidentiality identifier digest value, the terminal device hardware identifier, and the issuance time are encoded into context fields in a fixed order, outputting a 32-byte credential key. The deployment initialization configuration also fixes the key derivation function identifier, field encoding method, and field order; the conference management system and the terminal device use the same configuration. If any input field is missing, credential encapsulation is stopped, and the offline access credential is written with an empty value.

[0058] The meeting management system uses the credential key to encrypt and encapsulate the core confidentiality identifier, issuance time, and terminal device hardware identifier in groups to obtain offline access credentials. During group encryption and encapsulation, the meeting management system first generates plaintext fields for the credentials. These plaintext fields include the core confidentiality identifier, issuance time, valid period, terminal device hardware identifier, identifier resolution matrix version number and identifier resolution matrix digest value, local permission directory version number and local permission directory digest value, accessible object set digest value, and a random number. The start time of the valid period is the issuance time. The maximum valid duration of the offline credential is read by the meeting management system from a preset valid duration table based on the meeting security level. This preset valid duration table is generated by the meeting management system during deployment based on the meeting security level directory and meeting security policy, recording the correspondence between meeting security levels and the maximum valid duration. If an applicable permission downgrade instruction exists, the end time of the valid period is the earliest of the following: the end time of the current agenda, the end time of the permission downgrade instruction, the issuance time, and the maximum valid duration of the offline credential. If no applicable permission downgrade instruction exists, the end time is the earlier of the following: the end time of the current agenda, the issuance time, and the maximum valid duration of the offline credential. The conference management system performs length padding on the plaintext field of the credential each time before grouping it into 16-byte blocks. If the last block is less than 16 bytes, the missing bytes are added to the end as padding. When the plaintext field length is a multiple of 16 bytes, a complete block is added, and each byte is written with 16 as padding. The initialization vector is generated by a cryptographically secure random number generator in the hardware cryptographic module, and each credential has a unique initialization vector. The random number field is written to the unique random number generated during key derivation. The conference management system reads the credential key, inputs the credential key, the initialization vector, and all plaintext blocks into the secure block pattern with initialization vector that was fixed during deployment initialization, and outputs all ciphertext blocks according to the block association order specified by the secure block pattern. The conference management system concatenates all ciphertext blocks in sequence to obtain the encrypted identifier field. The meeting management system encapsulates the following fields in a fixed order: credential version field, core confidentiality identifier digest value, encryption identifier field, initialization vector field, hardware binding field, issuance time field, random number segment, valid time period field, identifier resolution matrix version field, identifier resolution matrix digest field, local permission directory version field, local permission directory digest field, and credential verification field to obtain an offline access credential. The hardware binding field contains the hardware identifier digest value of the endpoint device, and the initialization vector field contains the initialization vector for this credential. The credential verification field is calculated by performing a message authentication code on the credential key, core confidentiality identifier digest value, encryption identifier field, initialization vector field, hardware binding field, issuance time field, random number segment, valid time period field, identifier resolution matrix version field, identifier resolution matrix digest field, local permission directory version field, and local permission directory digest field.

[0059] The plaintext field of the credential also includes the session period and the allowed heartbeat frequency range. The session period is taken from the current reporting period in the end-side security agent's reporting configuration table; the allowed heartbeat frequency range is obtained by reading the heartbeat logs of successful accesses without security alarms from the previous 30 days in the conference management system, using the 5th and 95th percentiles of the historical heartbeat frequency as the lower and upper boundaries, respectively. If there are fewer than 100 valid logs, at least 100 logs meeting the same conditions during deployment initialization are used. Credential encapsulation is stopped if the lower boundary is greater than the upper boundary, the session period is not positive, or the field is missing. The key derivation function, block cipher algorithm, secure block mode, and message authentication code function are all fixed during deployment initialization, and the relevant key length, block length, output length, and internal parameters are configured according to the selected cryptographic algorithm specification.

[0060] In step S16, a transmission handshake quality check is performed on the encrypted transmission message generated based on the offline access credential to obtain the network connection status. If the network connection status is a weak network access status, local credential parsing and verification are performed based on the offline access credential to obtain a local verification result. Then, based on the local verification result, fragmented token reading control is performed to obtain a dynamic authorization result, including: The offline access credentials are read from the trusted execution environment of the terminal device to obtain local credential data; The local credential data is parsed to obtain the credential version field, core confidentiality identifier digest value, encryption identifier field, initialization vector field, hardware binding field, issuance time field, random number segment, valid time period field, identifier resolution matrix version field, identifier resolution matrix digest field, local permission directory version field, local permission directory digest field, and credential verification field. The hardware binding field is compared with the local hardware characteristics of the terminal device to obtain the hardware binding result. When the hardware binding result is consistent, a local key is derived based on the local hardware characteristics, the core secret identifier digest value, the issuance time field, and the random number segment. The encrypted identifier field is then decrypted based on the derived local credential key and the initial vector field to obtain the core secret identifier. Based on the local credential key, a message authentication code is calculated for the core confidentiality identifier digest value, the encrypted identifier field, the initialization vector field, the hardware binding field, the issuance time field, the random number segment, the valid time period field, the identifier resolution matrix version field, the identifier resolution matrix digest field, the local permission directory version field, and the local permission directory digest field. The calculation result is then compared byte-by-byte with the credential verification field. The trusted current time in the trusted execution environment is read. Based on the byte-by-byte comparison result, the hardware binding result, and the relationship between the trusted current time and the valid time period field, the local verification result is obtained.

[0061] Based on the local verification result, the message fields of the access request instruction are parsed to obtain the meeting data identifier and the request operation type. The meeting data identifier and the core confidentiality identifier are jointly vector encoded, and the encoding result is input into a pre-configured identifier resolution matrix for matrix multiplication mapping to obtain a confidentiality level mapping vector; The attribute matching degree is obtained by calculating the cosine similarity between the security level mapping vector and the locally stored baseline permission vector. When the meeting data identifier, the participant identity tag, and the request operation type completely match the local permission directory, and the attribute matching degree is greater than the preset permission comparison threshold, the feature dimensions that meet the weight conditions in the security level mapping vector are transformed into boundary fields to obtain the authorization boundary set. The dynamic authorization result is obtained by performing fragment token verification based on the authorized boundary set, the meeting data identifier, the request operation type, and the session heartbeat record. The fragment token verification involves reading the meeting data fragment sequence according to the time interval defined by the authorized boundary set, comparing the session period and heartbeat frequency of the access token for consistency, and verifying that the heartbeat sequence number and token sequence number stored by the trusted execution environment of the hardware are continuously increasing.

[0062] When the offline access credentials are empty, the conference client does not generate an encrypted transmission message, writes the dynamic authorization result to deny access, and terminates the current access process. When the offline access credentials are not empty, the conference client reads the newly generated session identifier from the trusted execution environment of the end device when the session is established, and generates an encrypted transmission message based on the offline access credentials, the session identifier, the message sequence number, the request time, and the request operation type. It then initiates a handshake with the conference data service and records the handshake response duration, the number of failures, the number of retransmissions, and the number of messages sent.

[0063] The conference client performs a handshake quality check on the access session corresponding to the encrypted transmission message. The handshake response duration is obtained by subtracting the handshake request sending time from the handshake response reception time. The retransmission ratio is obtained by dividing the number of retransmissions by the number of sent messages; when the number of sent messages is 0, the number of sent messages is set to 1. The handshake response duration threshold is determined by the conference management system reading the transmission logs from the previous 30 days where the access result was successful and there were no security alarms. The historical handshake response durations are sorted in ascending order, and the 95th percentile is taken as the handshake response duration threshold. The retransmission ratio threshold is determined by the 95th percentile of the historical retransmission ratio in the same batch of transmission logs. The handshake failure count threshold is determined by the maximum number of consecutive failures in the same batch of transmission logs. If the current 30 days of transmission logs are insufficient, the conference management system reads at least 100 transmission logs from the deployment initialization period where the access result was successful and there were no security alarms, and generates the initial handshake response duration threshold, initial retransmission ratio threshold, and initial handshake failure count threshold in the same way. If the handshake response duration exceeds the handshake response duration threshold, or the number of handshake failures exceeds the handshake failure count threshold, or the retransmission ratio exceeds the retransmission ratio threshold, the network connection status is written to the weak network access status; otherwise, the network connection status is written to the normal access status. When the network connection status is normal access status, the conference client sends the access request and offline access credentials to the conference data service. The conference data service verifies the offline access credentials and checks the conference data identifier, request operation type, and valid time period according to the currently updated permission boundaries. If the verification is successful, the dynamic authorization result is written to allow access; if any item fails the verification, the dynamic authorization result is written to deny access.

[0064] When the network connection is weak, the conference client performs local credential parsing and verification based on the offline access credentials to obtain a local verification result. The conference client reads the offline access credentials from the trusted execution environment (TEX) of the endpoint device to obtain local credential data. The TEX includes at least one of a Trusted Platform Module (TPM), a Secure Enclave, and a TrustZone. The endpoint security agent stores and reads the offline access credentials through the secure call interface of the TEX. The conference client parses the credential header of the local credential data to obtain the following fields: credential version field, core confidentiality identifier digest value, encryption identifier field, initialization vector field, hardware binding field, issuance time field, random number field, valid time period field, identifier resolution matrix version field, identifier resolution matrix digest field, local permission directory version field, local permission directory digest field, and credential verification field. The conference client compares the hardware binding field with the endpoint device's native hardware characteristics to obtain the hardware binding result. The local hardware characteristics are obtained by the end-side security agent in the same way as generating the end-side device hardware identifier in step S15. The conference client compares the local hardware characteristic summary value with the hardware binding field byte by byte. If all bytes are consistent, the hardware binding result is written consistently; if any byte is inconsistent, the hardware binding result is written inconsistently.

[0065] When the hardware binding result is consistent, the conference client calls the same key derivation function as in step S15, using the same device-level key pre-securely configured in the hardware trusted execution environment as the input key material, and a random number segment as the salt value. The core confidentiality identifier digest value, the local hardware feature digest value, and the issuance time field are combined into a context field according to the same field encoding method and fixed order as in step S15, outputting a 32-byte local credential key. If any input field is missing, the local verification result writing fails. The conference client uses the local credential key and the initialization vector field to decrypt the encrypted identifier field according to the fixed security grouping mode selected in step S15, and verifies and removes the trailing padding value according to the padding rules in step S15. If the padding value does not conform to the padding rules, the local verification result writing fails. After decryption, the core confidentiality identifier, issuance time, effective period, end-side device hardware identifier, identifier resolution matrix version number, identifier resolution matrix digest value, local permission directory version number, local permission directory digest value, and accessible object set digest value are obtained.

[0066] The conference client performs a digest operation on the decrypted core confidential identifier to obtain a local core confidential identifier digest value, and compares this local digest value byte-by-byte with the core confidential identifier digest value in the credential header. Following the same method used in step S15 to generate the credential verification field, the conference client calculates the message authentication code for the local credential key, core confidential identifier digest value, encrypted identifier field, initialization vector field, hardware binding field, issuance time field, random number segment, valid time period field, identifier resolution matrix version field, identifier resolution matrix digest field, local permission directory version field, and local permission directory digest field, and compares the calculation result byte-by-byte with the credential verification field. The conference client reads the trusted current time from the trusted clock or non-reversible time record in the trusted execution environment; if the trusted time is unavailable or less than the last saved trusted time, the local verification result writing fails. If the hardware binding result is consistent, the trusted current time is within the valid time period, the local core confidential identifier digest value is consistent byte-by-byte, and the message authentication code is consistent byte-by-byte, the local verification result writing passes; otherwise, the local verification result writing fails.

[0067] The conference client parses the message fields of the access request command based on the local verification result to obtain the conference data identifier and request operation type. When the local verification result is unsuccessful, the conference client stops parsing the access request command and writes the dynamic authorization result as "Access Denied". When the local verification result is successful, the conference client parses the conference data identifier, request operation type, session identifier, and fragment sequence number in the access request command, and reads the request time from the trusted clock or non-reversible time record in the hardware trusted execution environment. The conference client performs joint vector encoding on the conference data identifier and the core confidentiality identifier; after verifying that the identifier resolution matrix version number and digest value are consistent, the encoded result is input into the pre-configured identifier resolution matrix for matrix multiplication mapping to obtain the security level mapping vector. During joint vector encoding, the conference client generates encoded fields in a fixed order of conference data identifier, conference segment label, data security level label, participant identity label, and request operation type. A 1 is written when a field matches the local permission directory, and a 0 is written when it does not.

[0068] The local permission directory is generated by the conference management system when generating offline access credentials, based on the updated permission boundaries, security level association table, and set of accessible objects. It includes object number, belonging data directory identifier, conference data identifier, conference segment label, data security level label, participant identity label, request operation type, and authorization boundary fields. The conference management system synchronously distributes the local permission directory and the identifier resolution matrix generated from it to the trusted execution environment of the edge device, and writes the version number and digest value of both the local permission directory and the identifier resolution matrix into the offline access credentials. The row order of the identifier resolution matrix matches the field order of the joint vector encoding, and the column order matches the authorization boundary field order. If a joint vector field has an authorization correspondence with an authorization boundary field, the corresponding position in the matrix is ​​written as 1; otherwise, the corresponding position is written as 0. Before local authorization, the conference client verifies that the version number and digest value of the current local permission directory and the identifier resolution matrix are consistent with the records in the offline access credentials. If any of them are inconsistent, the dynamic authorization result is written as access denied. After all verifications pass, matrix multiplication mapping is performed. The conference client multiplies the value of each row in the joint vector encoding by the matrix element of the same row of the identifier resolution matrix, and then adds the products of the same column to obtain the security level mapping value of that column. The security level mapping values ​​of all columns are encapsulated into a security level mapping vector in column order.

[0069] The conference client calculates the attribute matching degree by performing a cosine similarity calculation between the security level mapping vector and the locally stored baseline permission vector. The baseline permission vector is generated by a local permission directory in the trusted execution environment of the edge device hardware, verified by version number and digest value, with the field order consistent with the security level mapping vector. The conference client queries the local permission directory based on the core confidentiality identifier and request operation type, writing 1 to the authorized boundary field for allowed access and 0 to the authorized boundary field for disallowed access. The conference client sorts the objects by object number and calculates the digest value of the object numbers listed in the local permission directory, comparing the digest value with the digest value of the accessible object set in the offline access credentials byte by byte; if the comparison is inconsistent, the dynamic authorization result is written as "Access Denied".

[0070] When calculating cosine similarity, the meeting client multiplies the values ​​at the same position in the security level mapping vector and the baseline permission vector, and sums them to obtain a product sum. Then, it calculates the square root of the sum of squares of the values ​​in each of the two vectors. Finally, it divides the product sum by the product of the two square roots to obtain the attribute matching degree. Meeting data identifiers, participant identity tags, and request operation types must completely match the local permission directory. Cosine similarity is only used for joint judgment of auxiliary attributes such as meeting paragraph tags and data security level tags. The permission comparison threshold is determined by the meeting management system reading the local authorization logs of the previous 30 days where the verification result was passed and the access result was successful. Historical attribute matching degrees are sorted from smallest to largest, and the 5th percentile is taken as the permission comparison threshold. If the current 30 days of local authorization logs are insufficient, the meeting management system constructs allowed access samples and denied access samples based on the local permission directory generated during deployment initialization, calculates the attribute matching degree for each, adds the minimum attribute matching degree in the allowed access samples to the maximum attribute matching degree in the denied access samples, and divides by 2 to obtain the initial permission comparison threshold.

[0071] The output boundary for attribute matching is 0 to 1; if any vector has a magnitude of 0, field dimensions are inconsistent, or non-numeric fields are included, the attribute matching score will be written as 0. The baseline permission vector, identifier resolution matrix, and permission comparison threshold are generated from the local permission directory corresponding to the current meeting, offline access credentials, and local authorization logs; if the meeting data identifier, participant identity, or request operation type is not recorded in the local permission directory, authorization matching will not be performed.

[0072] When the meeting data identifier, participant identity label, and request operation type completely match the local permission directory, and the attribute matching degree is greater than the preset permission comparison threshold, the meeting client performs boundary field transformation on the feature dimensions in the security level mapping vector that meet the weight conditions, obtaining an authorization boundary set. The weight conditions are determined by the identifier resolution matrix generation method. When the value of a feature dimension in the security level mapping vector is not less than 1, it is determined that the weight conditions are met; when the value of a feature dimension in the security level mapping vector is less than 1, it is determined that the weight conditions are not met. During boundary field transformation, the meeting client reads the meeting data identifier, time interval, segment number range, and allowed operation type corresponding to the feature dimensions that meet the weight conditions from the local permission directory, and encapsulates them into an authorization boundary set. The attribute matching degree is used to trigger boundary field transformation and does not directly output allowed access. If any field in the meeting data identifier, participant identity label, and request operation type does not completely match, or the attribute matching degree is not greater than the permission comparison threshold, the meeting client writes the dynamic authorization result as denied access.

[0073] The conference client performs fragment token verification based on the authorization boundary set, conference data identifier, request operation type, and session heartbeat records to obtain a dynamic authorization result. Fragment token verification involves reading the conference data fragment sequence according to the time interval defined by the authorization boundary set, and then comparing the session period and heartbeat frequency of the access token for consistency. The conference client first compares the conference data identifier in the access request with the conference data identifier in the authorization boundary set, then determines whether the request operation type belongs to the allowed operation types in the authorization boundary set, whether the fragment sequence number is within the fragment number range of the authorization boundary set, and whether the request time is within the time interval of the authorization boundary set. When a session is established, the trusted execution environment (TEE) generates a new session identifier and initializes the heartbeat sequence number and token sequence number to 0 in the non-reversible counter storage area. Under weak network access conditions, the conference client generates a session heartbeat record through the secure call interface of the TEE, with fields including session identifier, heartbeat time, heartbeat sequence number, and token sequence number. The conference client calculates the time difference between two consecutive heartbeats and compares it with the session period in the offline access credentials. It calculates the heartbeat frequency based on the number of consecutive heartbeats and the statistical duration, and compares it with the allowed frequency range recorded in the credentials. Simultaneously, it verifies that the heartbeat sequence number and token sequence number are continuously increasing compared to the previous record. After each successful verification, the trusted execution environment increments the corresponding sequence number by 1 and saves it to identify duplicate requests or token replays. Upon reconnection, the trusted execution environment generates a new session identifier and reinitializes the heartbeat sequence number and token sequence number to 0. The old session identifier and its sequence number record cannot be reused. The current session terminates when any sequence number reaches the storage limit of the non-reversible counting storage area. When the conference data identifier, request operation type, fragment number range, request time, heartbeat frequency, heartbeat sequence number, and token sequence number all satisfy the authorization boundary set constraints, the dynamic authorization result is written as "Access Allowed," and a read token for the current conference data fragment is generated. If any condition is not met, the dynamic authorization result is written as "Access Denied."

[0074] When decrypting offline access credentials, the meeting client synchronously reads the session period, allowed heartbeat frequency range, local permission directory version number, and local permission directory digest value, and performs integrity verification together with the credential verification field. If a field is missing, the trusted current time exceeds the valid period, the trusted time is unavailable or has rolled back, or the version or digest verification is inconsistent, the local verification result will fail to be written.

[0075] The second embodiment of the present invention provides a cloud-edge collaborative meeting data management system, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

Claims

1. A method for managing meeting data in a cloud-edge collaborative manner, characterized in that, include: The meeting location, device status, and meeting progress are obtained. Based on the meeting location, device status, and meeting progress, environmental context features are constructed to obtain a multi-dimensional environmental feature set. Based on the multidimensional environmental feature set, a support vector machine is used to classify the security level of the current environment to obtain the initial security level of the current environment. When the initial security level is lower than the preset security threshold, the terminal-side perception data containing device operation data and network traffic data is obtained from the terminal-side security agent, and the terminal behavior anomaly detection is performed on the terminal-side perception data to obtain abnormal behavior characteristics. When the abnormal behavior features are present in the edge-side sensing data, the call frequency risk is assessed based on the abnormal behavior features to obtain a risk level value. Then, a downgrade strategy instruction is encapsulated based on the risk level value to obtain a permission downgrade instruction. Finally, the access matrix mask is clipped based on the permission downgrade instruction to obtain the updated permission boundary. Based on the updated permission boundaries and the meeting process, the credentials are encrypted to obtain offline access credentials. Based on the encrypted transmission message generated by the offline access credential, a transmission handshake quality check is performed to obtain the network connection status. When the network connection status is a weak network access status, local credential parsing and verification are performed based on the offline access credential to obtain a local verification result. Based on the local verification result, fragmented token reading control is performed to obtain a dynamic authorization result.

2. The meeting data management method for end-to-cloud collaboration according to claim 1, characterized in that, The step of detecting terminal behavior anomalies in the edge-sensed data to obtain abnormal behavior features includes: The message fields of the edge-side sensing data are parsed to obtain device operation logs and network traffic records; The device operation logs and network traffic records are subjected to adjacent window difference extraction according to the collection time window to obtain a time-series behavior sequence containing load difference, memory difference and connection growth rate; The time-series behavior sequence is compared with the pre-stored edge behavior baseline by the field difference, and the comparison difference is divided by the baseline standard deviation of the corresponding field to obtain the behavior deviation vector. When a vector element in the behavior deviation vector exceeds the deviation range of the corresponding field, the original behavior field corresponding to the vector element is extracted to obtain the behavior feature to be matched. The abnormal behavior features are obtained by performing cosine similarity matching between the behavioral features to be matched and the pre-built abnormal behavior feature library.

3. The meeting data management method for end-to-cloud collaboration according to claim 1, characterized in that, The step of assessing the risk level based on the frequency of calls according to the abnormal behavior characteristics includes: The abnormal behavior characteristics are parsed to obtain the abnormal device identifier, abnormal resource type, and abnormal occurrence time; Based on the abnormal device identifier, the abnormal resource type, and the time of the abnormality, extract resource call records from the pre-stored audit log to obtain the target call records within the corresponding time range; Extract the request operation type from the target call record, and count the number of calls within the sliding time window according to the abnormal resource type and the request operation type respectively. Divide the number of calls by the window duration to obtain the resource call frequency. The frequency of resource calls is calculated by comparing it with the pre-stored baseline frequency of resources to obtain the frequency deviation multiple. The risk level value is obtained by performing interval matching in a pre-stored risk level mapping table based on the frequency deviation multiple.

4. The meeting data management method for end-to-cloud collaboration according to claim 1, characterized in that, The process of encapsulating the downgrade strategy instruction based on the risk level value to obtain the permission downgrade instruction includes: The risk response level corresponding to the risk level value is obtained by querying the pre-stored risk response level table according to the risk level value. The pre-stored access policy table is queried based on the risk response level to obtain the restricted operation type, target device identifier, and instruction validity period; The restricted operation type, the target device identifier, and the effective period of the instruction are encoded in the order of instruction version field, device field, operation field, and time period field to obtain the downgrade instruction field; The message authentication code is calculated on the downgrade instruction field to obtain the instruction verification field; The downgrade instruction field and the instruction verification field are encapsulated into a message to obtain the permission downgrade instruction.

5. The meeting data management method for end-to-cloud collaboration according to claim 1, characterized in that, The step of trimming the access matrix mask according to the permission downgrade instruction to obtain the updated permission boundary includes: The permission downgrade instruction is parsed to obtain the target device identifier, restricted operation type, and instruction verification field; Initial permissions are read from a pre-stored access control list based on the target device identifier, and the initial permissions are converted into an original access control matrix according to the arrangement of device rows and data directory columns. Based on the restricted operation type, the sensitive data directories that need to be isolated are extracted from the pre-stored data classification directory to obtain a set of sensitive directories; Based on the column position of the sensitive directory set in the data directory column and the restricted operation type, matrix values ​​are assigned to obtain a boundary reconstruction matrix that only sets the operation position corresponding to the restricted operation type in the sensitive directory to zero and keeps the other operation bits to one. The updated permission boundary is obtained by performing a bitwise multiplication operation between the boundary reconstruction matrix and the original access control matrix.

6. The meeting data management method for end-to-cloud collaboration according to claim 1, characterized in that, The step of encapsulating ciphertext based on the updated permission boundaries and the meeting process to obtain offline access credentials includes: Based on the updated permission boundaries, the accessible data directory is read from the meeting data service, and the object numbers of the accessible data directory are extracted to obtain the set of accessible objects. Based on the meeting process, the current agenda stage and meeting security level label are read from the meeting management system, and the fields of the current agenda stage and meeting security level label are combined to obtain the process security level field; Based on the set of accessible objects and the process security level field, a security level label association and matching is performed to obtain a core confidentiality identifier that includes meeting segment label, data security level label and participant identity label; The key is derived by using the core confidentiality identifier and the terminal device hardware identifier to obtain the credential key; The offline access credential is obtained by grouping and encrypting the core confidentiality identifier, the issuance time, and the terminal device hardware identifier according to the credential key.

7. The meeting data management method for end-to-cloud collaboration according to claim 6, characterized in that, The step of parsing and verifying local credentials based on the offline access credentials to obtain a local verification result includes: The offline access credentials are read from the trusted execution environment of the terminal device to obtain local credential data; The local voucher data is parsed to obtain the encrypted identifier field, hardware binding field, valid time period field, identifier resolution matrix version field, identifier resolution matrix summary field, and voucher verification field; The hardware binding field is compared with the local hardware characteristics of the terminal device to obtain the hardware binding result. When the hardware binding result is consistent, a local key is derived based on the local hardware characteristics, and the encrypted identifier field is decrypted based on the derived local credential key to obtain the core secret identifier. The message authentication code is calculated for the encrypted identifier field, the hardware binding field, the valid time period field, the identifier resolution matrix version field, and the identifier resolution matrix digest field. The calculation result is then compared byte by byte with the credential verification field to obtain the local verification result.

8. The meeting data management method for end-to-cloud collaboration according to claim 6, characterized in that, The step of performing fragmented token reading control based on the local verification result to obtain dynamic authorization results includes: Based on the local verification result, the message fields of the access request instruction are parsed to obtain the meeting data identifier and the request operation type. The meeting data identifier and the core confidentiality identifier are jointly vector encoded, and the encoding result is input into a pre-configured identifier resolution matrix for matrix multiplication mapping to obtain a confidentiality level mapping vector; The attribute matching degree is obtained by calculating the cosine similarity between the security level mapping vector and the locally stored baseline permission vector. When the meeting data identifier, the participant identity tag, and the request operation type completely match the local permission directory, and the attribute matching degree is greater than the preset permission comparison threshold, the feature dimensions that meet the weight conditions in the security level mapping vector are transformed into boundary fields to obtain the authorization boundary set. The dynamic authorization result is obtained by performing fragment token verification based on the authorized boundary set, the meeting data identifier, the request operation type, and the session heartbeat record. The fragment token verification involves reading the meeting data fragment sequence according to the time interval defined by the authorized boundary set, comparing the session period and heartbeat frequency of the access token for consistency, and verifying that the heartbeat sequence number and token sequence number are continuously increasing.

9. A cloud-edge collaborative conference data management system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the method described in any one of claims 1 to 8.

Images