Access control method, system, device, medium and product of message processing system

Abstract

The application provides an access control method, system, device, medium and product of a message processing system, and relates to the technical field of cloud computing. In the embodiment, a message topic is associated with an IP address white list, the source IP address is inquired according to the association relationship, if the source IP address is credible, whether the sender has the permission to perform an operation on the target message topic is inquired, and the corresponding operation is performed under the condition of having the permission. The security of accessing the message processing system is ensured through the verification of two dimensions of the IP address and the operation permission, without the need of maintaining a complex ACL, the complexity of management is reduced, the method can be applied to a multi-tenant environment, the performance degradation caused by the increase of the rules in the ACL due to the increase of the number of IP addresses is reduced, and the stability of the service is ensured.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to an access control method, system, device, medium and product for a message processing system. Background Technology

[0002] A distributed messaging platform is a system architecture for high-throughput, low-latency, and persistent processing of continuous data streams. It not only supports traditional message queue functions (such as publish / subscribe and point-to-point communication) but also emphasizes the storage, processing, and analysis capabilities of real-time data streams. For example, Kafka, as an industry-leading distributed messaging platform, is a core component of many cloud products and customer services in private clouds, providing tenants (users / applications) with secure, reliable, and easily manageable resource isolation.

[0003] Currently, distributed message flow platforms employ Access Control List (ACL) security mechanisms, which expose inherent management complexities in large-scale multi-tenant environments. ACLs tightly couple tenants (users / applications), topics, and Internet Protocol (IP) addresses. The number of rules in an ACL explodes exponentially with the increase in tenants, topics, and IP addresses, leading to extremely high operational costs. Manually managing massive amounts of fragmented ACL rules is highly error-prone, and automated scripts are also exceptionally complex, increasing security risks. To simplify ACL configuration, administrators may be forced to use wildcards such as Host:*, but this means that tenants with valid credentials can initiate access from any IP address, directly exposing the Kafka cluster to potential network attacks and leaving serious security vulnerabilities. Summary of the Invention

[0004] This application provides an access control method, system, device, medium, and product for a message processing system to solve at least one of the above-mentioned technical problems.

[0005] In a first aspect, embodiments of this application provide an access control method for a message processing system. The message processing system includes multiple service nodes. The method is applied to the service nodes and includes: responding to a message access request sent by a client, obtaining a sender identifier, a source IP address, and a target message topic to be accessed from the message access request; querying the source IP address in a whitelist of IP addresses associated with the target message topic; if the source IP address is found, querying whether the current sender has permission to execute a target operation based on the sender identifier; the target operation is the operation corresponding to the message access request executed on the target message topic; if so, executing the target operation.

[0006] Secondly, embodiments of this application provide a message processing system, which includes multiple service nodes. Each service node is configured to: respond to a message access request sent by a client, obtain the sender identifier, source IP address, and target message topic to be accessed from the message access request; query the source IP address in the IP address whitelist associated with the target message topic; if the source IP address is found, query whether the current sender has permission to execute the target operation based on the sender identifier; the target operation is the operation corresponding to the message access request executed on the target message topic; if so, execute the target operation.

[0007] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor implements any of the methods described above when executing the computer program.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods described above.

[0009] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a processor, implements any of the methods described above.

[0010] Compared with the prior art, this application has the following advantages:

[0011] This application provides an access control method, system, device, medium, and product for a message processing system. In response to a message access request sent by a client, the method obtains the sender identifier, source IP address, and target message topic from the message access request. It then queries the source IP address in a whitelist of IP addresses associated with the target message topic. If the source IP address is found, it checks whether the sender has permission to execute the target operation based on the sender identifier. The target operation is the operation corresponding to the message access request performed on the target message topic. If so, the target operation is executed. In this embodiment, by associating the message topic with the IP address whitelist, the method queries whether the source IP address is trustworthy based on the association. If trustworthy, it then checks whether the sender has permission to execute an operation on the target message topic. If permission is granted, the corresponding operation is executed. This two-dimensional verification of IP address and operation permission ensures the security of accessing the message processing system. Furthermore, it eliminates the need to maintain complex ACLs, reducing management complexity. It is suitable for multi-tenant environments, minimizing performance degradation caused by the increase in rules in the ACL due to an increase in IP addresses, and ensuring service stability.

[0012] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0013] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0014] Figure 1 This is a schematic diagram illustrating an application scenario of an access control method for a message processing system according to an embodiment of this application.

[0015] Figure 2 This is a flowchart of an access control method for a message processing system according to an embodiment of this application.

[0016] Figure 3 This is a flowchart of an access control method for a message processing system according to an embodiment of this application.

[0017] Figure 4 This is a structural block diagram of an access control device for a message processing system according to an embodiment of this application.

[0018] Figure 5 This is a block diagram of an electronic device used to implement embodiments of this application. Detailed Implementation

[0019] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0020] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0021] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0022] In related technologies, message processing systems (such as Kafka) use Access Control Lists (ACLs) for access control. An ACL contains multiple ACL rules, each consisting of a five-tuple: Principal, Host, Resource, Operation, and Permission. This defines "who, on which IP address, can perform which operation on which resource." The Principal refers to the user or application performing the operation. The Host is the client's IP address, such as 192.168.1.100 or a wildcard *. The Resource is the object being operated on, such as a message topic or group. The Operation is the specific action, such as Write or Read. The Permission specifies whether the operation is allowed or denied.

[0023] Using the ACL structure described above for access control has the following problems:

[0024] 1. Explosion of management complexity: In scenarios with multiple users, multiple message topics, and multiple IP addresses, the number of rules grows exponentially, resulting in extremely high management and auditing costs.

[0025] 2. Coupling and Ambiguity of Responsibilities: Tightly coupling identity permissions (who can do what) and network policies (where to access) into a single rule leads to unclear security responsibilities.

[0026] 3. High-risk configuration tendency: Due to the complexity of the configuration, administrators may tend to use the Host:* wildcard for ease of operation, which directly bypasses IP-based access control and introduces security risks.

[0027] 4. Performance bottleneck: When the ACL rule list is very long, the list needs to be traversed when validating each request, which may introduce uncontrollable performance latency.

[0028] To address the aforementioned issues, another related technology restricts access sources and implements access control outside the Kafka system through network infrastructure (such as Virtual Private Cloud (VPC) network ACLs, security groups, and hardware firewalls). For example, a security group can be configured for the message topic service node hosting a specific service, allowing only a specific range of IP addresses to access it. This approach has the following problems:

[0029] 1. Coarse-grained: Network security policies typically operate at the VPC network, subnet, or cloud host (service node instance) level, failing to achieve fine-grained message topic-level access control. If message topics from multiple services are deployed together on the same group of service nodes, this method cannot effectively isolate them.

[0030] 2. Fragmented Management: Security policy management is handled in the network module of the cloud console, completely separated from the message processing system's own management. Application deployment and scaling require simultaneous changes to Kafka permissions and external network policies, increasing operational complexity and the probability of errors.

[0031] 3. Poor dynamism: Changes to network ACLs / security groups typically take effect slower than changes to Kafka's internal metadata, making them unsuitable for scenarios requiring dynamic, high-frequency adjustments.

[0032] To address the aforementioned issues, this application proposes a "two-layer decoupled" security model, decomposing access control into two independent, orthogonal, and sequentially passing layers: the network admission layer and the application layer authorization. This resolves the complexity and security limitations of related technologies. Orthogonality means that the functions of two or more components are independent and do not affect each other, allowing for independent changes and combinations. In the network admission layer, since network requests (e.g., producing messages, consuming messages, group management, etc.) are related to accessing topics, an independent, mandatory IP address whitelist is configured for each topic. This configuration is stored directly as an extended attribute of the topic, independent of users or ACLs. In this way, network policies and identity permissions are decoupled, allowing network administrators or application maintenance personnel to focus only on which IPs are allowed to access a topic, making configuration intuitive and responsibilities clear.

[0033] The specific implementation of application-layer authorization includes: continuing to use Kafka's ACL mechanism, but using it in a "downgraded" way. That is, ACL rules no longer include host (IP address) information. ACLs are only responsible for defining the Principal's operation permissions for resources such as Topics and Groups. In this way, ACL rules become simpler and more stable; a Principal's permissions will not need to be changed due to the addition or removal of its deployment IP, greatly reducing the complexity of identity and permission management.

[0034] In practical applications, after receiving a message access request, the service node first performs IP verification at the network access layer, checking whether the source IP address is in the IP address whitelist, and then performs ACL verification at the application layer to determine whether it has the necessary permissions. If any layer of verification fails, the message access request will be rejected.

[0035] Figure 1 A schematic diagram of an application scenario for the access control method of the message processing system provided in this application, including the following process:

[0036] 1. The client application sends a message access request to the service node, carrying its identity credentials (User:AppA) and source IP address (10.0.1.10). The identity credentials are the sender's identifier; the client application can be either a message producer or a consumer.

[0037] 2. The message access request first enters the network processing layer of the service node (e.g., the SocketServer module) and is intercepted by the network admission layer. In the specific implementation, a validation handler (IpValidationHandler) is configured in the Processor thread of the SocketServer module to implement the function of the network admission layer.

[0038] The verification processor parses the target message topic (Topic), identity credential (User:AppA), and source IP address from the message access request. Then, it queries the metadata cache in memory. This cache stores the association between multiple message topics and IP address whitelists synchronized from the metadata center, i.e., a Topic IP whitelist hash table. The hash table includes key-value pairs, where the key in the key-value pair is the Topic, and the value in the key-value pair is a set of IP addresses.

[0039] The metadata center is configured with a message storage component to store metadata, such as message topic configurations, including the association between message topics and IP address whitelists (Topic.ip.whitelist=[...]). Service nodes monitor changes to the Topic configuration in the metadata center. When the IP whitelist is updated, the service node asynchronously updates it to its local high-efficiency memory cache (such as a ConcurrentHashMap). <String, Set <string>>, where Key is the Topic name and Value is a set of IPs.

[0040] The validator checks if the source IP address is in the target Topic's IP address whitelist. If it is, the verification passes, and the message access request is allowed to proceed to the application layer authorization section for further verification. If it is not, the request is directly rejected.

[0041] 3. In the application-layer authorization section, an operation permission list is obtained. This list records the operation permissions of multiple senders for multiple message topics. Operation permissions include allowing or denying the sender from performing the corresponding operation. The operation permission list can be a pre-configured list based on operation permission list configuration instructions, or it can directly use an ACL from the Kafka system, which can be a simplified ACL without IP addresses. The operation permission list is then checked to see if User:AppA has permission to perform the target operation corresponding to the message access request for the target topic, including but not limited to: read, write, etc. If permission is denied, the request is denied; if permission is granted, the request is allowed to be processed.

[0042] In this embodiment, independent metadata management is possible: the IP address whitelist is configured as a Topic parameter (e.g., topic.ip.whitelist), and can be added, deleted, or modified via the Topic Alter command, and is directly stored in a metadata storage component (e.g., ZooKeeper or KRaft Log). The lifecycle of managing the IP address whitelist can be bound to the Topic itself, without depending on or polluting the Kafka system's ACL storage. Furthermore, a custom validation processor is configured at the network processing layer of the service node. This processor can perform lightweight IP address validation before the Kafka system performs time-consuming protocol parsing, authentication, or ACL validation. If the validation fails, the request is rejected, preventing invalid requests from consuming backend resources. Moreover, when validating IP addresses, the validation processor only needs to perform one in-memory hash lookup (Map.get(topic).contains(ip)), with a time complexity of O(log n). O (1) Extremely high performance with minimal impact on request latency. The network admission layer is a security enhancement module that can be enabled / disabled independently. It can be used in parallel with Kafka's native ACLs without interference. Users can choose to use only this solution, only the native ACLs, or both to achieve the highest level of security.

[0043] The technical solution of this application overcomes the problems in related technologies through a "two-layer decoupling" model. The following is a comparative description from four aspects:

[0044] (1) Overcome management complexity: optimize management complexity from "Cartesian product explosion" to "linear growth".

[0045] In a multi-tenant (user / application) scenario, define the following variables:

[0046]

[0047] Table 1

[0048] In related technologies (native ACLs), due to the tight coupling of identity, resources, and network origin, a complete consumption authorization requires creating rules that bind IP addresses for both Topic and Group, resulting in a Cartesian product of the total number of rules.

[0049] Complexity formula: (1)

[0050] In the technical solution of this application, the management task is decomposed into two independent levels with additive complexity:

[0051] Application layer authorization: Manages ACL rules without IP addresses, the number of which is [number missing]. (2).

[0052] Network access layer: Manages the IP address whitelist for topics; the number of configuration items is [number missing]. T .

[0053] The complexity of management has changed from a multiplicative relationship to an additive relationship.

[0054] Complexity formula: (3)

[0055] In a specific example, the quantitative comparison of management complexity is shown in Table 2:

[0056]

[0057] Table 2

[0058] As shown in Table 2, the technical solution of this application reduces the complexity of the management unit by more than 97%. This is not just a reduction in quantity, but a dimensionality reduction from exponential growth to linear growth, which greatly reduces the total cost of operation and maintenance management and makes automation and security auditing simple and reliable.

[0059] (2) Overcoming ambiguous responsibilities: Achieving a clear separation of authority and responsibility

[0060] In related technologies, under the native ACL model, a single ACL rule combines responsibilities from three dimensions: identity, service, and network. Identity administrators, application developers, and network security engineers must jointly maintain the same complex rule system, leading to unclear responsibilities.

[0061] In the technical solution of this application, the two levels correspond to different management responsibilities:

[0062] Network access layer (IP address verification): This is the responsibility of network security officers or operations teams, focusing on "where access is possible".

[0063] Application layer authorization (permission verification): This is the responsibility of the identity administrator or application developer, focusing on "who can do what".

[0064] Technical Benefits: The technical solution presented in this application achieves "separation of concerns" in security management. Responsibilities are clearly defined, allowing teams to operate independently and in parallel without interference. For example, when expanding an application by adding IP addresses, the network security officer only needs to add the IP address to the relevant topic's IP address whitelist; no identity administrator intervention is required, significantly improving organizational collaboration efficiency.

[0065] (3) Overcome security limitations: strengthen defense-in-depth capabilities

[0066] In related technologies, the native ACL model integrates "identity-IP-resource" into a unified whole. Once a user's credentials are stolen, an attacker can directly obtain a precise list of authorized IP addresses by querying the user's ACL rules. This not only exposes critical network topology information but also provides attackers with clear targets for lateral movement, thus turning a single point of failure into a chain of risks.

[0067] In this application's technical solution, the organization and verification of information are fundamentally changed through the layered decoupling of "identity-resource" and "IP address-resource". First, the IP address whitelist is managed as an independent attribute of the Topic, decoupling it from user identity and thus avoiding the risk of network topology leakage through user credentials. Second, by placing an IP address verification logic at the network processing layer of the service node, message access requests are ensured to first pass through a resource-based, independent network access check.

[0068] Technical Effects: The technical solution of this application effectively blocks attack paths and isolates critical information. On the one hand, it protects network access policies from being exposed due to compromised user credentials, significantly increasing the difficulty for attackers to locate effective attack paths. On the other hand, it enforces a resource-centric security boundary. Even if an attacker possesses high-privilege credentials and controls a host, as long as the host's IP address is not in the target topic's IP address whitelist, access will be pre-blocked before reaching the application layer for authorization. This aligns with the "zero-trust" network security concept, providing a layer of network security protection independent of identity authentication for core data assets, making the system more robust.

[0069] (4) Overcome performance bottlenecks: Improve performance by shifting from traversal to search.

[0070] In related technologies, Kafka's default permission verification involves traversing the ACL rule list in memory, which has a time complexity of O(n log n). O In large-scale multi-tenant scenarios, when the number of rules is huge, this linear scan not only consumes considerable CPU resources, but more seriously, it can lead to unpredictable latency jitter, affecting the stability of the service and key performance indicators.

[0071] In this technical solution, the IP address whitelist is loaded and cached in memory, forming a highly efficient hash lookup structure on the local memory of the service node. When a request arrives at the service node, the front-end verification processor only needs to perform one hash lookup in the service node's memory to complete the IP address verification. Its average time complexity is O(log n). O (1).

[0072] Technical Effects: The technical solution of this application achieves constant-time performance. Even with a large number of rules, the IP verification time remains at an extremely low and predictable level, thus significantly improving the performance degradation and latency jitter issues caused by rule growth. Furthermore, through a front-end fast-fail mechanism, this technology can intercept illegal traffic at minimal cost before entering the time-consuming protocol parsing stage, further protecting resources in the service node and ensuring the high performance and high stability of the security module.

[0073] Figure 2 This is a flowchart illustrating an access control method for a message processing system according to an embodiment of this application. The method is applied to a service node of the message processing system, such as... Figure 2 As shown, it includes the following steps:

[0074] Step S201: Receive the message access request sent by the client.

[0075] Message access requests can include requests to read or write messages in the message processing system. The sender of a message access request can be an application, etc.

[0076] Step S202: Parse the message access request to obtain the sender identifier, source IP address, and target message subject to be accessed.

[0077] The sender's identifier may include, but is not limited to, the application's identifier, the client's identifier, or the user's login account.

[0078] Step S203: Determine whether the source IP address is in the IP address whitelist associated with the target message topic. If it is, proceed to step S204; otherwise, proceed to step S205.

[0079] The association relationships between multiple message topics and multiple IP address whitelists are pre-retrieved from the metadata storage component of the message processing system and cached in memory. The metadata storage component pre-configures associated IP address whitelists for each message topic. These association relationships are represented by hash tables, which contain key-value pairs where the key is the message topic and the value is a set of IP addresses. The system queries the keys in the multiple hash tables in memory for the target message topic. If the target message topic is found, the system then queries the associated values ​​for the source IP address.

[0080] Step S204: Determine whether the current sender has permission to execute the target operation corresponding to the message access request. If it has permission, proceed to step S206; otherwise, proceed to step S207.

[0081] Retrieve the operation permission list, which records the operation permissions of multiple senders for multiple message topics. The operation permissions include allowing the sender to perform the corresponding operation or denying the sender to perform the corresponding operation. Query the sender identifier and target message topic in the operation permission list to determine whether to allow the sender to perform the target operation.

[0082] Step S205: Request rejected, first error code returned.

[0083] If the source IP address is not in the IP address whitelist associated with the target message subject, the request is rejected and a first error code is sent to the client. The first error code can be NETWORK_EXCEPTION.

[0084] Step S206: For the target message topic, execute the target operation corresponding to the message access request.

[0085] If the sender has permission to perform the target operation, then it will perform a read or write operation on the messages under the target message topic.

[0086] Step S207: Request rejected, return second error code.

[0087] If the sender does not have permission to perform the target operation, it rejects the request and sends a second error code to the client, which can be AUTHORIZATION_FAILED.

[0088] In this embodiment, the message topic is associated with an IP address whitelist. The system queries the trustworthiness of the source IP address based on this association. If trusted, it then checks whether the sender has permission to perform an operation on the target message topic. If permission is granted, the corresponding operation is executed. This two-dimensional verification—using both IP address and operation permissions—ensures the security of accessing the message processing system. Furthermore, it eliminates the need to maintain complex ACLs, reducing management complexity. This makes it suitable for multi-tenant environments, minimizing performance degradation caused by an increase in ACL rules due to a rise in the number of IP addresses, and ensuring service stability.

[0089] This application provides an access control method for a message processing system. The message processing system includes multiple service nodes, and the method in this embodiment can be applied to any service node. A service node can be a server, platform, device, etc., with computing and processing capabilities. The server can be a server cluster or a single server.

[0090] like Figure 3 The flowchart shown is an access control method of a message processing system according to an embodiment of this application, including:

[0091] Step S301: In response to the message access request sent by the client, obtain the sender identifier, source IP address and target message subject to be accessed from the message access request.

[0092] Step S302: Query the source IP address in the IP address whitelist associated with the target message topic. If the source IP address is found, query whether the current sender has permission to execute the target operation based on the sender identifier. If so, execute the target operation, which is the operation corresponding to the message access request executed on the target message topic.

[0093] Message access requests can include, but are not limited to, requests to read or write messages in a message processing system. The sender of a message access request can be an application, etc.

[0094] The sender's identifier may include, but is not limited to, the application's identifier, the client's identifier, or the user's login account. The source IP address is the sender's IP address.

[0095] The target operations include, but are not limited to, writing and reading.

[0096] The access control method for a message processing system provided in this application responds to a message access request sent by a client. It obtains the sender identifier, source IP address, and target message topic from the message access request. It then queries the source IP address in the IP address whitelist associated with the target message topic. If the source IP address is found, it checks whether the sender has permission to execute the target operation based on the sender identifier. The target operation is the operation corresponding to the message access request performed on the target message topic. If so, the target operation is executed. In this embodiment, by associating the message topic with the IP address whitelist, the method queries whether the source IP address is trustworthy based on the association. If trustworthy, it then checks whether the sender has permission to execute an operation on the target message topic. If permission is granted, the corresponding operation is executed. This two-dimensional verification of IP address and operation permission ensures the security of accessing the message processing system. Furthermore, it eliminates the need to maintain complex ACLs, reducing management complexity. It is applicable to multi-tenant environments, minimizing performance degradation caused by an increase in rules within the ACL due to an increase in the number of IP addresses, and ensuring service stability.

[0097] The following describes the specific implementation process of each step above through various implementation methods:

[0098] In one possible implementation, before querying the source IP address in the IP address whitelist associated with the target message topic, the method further includes: obtaining the association relationship between multiple message topics and multiple IP address whitelists from the metadata storage component of the message processing system and caching it in memory, so as to determine the IP address whitelist associated with the target message topic based on the association relationship; the metadata storage component pre-configures the associated IP address whitelist for each of the multiple message topics.

[0099] The metadata storage component stores metadata, including configuration information for message topics. This configuration information includes a whitelist of IP addresses associated with each message topic. The IP address whitelist contains at least one trusted IP address, allowing access to messages under that message topic using an IP address from the whitelist.

[0100] In practical applications, the associations of multiple message topics and multiple IP address whitelists are obtained in advance from the metadata storage component and cached in memory. When processing message access requests, the source IP address can be queried from memory to see if it is in the IP address whitelist of the target message topic, thereby determining whether the source of the message access request is secure. Reading directly from memory can improve data processing speed.

[0101] In one possible implementation, the association includes a hash table containing key-value pairs, where the key is the message topic and the value is a set of IP addresses. The process of querying the source IP address within the whitelist of IP addresses associated with the target message topic involves: searching the target message topic among the keys of multiple hash tables in memory; and if the target message topic is found, then querying the source IP address among the values ​​associated with the target message topic.

[0102] The specific storage structure for the association relationship can be Map{Topic, Set[ip]}, where Set[ip] represents a set of IP addresses.

[0103] By creating a hash table to store the association between message topics and IP address whitelists, queries can be easily performed. A single hash query in the hash table can determine whether the source IP address is in the IP address whitelist, reducing query complexity and improving query speed.

[0104] In one possible implementation, the method further includes: monitoring configuration information changes for multiple message topics in the metadata storage component, the configuration information including the association between message topics and IP address whitelists; and updating the changed association between message topics and IP address whitelists into memory.

[0105] In practical applications, service nodes monitor changes to the configuration information of multiple topics in the metadata storage component through a listening mechanism. This configuration information includes the association between message topics and IP address whitelists. When the IP whitelist is updated, the service node asynchronously updates it to its local, high-efficiency memory cache (such as a ConcurrentHashMap). <String, Set <string>>, where Key is the Topic name and Value is the set of IPs, thus ensuring data synchronization between the associations in the metadata storage component and the associations cached in memory.

[0106] In this embodiment, data synchronization is achieved through a monitoring mechanism, which only incurs computational overhead when data changes, resulting in lower resource consumption and reduced network traffic and load.

[0107] In one possible implementation, before querying whether the current sender has permission to execute the target operation based on the sender identifier, the method further includes: obtaining an operation permission list, which records the operation permissions of multiple senders for multiple message topics; querying whether the current sender has permission to execute the target operation based on the sender identifier, including: querying the operation permission list for the sender identifier for the target message topic, and determining whether to allow the sender to execute the target operation based on the query result.

[0108] In practical applications, the sender identifier is first queried in the operation permission list. Operation permissions include allowing the sender to perform the corresponding operation or denying the sender to perform the corresponding operation. After finding the sender identifier, the system queries whether the sender is allowed to perform the target operation for the messages under the target message topic under that operator identifier.

[0109] In this embodiment, the system determines whether the requester has the necessary permissions by querying the list of operation permissions. This approach has low query complexity and fast data processing speed.

[0110] In one possible implementation, obtaining the operation permission list includes: configuring the operation permission list according to the operation permission list configuration instruction.

[0111] In practical applications, the operation permission list can be configured using the operation permission list configuration command. The operation permission list records the operation permissions of multiple senders for multiple message topics. Operation permissions include allowing the sender to perform a corresponding operation or denying the sender from performing a corresponding operation. A sender can be associated with one or more message topics, recording different operation permissions under each message topic. For example, for message topic A, application B can be allowed to read, but not to write.

[0112] In one possible implementation, obtaining the operation permission list includes: obtaining a pre-stored access control list (ACL) as the operation permission list.

[0113] In practical applications, native ACLs of the data processing system can also be pre-stored, and the ACL can be used to query whether the sender has the necessary permissions. This ACL does not need to include IP address information, as the IP address query has already been completed. Here, only the operation permissions need to be queried. Therefore, operation permission queries can be achieved using the native ACLs of the data processing system. Moreover, querying only operation permissions reduces the complexity of the query compared to related technologies that query both IP address and operation permissions via ACLs.

[0114] In one possible implementation, before querying the source IP address in the IP address whitelist associated with the target message topic, the method further includes: configuring a verification processor in the processor thread of the SocketServer module; querying the source IP address in the IP address whitelist associated with the target message topic includes: using the verification processor to query the source IP address in the IP address whitelist associated with the target message topic.

[0115] In this embodiment, a custom verification processor is configured in the Processor thread of the SocketServer module. The verification processor can perform lightweight IP address verification before the data processing system performs time-consuming protocol parsing, authentication, or permission verification. If the verification fails, the request is rejected to avoid invalid requests consuming backend resources.

[0116] This application provides a message processing system, which includes multiple service nodes: service node 1, service node 2, ..., service node n.

[0117] The service node is used to: respond to a message access request sent by a client, obtain the sender identifier, source IP address, and target message topic to be accessed from the message access request; query the source IP address in the IP address whitelist associated with the target message topic; if the source IP address is found, query whether the current sender has permission to execute the target operation based on the sender identifier. The target operation is the operation corresponding to the message access request to be executed on the target message topic. If so, the target operation is executed.

[0118] The message processing system provided in this application embodiment responds to a message access request sent by a client by obtaining the sender identifier, source IP address, and target message topic from the request. It then queries the source IP address in the IP address whitelist associated with the target message topic. If the source IP address is found, it checks whether the sender has permission to execute the target operation, which is the operation corresponding to the message access request performed on the target message topic. If so, the target operation is executed. In this embodiment, by associating the message topic with the IP address whitelist, the system checks whether the source IP address is trustworthy based on the association. If trustworthy, it then checks whether the sender has permission to execute an operation on the target message topic, and executes the corresponding operation if permission is granted. This two-dimensional verification of IP address and operation permission ensures the security of accessing the message processing system. Furthermore, it eliminates the need to maintain complex ACLs, reducing management complexity. It is suitable for multi-tenant environments, minimizing performance degradation caused by an increase in ACL rules due to an increase in the number of IP addresses, and ensuring service stability.

[0119] In one possible implementation, the service node is also used to: obtain the association relationship between multiple message topics and multiple IP address whitelists from the metadata storage component of the message processing system and cache it in memory before querying the source IP address in the IP address whitelist associated with the target message topic, so as to determine the IP address whitelist associated with the target message topic based on the association relationship; the metadata storage component pre-configures the associated IP address whitelist for each of the multiple message topics.

[0120] In one possible implementation, the association includes a hash table containing key-value pairs. The key in each key-value pair is the message topic, and the value is a set of IP addresses. When a service node queries the source IP address in the whitelist of IP addresses associated with the target message topic, it specifically: queries the keys of multiple hash tables in memory for the target message topic; if the target message topic is found, it then queries the values ​​associated with the target message topic for the source IP address.

[0121] In one possible implementation, the service node is also used to: monitor configuration information changes of multiple message topics in the metadata storage component, the configuration information including the association between message topics and IP address whitelists; and update the changed association between message topics and IP address whitelists into memory.

[0122] In one possible implementation, the service node is further configured to: obtain an operation permission list before querying whether the current sender has permission to execute the target operation based on the sender identifier, wherein the operation permission list records the operation permissions of multiple senders for multiple message topics; when the service node queries whether the current sender has permission to execute the target operation based on the sender identifier, it is specifically configured to: query the operation permission list for the sender identifier for the target message topic, and determine whether to allow the sender to execute the target operation based on the query result.

[0123] In one possible implementation, when the service node obtains the list of operation permissions, it specifically uses it for:

[0124] Configure the operation permission list according to the operation permission list configuration instructions.

[0125] In one possible implementation, when the service node obtains the list of operation permissions, it specifically uses it for:

[0126] Retrieve the pre-stored Access Control List (ACL) as the list of operation permissions.

[0127] In one possible implementation, the service node is further configured to: configure a verification processor in the processor thread of the SocketServer module before querying the source IP address in the IP address whitelist associated with the target message topic; when the service node queries the source IP address in the IP address whitelist associated with the target message topic, it is specifically configured to: use the verification processor to query the source IP address in the IP address whitelist associated with the target message topic.

[0128] Corresponding to the application scenarios and methods provided in the embodiments of this application, the embodiments of this application also provide an access control device for a message processing system, which is applied in the service node of the message processing system. For example... Figure 4 The diagram shown is a structural block diagram of an access control device for a message processing system according to an embodiment of this application. The device includes:

[0129] The acquisition module 401 is used to respond to a message access request sent by the client and obtain the sender identifier, source IP address and target message topic to be accessed from the message access request.

[0130] The query module 402 is used to query the source IP address in the IP address whitelist associated with the target message topic. If the source IP address is found, it queries whether the current sender has permission to execute the target operation based on the sender identifier. The target operation is the operation corresponding to the message access request executed on the target message topic. If so, the target operation is executed.

[0131] The access control device for the message processing system provided in this application embodiment responds to a message access request sent by a client by obtaining the sender identifier, source IP address, and target message topic to be accessed from the message access request. It then queries the source IP address in the IP address whitelist associated with the target message topic. If the source IP address is found, it checks whether the sender has permission to execute the target operation based on the sender identifier. The target operation is the operation corresponding to the message access request executed on the target message topic. If so, the target operation is executed. In this embodiment, by associating the message topic with the IP address whitelist, the source IP address is queried for trustworthiness based on the association. If trustworthy, the sender is then queried for permission to execute an operation on the target message topic. If permission is granted, the corresponding operation is executed. This two-dimensional verification of IP address and operation permission ensures the security of accessing the message processing system. Furthermore, it eliminates the need to maintain complex ACLs, reducing management complexity. It is suitable for multi-tenant environments, minimizing performance degradation caused by the increase in rules in the ACL due to the increase in the number of IP addresses, and ensuring service stability.

[0132] In one possible implementation, the device is further configured to: obtain the association between multiple message topics and multiple IP address whitelists from the metadata storage component of the message processing system and cache it in memory before querying the source IP address in the IP address whitelist associated with the target message topic, so as to determine the IP address whitelist associated with the target message topic based on the association relationship; the metadata storage component pre-configures the associated IP address whitelist for each of the multiple message topics.

[0133] In one possible implementation, the association includes a hash table containing key-value pairs, where the key is the message topic and the value is a set of IP addresses. When query module 402 queries the source IP address in the whitelist of IP addresses associated with the target message topic, it performs the following: queries the keys of multiple hash tables in memory for the target message topic; if the target message topic is found, it then queries the values ​​associated with the target message topic for the source IP address.

[0134] In one possible implementation, the device is also used to: monitor changes in configuration information of multiple message topics in the metadata storage component, the configuration information including the association between message topics and IP address whitelists; and update the changed association between message topics and IP address whitelists into memory.

[0135] In one possible implementation, the apparatus is further configured to: obtain an operation permission list before querying whether the current sender has permission to execute the target operation based on the sender identifier, the operation permission list recording the operation permissions of multiple senders for multiple message topics; when querying whether the current sender has permission to execute the target operation based on the sender identifier, the query module 402 is configured to:

[0136] Query the operation permission list to find the sender's operation permissions for the target message topic, and determine whether to allow the sender to execute the target operation based on the query results.

[0137] In one possible implementation, when obtaining the list of operation permissions, the device is used to:

[0138] Configure the operation permission list according to the operation permission list configuration instructions.

[0139] In one possible implementation, when obtaining the list of operation permissions, the device is used to:

[0140] Retrieve the pre-stored Access Control List (ACL) as the list of operation permissions.

[0141] In one possible implementation, the apparatus is further configured to: configure a verification processor in the processor thread of the SocketServer module before querying the source IP address in the IP address whitelist associated with the target message topic; when the query module 402 queries the source IP address in the IP address whitelist associated with the target message topic, it is configured to: use the verification processor to query the source IP address in the IP address whitelist associated with the target message topic.

[0142] The functions of each module in the embodiments of this application can be found in the corresponding descriptions in the above methods, and they have corresponding beneficial effects, which will not be repeated here.

[0143] Figure 5 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 5 As shown, the electronic device includes a memory 510 and a processor 520. The memory 510 stores a computer program that can run on the processor 520. When the processor 520 executes the computer program, it implements the method described in the above embodiments. The number of memories 510 and processors 520 can be one or more.

[0144] The electronic device also includes:

[0145] The communication interface 530 is used to communicate with external devices and exchange and transmit data.

[0146] If the memory 510, processor 520, and communication interface 530 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0147] Optionally, in a specific implementation, if the memory 510, processor 520, and communication interface 530 are integrated on a single chip, then the memory 510, processor 520, and communication interface 530 can communicate with each other through an internal interface.

[0148] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0149] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements the method provided in this application.

[0150] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0151] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0152] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0153] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0154] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0155] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0156] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0157] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0158] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0159] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0160] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0161] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / string> < / string>

Claims

1. An access control method of a message processing system, characterized by, The message processing system comprises a plurality of service nodes, and the method is applied to the service nodes, comprising: In response to a message access request sent by a client, obtaining a sender identifier, a source IP address and a target message topic to be accessed from the message access request; the sender identifier is an identity credential of an application of the client; Obtaining a pre-stored access control list (ACL) as an operation permission list; In the IP address white list associated with the target message topic, if the source IP address is queried, the current sender is queried in the operation permission list according to the sender identifier whether it has the permission to perform a target operation, the target operation is an operation corresponding to the message access request performed on the target message topic, if yes, the target operation is performed.

2. The method of claim 1, wherein, Before querying the source IP address in the IP address white list associated with the target message topic, the method further comprises: Obtaining an association relationship between a plurality of message topics and a plurality of IP address white lists from a metadata storage component of the message processing system and caching to a memory, so as to determine the IP address white list associated with the target message topic based on the association relationship; the metadata storage component pre-configures the associated IP address white list for the plurality of message topics respectively.

3. The method of claim 2, wherein, The association relationship comprises a hash table, the hash table comprises a key-value pair, the key in the key-value pair is the message topic, and the value in the key-value pair is an IP address set; Querying the source IP address in the IP address white list associated with the target message topic comprises: Querying the target message topic in the keys of the plurality of hash tables in the memory, and if the target message topic is queried, querying the source IP address in the value associated with the target message topic.

4. The method of claim 2, wherein, The method further comprises: Listening to configuration information change of the plurality of message topics in the metadata storage component, the configuration information comprising the association relationship between the message topic and the IP address white list; Updating the association relationship between the message topic and the IP address white list after the change to the memory.

5. The method according to any one of claims 1 to 4, characterized in that, Before querying whether the current sender has the permission to perform the target operation in the operation permission list according to the sender identifier, the method further comprises: Obtaining the operation permission list, the operation permission list recording operation permissions of a plurality of senders for a plurality of message topics; The operation permission list comprises: According to the operation permission list configuration instruction, configuring the operation permission list.

6. The method of claim 5, wherein, Before querying the source IP address in the IP address white list associated with the target message topic, the method further comprises: Configuring a verification processor in a processor thread of a socket service (SocketServer) module; 7. The method of claim 1, wherein, ​ ​ The querying the source IP address in the IP address white list associated with the target message topic comprises: The checking processor is configured to query the source IP address in the IP address white list associated with the target message topic.

8. A message processing system characterized by The message processing system comprises a plurality of service nodes; The service node is configured to: in response to a message access request sent by a client, acquire a sender identifier, a source IP address and a target message topic to be accessed from the message access request, the sender identifier being an identity credential of an application of the client; acquire a pre-stored access control list (ACL) as an operation permission list; query the source IP address in an IP address white list associated with the target message topic, and if the source IP address is queried, query whether the current sender has a permission to perform a target operation in the operation permission list according to the sender identifier, the target operation being an operation corresponding to the message access request performed on the target message topic, and if yes, perform the target operation.

9. An electronic device, comprising: The electronic device comprises a memory, a processor and a computer program stored in the memory, and the processor implements the method in any one of claims 1-7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method in any one of claims 1-7.

Images