Disclosure of Invention
Aiming at the problems existing in the prior art, the invention provides a mobile terminal safety monitoring method and system based on a micro-application architecture.
The invention is realized in such a way that the mobile terminal safety monitoring method based on the micro-application architecture comprises the following steps:
step one, identity verification, verifying the identity of an application program main body which is tried to be accessed;
step two, access authorization, verifying whether the access main body is allowed to finish the request operation on the appointed data;
thirdly, auditing, and tracking all operations executed by a user in the application;
and step four, secure communication, encrypting all communication entering and exiting the service, and completing the use identity authentication of the inter-process communication.
Further, the authentication, using the API gateway, processes the visitor in a manner that authenticates the visitor before forwarding the request to the service, tightly controls only authorized visitors and can enter the internal environment after passing the authentication:
(1) Event sequence for client: the client sends a request containing the credentials to the API gateway, the API gateway performs identity verification on the credentials, creates a security token and transmits the security token to the service;
(2) Event sequence based on logged-on client: the client sends out a login request containing the credentials, the API gateway returns a security token, the client contains the security token in the request of the calling operation, and the API gateway verifies the security token and forwards the security token to the service.
Further, the authorization verification is implemented by an API gateway based on OAuth2.0, and includes the following steps:
(1) The client side sends out a request and provides the credentials thereof by using basic identity verification;
(2) The API gateway sends an OAuth2.0 password grant request to an OAuth2.0 authentication server;
(3) The authentication server verifies the credentials of the API client and returns an access token and a refresh token;
(4) The API gateway includes an access token in its request for service. The service verifies the access token and uses it to authorize the request.
Further, the authorization verifies that the OAuth2.0 access token is used as a session token to authenticate the session oriented client, when the access token expires, it can obtain a new access token using a refresh token, the API client initiates the session by sending its credentials (POST) to the API gateway's/login endpoint, the API gateway returns the access token and the refresh token to the client, and the API client then provides both tokens when it issues a request to the API gateway:
(1) Transmitting the credentials of the login-based client to the API gateway;
(2) The LoginHandler of the API gateway sends a password grant request to an OAuth2.0 authentication server;
(3) The authentication server verifies the credentials of the client and returns an access token and a refresh token;
(4) The API gateway returns the access token and the refresh token to the client, usually in the form of a cookie;
(5) The client side comprises an access token and a refreshing token in a request sent to the API gateway;
(6) The Session Authentication Interceptor of the API gateway validates the access token and includes it in the request for service.
Further, the audit tracks all operations performed by the user in the application to detect security issues, helps the customer to achieve and enforce compliance, and uses a user behavior audit solution (UBA) to achieve user behavior tracking management.
Further, the secure communication, ideally, encrypts all the communication of the in-out service by adopting Transport Layer Security (TLS), and uses the IPC flow method to complete the use authentication of the inter-process communication.
Another object of the present invention is to provide a mobile terminal security monitoring system based on a micro-application architecture, the mobile terminal security monitoring system based on the micro-application architecture includes:
the identity verification module is used for verifying the identity of the application program main body which is tried to be accessed;
the access authorization module is used for verifying whether the access main body is allowed to finish the requested operation on the appointed data;
the auditing module is used for tracking all operations executed by a user in the application;
and the safety communication module is used for encrypting all communication of the access service and completing the use identity authentication of the inter-process communication.
It is a further object of the present invention to provide a computer device comprising a memory and a processor, the memory storing a computer program which, when executed by the processor, causes the processor to perform the steps of the mobile terminal security monitoring method based on a micro-application architecture.
Another object of the present invention is to provide a computer readable storage medium storing a computer program, which when executed by a processor, causes the processor to perform the steps of the mobile terminal security monitoring method based on a micro application architecture.
Another object of the present invention is to provide an information data processing terminal, where the information data processing terminal is used to implement the mobile terminal security monitoring system based on the micro-application architecture.
In combination with the technical scheme and the technical problems to be solved, the technical scheme to be protected has the following advantages and positive effects:
first, to the technical problems existing in the prior art, some technical effects brought by solving the problems have creative effects. The specific description is as follows:
(1) Based on the decoupling full-modularized architecture characteristic of the micro-application architecture, the invention provides the micro-application mobile terminal safety monitoring method and system for carrying out identity verification through an API gateway, carrying out access authorization through OAuth2.0, carrying out operation audit through a UBA scheme and carrying out safety process through an IPC method, and carrying out unified protection and management on functions, data, identities and authorities through the advantages of the micro-application architecture, thereby effectively solving the safety risk faced by mobile services under the micro-application architecture.
Second, a significant technical improvement of example 1:
1. the safety is improved: through identity verification and secondary verification, the certainty of the identity of the user is obviously enhanced, and the risks of fraud and illegal access are reduced. Meanwhile, protocols such as SSL/TLS are used for encrypting communication, so that safe transmission of data is ensured, and the property of data leakage is reduced.
2. And improving the data management capability: through access authorization and audit, accurate control and tracking of data access and operation of a user are realized, and misoperation and abuse of the data are effectively prevented.
Significant technical advances of example 2:
1. the enterprise data security is improved: through staff identity verification and secondary verification, safety is enhanced, and risks of illegal access to enterprise internal data are reduced. Meanwhile, the communication is encrypted by using VPN, SSL/TLS and other technologies, so that the safe transmission of data is ensured.
2. Strengthening enterprise internal authority management and audit: through access authorization and audit, enterprises can accurately control and track the data access and operation of staff, prevent misoperation and abuse of data, and effectively monitor the working behaviors of the staff.
Both embodiments represent significant technical advances in enhancing security, improving data management capability, etc. of a mobile terminal security monitoring method based on a micro-application architecture.
Detailed Description
The present invention will be described in further detail with reference to the following examples in order to make the objects, technical solutions and advantages of the present invention more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
The mobile terminal safety monitoring method based on the micro-application architecture can be used in many scenes. The following are two specific application embodiments and specific implementation schemes:
example 1: mobile banking application
1. And (3) identity authentication: the user opens the mobile banking application, inputs a user name and a password, and logs in. For some more sensitive operations (such as transfer or payment), additional secondary verification is required, such as entering a transaction password or biometric identification.
2. Access authorization: after a user logs in, the system determines services and data that they can access and operate based on their account type (e.g., normal user, VIP user or administrator) and the set permissions.
3. Auditing: the system records each operation of the user, including inquiring balance, transferring accounts, paying accounts, etc., and stores this information in a database for subsequent auditing and analysis.
4. Secure communication: the system encrypts all communications to and from the service using SSL/TLS or other protocols. During inter-process communication, identity verification is also performed, ensuring that only authorized processes can access data.
Example 2: mobile office application within an enterprise
1. And (3) identity authentication: employees log into the mobile office application using their enterprise account numbers and passwords. For some sensitive operations, a secondary verification is required, for example by receiving a verification code through a mailbox or a cell phone.
2. Access authorization: after logging in, the system determines the data and services that they can access and operate according to the employee's position and rights. For example, a common employee may not have access to sensitive data of human resources, whereas personnel of the human resources department may.
3. Auditing: the system records each operation of the employee, including viewing, modifying, adding or deleting data, and stores this information in a database for subsequent auditing and analysis.
4. Secure communication: the system encrypts all communications to and from the service using VPN, SSL/TLS, etc. techniques. During inter-process communication, identity verification is also performed, ensuring that only authorized processes can access data. As shown in fig. 1, the mobile terminal security monitoring method based on the micro-application architecture provided by the embodiment of the invention includes the following steps:
s101, verifying the identity of an application program main body;
s102, access authorization, verifying whether an access subject is allowed to finish the request operation on specified data;
s103, auditing, and tracking all operations executed by a user in the application;
s104, secure communication encrypts all communication entering and exiting the service and completes the use identity verification of the inter-process communication.
The micro-service architecture is a distributed architecture. Each external request is processed by the API gateway and at least one service. To achieve security in a micro-service architecture, it is necessary to determine who is responsible for verifying the user identity and who is responsible for access authorization. In typical microservice-based applications, however, a user cannot communicate directly with a microservice. Authentication needs to be handled by the API gateway.
The authentication provided by the embodiment of the invention uses the API gateway to process the authentication of the visitor before forwarding the request to the service, thereby strictly controlling only authorized visitor and entering the internal environment after passing the authentication.
As shown in fig. 2, the client uses the API gateway for authentication. The API client includes credentials in each request. The login-based client sends the credentials of the user to the API gateway for authentication and receives the session token. Once the API gateway validates the request, it invokes one or more services.
In order to ensure the accuracy of the service requirement provision, the API gateway includes a token containing user information in each service request. The service verifies the request using the token and obtains information about the principal. The API gateway may also provide the same token for the session-oriented client to use as a session token.
The event sequence of the client is as follows:
(1) The client issues a request containing credentials to the API gateway.
(2) The API gateway authenticates the credential, creates a security token, and passes it to the service.
The event sequence based on the logged-in client is as follows:
(1) The client issues a login request containing credentials.
(2) The API gateway returns a security token.
(3) The client includes a security token in the request to invoke the operation.
(4) The API gateway validates the security token and forwards it to the service.
The API gateway also needs to perform access authorization verification after the authentication is completed. Although the access authorization verification can be performed at the same time of the identity verification, in line with the former reason, if the access authorization is opened in advance, the vulnerability risk of the rights directory exposure is also brought. Thus access authorization is achieved using the service. The service may implement role-based access authorization for URLs and service methods. It may also implement ACLs to manage access to the aggregate.
In implementing security in a micro-application architecture, it is necessary to determine what type of token should be used by an API gateway to pass user information to a service. There are two types of tokens available for selection.
(1) Opaque (no readable) tokens, which are typically a string of UUIDs. A drawback of opaque tokens is that they degrade performance and usability and increase latency. Because the recipient of such a token must initiate a synchronous RPC call to the security service to verify the token and retrieve the user information.
(2) Transparent tokens (containing information about the user), one popular standard for transparent tokens is JSON Web Token (JWT). JWT is a standard way to securely transfer information (e.g., user identity and role) between the accessing parties. The content of the JWT contains a JSON object in which there is information about the user, such as his identity and role, and other metadata, such as expiration date, etc. It uses digital signatures known only to the creator of the JWT, such as API gateway and the receiver (service) of the JWT. The signature ensures that a malicious third party cannot forge or tamper with the JWT.
It is therefore appropriate to communicate user identity and role using JWTs in contrast. One problem with JWT is that this token is self-contained, that is, it is not revocable, because it no longer needs to access the security service for authentication. Depending on the design, the service will perform the request operation after verifying the JWT's signature and expiration date. Thus, there is no viable way to revoke a certain JWT token that falls into a malicious third party's hand. The solution is to publish JWTs with short expiration times, which can limit malicious parties. However, one disadvantage of short-term JWTs is that the application must somehow constantly re-publish the JWTs to keep the session active.
OAuth2.0 security standard is an access authorization protocol originally intended to enable users of public cloud services to grant third party applications access to their information without having to reveal their passwords to the third party applications. Although different from the requirement and the application of the project, the method can quickly build the realized API gateway identity verification function based on the mature protocol, and can overcome the defect that the JWT continuously keeps the session. The key concepts in OAuth2.0 are as follows:
(1) The authorization server: an API is provided for verifying the identity of a user, obtaining an access token and refreshing the token. The framework of OAuth2.0 authorization server is built using Spring OAuth.
(2) Access token: a token granting access rights to the resource server. The format of the access token depends on the particular implementation technology. The access token in JWT format is adopted in the implementation of Spring OAuth.
(3) Refresh token: the client is used for obtaining a long-acting but simultaneously revocable token of a new AccessToken.
(4) Resource server: the access token is used to authorize the accessed service. In a micro-application architecture, the service is a resource server.
(5) Client side: a client that wants to access a resource server. In the micro-application architecture, the API gateway is an OAuth2.0 client.
The method comprises the following steps:
(1) The client issues a request to provide its credentials using basic authentication.
(2) The API gateway issues an OAuth2.0 password grant request to the OAuth2.0 authentication server.
(3) The authentication server verifies the credentials of the API client and returns an access token and a refresh token.
(4) The API gateway includes an access token in its request for service. The service verifies the access token and uses it to authorize the request.
As shown in fig. 3, OAuth 2.0-based API gateway may use OAuth2.0 access token as a session token to authenticate a session-oriented client. And when the access token expires, it may use the refresh token to obtain a new access token. The API client initiates the session by sending its credentials (send POST) to the API gateway/login endpoint. The API gateway returns an access token and a refresh token to the client. The API client then provides both tokens when it issues a request to the API gateway.
(1) The login-based client sends its credentials to the API gateway.
(2) The loginfandler of the API gateway issues a password grant request to the OAuth2.0 authentication server.
(3) The authentication server verifies the credentials of the client and returns an access token and a refresh token.
(4) The API gateway returns the access token and the refresh token to the client, typically in the form of a cookie.
(5) The client includes an access token and a refresh token in a request issued to the API gateway.
(6) The Session Authentication Interceptor of the API gateway validates the access token and includes it in the request for service.
If the access token has expired or is about to expire, the API gateway will obtain a new access token by issuing an OAuth2.0 refresh authorization request, which is sent to the authorization server, containing the refresh token. If the refresh token has not expired or been revoked, the authorization server will return a new access token. The API gateway passes the new access token to the service and returns it to the client.
The audit provided by the embodiment of the invention tracks all operations executed by a user in the application so as to detect security problems, helps the client to realize and enforce compliance, and realizes user behavior tracking management by using a user behavior audit solution (UBA).
The secure communication provided by the embodiment of the invention ideally adopts Transport Layer Security (TLS) to encrypt all communication of the incoming and outgoing services, and uses an IPC flow method to complete the use identity verification of the inter-process communication.
As shown in fig. 4, a mobile terminal security monitoring system based on a micro-application architecture according to an embodiment of the present invention includes:
the identity verification module is used for verifying the identity of the application program main body which is tried to be accessed;
the access authorization module is used for verifying whether the access main body is allowed to finish the requested operation on the appointed data;
the auditing module is used for tracking all operations executed by a user in the application;
and the safety communication module is used for encrypting all communication of the access service and completing the use identity authentication of the inter-process communication.
The specific method of implementing step two (access authorization) and step three (auditing) may depend on some existing techniques and protocols. The following are some implementations:
step two: access authorization
Implementing access authorization typically requires the following steps:
1. and (3) identity authentication: first, the system needs to verify the identity of the requesting principal (e.g., user or service). This may be accomplished by a user name and password, API key, or other means of identification.
2. Checking authority: the system needs to check whether the principal has access to the requested data or to perform the requested operation. This is typically accomplished by looking at the principal's role or rights. For example, one general user can only read own data, and an administrator can read data of all users.
3. Authorization decision: the system may allow this request if the principal has access to the data or performs an operation. Otherwise, the system may reject the request and return an error or prompt.
This process may be implemented by various access control models, such as role-based access control (RBAC), attribute-based access control (ABAC), etc.
Step three: auditing
Implementing an audit typically requires the following steps:
1. logging: the system needs to record all the operations performed by the user in the application. This may be accomplished by writing detailed information of the operation (e.g., time of operation, user of operation, type of operation, result of operation, etc.) to the log file.
2. And (3) log storage: the system needs to store these log files in a secure place to prevent them from being tampered with or deleted. This can typically be accomplished by saving the log file in a database, or using a log management service.
3. And (3) log analysis: the system needs to analyze these log files periodically to check for any abnormal or suspected non-compliant operation. This may be accomplished by using log analysis tools or by sending log data to a Security Information and Event Management (SIEM) system.
The above are some ways of implementing access authorization and auditing. The specific implementation will vary depending on the needs and environment of the application.
The mobile terminal safety monitoring method based on the micro-application architecture, provided by the application embodiment of the invention, is applied to computer equipment, wherein the computer equipment comprises a memory and a processor, the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the mobile terminal safety monitoring method based on the micro-application architecture.
The mobile terminal safety monitoring method based on the micro-application architecture provided by the application embodiment of the invention is applied to an information data processing terminal, and the information data processing terminal is used for realizing the mobile terminal safety monitoring system based on the micro-application architecture.
It should be noted that the embodiments of the present invention can be realized in hardware, software, or a combination of software and hardware. The hardware portion may be implemented using dedicated logic; the software portions may be stored in a memory and executed by a suitable instruction execution system, such as a microprocessor or special purpose design hardware. Those of ordinary skill in the art will appreciate that the apparatus and methods described above may be implemented using computer executable instructions and/or embodied in processor control code, such as provided on a carrier medium such as a magnetic disk, CD or DVD-ROM, a programmable memory such as read only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The device of the present invention and its modules may be implemented by hardware circuitry, such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., as well as software executed by various types of processors, or by a combination of the above hardware circuitry and software, such as firmware.
The invention provides a mobile terminal safety monitoring method based on a micro-application architecture, which adopts the detailed working principle that:
identity verification (S101): this step is to confirm the identity of the individual (being the user or other system) attempting to access the application principal. This is typically done by a user name and password, or other form of authentication (e.g., biometric features such as fingerprint or facial recognition). The purpose of this step is to ensure that only authorized individuals can access the application.
Access authorization (S102): after authentication, the system may perform access authorization. This step is to confirm whether the user has the right to perform their attempted operation on the specified data. For example, a user may have access to view data, but not necessarily to modify the data. Access authorization is typically determined based on the role or permission level of the user.
Audit (S103): the auditing step is to track and record all the operations performed by the user in the application. These operations include viewing, modifying, adding or deleting data, etc. This step is important for subsequent problem investigation, as well as monitoring and analysis of user behavior.
Secure communication (S104): in the secure communication step, all communications to and from the service are encrypted to protect the security and privacy of the data. In addition, interprocess communication also requires authentication to prevent unauthorized processes from accessing or modifying data.
Through the four steps, the method can effectively protect the safety of the application program of the mobile terminal and prevent data leakage, unauthorized access and other security threats.
The foregoing is merely illustrative of specific embodiments of the present invention, and the scope of the invention is not limited thereto, but any modifications, equivalents, improvements and alternatives falling within the spirit and principles of the present invention will be apparent to those skilled in the art within the scope of the present invention.