[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

CN117375913A - Method for realizing multi-tenant control based on cloud message service - Google Patents

Method for realizing multi-tenant control based on cloud message service Download PDF

Info

Publication number
CN117375913A
CN117375913A CN202311314674.4A CN202311314674A CN117375913A CN 117375913 A CN117375913 A CN 117375913A CN 202311314674 A CN202311314674 A CN 202311314674A CN 117375913 A CN117375913 A CN 117375913A
Authority
CN
China
Prior art keywords
message
tenant
access
tenants
topic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311314674.4A
Other languages
Chinese (zh)
Inventor
喻春阳
徐筠
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Simulation Center
Original Assignee
Beijing Simulation Center
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Simulation Center filed Critical Beijing Simulation Center
Priority to CN202311314674.4A priority Critical patent/CN117375913A/en
Publication of CN117375913A publication Critical patent/CN117375913A/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

The invention discloses a method for realizing multi-tenant control based on cloud message service, which comprises the following steps: step 1: ensuring that each tenant has a unique identifier, implementing an identity verification mechanism to ensure that only authorized tenants can access a message queue or topic, verifying identity credentials of each requested tenant before accessing the message queue or topic, and ensuring the legitimacy of the access; step 2: creating an independent message queue or topic for each tenant; step 3: the tenant performs message publishing and subscribing through a unique message queue or theme; step 4: implementing monitoring and logging mechanisms to ensure that tenants can monitor their own messaging activities and performance; step 5: security measures are enhanced to ensure confidentiality and integrity of message delivery. The method provides stronger security and isolation, and is suitable for multi-tenant environments requiring high isolation, such as sensitive data or application programs with higher compliance requirements.

Description

Method for realizing multi-tenant control based on cloud message service
Technical Field
The invention relates to the technical field of computers, in particular to a method for realizing multi-tenant control based on cloud message service.
Background
Cloud messaging service (Cloud Messaging Service) generally refers to a messaging service based on cloud computing technology that allows developers to send and receive messages through a cloud platform to enable messaging and collaboration in a distributed application or system. Cloud messaging services may generally be used for the management of multiple tenants. Multi-tenant is an architecture model that allows a single application or service to simultaneously serve multiple different tenants (clients or users) and to isolate between those tenants to ensure security and data privacy, and cloud messaging services can well support the needs of multi-tenant applications. However, in the prior art, tenant data may exist in the same message queue or topic, and messages of different tenants may be mixed together, so that isolation of tenant data cannot be ensured.
Disclosure of Invention
In order to solve the problems, the invention provides a method for realizing multi-tenant control based on cloud message service.
In order to achieve the above purpose, the technical scheme adopted by the invention is as follows:
a method for realizing multi-tenant control based on cloud message service comprises the following steps: the method comprises the following steps:
step 1: ensuring that each tenant has a unique identifier, implementing an identity verification mechanism to ensure that only authorized tenants can access a message queue or topic, verifying identity credentials of each requested tenant before accessing the message queue or topic, and ensuring the legitimacy of the access;
step 2: creating an independent message queue or topic for each tenant;
step 3: the tenant performs message publishing and subscribing through the unique message queue or topic thereof, so that only the tenant can publish or subscribe to the own message queue or topic thereof; the tenant publishes the message to its own message queue or topic using its unique credentials; the lessees can only subscribe to own message queues or topics, so that isolation of message data is ensured;
step 4: implementing monitoring and logging mechanisms to ensure that tenants can monitor their own messaging activities and performance;
step 5: security measures are enhanced to ensure confidentiality and integrity of message delivery.
Further: the step 1 comprises the following steps:
1. tenant identity and unique identifier:
setting a unique identifier for each tenant, wherein the identifier is provided by the tenant when registering or creating an account or is automatically generated by a system;
2. using a cloud authentication service:
oauth2.0 is used to ensure that only authorized tenants can access the message queue or topic; generating a unique API key for each tenant, the key being used for authentication, the tenant having to provide its API key to authenticate its identity upon request;
3. identity authentication verification:
before accessing a message queue or a theme, authentication verification is implemented to ensure that only legal tenants can access the message queue or the theme;
4. error handling:
if the identity verification fails, returning an error message or a status code of the identity verification failure;
5. access control list:
which tenants have access to specific resources is defined in the ACL to enhance access control.
Further: the step 2 comprises the following steps:
1. namespace isolation:
when using the namespaces for isolation, each tenant is allocated a unique namespace for storing the message queues or topics thereof;
2. dynamic creation:
when new tenants register, their message queues or topics are dynamically created by:
recording tenant identification when registering or creating account;
setting an automation script to trigger creation of tenant-specific message queues or topics upon tenant registration;
defining resource naming rules to ensure that each tenant's queue or topic name is unique;
3. access control list:
configuring an access control list in a cloud message service to ensure that only a particular tenant can access its own message queue or topic is achieved by:
in a management interface of the cloud message service, setting ACL rules for each message queue or topic;
when accessing a message queue or a theme, the cloud message service verifies the identity of the requested tenant and decides whether to allow access according to ACL rules;
ACL rules are periodically reviewed and updated to ensure that they remain consistent with the access rights of the tenant.
Further: the step 3 comprises the following steps:
1. and (3) message release:
when a tenant needs to publish a message, ensuring that the message can only be published to a message queue or a theme of the tenant, the method is realized by the following steps:
in the message issue request, the tenant needs to provide its unique tenant identity;
before publishing the message, the cloud message service should check the identity of the requesting tenant and ownership of the message queue or topic;
if the verification is passed, the cloud message service transmits the message to a message queue or a theme owned by the tenant;
2. message subscription:
the tenant can only subscribe to its own message queue or topic, ensuring isolation of message data, by:
in the message subscription request, the tenant needs to provide its unique tenant identity credential to verify its identity;
after the identity verification of the tenant passes, inquiring a cloud message service to obtain a message queue or a list of topics owned by the tenant;
the tenant can select resources to be subscribed from a message resource list owned by the tenant;
once the resources to subscribe to are selected, the cloud message service establishes subscriptions for the tenants so that they can receive messages from these resources;
the cloud message service transmits the message to resources subscribed by the tenants, so that only the tenants with corresponding subscription rights can receive the message;
3. error handling:
implementing an error handling mechanism to handle invalid publish or subscribe requests, if a tenant tries to publish to an unauthorized message resource or subscribe to a resource that does not belong to them, a corresponding error message or status code needs to be returned;
4. access control list:
ensuring that only authorized tenants can publish or subscribe to their own message resources.
Further: the step 4 comprises the following steps:
1. log isolation:
ensuring that log data of the tenant is isolated, only the tenant can access the log data, and the method is realized by the following steps:
independent log storage: creating an independent log storage area for each tenant, and ensuring that log data of each tenant is stored independently;
access control: using an access control list or other rights management mechanism, restricting that only the corresponding tenant can access its own log data;
data isolation: ensuring that log data is physically or logically isolated to prevent data leakage between tenants;
2. monitoring instrument panel:
providing independent monitoring dashboards for each tenant so that they can view performance metrics and log data of their message queues or topics, by:
personalized dashboard: creating a personalized monitoring dashboard for each tenant, displaying messaging activities, performance metrics, and log data associated therewith;
custom report: allowing the tenant to customize reports and alarms to meet its specific monitoring needs;
and (3) real-time monitoring: providing a real-time monitoring function so that tenants can check the state and performance of resources at any time;
3. data aggregation and analysis:
data aggregation and analysis is implemented in a background system to provide insight for tenants regarding their messaging activities, by:
log analysis tool: using log analysis tools or platforms to process and analyze large amounts of log data to detect problems, trends, and anomalies;
and (3) performance monitoring: monitoring performance of a message queue or topic, including message delivery speed, delay, and resource utilization metrics;
periodic reporting: generating periodic reports to provide summary information to tenants regarding their messaging activities and performance;
4. safety considerations:
ensuring that the monitoring and logging system itself is secure against unauthorized access or data leakage;
access control: restricting access to the monitoring and logging tool to only authorized users or system administrators;
encryption: using encryption techniques to protect the transmission and storage of the monitoring data;
audit log: access and operation of all monitoring and logging systems are recorded for auditing and security scrutiny.
Further: the step 5 comprises the following steps:
1. encryption:
end-to-end encryption is implemented to ensure that only legitimate tenants can decrypt and read the message, by:
encrypting message content: encrypting the content of the message to ensure that the message cannot be read by unauthorized persons during transmission, even if intercepted;
using TLS/SSL: using TLS or SSL to secure the message transmission channel; this ensures encryption of the message during transmission;
key management: the encryption key is effectively managed, so that only legal tenants can access the key required by decryption;
2. digital signature:
the integrity of the message is verified using a digital signature to ensure that the message has not been tampered with, by:
digital signature generation: when the message is released, digital signature generation is carried out on the message content; signatures are typically generated using the private key of the tenant;
signature verification: at the message receiving end, verifying the digital signature by using the corresponding public key, so as to ensure the integrity and source of the message;
key management: the key required by the digital signature is effectively managed, so that only legal tenants can verify the signature;
3. defensive measures:
in order to protect the message queues or topics from DDoS attacks and other security threats, the following defensive measures are implemented:
DDoS protection: using DDoS protection services or devices to mitigate and prevent distributed denial of service attacks;
network security: implementing network layer security policies to protect the messaging infrastructure;
access control: strictly controlling who can access the message queue or subject, using strong password policy, and implementing multi-factor authentication to protect the account;
auditing and monitoring: real-time auditing and monitoring is implemented to detect abnormal activity and take action in time.
Compared with the prior art, the invention has the following technical progress:
the method provides powerful data isolation by creating independent message queues or topics and access control mechanisms for each tenant. Even if messages of different tenants exist in the same message queue or topic, they cannot access or view each other's messages. The method allows the message resources of the tenant to be dynamically created according to the needs, so that the tenant has high flexibility and expandability. New tenants can quickly create their own message queues or topics upon registration without manual intervention. By using authentication services (such as OAuth2.0 or API keys) provided by the cloud platform, it is ensured that only authorized tenants can access their message resources, providing strong access control, preventing unauthorized access.
By creating separate monitoring dashboards and log storage areas for each tenant, isolation of the monitoring data and log data is ensured. The tenant can only access the monitoring data and logs of the tenant and cannot contact the information of other tenants. The method includes security measures such as end-to-end encryption, digital signature, defensive measures and the like to ensure confidentiality and integrity of message delivery and help to protect messages from unauthorized access and risk of tampering. The present approach helps meet compliance requirements, such as GDPR, HIPAA, etc., by implementing stringent access control, data isolation, and security measures. The tenant's data is effectively protected, helping to comply with regulations. By isolating the message resources of the tenants in different named spaces or dedicated queues/topics, resource isolation between different tenants is ensured, meaning that the activities of one tenant do not affect other tenants.
In summary, the present approach emphasizes data isolation, authentication, access control, monitoring, security, and compliance. Compared with some simpler multi-tenant implementations, the method provides stronger security and isolation, and is suitable for multi-tenant environments requiring high isolation, such as sensitive data or application programs with higher compliance requirements.
Drawings
The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate the invention and together with the embodiments of the invention, serve to explain the invention.
In the drawings:
FIG. 1 is a flow chart of the present invention.
Detailed Description
The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present invention will be described below with reference to the accompanying drawings.
As shown in fig. 1, the invention discloses a method for realizing multi-tenant control based on cloud message service, which comprises the following steps:
step 1: creating tenant identity and identity verification
First, each tenant is ensured to have a unique identifier (e.g., tenant ID), and an authentication mechanism is implemented to ensure that only authorized tenants can access the message queue or topic.
Each tenant is assigned a unique identity using a cloud authentication service, such as oauth2.0 or API key.
Before the message queue or theme is accessed, the identity credentials of each requested tenant are verified, and the legitimacy of the access is ensured.
Step 2: creating message queues or topics
Creating an independent message queue or topic for each tenant may be accomplished by:
namespace isolation: a Namespace (Namespace) is used to isolate tenants. Each tenant has its own namespace within which the message queue or topic name is unique.
Dynamic creation: when new tenants register, their message queues or topics are dynamically created. Ensuring that these queues or topics are isolated can only be accessed by the tenant itself.
Access Control List (ACL): ACLs are configured in the cloud message service to ensure that only a particular tenant can access its own message queues or topics.
Step 3: message publishing and subscribing
A tenant publishes and subscribes to messages through its unique message queue or topic. Ensuring that only the tenant itself can publish or subscribe to its own message queue or topic.
And (3) message release: the tenant publishes the message to its own message queue or topic using its unique credentials.
Message subscription: the tenant can only subscribe to its own message queue or topic, ensuring isolation of message data.
Step 4: monitoring and logging
Implementing monitoring and logging mechanisms to ensure that tenants can monitor their own messaging activities and performance can be achieved by:
log isolation: the logs of the tenants are isolated, so that only the tenants can access the log data of the tenants.
Monitoring instrument panel: a separate monitoring dashboard is provided for each tenant so that they can view the performance metrics of their message queues or topics.
Step 5: safety of
Security measures are enhanced to ensure confidentiality and integrity of message delivery. Consider the following measures:
encryption: the message is encrypted end-to-end to ensure that only legitimate tenants can decrypt and read the message.
Digital signature: digital signatures are used to verify the integrity of messages, ensuring that messages are not tampered with.
Defensive measures: defensive measures are implemented to protect message queues or topics from DDoS attacks and other security threats.
Through the steps, a multi-tenant cloud message service can be created, isolation of tenant data is ensured, and even though the tenant data exist in the same message queue or subject, the method combines identity verification, isolation, access control, monitoring and security to realize data isolation and message transmission in a multi-tenant environment.
Specifically, step 1 includes:
1. tenant identity and unique identifier:
each tenant needs to have a unique identifier, commonly referred to as a tenant ID or tenant key, which may be provided by the tenant at registration or creation of an account, or automatically generated by the system.
2. Using a cloud authentication service:
selection of an appropriate authentication mechanism for the cloud platform, for example:
oauth2.0: oauth2.0 may be used to assign a unique access token (AccessToken) to each tenant. Oauth2.0 may be used to ensure that only authorized tenants can access the message queue or topic.
API key: a unique API key is generated for each tenant, these keys being used for authentication. The tenant must provide its API key to verify its identity upon request.
3. Identity authentication verification:
before accessing the message queue or topic, authentication verification is performed to ensure that only legitimate tenants can access, which can be achieved by:
authentication token: if oauth2.0 is used, it is verified whether the tenant's access token is valid and not expired. Ensuring that each tenant can only use its own access token.
Validating API key: if an API key is used, it is verified whether the API key contained in the request matches in the tenant record.
4. Error handling:
if authentication fails, an appropriate error handling mechanism needs to be defined, such as an error message or status code that returns authentication failure.
5. Access Control List (ACL):
this step may be used in conjunction with step 3 to further limit tenant access to the message queue or topic. Which tenants have access to specific resources is defined in the ACL to enhance access control.
Taking these steps into consideration, it is ensured that only authenticated and authorized tenants can access their own message queues or topics, thereby enabling data isolation and authentication, which are based on the cloud platform authentication service, and ensuring data isolation and security in a multi-tenant environment.
Specifically, step 2 includes:
1. namespace isolation:
when using namespaces (namespaces) for isolation, each tenant will be assigned a unique Namespace for storing its message queues or topics, which can operate according to the specific implementation of the cloud provider, as exemplified below:
creating a namespace in a cloud message service: cloud providers typically provide functionality to create namespaces. One namespace may be created for each tenant to ensure that message queues or topic names are unique within different namespaces.
Creating tenant-specific queues or topics: within the namespace of each tenant, an independent message queue or topic is created for the tenant. Each tenant is ensured to have access to only the resources within its own namespace.
Configuring access rights: using an access control mechanism, the namespaces of each tenant are configured to ensure that only that tenant has the proper access rights.
2. Dynamic creation:
when new tenants register, their message queues or topics can be dynamically created, which can be achieved by:
tenant registration: when a tenant registers or creates an account, its tenant identification (e.g., tenant ID) is recorded.
Automation scripts or services: an automation script or service is provided to trigger creation of tenant-specific message queues or topics upon tenant registration, which may call an API of the cloud message service to create resources.
Resource naming rules: a resource naming convention is defined to ensure that each tenant's queue or topic name is unique, e.g., using the tenant ID as part of the resource name.
3. Access Control List (ACL):
configuring an Access Control List (ACL) in a cloud message service to ensure that only a particular tenant can access its own message queue or topic may be accomplished by:
ACL setting: in the management interface of the cloud message service, ACL rules are set for each message queue or topic, which rules specify which tenants have access to the resources.
Tenant identity verification: upon accessing the message queue or topic, the cloud message service verifies the identity of the requesting tenant and decides whether to allow access according to ACL rules.
Periodic inspection: ACL rules are periodically reviewed and updated to ensure that they remain consistent with the access rights of the tenant.
Considering these implementation steps in combination, an independent message queue or topic may be created for each tenant to ensure data isolation, which may be fine-tuned according to the cloud messaging service used and the specific functionality of the platform, but provides a general guidance scheme to achieve data isolation in a multi-tenant environment.
Specifically, step 3 includes:
1. and (3) message release:
when tenants need to publish messages, ensuring that they can only publish messages to their own message queues or topics can be achieved by:
tenant identity verification: in a message publishing request, the tenant needs to provide its unique tenant identity, such as oauth2.0 token or API key, to verify its identity.
Checking authority: before publishing the message, the cloud message service should check the identity of the requesting tenant and ownership of the message queue/topic. Ensuring that only the tenant itself has rights to publish to a particular message resource.
Message delivery: if the verification is passed, the cloud message service passes the message to a message queue or topic owned by the tenant. The message data should be stored and transferred securely.
2. Message subscription:
the tenant can only subscribe to its own message queue or topic, ensuring isolation of message data. The following specific implementation method comprises the following steps:
tenant identity verification: in a message subscription request, a tenant needs to provide its unique tenant identity to verify its identity.
Acquiring available message resources: after the identity verification of the tenant passes, inquiring the cloud message service to obtain a message queue or a list of topics owned by the tenant.
Selecting message resources to subscribe to: the tenant may select a resource to subscribe to from a list of message resources that they own.
Subscription message resources: once the resources to subscribe to are selected, the cloud message service establishes subscriptions for the tenants so that they can receive messages from these resources.
Message delivery: the cloud message service delivers the message to resources subscribed by the tenants, so that only the tenants with corresponding subscription rights can receive the message.
3. Error handling:
an appropriate error handling mechanism is implemented to handle invalid publish or subscribe requests. If a tenant attempts to publish to an unauthorized message resource or subscribe to a resource that does not belong to them, a corresponding error message or status code needs to be returned.
4. Access Control List (ACL):
in combination with the above steps, it is ensured that only authorized tenants can publish or subscribe to their own message resources. ACL rules should limit the rights of message publication and subscription.
Through the implementation steps, the fact that the tenant can only publish or subscribe to the own message queue or subject can be ensured, so that data isolation is realized, and the steps are combined with identity verification, access control and error processing to ensure the safety and isolation of message transmission in a multi-tenant environment. The actual implementation may vary depending on the cloud provider and the specific application requirements, but this framework provides a general guidance scheme.
Specifically, step 4 includes:
1. log isolation:
ensuring that the log data of the tenant is isolated, only the tenant itself can access its log data. The following are some implementation methods:
independent log storage: creating an independent log storage area for each tenant ensures that log data of each tenant is stored separately.
Access control: using Access Control Lists (ACLs) or other rights management mechanisms, only the corresponding tenants are restricted from accessing their own log data.
Data isolation: ensure that log data is physically or logically isolated to prevent data leakage between tenants.
2. Monitoring instrument panel:
a separate monitoring dashboard is provided for each tenant so that they can view the performance metrics and log data of their message queues or topics. The following are some implementation methods:
personalized dashboard: a personalized monitoring dashboard is created for each tenant, displaying messaging activities, performance metrics, and log data associated therewith.
Custom report: allowing tenants to customize reports and alarms to meet their specific monitoring needs.
And (3) real-time monitoring: the real-time monitoring function is provided, so that the tenant can check the state and performance of the resources at any time.
3. Data aggregation and analysis:
data aggregation and analysis is implemented in a background system to provide insight for tenants regarding their messaging activities. The following implementation method is as follows:
log analysis tool: a log analysis tool or platform is used to process and analyze large amounts of log data to detect problems, trends, and anomalies.
And (3) performance monitoring: the performance of a message queue or topic is monitored, including metrics such as message delivery speed, delay, and resource utilization.
Periodic reporting: periodic reports are generated to provide summary information to the tenant regarding its messaging activities and performance.
4. Safety considerations:
the monitoring and logging system itself is secured against unauthorized access or data leakage.
Access control: only authorized users or system administrators are restricted from accessing the monitoring and logging tool.
Encryption: encryption techniques are used to protect the transmission and storage of the monitoring data.
Audit log: access and operation of all monitoring and logging systems are recorded for auditing and security scrutiny.
By the implementation method, the tenant can monitor own message transmission activity and performance and keep data isolation and security, and the steps combine log isolation, monitoring dashboards, data aggregation and security considerations to provide a comprehensive solution for monitoring and logging in a multi-tenant environment.
Specifically, step 5 includes:
1. encryption:
end-to-end encryption is implemented to ensure that only legitimate tenants can decrypt and read the message. The following are some implementation methods:
encrypting message content: the content of the message is encrypted to ensure that it cannot be read by unauthorized persons during transmission, even if intercepted.
Using TLS/SSL: the use of TLS (transport layer security) or SSL (secure sockets layer) to protect the security of the message transmission channel ensures encryption of the message during transmission.
Key management: the encryption key is effectively managed, and only legal tenants can access the key required for decryption.
2. Digital signature:
the digital signature is used to verify the integrity of the message to ensure that the message has not been tampered with. The following are some implementation methods:
digital signature generation: and at the time of message release, digital signature generation is carried out on the message content. Signatures are typically generated using the private key of the tenant.
Signature verification: at the message receiving end, the digital signature is verified by using the corresponding public key, so that the integrity and the source of the message are ensured.
Key management: the key required by the digital signature is effectively managed, so that only legal tenants can verify the signature.
3. Defensive measures:
in order to protect the message queues or topics from DDoS attacks and other security threats, the following defensive measures are implemented:
DDoS protection: DDoS protection services or devices are used to mitigate and prevent distributed denial of service attacks.
Network security: network layer security policies such as firewalls, intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS) are implemented to protect the messaging infrastructure.
Access control: tightly controlling who can access the message queue or topic, using strong cryptographic policies, and implementing multi-factor authentication (MFA) to secure accounts.
Auditing and monitoring: real-time auditing and monitoring is implemented to detect abnormal activity and take action in time.
These security measures may ensure the security of the message delivery against unauthorized access and data tampering. The actual implementation may vary depending on cloud provider and specific application requirements, but this provides a generic framework to secure messaging in a multi-tenant environment.
Finally, it should be noted that: the foregoing description is only a preferred embodiment of the present invention, and the present invention is not limited thereto, but may be modified or substituted for some of the technical features described in the foregoing embodiments by those skilled in the art, even though the present invention has been described in detail with reference to the foregoing embodiments. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the scope of the claims of the present invention.

Claims (6)

1. A method for implementing multi-tenant control based on cloud message service, comprising the following steps:
step 1: ensuring that each tenant has a unique identifier, implementing an identity verification mechanism to ensure that only authorized tenants can access a message queue or topic, verifying identity credentials of each requested tenant before accessing the message queue or topic, and ensuring the legitimacy of the access;
step 2: creating an independent message queue or topic for each tenant;
step 3: the tenant performs message publishing and subscribing through the unique message queue or topic thereof, so that only the tenant can publish or subscribe to the own message queue or topic thereof; the tenant publishes the message to its own message queue or topic using its unique credentials; the lessees can only subscribe to own message queues or topics, so that isolation of message data is ensured;
step 4: implementing monitoring and logging mechanisms to ensure that tenants can monitor their own messaging activities and performance;
step 5: security measures are enhanced to ensure confidentiality and integrity of message delivery.
2. The method for implementing multi-tenant control based on the cloud message service according to claim 1, wherein the step 1 includes:
1. tenant identity and unique identifier:
setting a unique identifier for each tenant, wherein the identifier is provided by the tenant when registering or creating an account or is automatically generated by a system;
2. using a cloud authentication service:
oauth2.0 is used to ensure that only authorized tenants can access the message queue or topic; generating a unique API key for each tenant, the key being used for authentication, the tenant having to provide its API key to authenticate its identity upon request;
3. identity authentication verification:
before accessing a message queue or a theme, authentication verification is implemented to ensure that only legal tenants can access the message queue or the theme;
4. error handling:
if the identity verification fails, returning an error message or a status code of the identity verification failure;
5. access control list:
which tenants have access to specific resources is defined in the ACL to enhance access control.
3. The method for implementing multi-tenant control based on the cloud message service according to claim 2, wherein the step 2 includes:
1. namespace isolation:
when using the namespaces for isolation, each tenant is allocated a unique namespace for storing the message queues or topics thereof;
2. dynamic creation:
when new tenants register, their message queues or topics are dynamically created by:
recording tenant identification when registering or creating account;
setting an automation script to trigger creation of tenant-specific message queues or topics upon tenant registration;
defining resource naming rules to ensure that each tenant's queue or topic name is unique;
3. access control list:
configuring an access control list in a cloud message service to ensure that only a particular tenant can access its own message queue or topic is achieved by:
in a management interface of the cloud message service, setting ACL rules for each message queue or topic;
when accessing a message queue or a theme, the cloud message service verifies the identity of the requested tenant and decides whether to allow access according to ACL rules;
ACL rules are periodically reviewed and updated to ensure that they remain consistent with the access rights of the tenant.
4. The method for implementing multi-tenant control based on the cloud message service according to claim 3, wherein the step 3 includes:
1. and (3) message release:
when a tenant needs to publish a message, ensuring that the message can only be published to a message queue or a theme of the tenant, the method is realized by the following steps:
in the message issue request, the tenant needs to provide its unique tenant identity;
before publishing the message, the cloud message service should check the identity of the requesting tenant and ownership of the message queue or topic;
if the verification is passed, the cloud message service transmits the message to a message queue or a theme owned by the tenant;
2. message subscription:
the tenant can only subscribe to its own message queue or topic, ensuring isolation of message data, by:
in the message subscription request, the tenant needs to provide its unique tenant identity credential to verify its identity;
after the identity verification of the tenant passes, inquiring a cloud message service to obtain a message queue or a list of topics owned by the tenant;
the tenant can select resources to be subscribed from a message resource list owned by the tenant;
once the resources to subscribe to are selected, the cloud message service establishes subscriptions for the tenants so that they can receive messages from these resources;
the cloud message service transmits the message to resources subscribed by the tenants, so that only the tenants with corresponding subscription rights can receive the message;
3. error handling:
implementing an error handling mechanism to handle invalid publish or subscribe requests, if a tenant tries to publish to an unauthorized message resource or subscribe to a resource that does not belong to them, a corresponding error message or status code needs to be returned;
4. access control list:
ensuring that only authorized tenants can publish or subscribe to their own message resources.
5. The method for implementing multi-tenant control based on the cloud message service of claim 4, wherein the step 4 includes:
1. log isolation:
ensuring that log data of the tenant is isolated, only the tenant can access the log data, and the method is realized by the following steps:
independent log storage: creating an independent log storage area for each tenant, and ensuring that log data of each tenant is stored independently;
access control: using an access control list or other rights management mechanism, restricting that only the corresponding tenant can access its own log data;
data isolation: ensuring that log data is physically or logically isolated to prevent data leakage between tenants;
2. monitoring instrument panel:
providing independent monitoring dashboards for each tenant so that they can view performance metrics and log data of their message queues or topics, by:
personalized dashboard: creating a personalized monitoring dashboard for each tenant, displaying messaging activities, performance metrics, and log data associated therewith;
custom report: allowing the tenant to customize reports and alarms to meet its specific monitoring needs;
and (3) real-time monitoring: providing a real-time monitoring function so that tenants can check the state and performance of resources at any time;
3. data aggregation and analysis:
data aggregation and analysis is implemented in a background system to provide insight for tenants regarding their messaging activities, by:
log analysis tool: using log analysis tools or platforms to process and analyze large amounts of log data to detect problems, trends, and anomalies;
and (3) performance monitoring: monitoring performance of a message queue or topic, including message delivery speed, delay, and resource utilization metrics;
periodic reporting: generating periodic reports to provide summary information to tenants regarding their messaging activities and performance;
4. safety considerations:
ensuring that the monitoring and logging system itself is secure against unauthorized access or data leakage;
access control: restricting access to the monitoring and logging tool to only authorized users or system administrators;
encryption: using encryption techniques to protect the transmission and storage of the monitoring data;
audit log: access and operation of all monitoring and logging systems are recorded for auditing and security scrutiny.
6. The method for implementing multi-tenant control based on the cloud message service of claim 5, wherein the step 5 includes:
1. encryption:
end-to-end encryption is implemented to ensure that only legitimate tenants can decrypt and read the message, by:
encrypting message content: encrypting the content of the message to ensure that the message cannot be read by unauthorized persons during transmission, even if intercepted;
using TLS/SSL: using TLS or SSL to secure the message transmission channel; this ensures encryption of the message during transmission;
key management: the encryption key is effectively managed, so that only legal tenants can access the key required by decryption;
2. digital signature:
the integrity of the message is verified using a digital signature to ensure that the message has not been tampered with, by:
digital signature generation: when the message is released, digital signature generation is carried out on the message content; signatures are typically generated using the private key of the tenant;
signature verification: at the message receiving end, verifying the digital signature by using the corresponding public key, so as to ensure the integrity and source of the message;
key management: the key required by the digital signature is effectively managed, so that only legal tenants can verify the signature;
3. defensive measures:
in order to protect the message queues or topics from DDoS attacks and other security threats, the following defensive measures are implemented:
DDoS protection: using DDoS protection services or devices to mitigate and prevent distributed denial of service attacks;
network security: implementing network layer security policies to protect the messaging infrastructure;
access control: strictly controlling who can access the message queue or subject, using strong password policy, and implementing multi-factor authentication to protect the account;
auditing and monitoring: real-time auditing and monitoring is implemented to detect abnormal activity and take action in time.
CN202311314674.4A 2023-10-11 2023-10-11 Method for realizing multi-tenant control based on cloud message service Pending CN117375913A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311314674.4A CN117375913A (en) 2023-10-11 2023-10-11 Method for realizing multi-tenant control based on cloud message service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311314674.4A CN117375913A (en) 2023-10-11 2023-10-11 Method for realizing multi-tenant control based on cloud message service

Publications (1)

Publication Number Publication Date
CN117375913A true CN117375913A (en) 2024-01-09

Family

ID=89395754

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311314674.4A Pending CN117375913A (en) 2023-10-11 2023-10-11 Method for realizing multi-tenant control based on cloud message service

Country Status (1)

Country Link
CN (1) CN117375913A (en)

Similar Documents

Publication Publication Date Title
Yu et al. A survey on security issues in services communication of Microservices‐enabled fog applications
Modi et al. A survey on security issues and solutions at different layers of Cloud computing
US8955042B2 (en) Systems and methods for implementing transparent encryption
US8909930B2 (en) External reference monitor
KR101762876B1 (en) Security System for Cloud Computing Service
US9900157B2 (en) Object signing within a cloud-based architecture
Kumar et al. A survey on secure cloud: security and privacy in cloud computing
US9043589B2 (en) System and method for safeguarding and processing confidential information
US20030051172A1 (en) Method and system for protecting digital objects distributed over a network
KR20030036787A (en) System for establishing an audit trail to protect objects distributed over a network
JP2013516685A (en) System and method for enforcing computer policy
US20140351924A1 (en) Method and system for providing limited secure access to sensitive data
Ahuja et al. A survey of the state of cloud security
US20240039709A1 (en) Method and apparatus for sharing encrypted data, and device and readable medium
CN110708156B (en) Communication method, client and server
CN109936555A (en) A kind of date storage method based on cloud platform, apparatus and system
Marshall et al. Security best practices for developing windows azure applications
CN111614686A (en) Key management method, controller and system
Junghanns et al. Engineering of secure multi-cloud storage
CN113239349B (en) Network security testing method for power monitoring system
Tutubala et al. A hybrid framework to improve data security in cloud computing
CN113647051A (en) System and method for secure electronic data transfer
CN108347411B (en) Unified security guarantee method, firewall system, equipment and storage medium
CN117375913A (en) Method for realizing multi-tenant control based on cloud message service
Siddiqui et al. Secure E-business transactions by securing web services

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination