WO2025138024A1 - 用于生成安全策略的方法及通信设备 - Google Patents

用于生成安全策略的方法及通信设备 Download PDF

Info

Publication number
WO2025138024A1
WO2025138024A1 PCT/CN2023/142889 CN2023142889W WO2025138024A1 WO 2025138024 A1 WO2025138024 A1 WO 2025138024A1 CN 2023142889 W CN2023142889 W CN 2023142889W WO 2025138024 A1 WO2025138024 A1 WO 2025138024A1
Authority
WO
WIPO (PCT)
Prior art keywords
security
policy
network element
security policy
terminal device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2023/142889
Other languages
English (en)
French (fr)
Inventor
甘露
付玉龙
曹进
易威
魏腾龙
蔺如嫣
李晖
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Oppo Mobile Telecommunications Corp Ltd
Original Assignee
Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangdong Oppo Mobile Telecommunications Corp Ltd filed Critical Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority to PCT/CN2023/142889 priority Critical patent/WO2025138024A1/zh
Publication of WO2025138024A1 publication Critical patent/WO2025138024A1/zh
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/37—Managing security policies for mobile devices or for controlling mobile applications

Definitions

  • a method for generating a security policy comprising: a security policy network element generates a security policy, wherein the security policy is associated with a service of a terminal device; and the security policy network element sends the security policy to a policy execution network element.
  • a method for generating a security policy comprising: a policy execution network element sends a first request message to a first network element, the first request message is used to request a security policy, the security policy is associated with the service of the terminal device, the first network element includes a security policy network element and/or a policy detection network element; the policy execution network element receives the security policy from the security policy network element.
  • a method for generating a security policy comprising: a policy detection network element receives a first request message from a policy execution network element, the first request message is used to request a security policy; in response to the first request message, the policy detection network element generates a security requirement corresponding to the service of the terminal device; the policy detection network element sends the security requirement to a security policy network element, and the security requirement is used by the security policy network element to generate the security policy.
  • a method for generating a security policy comprising: a terminal device sends a first indication message to a policy execution network element, the first indication message being used to indicate that a service of the terminal device has changed; the terminal device receives a security policy from the policy execution network element, the security policy being associated with the service of the terminal device.
  • a communication device wherein the communication device is a security policy network element, and the communication device includes: a generation unit, used to generate a security policy, wherein the security policy is associated with a service of a terminal device; and a sending unit, used to send the security policy to a policy execution network element.
  • a communication device which is a policy detection network element, and the communication device includes: a receiving unit, used to receive a first request message from a policy execution network element, the first request message is used to request a security policy; a generating unit, used to generate a security requirement corresponding to the service of the terminal device in response to the first request message; and a sending unit, used to send the security requirement to the security policy network element, the security requirement is used by the security policy network element to generate the security policy.
  • a communication device which is a terminal device, and the communication device includes: a sending unit, used to send first indication information to a policy execution network element, the first indication information is used to indicate that a service of the terminal device has changed; a receiving unit, used to receive a security policy from the policy execution network element, the security policy is associated with the service of the terminal device.
  • FIG3 is a schematic diagram of the structure of an intelligent zero-trust architecture.
  • FIG. 4 is a schematic flowchart for generating a security policy provided in an embodiment of the present application.
  • FIG. 7 is another schematic flowchart for generating a security policy provided in an embodiment of the present application.
  • FIG8 is a schematic diagram of the structure of a zero-trust architecture provided in an embodiment of the present application.
  • the network elements or components in the NIST zero trust architecture may include a policy engine (PE), a policy administrator (PA), and a policy enforcement point (PEP).
  • PE policy engine
  • PA policy administrator
  • PEP policy enforcement point
  • the policy engine is responsible for making the final decision on resource access for a given subject.
  • the policy engine can use input from trust algorithms to grant, deny, or revoke access to resources based on enterprise policy and input from external sources such as continuous diagnostics and mitigation (CDM) systems, threat intelligence services, etc.
  • CDM continuous diagnostics and mitigation
  • the policy engine and policy administrator can work together.
  • the policy engine can make decisions and record the decision results (approval or rejection), and the policy administrator can execute the decision.
  • the policy administrator may be responsible for establishing and/or closing a communication path between a subject and a resource. For example, the policy administrator may send a command to a policy enforcement point to establish or close a communication path between a subject and a resource. In some implementations, the policy administrator may communicate with the policy enforcement point to create the communication path. The communication between the policy administrator and the policy enforcement point may be performed via a control plane.
  • the policy administrator can generate a per-session specific authentication token or credential that the client can use to access enterprise resources.
  • the policy administrator is closely associated with the policy engine, and can allow or deny sessions based on the policy engine's decision. If the session is authorized and the request is authenticated, the policy administrator can send a command to the policy enforcement point to allow the session to begin. If the session is denied or the previous approval is revoked, the policy administrator can send a command to the policy enforcement point to close the connection.
  • the policy administrator and the policy engine are two independent components, or the policy administrator and the policy engine are integrated into one component.
  • a policy enforcement point can be responsible for enabling, monitoring, and terminating connections between principals and resources.
  • a policy enforcement point can communicate with a policy administrator.
  • a policy enforcement point can forward requests and/or receive policy updates from a policy administrator.
  • the policy enforcement point is a single logical component, but the policy enforcement point can also be divided into two components.
  • the policy enforcement point can include a client and a resource.
  • the client can be, for example, an agent on a terminal device, and the resource can be, for example, a resource front-end gateway component that controls access.
  • the above components can communicate through a separate control plane, while application data can be transmitted on the data plane.
  • the zero trust architecture may also include other components.
  • the zero trust architecture may also include one or more of the following components: CDM system, industry compliance system, threat intelligence source, network and system activity logs, data access policy, identity management system, security information and event management (SIEM) system, enterprise public key infrastructure (PKI).
  • CDM system industry compliance system
  • threat intelligence source threat intelligence source
  • network and system activity logs data access policy
  • SIEM security information and event management
  • PKI enterprise public key infrastructure
  • the components in the intelligent zero trust architecture may include an intelligent policy engine (IPE) and an intelligent agent portal (IAP).
  • IPE intelligent policy engine
  • IAP intelligent agent portal
  • IPE can be responsible for dynamically authorizing access requests. IPE can use reinforcement learning algorithms to maximize assurance scores, that is, evaluate and adjust trust policies in response to real-time observed user or device behavior, network resource access events, and newly detected abnormal behaviors. IAP can support federated learning (FL), which is a distributed learning method that can share and update models among multiple agents to provide a comprehensive model of the network environment.
  • FL federated learning
  • the above communication system can be provided with common capabilities by a minimized and simple core, such as endogenous intelligent strategies, security, and flexible spectrum management.
  • the above communication system can be specially optimized for four capability directions, including clouding, critical IoT, ubiquitous IoT and sensing.
  • the subsystems can choose whether to maintain air interface compatibility as needed, and determine the degree of sharing air interface technology and hardware design with the broadband cellular subsystem as needed.
  • the above communication system can replace the general and complex traditional software algorithms with a black-boxed and specialized artificial intelligence (AI) algorithm library to achieve "relative independence and individual optimization" of each subsystem and greatly simplify the communication protocol.
  • AI artificial intelligence
  • the switching and combination of multiple subsystems can be achieved through the switching and combination of multiple AI algorithms.
  • the devices in the communication system can use security policies to communicate.
  • the security policy can be generated by the network element in the zero trust architecture.
  • the security policy can be generated by the PE.
  • the PE can update the security policy.
  • Some communication systems have introduced a variety of services.
  • the business scenarios in the communication system may include smart homes, smart wearable devices, zero-power devices, telepathic Internet, twin body area network, intelligent interaction, smart agriculture, smart industry, super-energy transportation, precision medicine, universal education, virtual travel, instant rescue, "no man's land” detection, etc.
  • the rich business scenarios also pose new challenges to the security of the communication system.
  • the security policy and business data in the zero-trust architecture are not integrated enough, and can no longer meet the security requirements of different businesses in the communication system.
  • the 6G network environment is expected to achieve deep perception of business data and network status, which requires security policies to be seamlessly integrated with real-time business data and network status information to achieve accurate risk assessment and policy deployment.
  • ZTA and i-ZTA take data-driven security policy implementation into consideration, they have not yet fully achieved in-depth integration with the rich business data and network status information in the 6G network environment. Therefore, in a rapidly changing network environment, current security policies may not be able to fully utilize real-time data for effective risk prediction and response, resulting in inaccurate security responses or insufficient timeliness of security responses, and failing to fully realize the potential of data-driven security policies.
  • security policies are updated or new security policies are generated only when the preset conditions are met.
  • security policies need to be updated they are updated manually.
  • i-ZTA introduces intelligent components, i-ZTA is not integrated with business data, but only updates security policies based on changes in the network environment.
  • an embodiment of the present application provides a method for generating a security policy.
  • a security policy associated with the service of the terminal device can be generated, thereby meeting the security requirements of different services in the communication system.
  • a security policy network element generates a security policy.
  • the security policy network element may be, for example, a PE.
  • the security policy network element may be an AI Sec PE.
  • the security policy network element may also be replaced by other terms, such as the security policy network element may be replaced by a policy engine or a policy engine network element.
  • the security policy may be associated with the service of the terminal device.
  • the security policy network element may generate a security policy corresponding to the service based on the service of the terminal device.
  • different services may correspond to different security policies.
  • different services may also correspond to the same security policy, which is not specifically limited in the embodiments of the present application.
  • the embodiments of the present application can achieve accurate risk assessment and policy deployment by integrating service data with security policies.
  • security policies can be updated based on changes in the services of terminal devices to improve the real-time nature of security policies.
  • a security policy network element can update security policies when the services of terminal devices change.
  • security policies can respond to changes in services in real time and meet the latency requirements of the communication system.
  • the 6G network is expected to support higher data rates and lower latency, which means that the network environment and service requirements will be more dynamic and changeable.
  • the embodiments of the present application update security policies based on changes in the services of terminal devices, so as to respond to the dynamics of services in real time.
  • the security policy corresponding to the terminal device's business is generated based on the state changes.
  • Deep forest is a decision tree ensemble method with a cascade structure, including two parts: multi-granularity scanning and cascade forest.
  • multi-granularity scanning scans the original input features to generate new feature vectors by setting sliding windows of different granularities; cascade forest processes the output of the previous cascade and the original input features to generate the input data of the next cascade.
  • This application can use measure-aware feature reuse (MAFR) and measure-aware layer growth (MALG) to achieve the multi-label output task goal of deep forest.
  • MAFR selects the input of the next cascade based on the confidence of the output of the previous cascade, and MALG determines whether the cascade layer training is completed according to the optimal evaluation index. Since the deep forest model has a fast training speed and can be easily parallelized and can process large-scale data sets, by using the deep forest model to generate security policies, the speed of generating security policies can be improved and the accuracy of security policies can be guaranteed.
  • the sub-requirement in the security requirement may be a sub-requirement in the security requirement list.
  • the security requirement may include multiple sub-requirements in the security requirement list.
  • the security requirement list may be a preset security requirement list.
  • the security requirement list may be used as an input to the first model.
  • the first model may establish a correspondence between services of the terminal device and sub-requirements, and may select corresponding sub-requirements based on the services of the terminal device.
  • a security policy may include multiple sub-policies, or in other words, a security policy may be composed of multiple sub-policies.
  • a security policy may be composed of multiple sub-policies.
  • the generated security policy may include the following sub-policies: a sub-policy corresponding to lightweight authentication, a sub-policy corresponding to distributed security, a sub-policy corresponding to data authorization, and a sub-policy corresponding to low-level security protection.
  • the input parameters of the first model may include security capabilities.
  • the security capabilities may be security capabilities corresponding to the services of the terminal device, or the security capabilities may be determined based on the services of the terminal device.
  • security capabilities may also be referred to as security functions.
  • the generated security policy may correspond to the security capabilities, and may meet the security requirements of different security capabilities. For example, when the security capabilities change, the security policy network element may generate a new security policy or update the security policy.
  • the security capability may include multiple sub-capabilities, or in other words, the security capability may be a modular security capability.
  • the security capability may be a modular security capability.
  • the sub-capability may be a sub-capability in a security capability library.
  • the security capability library may be, for example, a 3GPP security capability library.
  • the security capability library includes multiple sub-capabilities. When generating a security policy, a corresponding sub-capability may be selected according to actual business needs.
  • the security capability library may also be referred to as a modular security capability library.
  • the security capability library may be used as an input to the first model.
  • the first model may establish a correspondence between services of the terminal device and sub-capabilities, and may select corresponding sub-capabilities based on the services of the terminal device.
  • security capabilities may include one or more of the following sub-capabilities: 128-bit keys, authentication and key agreement (AKA), identity-based authorization, PKI, quantum-resistant keys, distributed authentication, attribute-based authorization, authorization (Oauth), physical layer keys, lightweight authentication, data-based authorization, blockchain, etc.
  • AKA authentication and key agreement
  • identity-based authorization PKI
  • quantum-resistant keys distributed authentication
  • attribute-based authorization authorization
  • physical layer keys lightweight authentication, data-based authorization, blockchain, etc.
  • AKA may include one or more of the following: 5G-AKA, AES-AKA, EAP-AKA, BEST-AKA, EPS-AKA, EAP-TLS, EAP-AKA', etc.
  • security capabilities may span multiple security domains from the physical layer to the application layer.
  • Security capabilities may include multiple mechanisms such as identity authentication, authorization, data encryption, integrity verification, and replay attack protection.
  • the security capabilities may include security capabilities corresponding to security requirements.
  • the security capabilities may include security capabilities of different protocol layers.
  • the security capabilities may include one or more of the following: security capabilities of the non-access layer, security capabilities of the RRC layer, security capabilities of the physical layer, and security capabilities of the application layer.
  • the security capabilities of the non-access layer may include security capabilities corresponding to one or more of the following security requirements: authentication and key negotiation, data confidentiality, data integrity, and exception handling mechanisms.
  • the security capabilities of the RRC layer may include security capabilities corresponding to one or more of the following security requirements: data confidentiality, data integrity, security mode command setting, sequence number synchronization mechanism, and exception handling mechanism.
  • the security capabilities of the physical layer may include security capabilities corresponding to one or more of the following security requirements: encryption, channel coding and modulation, and physical layer identity authentication and fingerprint recognition.
  • the security capabilities of the application layer may include security capabilities corresponding to one or more of the following security requirements: network slicing security, user privacy protection, and security of open interfaces.
  • the security capabilities corresponding to authentication and key negotiation may include one or more of the following: EPS-AKA, 5G-AKA, EAP-AKA, EAP-AKA', EAP-TLS, lightweight authentication protocol (such as BEST-AKA), and ultra-lightweight authentication protocol.
  • the security capabilities corresponding to data confidentiality may include one or more of the following: EEA0, EEA1, EEA2, EEA3, NEA0, NEA1, and NEA2.
  • the security capabilities corresponding to data integrity may include one or more of the following: EIA0, EIA1, EIA2, EIA3, NEA0, NEA1, and NEA2.
  • the security capabilities corresponding to the exception handling mechanism may include one or more of the following: authentication exception handling, network failure and recovery, security mode command error handling, and distributed denial of service (DDOS) processing.
  • DDOS distributed denial of service
  • the security capabilities corresponding to data confidentiality may include one or more of the following: EEA0, EEA1, EEA2, EEA3, NEA0, NEA1, NEA2.
  • the security capabilities corresponding to data integrity may include one or more of the following: EIA0, EIA1, EIA2, EIA3, NEA0, NEA1, NEA2.
  • the security capabilities corresponding to the security mode command setting may include the encryption algorithm and/or integrity algorithm specified for use.
  • the security capabilities corresponding to the exception handling mechanism may include one or more of the following: security mode failure, connection loss, and reconstruction loss.
  • security capabilities corresponding to encryption may include data scrambling.
  • Security capabilities corresponding to channel coding and modulation may include one or more of the following: low-density parity-check (LDPC), Turbo code, and polar code.
  • Security capabilities corresponding to physical layer authentication and fingerprinting may include one or more of the following: device-specific radio frequency feature identification, time and frequency analysis, signal waveform analysis, environment and channel characteristics.
  • the security capabilities corresponding to network slicing security may include one or more of the following: slice isolation, slice secondary authentication.
  • the security capabilities corresponding to user privacy protection may include one or more of the following: subscription concealed identifier (SUCI), temporary mobile subscriber identity (TMSI), globally unique temporary UE identity (GUTI) (such as 5G-GUTI), user consent, subscriber data management and exposure.
  • the security capabilities corresponding to the security of open interfaces may include one or more of the following: OAuth 2.0, OpenID Connect, and authentication and key management for application (AKMA).
  • the security capability can be compatible with the security mechanisms of different communication networks (such as 4G networks, 5G networks, etc.) and provide necessary scalability for future network environments, ensuring that with the development of network technology, the security measures provided in the embodiments of the present application can still remain forward-looking and flexible.
  • different communication networks such as 4G networks, 5G networks, etc.
  • a security capability may include multiple sub-capabilities
  • a security policy may include multiple sub-policies
  • the multiple sub-policies may correspond to the multiple sub-capabilities, respectively.
  • the multiple sub-policies may correspond to the multiple sub-capabilities one by one.
  • the required security capabilities may include distributed authentication and authorization based on business data.
  • sub-policies corresponding to distributed authentication and sub-policies corresponding to authorization based on business data can be generated.
  • the input parameters of the first model may include security rules and/or security situation.
  • the security situation may include system security situation and/or network security situation.
  • the security situation may include, for example, one or more of the following: network behavior monitoring, security operation and maintenance management, and system event logs.
  • Security rules may include compliance requirements and/or threat analysis.
  • security rules may include static rules and/or dynamic rules.
  • Static rules may include sets of rules that do not change frequently.
  • Static rules may include one or more of the following: data access policies, public key infrastructure, identity management rules, and configuration of security information and event management.
  • Dynamic rules may include one or more of the following: real-time feedback from data monitoring, compliance detection, threat intelligence updates, and activity logs. This information helps the core network understand the current security environment and ongoing events.
  • the security policy network element can update the security policy or generate a new security policy so that the generated security policy can adapt to the rapidly changing network environment and emerging threats.
  • the input parameters of the first model may include any one of the above parameters, or the input parameters of the first model may include multiple of the above parameters.
  • the input parameters of the first model may include system type, security requirements, security capabilities, security rules, and security posture, as shown in FIG8.
  • the input parameters of the first model may include system type, security requirements, and security capabilities, as shown in FIG9.
  • the security requirements may be preset security requirements.
  • the security requirements may be manually determined by a staff member. After the staff member determines the security requirements, the security requirements may be input into the first model.
  • the staff member may determine the security requirements based on a security requirements list. For example, the staff member may select one or more sub-requirements from the security requirements list according to the business of the terminal device to form a final security requirement.
  • the security requirement may be generated based on the second model. Generating the security requirement through the second model may make the generation of the security requirement more intelligent.
  • the second model may be any neural network model.
  • the second model may be an AI model or an ML model.
  • the second model may be a deep forest model.
  • security requirements may be generated by other network elements other than the security policy network element.
  • security requirements may be generated by a policy detection network element.
  • the policy detection network element may be a PD, for example.
  • the policy detection network element may generate security requirements based on the second model. After generating the security requirements, the policy detection network element may send the security requirements to the security policy network element, as shown in Figure 9. In some implementations, the policy detection network element may send the security requirements to the security policy network element through the policy management network element.
  • the security policy network element may consider that the service of the terminal device has changed. In this case, the security policy network element may generate a security policy.
  • the input parameters of the second model may include one or more of the following: security rules and business data.
  • Business data may include one or more of the following: network traffic, device status, and service quality parameters. Changes in business data may reflect changes in business requirements. For example, if a terminal device transitions from a business with low security requirements to a business with high security requirements, the corresponding business data will also change.
  • Security rules can include static rules and/or dynamic rules.
  • Static rules can include sets of rules that do not change frequently.
  • Static rules can include one or more of the following: data access policies, public key infrastructure, identity management rules, and configuration of security information and event management.
  • Dynamic rules can include one or more of the following: real-time feedback from data monitoring, compliance detection, threat intelligence updates, and activity logs. This information helps the core network understand the current security environment and ongoing events.
  • the output of the policy detection network element includes security requirements.
  • the security requirements can be generated based on business data and/or security rules.
  • the security requirements can be security requirements in the security requirements list.
  • the policy detection network element can have intelligent analysis and prediction functions, and can use the second model and data analysis technology to process and interpret input data to generate accurate security requirements.
  • the policy detection network element may generate security requirements when the service of the terminal device changes.
  • the policy execution network element may detect whether the service of the terminal device changes.
  • the policy execution network element may send a first request message to the policy detection network element (such as step S510 in Figure 5 or step S610 in Figure 6), and the first request message is used to request a security policy.
  • the policy detection network element generates security requirements (such as step S620 in Figure 6).
  • the policy detection network element may generate security requirements based on the second model.
  • the policy detection network element may send the security requirements to the security policy network element (such as step S630 in Figure 6).
  • the policy execution network element may send the first request message to the policy detection network element through the policy management network element.
  • the policy execution network element may send the first request message to the policy management network element, and after receiving the first request message, the policy management network element may forward the first request message to the policy detection network element.
  • the embodiment of the present application does not specifically limit the manner in which the policy execution network element determines whether the service of the terminal device has changed.
  • the policy execution network element may monitor the service of the terminal device to determine whether the service of the terminal device has changed.
  • the terminal device may send first indication information (such as step S710 in Figure 7) to the policy execution network element when the service has changed, and the first indication information is used to indicate that the service of the terminal device has changed.
  • the policy execution network element may determine whether the service of the terminal device has changed based on the indication of the terminal device.
  • the policy detection network element may also generate security requirements according to the instructions of the security policy network element. For example, the security policy network element may determine whether it is necessary to generate or update the security policy based on certain rules (such as the calculated trust value). In the case of determining that it is necessary to generate or update the security policy, the security policy network element may send instruction information to the policy detection network element to instruct the policy detection network element to generate a new security requirement.
  • the security policy network element may send instruction information to the policy detection network element to instruct the policy detection network element to generate a new security requirement.
  • the solution of the embodiment of the present application may include two security architectures.
  • One security architecture includes a security policy network element.
  • the security policy network element may be an engine component, so the architecture may also be called a single-engine architecture, as shown in FIG8.
  • Another security architecture includes a security policy network element and a policy detection network element.
  • the security policy network element and the policy detection network element may both be engine components, so the architecture may also be called a dual-engine architecture, as shown in FIG9.
  • FIG8 and FIG9 are introduced below.
  • the security policy network element may generate a security policy based on the first model.
  • the input parameters of the first model may include one or more of the following: security requirements, security capabilities, system types, security rules, and security posture.
  • step S1050 the PA forwards the security policy to the PEP.
  • step S1060 the PEP sends a security policy to the UE.
  • PE can trigger PE to initiate security policy update when the UE's service changes.
  • PEP and UE can obtain the same security policy, and subsequently PEP and UE can perform security protection based on the same security policy and security functions.
  • the PEP and the UE can use the same physical layer key mechanism for secure transmission protection.
  • step S1140 PE determines whether a new security policy is needed. If a new security policy is needed, step S1150 is executed; if a new security policy is not needed, the process ends.
  • PE can trigger PE to initiate security policy update when the UE's service changes.
  • PEP and UE can obtain the same security policy, and subsequently PEP and UE can perform security protection based on the same security policy and security functions. For example, PEP and UE can use the same physical layer key mechanism for secure transmission protection.
  • PE can train the first model.
  • PE can request relevant data from the core network element (such as the network data analysis function (NWDAF) element), and PE can use the relevant data to train the first model.
  • the relevant data may include security requirements, security rules, security situation, system type, security capabilities, etc.
  • PE can request relevant data from the core network element (such as the NWDAF element), and PE can use the relevant data to train the first model.
  • the relevant data may include security requirements, security rules, security situation, system type, security capabilities, etc.
  • the system When an outsider attempts to enter illegally, the system will analyze the collected signal changes through the precise sensing of the 6G network, and then determine the presence of the intruder. Once it is confirmed that an abnormal situation has occurred, the system will immediately send an alarm to the resident's mobile device to ensure the safety of family property.
  • each business scenario is accompanied by unique security requirements due to its unique characteristics. Whether it is regular home operations, real-time monitoring of user behavior status, or instant alarm for illegal intrusion, the security challenges and requirements behind them have their own unique levels and differences.
  • the specific security requirements can be shown in Table 1.
  • the smart bracelet uses AR technology to show him the steps to treat the injury, and the low-frequency electrical pain therapy device built into the smart wristband quickly relieves his pain. During this period, all data is transmitted in real time through the network to ensure that the user gets the best medical advice and rescue at the first time.
  • Smart IoT devices are reflected in many scenarios, and shopping malls are a good example.
  • 3GPP IoT devices can be deployed on store shelves and storage areas to sense the inventory status of commodities in real time and adjust the supply and marketing strategy accordingly to ensure supply and demand balance and avoid inventory backlogs.
  • IoT devices can sense and adapt to changes in the flow of people and temperature in shopping malls in real time.
  • the lighting and air-conditioning systems can be automatically adjusted to create a more suitable shopping environment for the public.
  • energy consumption can be reduced, thereby effectively optimizing operating costs.
  • shopping malls have introduced indoor navigation systems driven by environmental IoT to provide customers with accurate indoor navigation services, easily guiding them to find parking spaces and destination stores.
  • FIG12 is a schematic block diagram of a communication device provided in an embodiment of the present application.
  • the communication device 1200 shown in FIG12 can be any security policy network element described above.
  • the communication device shown in FIG12 includes a generating unit 1210 and a sending unit 1220.
  • the generating unit 1210 and the determining unit may be processors, and the sending unit 1220 and the receiving unit may be transceivers.
  • the communication device 1200 may further include a memory.
  • the generating unit 1210 is configured to generate a security policy, where the security policy is associated with a service of the terminal device.
  • the sending unit 1220 is used to send the security policy to the policy execution network element.
  • the generating unit is configured to: generate the security policy based on a first model.
  • the input parameters of the first model include at least one of the following: The corresponding system type, the security requirements corresponding to the business of the terminal device, and the security capabilities corresponding to the business of the terminal device.
  • the security capability includes multiple sub-capabilities
  • the security policy includes multiple sub-policies
  • the multiple sub-policies correspond to the multiple sub-capabilities, respectively.
  • the security requirement includes multiple sub-requirements in a security requirement list.
  • the input parameters of the first model also include at least one of the following: security rules, network security situation, and system security situation.
  • the communication device further includes: a receiving unit, configured to receive the security requirement from a policy detection network element.
  • the security requirement is generated when a service of the terminal device changes.
  • the security requirements are generated based on a second model.
  • the communication device before generating a security policy, further includes: a receiving unit, configured to receive a first request message sent by the policy execution network element, wherein the first request message is used to request the security policy, and the first request message is sent when a service of the terminal device changes.
  • the communication device further includes a judgment unit, wherein the judgment unit is configured to judge whether it is necessary to generate the security policy; and the generation unit is configured to generate the security policy if it is necessary to generate the security policy.
  • FIG13 is a schematic block diagram of a communication device provided in an embodiment of the present application.
  • the communication device 1300 shown in FIG13 can be any policy execution network element described above.
  • the communication device shown in FIG13 includes a sending unit 1310 and a receiving unit 1320.
  • the transmitting unit 1310 and the receiving unit 1320 may be transceivers.
  • the communication device 1300 may further include a memory and a processor.
  • the sending unit 1310 is used to send a first request message to a first network element, where the first request message is used to request a security policy, where the security policy is associated with the service of the terminal device, and the first network element includes a security policy network element and/or a policy detection network element.
  • the receiving unit 1320 is configured to receive the security policy from the security policy network element.
  • the security policy is generated based on a first model.
  • the input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, a security requirement corresponding to the service of the terminal device, and a security capability corresponding to the service of the terminal device.
  • the security capability includes multiple sub-capabilities
  • the security policy includes multiple sub-policies
  • the multiple sub-policies correspond to the multiple sub-capabilities, respectively.
  • the security requirement includes multiple sub-requirements in a security requirement list.
  • the input parameters of the first model also include at least one of the following: security rules, network security situation, and system security situation.
  • the security requirement is sent by the policy detection network element to the security policy network element.
  • the security requirement is generated when a service of the terminal device changes.
  • the security requirements are generated based on a second model.
  • the receiving unit before sending the first request message to the first network element, is further used to: receive first indication information from a terminal device, where the first indication information is used to indicate that a service of the terminal device has changed.
  • FIG14 is a schematic block diagram of a communication device provided in an embodiment of the present application.
  • the communication device 1400 shown in FIG14 can be any of the policy detection network elements described above.
  • the communication device shown in FIG14 includes a receiving unit 1410 , a generating unit 1420 and a sending unit 1430 .
  • the receiving unit 1410 and the sending unit 1430 may be transceivers, and the generating unit 1420 may be a processor.
  • the communication device 1400 may further include a memory.
  • the receiving unit 1410 is configured to receive a first request message from a policy execution network element, where the first request message is used to request a security policy.
  • the generating unit 1420 is used to generate a security requirement corresponding to the service of the terminal device in response to the first request message.
  • the sending unit 1430 is used to send the security requirement to the security policy network element, and the security requirement is used by the security policy network element to generate the security policy.
  • the security policy is generated based on a first model.
  • the input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, the security requirements, and a security capability corresponding to the service of the terminal device.
  • the security capability includes multiple sub-capabilities
  • the security policy includes multiple sub-policies
  • the multiple sub-policies correspond to the multiple sub-capabilities, respectively.
  • the security requirement includes multiple sub-requirements in a security requirement list.
  • the security requirements are generated based on a second model.
  • FIG15 is a schematic block diagram of a communication device provided in an embodiment of the present application.
  • the communication device 1500 shown in FIG15 can be any terminal device described above.
  • the communication device shown in FIG15 includes a sending unit 1510 and a receiving unit 1520.
  • the transmitting unit 1510 and the receiving unit 1520 may be transceivers.
  • the communication device 1500 may further include a memory and a processor.
  • the sending unit 1510 is configured to send first indication information to a policy execution network element, where the first indication information is used to indicate that a service of the terminal device has changed;
  • the receiving unit 1520 is used to receive a security policy from the policy execution network element, where the security policy is associated with the service of the terminal device.
  • the security policy is generated based on a first model.
  • the input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, a security requirement corresponding to the service of the terminal device, and a security capability corresponding to the service of the terminal device.
  • the security capability includes multiple sub-capabilities
  • the security policy includes multiple sub-policies
  • the multiple sub-policies correspond to the multiple sub-capabilities, respectively.
  • the security requirement belongs to a plurality of sub-requirements in a security requirement list.
  • the input parameters of the first model also include at least one of the following: security rules, network security situation, and system security situation.
  • the security requirement is sent by a policy detection network element to the security policy network element.
  • the security requirement is generated when a service of the terminal device changes.
  • the security requirements are generated based on a second model.
  • the size of the serial numbers of the above-mentioned processes does not mean the order of execution.
  • the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only schematic.
  • the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, 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 interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.
  • the computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.
  • the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center.
  • the computer-readable storage medium may be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated.
  • the available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital video disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.
  • a magnetic medium e.g., a floppy disk, a hard disk, a magnetic tape
  • an optical medium e.g., a digital video disc (DVD)
  • DVD digital video disc
  • SSD solid state disk

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请提供了一种用于生成安全策略的方法及通信设备。该方法包括：安全策略网元生成安全策略，所述安全策略与终端设备的业务相关联；所述安全策略网元向策略执行网元发送所述安全策略。

Description

用于生成安全策略的方法及通信设备 技术领域
本申请涉及通信技术领域，并且更为具体地，涉及一种用于生成安全策略的方法及通信设备。
背景技术
为了保证通信系统的安全性，通信系统中的设备可以使用安全策略进行通信。安全策略可以由零信任架构中的网元(如安全策略网元)生成。
目前，安全策略网元是基于网络状态生成安全策略的。但是，随着通信系统的不断演进，这种生成方式已经不能满足通信系统的安全要求。
发明内容
本申请提供一种用于生成安全策略的方法及通信设备。下面对本申请涉及的几个方面进行详细介绍。
第一方面，提供了一种用于生成安全策略的方法，包括：安全策略网元生成安全策略，所述安全策略与终端设备的业务相关联；所述安全策略网元向策略执行网元发送所述安全策略。
第二方面，提供了一种用于生成安全策略的方法，包括：策略执行网元向第一网元发送第一请求消息，所述第一请求消息用于请求安全策略，所述安全策略与所述终端设备的业务相关联，所述第一网元包括安全策略网元和/或策略检测网元；所述策略执行网元接收来自所述安全策略网元的所述安全策略。
第三方面，提供了一种用于生成安全策略的方法，包括：策略检测网元接收来自策略执行网元的第一请求消息，所述第一请求消息用于请求安全策略；响应于所述第一请求消息，所述策略检测网元生成与所述终端设备的业务对应的安全需求；所述策略检测网元向安全策略网元发送所述安全需求，所述安全需求用于所述安全策略网元生成所述安全策略。
第四方面，提供了一种用于生成安全策略的方法，包括：终端设备向策略执行网元发送第一指示信息，所述第一指示信息用于指示所述终端设备的业务发生变化；所述终端设备接收来自所述策略执行网元的安全策略，所述安全策略与所述终端设备的业务相关联。
第五方面，提供了一种通信设备，所述通信设备为安全策略网元，所述通信设备包括：生成单元，用于生成安全策略，所述安全策略与终端设备的业务相关联；发送单元，用于向策略执行网元发送所述安全策略。
第六方面，提供了一种通信设备，所述通信设备为策略执行网元，所述通信设备包括：发送单元，用于向第一网元发送第一请求消息，所述第一请求消息用于请求安全策略，所述安全策略与所述终端设备的业务相关联，所述第一网元包括安全策略网元和/或策略检测网元；接收单元，用于接收来自所述安全策略网元的所述安全策略。
第七方面，提供了一种通信设备，所述通信设备为策略检测网元，所述通信设备包括：接收单元，用于接收来自策略执行网元的第一请求消息，所述第一请求消息用于请求安全策略；生成单元，用于响应于所述第一请求消息，生成与所述终端设备的业务对应的安全需求；发送单元，用于向安全策略网元发送所述安全需求，所述安全需求用于所述安全策略网元生成所述安全策略。
第八方面，提供了一种通信设备，所述通信设备为终端设备，所述通信设备包括：发送单元，用于向策略执行网元发送第一指示信息，所述第一指示信息用于指示所述终端设备的业务发生变化；接收单元，用于接收来自所述策略执行网元的安全策略，所述安全策略与所述终端设备的业务相关联。
随着通信系统的不断演进，通信系统中的业务场景也越来越丰富，本申请可以生成与终端设备的业务相关联的安全策略，使得生成的安全策略能够与终端设备的业务相匹配，以满足通信系统的安全要求。
附图说明
图1是本申请实施例应用的无线通信系统100。
图2是一种传统的零信任架构的结构示意图。
图3是一种智能零信任架构的结构示意图。
图4是本申请实施例提供的一种用于生成安全策略的示意性流程图。
图5是本申请实施例提供的另一种用于生成安全策略的示意性流程图。
图6是本申请实施例提供的另一种用于生成安全策略的示意性流程图。
图7是本申请实施例提供的另一种用于生成安全策略的示意性流程图。
图8是本申请实施例提供的一种零信任架构的结构示意图。
图9是本申请实施例提供的另一种零信任架构的结构示意图。
图10是本申请实施例提供的一种生成安全策略的示意性流程图。
图11是本申请实施例提供的另一种生成安全策略的示意性流程图。
图12是本申请实施例提供的一种通信设备的示意性框图。
图13是本申请实施例提供的另一种通信设备的示意性框图。
图14是本申请实施例提供的另一种通信设备的示意性框图。
图15是本申请实施例提供的另一种通信设备的示意性框图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
图1是本申请实施例应用的无线通信系统100。该无线通信系统100可以包括网络设备110和终端设备120。网络设备110可以是与终端设备120通信的设备。网络设备110可以为特定的地理区域提供通信覆盖，并且可以与位于该覆盖区域内的终端设备120进行通信。
图1示例性地示出了一个网络设备和两个终端设备，可选地，该无线通信系统100可以包括多个网络设备并且每个网络设备的覆盖范围内可以包括其它数量的终端设备，本申请实施例对此不做限定。
可选地，该无线通信系统100还可以包括网络控制器、移动管理实体等其他网络实体，本申请实施例对此不作限定。
应理解，本申请实施例的技术方案可以应用于各种通信系统，例如：第五代(5th generation，5G)系统或新无线(new radio，NR)、长期演进(long term evolution，LTE)系统、LTE频分双工(frequency division duplex，FDD)系统、LTE时分双工(time division duplex，TDD)等。本申请提供的技术方案还可以应用于未来的通信系统，如第六代移动通信系统，又如卫星通信系统，等等。
本申请实施例中的终端设备也可以称为用户设备(user equipment，UE)、接入终端、用户单元、用户站、移动站、移动台(mobile station，MS)、移动终端(mobile terminal，MT)、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。本申请实施例中的终端设备可以是指向用户提供语音和/或数据连通性的设备，可以用于连接人、物和机，例如具有无线连接功能的手持式设备、车载设备等。本申请的实施例中的终端设备可以是手机(mobile phone)、平板电脑(Pad)、笔记本电脑、掌上电脑、移动互联网设备(mobile internet device，MID)、可穿戴设备，虚拟现实(virtual reality，VR)设备、增强现实(augmented reality，AR)设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。可选地，UE可以用于充当基站。例如，UE可以充当调度实体，其在车辆外联(vehicle-to-everything，V2X)或设备到设备(device to device，D2D)等中的UE之间提供侧行链路信号。比如，蜂窝电话和汽车利用侧行链路信号彼此通信。蜂窝电话和智能家居设备之间通信，而无需通过基站中继通信信号。
本申请实施例中的网络设备可以是用于与终端设备通信的设备，该网络设备也可以称为接入网设备或无线接入网设备，如网络设备可以是基站。本申请实施例中的网络设备可以是指将终端设备接入到无线网络的无线接入网(radio access network，RAN)节点(或设备)。基站可以广义的覆盖如下中的各种名称，或与如下名称进行替换，比如：节点B(NodeB)、演进型基站(evolved NodeB，eNB)、下一代基站(next generation NodeB，gNB)、中继站、传输点(transmitting and receiving point，TRP)、发射点(transmitting point，TP)、主站MeNB、辅站SeNB、多制式无线(MSR)节点、家庭基站、网络控制器、接入节点、无线节点、接入点(access point，AP)、传输节点、收发节点等。基站可以是宏基站、微基站、中继节点、施主节点或类似物，或其组合。基站还可以指用于设置于前述设备或装置内的通信模块、调制解调器或芯片。基站还可以是移动交换中心以及设备到设备D2D、V2X、机器到机器(machine-to-machine，M2M)通信中承担基站功能的设备、6G网络中的网络侧设备、未来的通信系统中承担基站功能的设备等。基站可以支持相同或不同接入技术的网络。本申请的实施例对网络设备所采用的具体技术和具体设备形态不做限定。
基站可以是固定的，也可以是移动的。例如，直升机或无人机可以被配置成充当移动基站，一个或多个小区可以根据该移动基站的位置移动。在其他示例中，直升机或无人机可以被配置成用作与另一基站通信的设备。
在一些部署中，本申请实施例中的网络设备可以是指CU或者DU，或者，网络设备包括CU和DU。gNB还可以包括AAU。
网络设备和终端设备可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上；还 可以部署在空中的飞机、气球或卫星上。本申请实施例中对网络设备和终端设备所处的场景不做限定。
应理解，本申请中的通信设备的全部或部分功能也可以通过在硬件上运行的软件功能来实现，或者通过平台(例如云平台)上实例化的虚拟化功能来实现。
零信任架构
零信任架构(zero trust architecture，ZTA)可以为美国国家标准与技术研究院(national institute of standards and technology，NIST)零信任架构。零信任架构的目的是确保网络资源的安全访问，通过实施严格的访问控制和监控，以响应不断变化的威胁环境。这种架构的设计旨在提高安全性，减少对传统网络边界的依赖，并确保即使在高度动态和分散的网络环境中也能保持数据和资源的安全。零信任架构的理念是：网络中的每个请求都不被默认信任、每次访问都需要经过严格的授权和监控。
参见图2，NIST零信任架构中的网元或组件可以包括策略引擎(policy engine，PE)、策略管理员(policy administrator，PA)以及策略执行点(policy enforcement point，PEP)。
策略引擎负责对给定主体的资源访问进行最终决策。策略引擎可以根据企业策略以及来自外部来源(如连续诊断和缓解(continuous diagnostics and mitigation，CDM)系统、威胁情报服务)的输入作为信任算法的输入，以授予、拒绝或撤销对资源的访问。策略引擎和策略管理员可以相互配合使用。策略引擎可以进行决策并记录决策结果(批准或拒绝)，策略管理员可以执行决策。
策略管理员可以负责在主体和资源之间建立和/或关闭通信路径。例如，策略管理员可以向策略执行点发送命令，以建立或关闭主体与资源之间的通信路径。在一些实现方式中，策略管理员可以通过与策略执行点通信，以创建通信路径。策略管理员与策略执行点之间的通信可以通过控制平面进行。
策略管理员可以生成每个会话特定的身份验证令牌或凭证，客户端可以使用该令牌或凭证来访问企业资源。策略管理员与策略引擎密切相关，策略管理员可以基于策略引擎的决策来允许或拒绝会话。如果会话经过授权并且请求经过身份验证，则策略管理员可以向策略执行点发送命令，以允许会话开始。如果会话被拒绝或之前的批准被撤销，则策略管理员可以向策略执行点发送命令以关闭连接。
在一些实现方式中，策略管理员和策略引擎为两个独立的组件，或者，策略管理员和策略引擎集成在一个组件上。
策略执行点可以负责启用、监控以及中止主体与资源之间的连接。策略执行点可以与策略管理员进行通信。策略执行点可以转发请求和/或从策略管理员接收策略更新。
在零信任架构中，策略执行点为一个单一的逻辑组件，但是策略执行点也可以划分为两个组件。例如，策略执行点可以包括客户端和资源端。客户端例如可以为终端设备上的代理，资源端例如可以为控制访问的资源前端网关组件。
上述组件可以通过一个分离的控制平面进行通信，而应用数据可以在数据平面进行传输。
继续参见图2，零信任架构还可以包括其他的组件。例如，零信任架构还可以包括以下组件中的一种或多种：CDM系统、行业合规系统、威胁情报源、网络和系统活动日志、数据访问策略、身份管理系统、安全信息和事件管理(security information and event management，SIEM)系统、企业公钥基础设施(public key infrastructure，PKI)。
智能零信任架构
参见图3，智能零信任架构(intelligent zero trust architecture，i-ZTA)中的组件可以包括智能策略引擎(intelligent policy engine,IPE)和智能代理门户(intelligent agent portal,IAP)。
IPE可以负责动态授权访问请求。IPE可以使用强化学习算法来最大化保证分数，即评估和调整信任策略，以响应实时观察到的用户或设备的行为、网络资源访问事件以及新检测到的异常行为。IAP可以支持联合学习(federated learning，FL)，联合学习方法为一种分布式的学习方法，可以在多个代理之间共享和更新模型，以此来提供一个全面的网络环境模型。
继续参见图3，智能零信任架构还可以包括智能网络安全状态分析(Intelligent Network Security State Analysis，INSSA)。INSSA使用图神经网络(graph neural network，GNN)对网络进行建模，并采用对抗学习进行风险评估。这种方法能够动态监测网络资产的安全状态，并实时评估它们是否符合安全政策规则。
智能零信任架构的运作流程涉及多个交互层面。当一个设备或用户尝试访问网络资源时，IPE会评估该请求，并根据当前的网络环境和历史行为数据决定是否授权。如果设备缺乏计算能力，IAP会介入，通过联合学习机制来评估和处理请求。同时，INSSA持续监控网络状态，确保所有通信行为都符合安全策略。这些组件的相互作用确保了即使在网络环境发生变化时，安全策略也能实时更新和执行。
通信系统架构
随着技术的发展，人们对通信系统的要求越来越高，一方面希望通信系统能够实现更高的系统性能，另一方面还希望通信系统为一个极简的系统，以降低部署和运营成本。一种可行的解决方案是：在一个 极简的共性技术核心上，设计多个子系统，多个子系统之间可以解绑，且多个子系统可以各自优化，从而实现一个“能力按需分配、功能灵活组合”的“极简多能”的通信系统。
上述通信系统可以由一个最小化的极简核心提供共性能力，如提供内生智能策略、安全、灵活频谱管理等能力。
上述通信系统可以针对四个能力方向做专门优化，这四个能力方向包括：云连接(clouding)、关键物联(critical IoT)、泛在物联(ubiquitous IoT)和感知(sensing)。
在每个能力方向上可以设计一个或多个子系统。在一些实现方式中，可以根据应用场景、频谱、接口类型等，选择对应的关键技术，并分别进行硬件系统设计。例如，子系统可以包括以下中的一种或多种子系统：宽带蜂窝、D2D、高可靠低时延通信(ultra reliable low latency communication，URLLC)、定位与感知、大规模物联网和空天通信等。
子系统之间可以按需选择是否保持空口兼容性，按需确定与宽带蜂窝子系统共用空口技术与硬件设计的程度。
上述通信系统可以黑箱化、专业化的人工智能(artificial intelligence，AI)算法库替代通用而复杂的传统软件算法，实现各个子系统的“相对独立、各自优化”和通信协议的大幅简化。通过多种AI算法的切换和组合，实现多个子系统的切换和组合。
上述通信系统可以适用于任意一种通信系统，如6G系统或未来的通信系统等。
为了保证通信系统的安全性，通信系统中的设备可以使用安全策略进行通信。安全策略可以由零信任架构中的网元生成。例如，安全策略可以由PE生成。另外，在需要更新安全策略的情况下，PE可以对安全策略进行更新。
一些通信系统(如6G系统)引入了各种各样的业务。例如，通信系统中的业务场景可以包括智慧家庭、智能穿戴设备、零功耗设备、通感互联网、孪生体域网、智能交互、智赋农业、智赋工业、超能交通、精准医疗、普智教育、虚拟畅游、即时抢险、“无人区”探测等。丰富的业务场景也对通信系统的安全性提出了新的挑战。目前，零信任架构中的安全策略与业务数据融合度不足，已经不能满足通信系统中不同业务的安全需求。
以6G系统为例，6G网络环境预期将实现对业务数据与网络状态的深度感知，而这需要安全策略能够与实时业务数据和网络状态信息无缝融合，以实现精准的风险评估与策略部署。ZTA和i-ZTA虽然考虑到数据驱动的安全策略实施，但尚未完全实现与6G网络环境中丰富的业务数据和网络状态信息的深入整合。因此，在快速变化的网络环境中，目前的安全策略可能无法充分利用实时数据进行有效的风险预测和应对，导致安全响应不够精确或者安全响应的时效性不足，未能充分发挥数据驱动安全策略的潜力。
针对NIST零信任架构，安全策略的生成或更新依赖于预设条件和人工干预，在安全策略的部署和调整上显示出被动和滞后的特点，无法满足动态变化的业务需求。例如，只有在满足预设条件的情况下，才会更新安全策略或生成新的安全策略。又例如，在需要更新安全策略的情况下，都是采用人工手动进行更新。虽然i-ZTA引入了智能化组件，但是i-ZTA并没有与业务数据相融合，而仅是基于网络环境的变化来更新安全策略。
为了解决上述问题中的一个或多个，本申请实施例提供一种用于生成安全策略的方法，通过将安全策略与终端设备的业务相关联，在生成安全策略时，可以生成与终端设备的业务相关联的安全策略，从而可以满足通信系统中不同业务的安全需求。
下面结合图4，对本申请实施例的方案进行详细介绍。
参见图4，在步骤S410，安全策略网元生成安全策略。安全策略网元例如可以为PE。在一些实施例中，安全策略网元可以为AI Sec PE。
需要说明的是，在一些实现方式中，安全策略网元也可以替换为其他的术语，如安全策略网元可以替换为策略引擎或策略引擎网元等。
在一些实施例中，安全策略可以与终端设备的业务相关联。例如，安全策略网元可以基于终端设备的业务，生成与该业务对应的安全策略。在一些实现方式中，不同的业务可以对应不同的安全策略。当然，不同的业务也可以对应相同的安全策略，本申请实施例对此不做具体限定。本申请实施例通过将业务数据与安全策略进行融合，可以实现精准的风险评估与策略部署。
在一些实现方式中，安全策略可以基于终端设备的业务变化进行更新，以提高安全策略的实时性。例如，安全策略网元可以在终端设备的业务发生变化的情况下，更新安全策略。通过由终端设备的业务变化来触发安全策略的更新，使得安全策略可以实时响应业务的变化，满足通信系统对时延的要求。以6G系统为例，6G网络预期将支持更高的数据速率和更低的延迟，这意味着网络环境和业务需求将更加动态和多变。本申请实施例通过基于终端设备业务的变化对安全策略进行更新，能够实时响应业务的动 态变化，生成与终端设备的业务对应的安全策略。
终端设备的业务是否发生变化可以由策略执行网元进行检测。在一些实施例中，策略执行网元可以检测终端设备的业务是否发生变化，在终端设备的业务发生变化的情况下，策略执行网元可以向安全策略网元发送指示信息，以指示终端设备的业务发生变化。在一些实现方式中，在终端设备的业务发生变化的情况下，策略执行网元可以向安全策略网元发送第一请求消息(如图5中的步骤S510)，该第一请求消息用于请求安全策略。安全策略网元接收到第一请求消息后，可以生成安全策略。
本申请实施例对策略执行网元不做具体限定，策略执行网元也可以称为业务功能网元。策略执行网元可以为PEP。在一些实现方式中，策略执行网元可以包括以下中的一种或多种：应用功能(application function，AF)，网络开放功能(network exposure function，NEF)，网络存储功能(network repository function，NRF)，策略控制功能(policy control function，PCF)，接入与移动管理功能(access and mobility management function，AMF)，认证服务功能(authentication server function，AUSF)，基站，用户平面功能(user plane function，UPF)，边缘节点等。
在一些实施例中，安全策略可以基于网络状态的变化进行更新。例如，安全策略网元可以在网络状态发生变化的情况下，更新安全策略或生成新的安全策略。通过将安全策略与网络状态信息相融合，可以实现精准的风险评估和策略部署。
在一些实现方式中，策略执行网元可以通过策略管理网元向安全策略网元发送第一请求消息。例如，策略执行网元可以向策略管理网元发送第一请求消息，策略管理网元接收到第一请求消息后，可以将第一请求消息转发至安全策略网元。
本申请实施例中的策略管理网元可以为PA。
本申请实施例对策略执行网元确定终端设备的业务是否发生变化的方式不做具体限定。作为一个示例，策略执行网元可以对终端设备的业务进行监测，以确定终端设备的业务是否发生变化。作为另一个示例，终端设备可以在业务发生变化的情况下，向策略执行网元发送第一指示信息，第一指示信息用于指示终端设备的业务发生变化。也就是说，策略执行网元可以基于终端设备的指示，确定终端设备的业务是否发生变化。
在一些实施例中，虽然终端设备的业务发生变化，但是变化之前的业务和变化之后的业务所需要的安全策略有可能相同，在该情况下，安全策略网元可以不生成或更新安全策略，以降低开销。也就是说，安全策略网元可以在生成安全策略之前，判断是否需要生成安全策略，例如，判断是否需要新的安全策略或判断是否需要更新安全策略。如果需要生成安全策略，则安全策略网元生成安全策略；如果不需要生成安全策略，则安全策略网元可以不生成安全策略。举例说明，如果安全策略网元判断需要新的安全策略，则安全策略网元生成新的安全策略；如果安全策略网元判断不需要新的安全策略，则安全策略网元可以不生成新的安全策略。或者，如果安全策略网元判断需要更新安全策略，则安全策略网元更新安全策略；如果安全策略网元判断不需要更新安全策略，则安全策略网元可以不更新安全策略。
在一些实施例中，业务发生变化可以包括以下情况中的一种或多种：新增了业务、当前的业务条件发生了变化。
在一些实施例中，安全策略网元可以基于第一模型生成安全策略。第一模型可以为任意一种神经网络模型。例如，第一模型可以为AI模型或机器学习(machine learning，ML)模型。在一些实现方式中，第一模型可以为深度森林模型。
深度森林(deep forest，DF)是一种具有级联结构的决策树集成方法，包括多粒度扫描和级联森林两个部分。其中，多粒度扫描通过设置不同粒度的滑动窗口，对原始输入特征进行扫描以生成新的特征向量；级联森林通过对上一级联的输出与原始输入特征进行处理，以生成下一级联的输入数据。本申请可以采用度量感知特征重用(measure-aware feature reuse，MAFR)和度量感知层增长(measure-aware layer growth，MALG)以实现深度森林多标签输出任务目标。其中，MAFR基于上一级联输出的置信度来选择下一级联的输入，MALG则根据最优评估指标确定级联层训练是否结束。由于深度森林模型的训练速度快，并且可很容易地进行并行化处理，能够处理大规模的数据集，因此，通过使用深度森林模型生成安全策略，可以提高生成安全策略的速度以及保证安全策略的准确性。
在一些实施例中，第一模型的输入参数可以包括系统类型。该系统类型可以为与终端设备的业务对应的系统类型，或者说，该系统类型可以是基于终端设备的业务确定的。通过将系统类型作为第一模型的输入参数，可以使得生成的安全策略与系统类型对应，从而能够满足不同系统的安全需求。例如，在系统类型发生变化的情况下，安全策略网元可以生成新的安全策略或更新安全策略。
在一些实现方式中，系统类型也可以称为系统能力。该系统类型例如可以为6G系统中的系统能力或子系统能力。
在一些实现方式中，通信系统可以包括以下一种或多种系统类型：宽带蜂窝、D2D、URLLC、定位 与感知、大规模物联网和空天通信等。在另一些实现方式中，通信系统可以包括以下一种或多种系统类型：通信感知一体化(integrated sensing and communication，ISAC)、零功耗通信、太赫兹、AI/ML、可重构智能表面(reconfigurable intelligent surface，RIS)、多输入多输出(multiple-input multiple-output，MIMO)等。
以通信系统的类型包括零功耗通信系统为例，由于零功耗通信系统的计算能力受限，因此，零功耗通信系统需要在资源受限的情况下完成安全功能，例如，安全策略需要终端设备在花费较少的资源的情况下即可完成执行。基于此，零功耗通信系统的安全策略可以包括以下子策略中的一种或多种：轻量级安全凭证管理、轻量级认证和物理层密钥保护等。
在一些实施例中，第一模型的输入参数可以包括安全需求。该安全需求可以为与终端设备的业务对应的安全需求，或者说，该安全需求可以是基于终端设备的业务确定的。通过将安全需求作为第一模型的输入参数，可以使得生成的安全策略与安全需求对应，从而可以生成不同安全需求下的安全策略。例如，在安全需求发生变化的情况下，安全策略网元可以生成新的安全策略或更新安全策略。
在一些实施例中，安全需求可以包括多个子需求。多个子需求之间可以相互组合，形成最终的安全需求。通过将安全需求划分为多个子需求，使得子需求可以根据终端设备的业务需求灵活组合，以满足终端设备的业务需求，从而使得安全策略的生成更加灵活化。
在一些实施例中，安全需求可以包括不同协议层的安全需求。例如，安全需求可以包括以下中的一种或多种：非接入层的安全需求、无线资源控制(radio resource control，RRC)层的安全需求、物理层的安全需求和应用层的安全需求。非接入层的安全需求可以包括以下中的一种或多种：认证和密钥协商、数据保密性、数据完整性和异常处理机制。RRC层的安全需求可以包括以下中的一种或多种：数据保密性、数据完整性、安全模式命令设置、序列号同步机制和异常处理机制。物理层的安全需求可以包括以下中的一种或多种：加密、信道编码与调制、物理层身份验证和指纹识别。应用层的安全需求可以包括以下中的一种或多种：网络切片安全、用户隐私保护和开放接口的安全。
在一些实施例中，安全需求可以包括以下中的一个或多个子需求：业务领域、数据类型、数据流向、安全等级、网络环境、交互模式、业务优先级、延迟要求、隐私级别、身份与授权机制、网络隔离程度、加密密钥强度等。
在一些实施例中，不同的安全需求可以对应不同的安全策略。以安全等级为例，不同的安全等级可以对应不同的加密强度和访问控制的严格程度。以数据类型为例，不同的数据类型(如用户数据、机器数据和模型数据等)可能需要不同的保护级别和处理方式。
在一些实施例中，安全需求中的子需求可以为安全需求列表中的子需求，换句话说，安全需求可以包括安全需求列表中的多个子需求。安全需求列表可以为预设的安全需求列表。通过从安全需求列表中选择安全需求，可以简化安全需求的确定过程，使得生成的安全需求更加规范化，从而可以降低生成安全策略的难度。
在一些实现方式中，可以将安全需求列表作为第一模型的输入。第一模型可以建立终端设备的业务与子需求之间的对应关系，可以基于终端设备的业务选择对应的子需求。
在一些实施例中，安全策略可以包括多个子策略，或者说，安全策略可以通过多个子策略组合而成，通过子策略的设计，使得在生成安全策略时，可以根据终端设备的业务需要，灵活组合不同的子策略，增加生成安全策略的灵活性。
在一些实施例中，安全策略可以包括多个子策略，多个子策略可以分别与多个子需求对应。换句话说，多个子策略可以与多个子需求一一对应。一个子策略对应一个子需求。在生成安全策略时，可以针对多个子需求，生成分别与多个子需求对应的多个子策略，将多个子策略进行组合形成最终的安全策略。
举例说明，假设安全需求包括轻量级认证、分布式安全、数据授权和低层安全保护，则生成的安全策略可以包括以下子策略：与轻量级认证对应的子策略、与分布式安全对应的子策略、与数据授权对应的子策略以及与低层安全保护对应的子策略。
在一些实施例中，第一模型的输入参数可以包括安全能力。该安全能力可以为与终端设备的业务对应的安全能力，或者说，该安全能力可以是基于终端设备的业务确定的。在一些实施例中，安全能力也可以称为安全功能。通过将安全能力作为第一模型的输入参数，可以使得生成的安全策略与安全能力对应，能够满足不同安全能力的安全需求。例如，在安全能力发生变化的情况下，安全策略网元可以生成新的安全策略或更新安全策略。
在一些实现方式中，安全能力也可以称为安全机制或第三代合作伙伴计划(3rd generation partnership project，3GPP)安全机制。
在一些实现方式中，安全能力可以包括多个子能力，或者说，安全能力可以为模块化的安全能力。通过将安全能力模块化，在生成安全策略时，可以根据具体的安全需求快速地选择和组合不同的安全模 块，以有效实现预定的安全策略。
在一些实现方式中，上述子能力可以为安全能力库中的子能力。该安全能力库例如可以为3GPP安全能力库。安全能力库中包括多个子能力。在生成安全策略时，可以根据实际的业务需要，选择对应的子能力。
在一些实现方式中，安全能力库也可以称为模块化安全能力库。
在一些实现方式中，可以将安全能力库作为第一模型的输入。第一模型可以建立终端设备的业务与子能力之间的对应关系，可以基于终端设备的业务选择对应的子能力。
例如，安全能力(或安全能力库)可以包括以下中的一个或多个子能力：128位密钥、认证与密钥协商(authentication and key agreement，AKA)、基于身份的授权、PKI、抗量子密钥、分布式认证、基于属性的授权、授权(Oauth)、物理层密钥、轻量级认证、基于数据的授权、区块链等。
在一些实施例中，AKA可以包括以下中的一种或多种：5G-AKA、AES-AKA、EAP-AKA、BEST-AKA、EPS-AKA、EAP-TLS、EAP-AKA'等。
可以理解的是，子能力划分的颗粒度越细，子能力之间的组合会越灵活，生成的安全策略将会更符合终端设备的业务需求。
在一些实施例中，安全能力可以跨越从物理层到应用层的多个安全领域。安全能力可以包括身份验证、授权、数据加密、完整性验证和重放攻击防护等多种机制。
在一些实现方式中，安全能力可以包括与安全需求对应的安全能力。例如，安全能力可以包括不同协议层的安全能力。例如，安全能力可以包括以下中的一种或多种：非接入层的安全能力、RRC层的安全能力、物理层的安全能力和应用层的安全能力。非接入层的安全能力可以包括针对以下中一种或多种安全需求对应的安全能力：认证和密钥协商、数据保密性、数据完整性和异常处理机制。RRC层的安全能力可以包括针对以下中一种或多种安全需求对应的安全能力：数据保密性、数据完整性、安全模式命令设置、序列号同步机制和异常处理机制。物理层的安全能力可以包括针对以下中一种或多种安全需求对应的安全能力：加密、信道编码与调制和物理层身份验证和指纹识别。应用层的安全能力可以包括针对以下中一种或多种安全需求对应的安全能力：网络切片安全、用户隐私保护和开放接口的安全。
在一些实现方式中，以非接入层为例，与认证与密钥协商对应的安全能力可以包括以下中的一种或多种：EPS-AKA、5G-AKA、EAP-AKA、EAP-AKA'、EAP-TLS、轻量级认证协议(如BEST-AKA)、超轻量级认证协议。与数据保密性对应的安全能力可以包括以下中的一种或多种：EEA0、EEA1、EEA2、EEA3、NEA0、NEA1、NEA2。与数据完整性对应的安全能力可以包括以下中的一种或多种：EIA0、EIA1、EIA2、EIA3、NEA0、NEA1、NEA2。与异常处理机制对应的安全能力可以包括以下中的一种或多种：认证异常处理、网络失败和恢复、安全模式命令错误处理、分布式拒绝服务(distributed denial of service，DDOS)处理。
在一些实现方式中，以RRC层为例，与数据保密性对应的安全能力可以包括以下中的一种或多种：EEA0、EEA1、EEA2、EEA3、NEA0、NEA1、NEA2。与数据完整性对应的安全能力可以包括以下中的一种或多种：EIA0、EIA1、EIA2、EIA3、NEA0、NEA1、NEA2。与安全模式命令设置对应的安全能力可以包括指定使用的加密算法和/或完整性算法。与异常处理机制对应的安全能力可以包括以下中的一种或多种：安全模式失败、连接丢失和重建丢失。
在一些实现方式中，以物理层为例，与加密对应的安全能力可以包括数据加扰。与信道编码与调制对应的安全能力可以包括以下中的一种或多种：低密度奇偶校验(low-density parity-check，LDPC)、Turbo码和polar码。与物理层身份验证和指纹识别对应的安全能力可以包括以下中的一种或多种：设备特定的射频特征识别、时间和频率分析、信号波形分析、环境和信道特性。
在一些实现方式中，以应用层为例，与网络切片安全对应的安全能力可以包括以下中的一种或多种：切片隔离、切片二次认证。与用户隐私保护对应的安全能力可以包括以下中的一种或多种：用户隐藏标识符(subscription concealed identifier，SUCI)、临时移动用户识别码(temporary mobile subscriber identity，TMSI)、全球唯一临时UE标识(globally unique temporary UE identity，GUTI)(如5G-GUTI)、用户同意(user consent)、订阅者数据管理与暴露。与开放接口的安全对应的安全能力可以包括以下中的一种或多种：OAuth 2.0、OpenID Connect和应用的认证与密钥管理(authentication and key management for application，AKMA)。
通过模块化的安全能力设计，使得安全能力可以兼容不同通信网络(如4G网络、5G网络等)的安全机制，并针对未来的网络环境提供必要的扩展性，能够确保随着网络技术的发展，本申请实施例提供的安全措施仍然能够保持前瞻性和灵活性。
在一些实施例中，安全能力可以包括多个子能力，安全策略可以包括多个子策略，多个子策略可以分别与多个子能力对应。换句话说，多个子策略可以与多个子能力一一对应。一个子策略对应一个子能 力。在生成安全策略时，可以针对多个子能力，生成分别与多个子能力对应的多个子策略，将多个子策略进行组合形成最终的安全策略。
以终端设备的业务为工业互联网业务为例，工业互联网需要考虑全产业链环节不同地点的数据搜集与处理，因此，需要的安全能力可以包括分布式认证以及基于业务数据的授权。在生成安全策略时，可以生成与分布式认证对应的子策略以及与基于业务数据的授权对应的子策略。
在一些实施例中，为了使安全策略能够适应网络的动态变化，第一模型的输入参数中可以包括安全规则和/或安全态势。安全态势可以包括系统安全态势和/或网络安全态势。安全态势例如可以包括以下中的一种或多种：网络行为监测、安全运维管理和系统事件日志。
安全规则可以包括合规要求和/或威胁分析。在一些实现方式中，安全规则可以包括静态规则和/或动态规则。静态规则可以包括不经常变化的规则集。静态规则可以包括以下中的一种或多种：数据访问策略、公钥基础设施、身份管理规则以及安全信息和事件管理的配置等。动态规则可以包括以下中的一种或多种：数据监控的实时反馈、合规性检测、威胁情报更新和活动日志等。这些信息有助于核心网理解当前的安全环境和正在发生的事件。
在安全规则和/或安全态势发生变化的情况下，安全策略网元可以更新安全策略或生成新的安全策略，使得生成的安全策略可以适应快速变化的网络环境以及适应新出现的威胁。
第一模型的输入参数可以包括上述参数中的任意一种，或者，第一模型的输入参数可以包括上述参数中的多种。例如，第一模型的输入参数可以包括系统类型、安全需求、安全能力、安全规则和安全态势，如图8所示。又例如，第一模型的输入参数可以包括系统类型、安全需求和安全能力，如图9所示。
本申请实施例对安全需求的确定方式不做具体限定。作为一个示例，安全需求可以是预设的安全需求。安全需求可以是工作人员人工确定的。工作人员确定好安全需求后，可以将安全需求输入到第一模型中。在一些实现方式中，工作人员可以基于安全需求列表确定安全需求。例如，工作人员可以根据终端设备的业务，从安全需求列表中选择一个或多个子需求，形成最终的安全需求。
作为另一个示例，安全需求可以是基于第二模型生成的。通过第二模型生成安全需求可以使得安全需求的生成更加智能化。
第二模型可以为任意一种神经网络模型。例如，第二模型可以为AI模型或ML模型。在一些实现方式中，第二模型可以为深度森林模型。
在一些实现方式中，安全需求可以由安全策略网元之外的其他网元生成。例如，安全需求可以由策略检测网元生成。策略检测网元例如可以为PD。通过由其他网元生成安全策略，可以增加安全策略生成过程的灵活性和动态适应能力。
在一些实现方式中，策略检测网元可以基于第二模型生成安全需求。策略检测网元在生成安全需求后，可以向安全策略网元发送安全需求，如图9所示。在一些实现方式中，策略检测网元可以通过策略管理网元向安全策略网元发送安全需求。
安全策略网元接收到来自策略检测网元的安全需求后，可以认为终端设备的业务发生了变化，在该情况下，安全策略网元可以生成安全策略。
在一些实施例中，第二模型的输入参数可以包括以下中的一种或多种：安全规则和业务数据。业务数据可以包括以下中的一种或多种：网络流量、设备状态和服务质量参数等。业务数据的变化可以反映业务需求的变化。例如，如果终端设备从一个低安全需求的业务过渡到一个高安全需求的业务，则对应的业务数据也会发生变化。
安全规则可以包括静态规则和/或动态规则。静态规则可以包括不经常变化的规则集。静态规则可以包括以下中的一种或多种：数据访问策略、公钥基础设施、身份管理规则以及安全信息和事件管理的配置等。动态规则可以包括以下中的一种或多种：数据监控的实时反馈、合规性检测、威胁情报更新和活动日志等。这些信息有助于核心网理解当前的安全环境和正在发生的事件。
策略检测网元(或第二模型)的输出包括安全需求。安全需求可以基于业务数据和/或安全规则来生成。安全需求可以为安全需求列表中的安全需求。策略检测网元可以具有智能分析和预测功能，可以利用第二模型和数据分析技术来处理和解释输入数据，从而生成准确的安全需求。
在一些实施例中，策略检测网元可以在终端设备的业务发生变化的情况下，生成安全需求。在一些实现方式中，策略执行网元可以检测终端设备的业务是否发生变化，在终端设备的业务发生变化的情况下，策略执行网元可以向策略检测网元发送第一请求消息(如图5中的步骤S510或图6中的步骤S610)，第一请求消息用于请求安全策略。响应于第一请求消息，策略检测网元生成安全需求(如图6中的步骤S620)。例如，策略检测网元可以基于第二模型生成安全需求。在生成安全需求后，策略检测网元可以向安全策略网元发送安全需求(如图6中的步骤S630)。
在一些实现方式中，策略执行网元可以通过策略管理网元向策略检测网元发送第一请求消息。例如，策略执行网元可以向策略管理网元发送第一请求消息，策略管理网元接收到第一请求消息后，可以将第一请求消息转发至策略检测网元。
本申请实施例对策略执行网元确定终端设备的业务是否发生变化的方式不做具体限定。作为一个示例，策略执行网元可以对终端设备的业务进行监测，以确定终端设备的业务是否发生变化。作为另一个示例，终端设备可以在业务发生变化的情况下，向策略执行网元发送第一指示信息(如图7中的步骤S710)，第一指示信息用于指示终端设备的业务发生变化。也就是说，策略执行网元可以基于终端设备的指示，确定终端设备的业务是否发生变化。
在一些实施例中，策略检测网元也可以根据安全策略网元的指示生成安全需求。例如，安全策略网元可以基于一定的规则(如计算出的信任值)确定是否需要生成或更新安全策略。在确定需要生成或更新安全策略的情况下，安全策略网元可以向策略检测网元发送指示信息，以指示策略检测网元生成新的安全需求。
下面结合图8和图9，对本申请实施例涉及的安全架构进行介绍。
本申请实施例的方案可以包括两种安全架构。一种安全架构包括安全策略网元。安全策略网元可以为一种引擎组件，因此，该架构也可以称为单引擎架构，如图8所示。另一种安全架构包括安全策略网元和策略检测网元。安全策略网元和策略检测网元可以均为引擎组件，因此，该架构也可以称为双引擎架构，如图9所示。下面对图8和图9所示的方案分别进行介绍。
参见图8，安全策略网元可以基于第一模型生成安全策略。第一模型的输入参数可以包括以下中的一种或多种：安全需求、安全能力、系统类型、安全规则和安全态势。
参见图9，策略检测网元可以基于第二模型生成安全需求。策略检测网元可以将生成的安全需求发送至安全策略网元。第二模型的输入参数可以包括以下中的一种或多种：业务数据和安全规则。
安全策略网元可以基于第一模型生成安全策略。第一模型的输入参数可以包括以下中的一种或多种：安全需求、安全能力和系统类型。
需要说明的是，图8和图9中将安全策略网元和策略管理网元分为两个网元进行介绍，但是，在一些实施例中，安全策略网元和策略管理网元也可以集成在一个网元中。
在一些实现方式中，安全策略网元向策略执行网元发送安全策略(参见图4中的步骤S420和图5中的步骤S520)。安全策略网元在生成安全策略后，可以向策略执行网元发送安全策略，以使策略执行网元可以执行该安全策略。
在一些实施例中，安全策略网元可以通过策略管理网元向策略执行网元发送安全策略。例如，安全策略网元向策略管理网元发送安全策略，策略管理网元可以将安全策略转发至策略执行网元。
在一些实施例中，策略执行网元可以向终端设备发送安全策略(如图7中的步骤S720)，以使终端设备和策略执行网元中的安全策略相同，终端设备和策略执行网元可以基于相同的安全策略进行安全通信。例如，终端设备和策略执行网元可以采用相同的物理层密钥进行安全传输保护。
下面结合两个具体的示例，对本申请实施例的方案进行详细阐述。需要说明的是，下文中的示例仅是为了便于理解，对本申请实施例的方案进行的解释说明，本申请实施例不应局限于以下实施例。
示例一
示例一的方案适用于图8所示的架构。
参见图10，在步骤S1010，PEP向PE发送请求消息。PEP在发送请求消息之前，可以先确定终端设备的业务是否发生变化。在终端设备的业务发生变化的情况下，PEP向PE发送请求消息，该请求消息用于请求安全策略。
在一些实现方式中，步骤S1010可以包括步骤S1010a和步骤S1010b。在步骤S1010a，PEP向PA发送请求消息。在步骤S1010b，PA向PE转发该请求消息。
在一些实现方式中，在步骤S1010之前，图10所示的方法还可以包括步骤S1005。在步骤S1005，PEP可以接收UE发送的指示信息，该指示信息用于指示UE的业务发生变化。
在步骤S1020，PE判断是否需要新的安全策略。如果需要新的安全策略，则执行步骤S1030；如果不需要新的安全策略，则结束流程。
在步骤S1030，PE使用第一模型生成安全策略。第一模型为深度森林模型。
在步骤S1040，PE向PA发送安全策略。
在步骤S1050，PA向PEP转发安全策略。
在步骤S1060，PEP向UE发送安全策略。
通过上述流程，PE可以在UE的业务发生变化的情况下，触发PE发起安全策略的更新。另外，PEP和UE可以获得相同的安全策略，后续PEP和UE可以基于相同的安全策略和安全功能进行安全保 护。例如，PEP和UE可以采用相同的物理层密钥机制进行安全传输保护。
示例二
示例二的方案适用于图9所示的架构。
参见图11，在步骤S1110，PEP向PD发送请求消息。PEP在发送请求消息之前，可以先确定终端设备的业务是否发生变化。在终端设备的业务发生变化的情况下，PEP向PD发送请求消息，该请求消息用于请求安全策略。
在一些实现方式中，步骤S1110可以包括步骤S1110a和步骤S1110b。在步骤S1110a，PEP向PA发送请求消息。在步骤S1110b，PA向PD转发该请求消息。
在一些实现方式中，在步骤S1110之前，图11所示的方法还包括步骤S1105。在步骤S1105，PEP可以接收UE发送的指示信息，该指示信息用于指示UE的业务发生变化。
在步骤S1120，PD利用第二模型生成安全需求。第二模型可以为深度森林模型。
在步骤S1130，PD向PE发送第一消息，第一消息中包括安全需求。
在一些实现方式中，步骤S1130可以包括步骤S1130a和步骤S1130b。在步骤S1130a，PD向PA发送第一消息。在步骤S1130b，PA向PE转发第一消息。
在步骤S1140，PE判断是否需要新的安全策略。如果需要新的安全策略，则执行步骤S1150；如果不需要新的安全策略，则结束流程。
在步骤S1150，PE使用第一模型生成安全策略。第一模型为深度森林模型。第一模型的输入参数可以包括PD生成的安全需求。
在步骤S1160，PE向PA发送安全策略。
在步骤S1170，PA向PEP转发安全策略。
在步骤S1180，PEP向UE发送安全策略。
示例二与示例一的区别在于，示例二中的安全需求是PD生成的，通过由PD生成安全需求，可以提高安全策略生成的灵活性。
通过上述流程，PE可以在UE的业务发生变化的情况下，触发PE发起安全策略的更新。另外，PEP和UE可以获得相同的安全策略，后续PEP和UE可以基于相同的安全策略和安全功能进行安全保护。例如，PEP和UE可以采用相同的物理层密钥机制进行安全传输保护。
本申请对第一模型和第二模型的训练过程不做具体限定。在一些实施例中，PE可以对第一模型进行训练。以图8所示的架构为例，PE可以向核心网网元(如网络数据分析功能(network data analytics function，NWDAF)网元)请求相关数据，PE可以利用相关数据对第一模型进行训练。相关数据可以包括安全需求、安全规则、安全态势、系统类型、安全能力等。以图9所示的架构为例，PE可以向核心网网元(如NWDAF网元)请求相关数据，PE可以利用相关数据对第一模型进行训练。相关数据可以包括安全需求、安全规则、安全态势、系统类型、安全能力等。
在一些实施例中，PD可以对第二模型进行训练。以图9所示的架构为例，PD可以向核心网网元(如NWDAF网元)请求相关数据，PD可以利用相关数据对第二模型进行训练。相关数据可以包括业务数据、动态安全规则和静态安全规则。业务数据例如可以包括：网络活动数据、设备行为数据、用户交互数据和安全事件数据等。
下面结合三个应用示例，来体现本申请中安全策略的高效编排和实施。
场景一、智慧家庭场景
以现代化的住宅为例，其中布局了众多智慧家居和感知传感器，构建了一套完善的智能家庭系统。在日常生活中，该系统能够实时响应居住者的需求。例如，当居住者于清晨醒来，系统通过感知技术自动识别其位置和行为，进而自动调节窗帘、电灯，为其营造最佳的室内环境。又例如，感知技术还能识别居住者的日常活动，如健身运动状态。系统能够通过无线信号实时感知和分析居住者的身体动作，如仰卧起坐或跑步，从而为其提供合适的运动反馈。又例如，考虑到居住者可能长时间不在家的情况，系统设有入侵检测功能。当有外部人员试图非法进入，系统会通过6G网络的精准感知，分析收集到的信号变化，进而判定入侵者的存在。一旦确认有异常情况发生，系统将立即向居住者的移动设备发送警报，确保家庭财产的安全。
在对不同的场景深入分析后，每个业务场景因其独特的特性都伴随着独特的安全需求。无论是常规家居操作、用户行为状态的实时监测，还是非法入侵的即时报警，背后的安全挑战与需求都有其特有的层次和差异。具体的安全需求可以如表1所示。
表1
场景二、智慧穿戴场景
以某用户的生活为例，其智慧手环、智慧鞋、智慧眼镜和智慧腕带，都可以与网络(如6G网络)通信，共同构建了一个完整的智慧健康和运动管理系统。当用户开始新的一天，智慧手环自动启动，凭借先进的感知技术，实时监测他的心率、血压、呼吸频率等关键健康指标。随着用户开始他的日常锻炼，例如羽毛球训练，智慧鞋可以准确捕捉他的运动数据，如步伐、速度和跳跃，同时智慧眼镜通过高速的网络实时分析运动场上的数据，为他提供即时反馈和指导。当用户在锻炼中遭遇不测，如扭伤脚踝，他的穿戴设备立即感知到这一异常，启动紧急模式。智慧手环借助AR技术为他展示伤势处理的步骤，智慧腕带内置的低频电疼痛治疗仪则迅速减轻他的疼痛。在此期间，所有数据均通过网络实时传输，确保用户在第一时间得到最佳的医疗建议和救援。
随着智慧穿戴设备在各个方面的广泛应用，其背后所涉及的业务也变得越来越复杂。这些业务不仅关乎到用户的日常健康与运动，更涉及到紧急医疗救援、运动反馈指导、甚至伤势的实时处理。每一种业务都有其独特的数据和操作流程，因此它们的安全需求也各不相同。日常健康监测可能更加注重数据的完整性和隐私保护；而运动性能检测更侧重于数据的实时性和精确性；基于AR的伤势处理则需确保数据的可用性和应急响应能力。表2示出了三种智慧穿戴设备使用场景下的安全需求。
表2

场景三、智慧物联网设备场景
智慧物联网设备在多个场景中都有所体现，而购物中心是一个比较好的例子。例如，针对商品供销管理，可以通过部署3GPP IoT设备于店铺货架与存储区，以实时地感知商品存货状态并据此调整供销策略，保障供需平衡且避免库存积压。又例如，IoT设备可以实时地感知并适应购物中心中的人流变化和温度变化，如照明与空调系统可以自动调节，以为公众创造出一个比较适宜的购物环境，另外，还可以降低能源消耗，从而实现了运营成本的有效优化。又例如，购物中心引入了基于环境IoT驱动的室内导航系统，以为顾客提供精确的室内导航服务，轻松地引导他们找到停车位与目的店铺。
上述不同场景可以对应不同的安全需求，如表3所示。
表3
上文结合图1至图11，详细描述了本申请的方法实施例，下面结合图12至图15，详细描述本申请的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
图12是本申请实施例提供的一种通信设备的示意性框图。图12所示的通信装置1200可以为上文描述的任意一种安全策略网元。图12所示的通信装置包括生成单元1210和发送单元1220。
在一些实施例中，生成单元1210和判断单元可以为处理器，发送单元1220和接收单元可以为收发器。在一些实现方式中，通信装置1200还可以包括存储器。
生成单元1210，用于生成安全策略，所述安全策略与终端设备的业务相关联。
发送单元1220，用于向策略执行网元发送所述安全策略。
在一些可能的实现方式中，所述生成单元用于：基于第一模型生成所述安全策略。
在一些可能的实现方式中，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对 应的系统类型、与所述终端设备的业务对应的安全需求、与所述终端设备的业务对应的安全能力。
在一些可能的实现方式中，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
在一些可能的实现方式中，所述安全需求包括安全需求列表中的多个子需求。
在一些可能的实现方式中，所述第一模型的输入参数还包括以下至少之一：安全规则、网络安全态势、系统安全态势。
在一些可能的实现方式中，所述通信设备还包括：接收单元，用于接收来自策略检测网元的所述安全需求。
在一些可能的实现方式中，所安全需求是在所述终端设备的业务发生变化的情况下生成。
在一些可能的实现方式中，所述安全需求基于第二模型生成。
在一些可能的实现方式中，在生成安全策略之前，所述通信设备还包括：接收单元，用于接收所述策略执行网元发送的第一请求消息，所述第一请求消息用于请求所述安全策略，所述第一请求消息是在所述终端设备的业务发生变化的情况下发送。
在一些可能的实现方式中，所述通信设备还包括判断单元，所述判断单元，用于判断是否需要生成所述安全策略；所述生成单元，用于在需要生成所述安全策略的情况下，生成所述安全策略。
图13是本申请实施例提供的一种通信设备的示意性框图。图13所示的通信装置1300可以为上文描述的任意一种策略执行网元。图13所示的通信装置包括发送单元1310和接收单元1320。
在一些实施例中，发送单元1310和接收单元1320可以为收发器。在一些实现方式中，通信装置1300还可以包括存储器和处理器。
发送单元1310，用于向第一网元发送第一请求消息，所述第一请求消息用于请求安全策略，所述安全策略与所述终端设备的业务相关联，所述第一网元包括安全策略网元和/或策略检测网元。
接收单元1320，用于接收来自所述安全策略网元的所述安全策略。
在一些可能的实现方式中，所述安全策略基于第一模型生成。
在一些可能的实现方式中，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、与所述终端设备的业务对应的安全需求、与所述终端设备的业务对应的安全能力。
在一些可能的实现方式中，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
在一些可能的实现方式中，所述安全需求包括安全需求列表中的多个子需求。
在一些可能的实现方式中，所述第一模型的输入参数还包括以下至少之一：安全规则、网络安全态势、系统安全态势。
在一些可能的实现方式中，所述安全需求由所述策略检测网元发送至所述安全策略网元。
在一些可能的实现方式中，所述安全需求是在所述终端设备的业务发生变化的情况下生成。
在一些可能的实现方式中，所述安全需求基于第二模型生成。
在一些可能的实现方式中，在向第一网元发送第一请求消息之前，所述接收单元还用于：接收来自终端设备的第一指示信息，所述第一指示信息用于指示所述终端设备的业务发生变化。
图14是本申请实施例提供的一种通信设备的示意性框图。图14所示的通信装置1400可以为上文描述的任意一种策略检测网元。图14所示的通信装置包括接收单元1410、生成单元1420和发送单元1430。
在一些实施例中，接收单元1410和发送单元1430可以为收发器，生成单元1420可以为处理器。在一些实现方式中，通信装置1400还可以包括存储器。
接收单元1410，用于接收来自策略执行网元的第一请求消息，所述第一请求消息用于请求安全策略。
生成单元1420，用于响应于所述第一请求消息，生成与所述终端设备的业务对应的安全需求。
发送单元1430，用于向安全策略网元发送所述安全需求，所述安全需求用于所述安全策略网元生成所述安全策略。
在一些可能的实现方式中，所述安全策略基于第一模型生成。
在一些可能的实现方式中，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、所述安全需求、与所述终端设备的业务对应的安全能力。
在一些可能的实现方式中，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
在一些可能的实现方式中，所述安全需求包括安全需求列表中的多个子需求。
在一些可能的实现方式中，所述安全需求基于第二模型生成。
图15是本申请实施例提供的一种通信设备的示意性框图。图15所示的通信装置1500可以为上文描述的任意一种终端设备。图15所示的通信装置包括发送单元1510和接收单元1520。
在一些实施例中，发送单元1510和接收单元1520可以为收发器。在一些实现方式中，通信装置1500还可以包括存储器和处理器。
发送单元1510，用于向策略执行网元发送第一指示信息，所述第一指示信息用于指示所述终端设备的业务发生变化；
接收单元1520，用于接收来自所述策略执行网元的安全策略，所述安全策略与所述终端设备的业务相关联。
在一些可能的实现方式中，所述安全策略基于第一模型生成。
在一些可能的实现方式中，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、与所述终端设备的业务对应的安全需求、与所述终端设备的业务对应的安全能力。
在一些可能的实现方式中，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
在一些可能的实现方式中，所述安全需求属于安全需求列表中的多个子需求。
在一些可能的实现方式中，所述第一模型的输入参数还包括以下至少之一：安全规则、网络安全态势、系统安全态势。
在一些可能的实现方式中，所述安全需求由策略检测网元发送至所述安全策略网元。
在一些可能的实现方式中，所述安全需求是在所述终端设备的业务发生变化的情况下生成。
在一些可能的实现方式中，所述安全需求基于第二模型生成。
在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，数字通用光盘(digital video disc，DVD))或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (72)

  1. 一种用于生成安全策略的方法，其特征在于，所述方法包括：
    安全策略网元生成安全策略，所述安全策略与终端设备的业务相关联；
    所述安全策略网元向策略执行网元发送所述安全策略。
  2. 根据权利要求1所述的方法，其特征在于，所述安全策略网元生成安全策略，包括：
    所述安全策略网元基于第一模型生成所述安全策略。
  3. 根据权利要求2所述的方法，其特征在于，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、与所述终端设备的业务对应的安全需求、与所述终端设备的业务对应的安全能力。
  4. 根据权利要求3所述的方法，其特征在于，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
  5. 根据权利要求3或4所述的方法，其特征在于，所述安全需求包括安全需求列表中的多个子需求。
  6. 根据权利要求3-5中任一项所述的方法，其特征在于，所述第一模型的输入参数还包括以下至少之一：安全规则、网络安全态势、系统安全态势。
  7. 根据权利要求3或4所述的方法，其特征在于，所述方法还包括：
    所述安全策略网元接收来自策略检测网元的所述安全需求。
  8. 根据权利要求7所述的方法，其特征在于，所安全需求是在所述终端设备的业务发生变化的情况下生成。
  9. 根据权利要求8所述的方法，其特征在于，所述安全需求基于第二模型生成。
  10. 根据权利要求1-9中任一项所述的方法，其特征在于，在所述安全策略网元生成安全策略之前，所述方法还包括：
    所述安全策略网元接收所述策略执行网元发送的第一请求消息，所述第一请求消息用于请求所述安全策略，所述第一请求消息是在所述终端设备的业务发生变化的情况下发送。
  11. 根据权利要求1-10中任一项所述的方法，其特征在于，在所述安全策略网元生成安全策略之前，所述方法还包括：
    所述安全策略网元判断是否需要生成所述安全策略；
    所述安全策略网元生成安全策略，包括：
    在需要生成所述安全策略的情况下，所述安全策略网元生成所述安全策略。
  12. 一种用于生成安全策略的方法，其特征在于，包括：
    策略执行网元向第一网元发送第一请求消息，所述第一请求消息用于请求安全策略，所述安全策略与所述终端设备的业务相关联，所述第一网元包括安全策略网元和/或策略检测网元；
    所述策略执行网元接收来自所述安全策略网元的所述安全策略。
  13. 根据权利要求12所述的方法，其特征在于，所述安全策略基于第一模型生成。
  14. 根据权利要求13所述的方法，其特征在于，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、与所述终端设备的业务对应的安全需求、与所述终端设备的业务对应的安全能力。
  15. 根据权利要求14所述的方法，其特征在于，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
  16. 根据权利要求14或15所述的方法，其特征在于，所述安全需求包括安全需求列表中的多个子需求。
  17. 根据权利要求14-16中任一项所述的方法，其特征在于，所述第一模型的输入参数还包括以下至少之一：安全规则、网络安全态势、系统安全态势。
  18. 根据权利要求14或15所述的方法，其特征在于，所述安全需求由所述策略检测网元发送至所述安全策略网元。
  19. 根据权利要求18所述的方法，其特征在于，所述安全需求是在所述终端设备的业务发生变化的情况下生成。
  20. 根据权利要求18或19所述的方法，其特征在于，所述安全需求基于第二模型生成。
  21. 根据权利要求12-20中任一项所述的方法，其特征在于，在所述策略执行网元向第一网元发送第一请求消息之前，所述方法还包括：
    所述策略执行网元接收来自终端设备的第一指示信息，所述第一指示信息用于指示所述终端设备的业务发生变化。
  22. 一种用于生成安全策略的方法，其特征在于，包括：
    策略检测网元接收来自策略执行网元的第一请求消息，所述第一请求消息用于请求安全策略；
    响应于所述第一请求消息，所述策略检测网元生成与所述终端设备的业务对应的安全需求；
    所述策略检测网元向安全策略网元发送所述安全需求，所述安全需求用于所述安全策略网元生成所述安全策略。
  23. 根据权利要求22所述的方法，其特征在于，所述安全策略基于第一模型生成。
  24. 根据权利要求23所述的方法，其特征在于，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、所述安全需求、与所述终端设备的业务对应的安全能力。
  25. 根据权利要求24所述的方法，其特征在于，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
  26. 根据权利要求24或25所述的方法，其特征在于，所述安全需求包括安全需求列表中的多个子需求。
  27. 根据权利要求22-26中任一项所述的方法，其特征在于，所述安全需求基于第二模型生成。
  28. 一种用于生成安全策略的方法，其特征在于，包括：
    终端设备向策略执行网元发送第一指示信息，所述第一指示信息用于指示所述终端设备的业务发生变化；
    所述终端设备接收来自所述策略执行网元的安全策略，所述安全策略与所述终端设备的业务相关联。
  29. 根据权利要求28所述的方法，其特征在于，所述安全策略基于第一模型生成。
  30. 根据权利要求29所述的方法，其特征在于，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、与所述终端设备的业务对应的安全需求、与所述终端设备的业务对应的安全能力。
  31. 根据权利要求30所述的方法，其特征在于，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
  32. 根据权利要求30所述的方法，其特征在于，所述安全需求属于安全需求列表中的多个子需求。
  33. 根据权利要求30-32中任一项所述的方法，其特征在于，所述第一模型的输入参数还包括以下至少之一：安全规则、网络安全态势、系统安全态势。
  34. 根据权利要求30或31所述的方法，其特征在于，所述安全需求由策略检测网元发送至所述安全策略网元。
  35. 根据权利要求34所述的方法，其特征在于，所述安全需求是在所述终端设备的业务发生变化的情况下生成。
  36. 根据权利要求35所述的方法，其特征在于，所述安全需求基于第二模型生成。
  37. 一种通信设备，其特征在于，所述通信设备为安全策略网元，所述通信设备包括：
    生成单元，用于生成安全策略，所述安全策略与终端设备的业务相关联；
    发送单元，用于向策略执行网元发送所述安全策略。
  38. 根据权利要求37所述的通信设备，其特征在于，所述生成单元用于：
    基于第一模型生成所述安全策略。
  39. 根据权利要求38所述的通信设备，其特征在于，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、与所述终端设备的业务对应的安全需求、与所述终端设备的业务对应的安全能力。
  40. 根据权利要求39所述的通信设备，其特征在于，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
  41. 根据权利要求39或40所述的通信设备，其特征在于，所述安全需求包括安全需求列表中的多个子需求。
  42. 根据权利要求39-41中任一项所述的通信设备，其特征在于，所述第一模型的输入参数还包括以下至少之一：安全规则、网络安全态势、系统安全态势。
  43. 根据权利要求39或40所述的通信设备，其特征在于，所述通信设备还包括：
    接收单元，用于接收来自策略检测网元的所述安全需求。
  44. 根据权利要求43所述的通信设备，其特征在于，所安全需求是在所述终端设备的业务发生变化的情况下生成。
  45. 根据权利要求44所述的通信设备，其特征在于，所述安全需求基于第二模型生成。
  46. 根据权利要求37-45中任一项所述的通信设备，其特征在于，在生成安全策略之前，所述通信 设备还包括：
    接收单元，用于接收所述策略执行网元发送的第一请求消息，所述第一请求消息用于请求所述安全策略，所述第一请求消息是在所述终端设备的业务发生变化的情况下发送。
  47. 根据权利要求37-46中任一项所述的通信设备，其特征在于，所述通信设备还包括判断单元，
    所述判断单元，用于判断是否需要生成所述安全策略；
    所述生成单元，用于在需要生成所述安全策略的情况下，生成所述安全策略。
  48. 一种通信设备，其特征在于，所述通信设备为策略执行网元，所述通信设备包括：
    发送单元，用于向第一网元发送第一请求消息，所述第一请求消息用于请求安全策略，所述安全策略与所述终端设备的业务相关联，所述第一网元包括安全策略网元和/或策略检测网元；
    接收单元，用于接收来自所述安全策略网元的所述安全策略。
  49. 根据权利要求48所述的通信设备，其特征在于，所述安全策略基于第一模型生成。
  50. 根据权利要求49所述的通信设备，其特征在于，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、与所述终端设备的业务对应的安全需求、与所述终端设备的业务对应的安全能力。
  51. 根据权利要求50所述的通信设备，其特征在于，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
  52. 根据权利要求50或51所述的通信设备，其特征在于，所述安全需求包括安全需求列表中的多个子需求。
  53. 根据权利要求50-52中任一项所述的通信设备，其特征在于，所述第一模型的输入参数还包括以下至少之一：安全规则、网络安全态势、系统安全态势。
  54. 根据权利要求50或51所述的通信设备，其特征在于，所述安全需求由所述策略检测网元发送至所述安全策略网元。
  55. 根据权利要求54所述的通信设备，其特征在于，所述安全需求是在所述终端设备的业务发生变化的情况下生成。
  56. 根据权利要求54或55所述的通信设备，其特征在于，所述安全需求基于第二模型生成。
  57. 根据权利要求48-56中任一项所述的通信设备，其特征在于，在向第一网元发送第一请求消息之前，所述接收单元还用于：
    接收来自终端设备的第一指示信息，所述第一指示信息用于指示所述终端设备的业务发生变化。
  58. 一种通信设备，其特征在于，所述通信设备为策略检测网元，所述通信设备包括：
    接收单元，用于接收来自策略执行网元的第一请求消息，所述第一请求消息用于请求安全策略；
    生成单元，用于响应于所述第一请求消息，生成与所述终端设备的业务对应的安全需求；
    发送单元，用于向安全策略网元发送所述安全需求，所述安全需求用于所述安全策略网元生成所述安全策略。
  59. 根据权利要求58所述的通信设备，其特征在于，所述安全策略基于第一模型生成。
  60. 根据权利要求59所述的通信设备，其特征在于，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、所述安全需求、与所述终端设备的业务对应的安全能力。
  61. 根据权利要求60所述的通信设备，其特征在于，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
  62. 根据权利要求60或61所述的通信设备，其特征在于，所述安全需求包括安全需求列表中的多个子需求。
  63. 根据权利要求58-62中任一项所述的通信设备，其特征在于，所述安全需求基于第二模型生成。
  64. 一种通信设备，其特征在于，所述通信设备为终端设备，所述通信设备包括：
    发送单元，用于向策略执行网元发送第一指示信息，所述第一指示信息用于指示所述终端设备的业务发生变化；
    接收单元，用于接收来自所述策略执行网元的安全策略，所述安全策略与所述终端设备的业务相关联。
  65. 根据权利要求64所述的通信设备，其特征在于，所述安全策略基于第一模型生成。
  66. 根据权利要求65所述的通信设备，其特征在于，所述第一模型的输入参数包括以下至少之一：与所述终端设备的业务对应的系统类型、与所述终端设备的业务对应的安全需求、与所述终端设备的业务对应的安全能力。
  67. 根据权利要求66所述的通信设备，其特征在于，所述安全能力包括多个子能力，所述安全策略包括多个子策略，所述多个子策略分别与所述多个子能力对应。
  68. 根据权利要求66所述的通信设备，其特征在于，所述安全需求属于安全需求列表中的多个子需求。
  69. 根据权利要求66-68中任一项所述的通信设备，其特征在于，所述第一模型的输入参数还包括以下至少之一：安全规则、网络安全态势、系统安全态势。
  70. 根据权利要求66或67所述的通信设备，其特征在于，所述安全需求由策略检测网元发送至所述安全策略网元。
  71. 根据权利要求70所述的通信设备，其特征在于，所述安全需求是在所述终端设备的业务发生变化的情况下生成。
  72. 根据权利要求71所述的通信设备，其特征在于，所述安全需求基于第二模型生成。
PCT/CN2023/142889 2023-12-28 2023-12-28 用于生成安全策略的方法及通信设备 Pending WO2025138024A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2023/142889 WO2025138024A1 (zh) 2023-12-28 2023-12-28 用于生成安全策略的方法及通信设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2023/142889 WO2025138024A1 (zh) 2023-12-28 2023-12-28 用于生成安全策略的方法及通信设备

Publications (1)

Publication Number Publication Date
WO2025138024A1 true WO2025138024A1 (zh) 2025-07-03

Family

ID=96216624

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/142889 Pending WO2025138024A1 (zh) 2023-12-28 2023-12-28 用于生成安全策略的方法及通信设备

Country Status (1)

Country Link
WO (1) WO2025138024A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018187961A1 (zh) * 2017-04-12 2018-10-18 华为技术有限公司 一种安全策略的处理方法和相关设备
CN109600339A (zh) * 2017-09-30 2019-04-09 华为技术有限公司 通信方法、装置和系统
CN113949573A (zh) * 2021-10-18 2022-01-18 天翼数字生活科技有限公司 一种零信任的业务访问控制系统及方法
CN115696332A (zh) * 2022-12-29 2023-02-03 中国信息通信研究院 基于跨层零信任的5g边缘计算安全访问控制系统和方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018187961A1 (zh) * 2017-04-12 2018-10-18 华为技术有限公司 一种安全策略的处理方法和相关设备
CN109600339A (zh) * 2017-09-30 2019-04-09 华为技术有限公司 通信方法、装置和系统
CN113949573A (zh) * 2021-10-18 2022-01-18 天翼数字生活科技有限公司 一种零信任的业务访问控制系统及方法
CN115696332A (zh) * 2022-12-29 2023-02-03 中国信息通信研究院 基于跨层零信任的5g边缘计算安全访问控制系统和方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DAVID GABAY, MITRE CORPORATION: "New KI: Support for Policy Decision Points and Policy Enforcement Points within 5GC SBA", 3GPP DRAFT; S3-230720; TYPE PCR; FS_ZTS, vol. SA WG3, 10 February 2023 (2023-02-10), Athens, GR, pages 1 - 2, XP052237169 *
KEYVAN RAMEZANPOUR; JITHIN JAGANNATH: "Intelligent Zero Trust Architecture for 5G/6G Networks: Principles, Challenges, and the Role of Machine Learning in the context of O-RAN", ARXIV.ORG, 27 July 2022 (2022-07-27), pages 1 - 14, XP091280923 *

Similar Documents

Publication Publication Date Title
TWI770803B (zh) 憑藉5g及其上之外之工業自動化
US11026095B2 (en) Real-time network provisioning for distributed virtual zones of collaborative mobile devices for 5G or other next generation network
Aïvodji et al. IOTFLA: A secured and privacy-preserving smart home architecture implementing federated learning
US20230284119A1 (en) Access to snpn by using credential owned by entity separated from snpn, and support for f1 interface therefor
US20200314796A1 (en) Method and apparatus for sidelink signalling in wireless communication system
WO2023044904A1 (zh) 通信方法、终端设备及网络设备
WO2023066351A1 (zh) 一种通信方法及装置
WO2023231713A1 (zh) 通信方法、装置及系统
US20230239692A1 (en) Machine to machine communication acceleration via encryption bypass
EP4205447B1 (en) Method and apparatus for cell reselection in sliced network in wireless communication system
US20240172032A1 (en) Method applied to communication system and communication apparatus
WO2024067351A1 (zh) 传输数据的方法和相关装置
CN116830638A (zh) 通信控制方法及装置、通信设备、通信系统、存储介质
WO2025138024A1 (zh) 用于生成安全策略的方法及通信设备
WO2025140055A1 (zh) 分布式训练方法、装置、系统、芯片模组及存储介质
Abdulqadir et al. Tracking infected covid-19 persons and their proximity users using D2D in 5G networks
KR20230145075A (ko) 무선 통신 시스템에서 셀 재선택을 위한 방법 및 장치
OA20434A (en) Wireless time-sensitive networking
US20250301342A1 (en) AI/ML Model/Functionality Adaptation for RRM Enhancements
WO2025065972A1 (en) Method and apparatus for communication
WO2025065977A1 (en) Method and apparatus for authentication
US20240362044A1 (en) Virtual assistant for facilitating actions in omnichannel telecommunications environment
US20260100961A1 (en) Code injection prevention for communication devices
EP4535209A1 (en) Service processing method and apparatus, network device and storage medium
Bangera Exploring the Potential of Private Wireless Networks for Enhanced Healthcare Services and Applications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23962703

Country of ref document: EP

Kind code of ref document: A1