SOA service access control system and method based on application sandbox

Abstract

The invention discloses an SOA service access control system and method based on an application sandbox. The SOA service access control system comprises an SOA service client, the application sandbox, a registration center or an SOA service. The SOA service client is arranged in an application sandbox, and the application sandbox is provided with a configuration analysis module, an application sandbox engine and an error alarm module; the SOA service client side at least comprises a configuration file of the SOA service client side, a configuration analysis module of the application sandbox analyzes the configuration file, control over access of the SOA service client side is achieved through an application sandbox engine according to configured strategy rules, allowed operation is forwarded to a registration center or SOA service, and otherwise, the allowed operation is reported to an error alarm module. According to the invention, the SOA service client is placed in the application sandbox, so that the client is isolated from system resources, and the security and stability of the system are prevented from being damaged by malicious behaviors, vulnerability utilization and unauthorized service requests of the client.

Description

Technical Field

[0001] The present invention relates to a SOA service access control method, and in particular to an SOA service access control system and method based on an application sandbox. Background Art

[0002] SOA (Service-Oriented Architecture) is a service-centric distributed architecture that supports flexible integration and dynamic collaboration across systems and platforms by defining loosely coupled, reusable service modules to meet complex business needs. In automotive electronic and electrical architectures, SOA, through its modularity, flexibility, and scalability, effectively supports requirements such as overall vehicle architecture optimization, dynamic feature updates, enhanced user experience, and vehicle-cloud collaboration.

[0003] SOA service clients typically work through the steps of service discovery, service connection, and service invocation. While service interactions are flexible and decoupled, this high degree of flexibility also presents security risks, such as service abuse, including unauthorized service invocations and resource exhaustion attacks. Traditional approaches restrict service client behavior through registries or by writing plug-in restriction logic on SOA servers, which is not universally applicable. Alternatively, centralized access control is implemented through methods such as API gateways, which suffer from poor resource consumption and performance and cannot be separated from the server. Summary of the Invention

[0004] In order to address the deficiencies in the prior art, the present invention aims to provide an SOA service access control system and method based on an application sandbox.

[0005] To achieve the purpose of the present invention, the technical solution adopted by the present invention is: An SOA service access control system based on an application sandbox includes an SOA service client, an application sandbox, a registration center or an SOA service; the SOA service client is placed in the application sandbox, and the application sandbox is configured with a configuration parsing module, an application sandbox engine, and an error alarm module; The SOA service client contains at least its own configuration file. The configuration parsing module of the application sandbox parses the configuration file and controls access to the SOA service client according to the configured policy rules through the application sandbox engine. Permitted operations are forwarded to the registration center or SOA service, otherwise they are reported to the error alarm module.

[0006] Furthermore, the configuration of the SOA service client configuration file includes: Service discovery permissions: whether the user is allowed to perform SOA service discovery or access the SOA registry; List of accessible SOA services: whether a client is allowed to initiate a connection to a specific SOA service, and clarify the scope of services to which the client can connect; Service method call permission: whether a request is allowed to be made to a specific method of the SOA service.

[0007] Furthermore, the specific definition of SOA service methods includes: Access frequency limit: the upper limit of the number of method calls per unit time; Access time restriction: whether to allow calls in certain business scenarios or time periods; Parameter constraint rules: restrict the value range or validity of request parameters.

[0008] Furthermore, the security and rationality of the configuration file are solved through the PKI signature mechanism and manual review mechanism.

[0009] A method for SOA service access control based on application sandbox, comprising the steps of: S1: After the SOA service client is placed in the application sandbox, the SOA application configuration file is parsed by the configuration parsing module of the application sandbox; S2: Update the policy rules after configuration parsing to the application sandbox engine; S3: The SOA service client's operation is determined by the application sandbox engine. If it is an authorized operation, it will be released by the application sandbox to the registration center or specific SOA service; S4: If the operation is not authorized, the operation of the SOA service client is recorded by the error alarm module.

[0010] Furthermore, in S2, the structured policy after reading and parsing is converted into a data structure recognizable by the application sandbox engine, such as JSON, binary structure or memory table structure. The policy includes an access control table, a service-method mapping table, and a frequency limit table, and is hot updated through IPC to take effect.

[0011] Furthermore, in S3, the specific behaviors of SOA service client operations include: S31: The SOA service client requests SOA service information from the service registry through service discovery. If the service discovery configuration in the configuration file allows it, service discovery is performed. If the service discovery configuration in the configuration file is not set, the sandbox rule restricts the request to the sandbox environment, and service discovery cannot be performed. S32: The service registration center returns service list information to the SOA service client; S33: The SOA service client connects to the service through the returned service list. When connecting to the SOA service, if this rule is configured, the connection request will be allowed if the sandbox rule is checked. If this rule is not configured, the request will be restricted within the sandbox. S34: After the SOA service client successfully connects to the SOA service, it makes a service method request. If a service method request is configured, the service method request will reach the SOA service and be processed. If no service method request is configured, the service method request will be restricted within the sandbox and will not reach the SOA service. S35: Further restrictions are imposed on the application sandbox for the allowed service method requests, including: access frequency restrictions, access time restrictions, and parameter constraint rule restrictions.

[0012] Furthermore, in S4, the error alarm module supports triggering automatic response strategies and isolating abnormal clients; the error alarm module works together with other security modules to further protect the system, specifically reporting abnormal behavior information to the firewall, IDS, and SIEM security modules through real-time alarms.

[0013] The beneficial effect of the present invention is that, compared with the existing technology, the present invention isolates the client from system resources by placing the SOA service client in an application sandbox, thereby preventing the client from damaging the security and stability of the system due to malicious behavior, vulnerability exploitation, and unauthorized service requests.

[0014] This invention dynamically monitors and responds to service client behavior through configuration files. This centralized control within the sandbox reduces development costs on the registry or SOA server side, making it more efficient and versatile. By pre-empting access control within the sandbox environment, this invention effectively reduces resource consumption on core services, simplifies server-side implementation complexity, and improves overall system performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 Schematic diagram of the SOA service access control system based on application sandbox according to the present invention; Figure 2 It is a schematic diagram of a specific embodiment of SOA service client behavior. DETAILED DESCRIPTION

[0016] The technical solution of the present invention will be further described below in conjunction with the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention and are not intended to limit the scope of protection of this application.

[0017] like Figure 1 As shown, the SOA service access control system based on application sandbox described in the present invention includes an SOA service client, an application sandbox, a registration center or an SOA service; the SOA service client is placed in the application sandbox, and the application sandbox is configured to configure a parsing module, an application sandbox engine, and an error alarm module.

[0018] Application sandboxing is a security mechanism that isolates the runtime environment and limits an application's access to system resources, thereby protecting the system and other applications from malicious activity. When an SOA service client is placed in an application sandbox, its resource control mechanism prevents it from accessing any system resources, including SOA services, by default.

[0019] In addition to the application, each SOA service client must contain at least its own configuration file. The configuration parsing module of the application sandbox parses the configuration file and controls access to the SOA service client based on policy rules through the application sandbox engine. Permitted operations will be forwarded to the registration center or the corresponding SOA service. Otherwise, they will be reported to the error alarm module. This module can be linked with other tools such as firewalls to further protect the system.

[0020] The SOA service access control method based on application sandbox of the present invention comprises the following steps: S1: After the SOA service client is placed in the application sandbox, the SOA application configuration file is parsed through the configuration parsing module; The configuration of the SOA service client configuration file includes: 1. Service discovery permissions: whether the user is allowed to perform SOA service discovery and access the SOA registry; 2. List of accessible SOA services: Whether a client is allowed to initiate a connection to a specific SOA service, clarifying the scope of services to which the client can connect; 3. Service method call permissions: Whether a request is allowed to initiate a specific method of the SOA service, which can be broken down into specific methods or method sets within a service; 4. Specific limitations on SOA service methods, including: Access frequency limit: for example, the upper limit of the number of calls per unit time to a certain method; Access time restriction: whether to allow calls in certain business scenarios or time periods (for example, prohibiting OTA while the vehicle is in motion); Parameter constraint rules: restrict the value range or validity of request parameters.

[0021] The security and rationality of configuration files can be addressed through a PKI plus manual review mechanism. Specifically: 1. Manual review mechanism: All configuration files must be manually reviewed before release to ensure that the policy complies with business logic and security boundaries. For example, entertainment domain clients are prohibited from accessing key control services in the intelligent driving domain; OTA services cannot be called while the vehicle is in motion. 2. PKI Signature Mechanism: Configuration files that have passed manual review will be digitally signed using the PKI (Public Key Infrastructure) mechanism. This verifies that the file has not been tampered with when the configuration is loaded, preventing developers or attackers from bypassing the review mechanism and privately changing the configuration authorization.

[0022] S2: Update the policy rules after configuration parsing to the application sandbox engine; Specifically, by reading the parsed structured policy and converting it into a data structure recognizable by the sandbox engine (such as JSON, binary structure or memory table structure), the policy including the access control list (ACL), service-method mapping table, frequency limit table, etc. is hot-updated and takes effect through IPC.

[0023] S3: The SOA service client's operation is determined by the application sandbox engine. If it is an authorized operation, it will be released by the application sandbox to the registration center or specific SOA service; The application sandbox engine will reasonably allocate the accessible resources of the program according to the configuration file, and further reasonably restrict the behavior during the service request process. The application sandbox engine implements the restriction of behavior during the service request process through behavior interception, decision control, and log alarms. Specifically, it monitors or hooks all key behaviors and intercepts them through system calls; it takes over the application code behavior through the proxy interface of the service SDK, the RPC middle layer, and API proxy injection; after the SOA behavior occurs, it matches the defined rules, such as the range of parameter intervals, call frequency, etc.; it disallows all undefined behaviors; it records illegal behaviors and sends alarms to cooperate with other modules to enhance system security.

[0024] The specific behaviors of SOA service client operations are as follows: S31: The SOA service client requests SOA service information from the service registry through service discovery. If the service discovery configuration in the configuration file allows it, service discovery is performed. If the service discovery configuration in the configuration file is not set, the sandbox rules will restrict the request to the sandbox environment, and service discovery will not be performed. S32: The service registration center returns service list information to the SOA service client; S33: The SOA service client connects to the service through the returned service list. When connecting to the SOA service, if this rule is configured, the connection request will be allowed if the sandbox rule is checked. If this rule is not configured, the request will be restricted within the sandbox. S34: After the SOA service client successfully connects to the SOA service, it makes a service method request. If the service method request is configured, the service method request will reach the SOA service and be processed. If the service method request is not configured, the service method request will be restricted to the sandbox and cannot reach the SOA service. S35: The application sandbox can further restrict the allowed service method requests. For example, if the number of requests per unit time or the request parameter range is not within the request, the request will also be restricted to the sandbox and cannot reach the SOA service.

[0025] S4: If the operation is not authorized, the operation of the SOA service client will be recorded by the error alarm module, which can be linked with other security modules for operation.

[0026] The error alert module can be integrated with other tools, such as firewalls, to further protect the system. Specifically, it reports abnormal behavior information to security devices such as firewalls, IDS, and SIEM through real-time alerts. Firewalls can automatically adjust access rules based on alerts to dynamically block attack traffic. The intrusion detection system combines sandbox logs for behavioral analysis to identify complex threats. Furthermore, the module supports triggering automatic response policies, such as isolating abnormal clients, enhancing the system's overall security situational awareness and achieving multi-layered coordinated protection.

[0027] A specific embodiment of the present application, such as Figure 2 As shown in the following figure, the sample configuration of the SOA service client configuration file includes: 1. Service discovery: whether SOA service discovery is allowed; 2. SOA service 1 / 2 access: whether the connection to the specific SOA service is allowed; 3. SOA service method 1 / 2 request: whether the request is allowed to initiate a specific method of the SOA service; 4. The number of requests per unit time for SOA service methods and the limit of request parameter range.

[0028] The behavior of the SOA service client is as follows: S01: The SOA service client requests SOA service information from the service registry through service discovery. If service discovery is configured as "no" in the configuration file, the sandbox rule restricts the request to the sandbox environment, preventing service discovery. This means that the behavior in S02 will not occur. S02: The service registration center returns the service list information to the SOA service client; S03 / S06: The SOA service client connects to the service using the returned service list. When connecting to SOA service 1, if this rule is configured, the sandbox rule check will allow the connection request. When connecting to SOA service 2, if this rule is not configured, the request will be restricted within the sandbox and will not be able to reach SOA service 2. S04 / S05: After the SOA service client successfully connects to the SOA service, it makes a service method request. If a request for service method 1 is configured, the request will reach SOA service 1 and be processed. If a request for service method 2 is not configured, the request will be restricted to the sandbox and will not reach the SOA service. S07: The application sandbox can further restrict the allowed service method requests. If the number of requests per unit time exceeds 3 times, or the request parameter range is not between x1 and x2, the request will also be restricted in the sandbox and cannot reach the SOA service.

[0029] The beneficial effect of the present invention is that, compared with the existing technology, the present invention isolates the client from system resources by placing the SOA service client in an application sandbox, thereby preventing the client from damaging the security and stability of the system due to malicious behavior, vulnerability exploitation, and unauthorized service requests.

[0030] This invention dynamically monitors and responds to service client behavior through configuration files. This centralized control within the sandbox reduces development costs on the registry or SOA server side, making it more efficient and versatile. By pre-empting access control within the sandbox environment, this invention effectively reduces resource consumption on core services, simplifies server-side implementation complexity, and improves overall system performance.

[0031] The applicant of the present invention has made a detailed explanation and description of the implementation examples of the present invention in conjunction with the drawings in the specification. However, those skilled in the art should understand that the above implementation examples are only preferred implementation plans of the present invention, and the detailed description is only to help readers better understand the spirit of the present invention, and is not a limitation on the scope of protection of the present invention. On the contrary, any improvements or modifications based on the inventive spirit of the present invention should fall within the scope of protection of the present invention.

Claims

1. A SOA service access control system based on application sandbox, characterized in that: Includes SOA service client, application sandbox, registration center or SOA service; SOA service client is placed in the application sandbox, and the application sandbox configuration parsing module, application sandbox engine, and error alarm module; The SOA service client contains at least its own configuration file. The configuration parsing module of the application sandbox parses the configuration file and controls access to the SOA service client according to the configured policy rules through the application sandbox engine. Permitted operations are forwarded to the registration center or SOA service, otherwise they are reported to the error alarm module.

2. The SOA service access control system based on application sandbox according to claim 1, characterized in that: The configuration of the SOA service client configuration file includes: Service discovery permissions: whether the user is allowed to perform SOA service discovery or access the SOA registry; List of accessible SOA services: whether a client is allowed to initiate a connection to a specific SOA service, and clarify the scope of services to which the client can connect; Service method call permission: whether a request is allowed to be made to a specific method of the SOA service.

3. The SOA service access control system based on application sandbox according to claim 2, characterized in that: Specific limitations on SOA service methods include: Access frequency limit: the upper limit of the number of method calls per unit time; Access time restriction: whether to allow calls in certain business scenarios or time periods; Parameter constraint rules: restrict the value range or validity of request parameters.

4. The SOA service access control system based on application sandbox according to claim 1, characterized in that: The security and rationality of the configuration file are ensured through the PKI signature mechanism and manual review mechanism.

5. A SOA service access control method based on application sandbox, characterized in that: Including steps: S1: After the SOA service client is placed in the application sandbox, the SOA application configuration file is parsed by the configuration parsing module of the application sandbox; S2: Update the policy rules after configuration parsing to the application sandbox engine; S3: The SOA service client's operation is determined by the application sandbox engine. If it is an authorized operation, it will be released by the application sandbox to the registration center or specific SOA service; S4: If the operation is not authorized, the operation of the SOA service client is recorded by the error alarm module.

6. The SOA service access control method based on application sandbox according to claim 5, characterized in that: In S2, the structured policy after reading and parsing is converted into a data structure that can be recognized by the application sandbox engine, such as JSON, binary structure or memory table structure. The policy includes an access control table, a service-method mapping table, and a frequency limit table, and is hot updated through IPC to take effect.

7. The SOA service access control method based on application sandbox according to claim 5, characterized in that: In S3, the specific behaviors of SOA service client operations include: S31: The SOA service client requests SOA service information from the service registry through service discovery. If the service discovery configuration in the configuration file allows it, service discovery is performed. If the service discovery configuration in the configuration file is not set, the sandbox rule restricts the request to the sandbox environment, and service discovery cannot be performed. S32: The service registration center returns service list information to the SOA service client; S33: The SOA service client connects to the service through the returned service list. When connecting to the SOA service, if this rule is configured, the connection request will be allowed if the sandbox rule is checked. If this rule is not configured, the request will be restricted within the sandbox. S34: After the SOA service client successfully connects to the SOA service, it makes a service method request. If a service method request is configured, the service method request will reach the SOA service and be processed. If no service method request is configured, the service method request will be restricted within the sandbox and will not reach the SOA service. S35: Further restrictions are imposed on the application sandbox for the allowed service method requests, including: access frequency restrictions, access time restrictions, and parameter constraint rule restrictions.

8. The SOA service access control method based on application sandbox according to claim 5, characterized in that: In S4, the error alarm module supports triggering automatic response strategies and isolating abnormal clients. The error alarm module collaborates with other security modules to further protect the system, specifically reporting abnormal behavior information to the firewall, IDS, and SIEM security modules through real-time alarms.

Images