Power cloud data security access method and system

Abstract

The invention belongs to the technical field of network communication security, and discloses a power cloud data security access method and system, and the method comprises the steps: a client builds and transmits an access request packet containing a protocol version number, a checksum, basic information and a digital certificate; after receiving the request packet, the server performs check and verification and protocol verification; a security access chain is generated by extracting a request packet main body, and time window verification, data access permission verification and access frequency verification are carried out; after the verification is passed, carrying out digital certificate authentication, and carrying out supplementary authentication if necessary; and after the authentication is successful, the server generates a dynamic encryption key to encrypt the data and sends the encrypted data to the client, and the client generates a corresponding decryption key for decryption. Through a standardized request format, dynamic key generation and a multiple verification mechanism, the security and reliability of data access are ensured, unauthorized access and unauthorized operation are effectively prevented, and reliable guarantee is provided for security access of power cloud data.

Description

Technical Field

[0001] The present invention relates to the field of network communication security technology, and more specifically, to a method and system for secure access to power cloud data. Background Art

[0002] With the in-depth advancement of the information construction of the power system, the power cloud platform has become an important infrastructure for power data storage, processing and sharing. In the power cloud environment, how to ensure the security and controllability of data access has become a key issue to ensure the stable operation of the power system.

[0003] However, the existing power cloud data access solutions have many deficiencies in terms of security. First, the traditional access control mechanism often adopts a static username and password authentication method, which is difficult to deal with security threats such as identity forgery and replay attacks. Secondly, data access rights management lacks refined control and cannot implement differentiated security strategies based on data sensitivity and user roles. In addition, during the data transmission process, due to the lack of effective encryption mechanism and integrity verification, data leakage or tampering is easy to occur.

[0004] When processing data access requests, current power cloud platforms usually use a simple authentication and authorization mechanism, which fails to fully consider security factors such as access timeliness, frequency control, and dynamic authentication. This approach not only increases data security risks, but also fails to meet the power industry's strict requirements for data access security, and may pose a potential threat to the safe and stable operation of the power system. Summary of the invention

[0005] In order to overcome the problem of data security risks in the prior art, the present invention proposes a power cloud data security access method and system to solve the above problems.

[0006] The present invention provides the following technical solutions: A method for secure access to electric power cloud data, comprising: S1. The client constructs and sends an access request packet for power cloud data, wherein the access request packet includes a request packet header and a request packet body; S2. The server receives the access request packet and verifies the access request packet according to the header of the request packet; S3. Obtain the request verification result, extract the request package body for the access request package that passes the request verification, and generate a security access chain based on the extracted request package body; S4. Perform access verification based on the generated security access chain, including time window verification, data access permission verification, and access frequency verification; S5. Obtain access verification results. When data access permission verification, access frequency verification, and time window verification are all passed, identity authentication is performed according to the security access chain. S6. Obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

[0007] Preferably, the request packet header includes a data transmission protocol version number and a checksum; the request packet body includes basic information and a digital certificate; the basic information includes a request type, a request target, a request span, a timestamp, and requester information.

[0008] Preferably, the request verification includes: Calculate the checksum of the access request packet and compare the calculated checksum with the checksum provided in the request packet header; if they are the same, perform protocol verification; if they are different, determine the request verification result as failed; The protocol verification includes: obtaining a data transmission protocol version number and comparing it with a list of data transmission protocol version numbers supported by the server; If the same data transmission protocol version number is not found, the request verification result is judged as failed; If the same data transmission protocol version number is found, the transmission protocol rule corresponding to the data transmission protocol version number is extracted, and the request packet is checked to see whether it complies with the transmission protocol rule; If it meets the requirements, the request verification result is judged as passed; if it does not meet the requirements, the request verification result is judged as failed.

[0009] Preferably, the step of generating a security access chain according to the extracted request packet body includes: Get the basic information in the request package body; The first chain is formed using the request type, request target, request span, timestamp and requester information in the basic information; According to the requester information and the request target, the requester's request frequency for the request target is obtained from the server side and recorded as the server frequency; Obtain metadata of the request target, the metadata including type, permission number, window time, allowed frequency and authentication identifier; wherein the permission number corresponds to a permission table, the permission table includes permission users and corresponding span permissions, and the authentication identifier is used to indicate whether supplementary authentication is required; The second chain is formed using the server frequency and metadata of the requested data; The first chain and the second chain are combined to obtain a safety access chain.

[0010] Preferably, the time window verification includes obtaining a timestamp and a window time in the security access chain, and determining whether the timestamp is within the window time; If not, the time window verification fails; if so, the time difference is obtained by subtracting the current time from the timestamp to determine whether the time difference is within the preset time difference range; If yes, the time window verification passes; if no, the time window verification fails; The data access right verification includes: obtaining the permission number and requester information in the security access chain, obtaining the permission table according to the permission number, and querying whether the requester is a permission user in the permission table; If not, the data access permission verification fails; if so, the corresponding span permission is obtained to determine whether the requested span in the security access chain is within the span permission; If yes, the data access permission verification is passed; if no, the data access permission verification is failed; The access frequency verification includes: obtaining the server frequency and the allowed frequency in the security access chain, and determining whether the request frequency is not greater than the allowed frequency. If so, the access frequency verification passes; if not, the access frequency verification fails.

[0011] Preferably, the step of performing identity authentication according to the security access chain includes: Obtain digital certificates and verify digital certificates; When the digital certificate verification fails, it is determined that the identity authentication fails; When the digital certificate verification is successful, the authentication identifier of the secure access chain is obtained; If the authentication flag is no, it is determined that the identity authentication is passed; If the certification mark is yes, then supplementary certification is performed; If the supplementary authentication passes, the identity authentication is determined to be passed; otherwise, the identity authentication fails.

[0012] Preferably, the step of supplementary authentication includes: Obtain the public key in the digital certificate, generate a random challenge code on the server side, and combine the challenge code and generation time into the information to be signed; The information to be signed is sent to the client, which uses the private key to digitally sign the information to be signed and returns the signature result to the server; The server uses the public key to decrypt the signature result, and determines whether the decrypted signature result is consistent with the information to be signed, and whether the difference between the generation time in the decrypted signature result and the current time is within a preset range; When both of the above judgment results are yes, the supplementary authentication is judged to be passed; otherwise, the supplementary authentication is judged to be failed.

[0013] Preferably, the step of generating the encryption key includes: obtaining the request type, timestamp, requester information and server frequency in the security access chain; generating the encryption key using a key generation algorithm according to the request type, timestamp, requester information and server frequency; The steps for generating the decryption key include: obtaining the request type, timestamp, requester information and request target in the access request package, obtaining the request frequency of the requester for the request target recorded by the client and recording it as the client frequency; generating the decryption key using the same key generation algorithm based on the request type, timestamp, requester information and client frequency in the access request package.

[0014] The present invention also provides a power cloud data security access system, which is used to implement a power cloud data security access method, including: A request packet construction module, used for the client to construct and send an access request packet to the power cloud data, wherein the access request packet includes a request packet header and a request packet body; A request verification module is used for receiving an access request packet at the server side and performing request verification on the access request packet according to the request packet header; A security chain generation module is used to obtain the request verification result, extract the request package body for the access request package that has passed the request verification, and generate a security access chain based on the extracted request package body; An access verification module is used to perform access verification based on the generated security access chain, including data access permission verification, access frequency verification, and time window verification; The identity authentication module is used to obtain access verification results. When the data access permission verification, access frequency verification and time window verification are all passed, identity authentication is performed according to the security access chain; The data security transmission module is used to obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

[0015] The present invention provides a method and system for secure access to power cloud data, which has the following beneficial effects: By designing a standardized access request format including a request packet header and a request packet body, combined with checksum verification and protocol verification mechanisms, the integrity and accuracy of data transmission can be effectively ensured. At the same time, the setting of the protocol version number provides good scalability for subsequent protocol upgrades, making the system more adaptable and maintainable. The present invention designs a triple verification mechanism consisting of time window verification, data access permission verification, and access frequency verification, which significantly improves the security of data access by accurately controlling the timeliness, scope of authority, and access frequency of data access. In particular, the introduction of the permission table realizes refined permission management based on user identity and data characteristics, effectively preventing unauthorized access and unauthorized operations. In addition, the present invention constructs a complete data access security protection system through a dual identity authentication mechanism based on digital certificate verification and supplementary authentication, in conjunction with an encryption and decryption scheme for dynamic key generation. This mechanism can not only effectively prevent identity forgery and replay attacks, but also ensure the security of the data transmission process through dynamic key generation, providing reliable protection for secure access to power cloud data. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A schematic diagram of a flow chart of a method for securely accessing power cloud data according to the present invention; Figure 2 This is a module schematic diagram of a power cloud data security access system of the present invention. DETAILED DESCRIPTION

[0017] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention. Example 1

[0018] See also Figure 1 In this embodiment, a method for securely accessing power cloud data includes: S1. The client constructs and sends an access request packet for power cloud data, wherein the access request packet includes a request packet header and a request packet body; The request packet header includes the data transmission protocol version number and checksum; the request packet body includes basic information and a digital certificate; the basic information includes request type, request target, request span, timestamp and requester information.

[0019] In this embodiment, the client first needs to construct an access request packet, which consists of a request packet header and a request packet body, and is used to initiate a data access request to the power cloud data platform. The request packet header contains two important fields: the data transmission protocol version number and the checksum. Among them, the data transmission protocol version number is used to identify the currently used protocol version to ensure the compatibility of the communication protocol between the client and the server; the checksum is used to verify the integrity and accuracy of the data transmission. The checksum can be calculated by converting the content of the access request packet into the corresponding numerical value through ASCII code value or Unicode code value and then adding them.

[0020] You can also view the string as a series of binary bits and then perform bitwise operations (such as XOR operations) to get the checksum.

[0021] The request package body contains two parts: basic information and digital certificate. The basic information includes the following key fields: request type, which is used to describe the operation type of this request, such as data query, data writing, etc.; request target, which indicates the specific data object or resource that needs to be accessed; request span: describes the time range of the required data; timestamp: records the specific time when the request is initiated, which is used to control the timeliness of the request; requester information: contains the user identity information of the user who initiated the request, including user ID, department, etc. Digital certificates can ensure the legitimacy of the source of the request. After completing the construction of the request package, the client sends it to the power cloud data platform through a secure network channel. This standardized request package format design not only ensures the security of data access, but also improves the efficiency and reliability of data transmission. At the same time, by setting the version number, space is also reserved for subsequent protocol upgrades and optimizations.

[0022] S2. The server receives the access request packet and verifies the access request packet according to the header of the request packet; The request verification includes: Calculate the checksum of the access request packet and compare the calculated checksum with the checksum provided in the request packet header; if they are the same, perform protocol verification; if they are different, determine the request verification result as failed; The protocol verification includes: obtaining a data transmission protocol version number and comparing it with a list of data transmission protocol version numbers supported by the server; If the same data transmission protocol version number is not found, the request verification result is judged as failed; If the same data transmission protocol version number is found, the transmission protocol rule corresponding to the data transmission protocol version number is extracted, and the request packet is checked to see whether it complies with the transmission protocol rule; If it meets the requirements, the request verification result is judged as passed; if it does not meet the requirements, the request verification result is judged as failed.

[0023] In this embodiment, after receiving the access request packet, the server first needs to perform strict request verification to ensure the security and reliability of data access. The request verification process mainly includes two steps: checksum verification and protocol verification.

[0024] For checksum verification, the server will recalculate the checksum of the entire access request packet using the same algorithm as the client (such as MD5 or SHA-256). The calculated checksum will be compared with the checksum provided in the request packet header. Only if the two are exactly the same will the next step of protocol verification be entered; if the checksum does not match, it means that the data may have been tampered with or damaged during transmission, and the request verification result will be immediately judged as failed.

[0025] In the protocol verification phase, the server first obtains the data transmission protocol version number from the request packet header and compares it with the list of protocol version numbers supported by the server. The server usually maintains a list of supported protocol version numbers to achieve backward compatibility with multiple versions of the protocol. If the protocol version number in the request packet is not found in the support list, it means that the client is using an unsupported protocol version and the verification will be directly judged as failed.

[0026] If a matching protocol version number is found, the server will further extract the transmission protocol rules corresponding to the version. The rules can be set according to actual needs, usually including specific specifications such as data format requirements, required field checks, and field value range restrictions. The server will conduct a comprehensive check on the request package based on these rules to ensure that the structure and content of the request package fully comply with the protocol specifications. Only request packages that pass all rule checks will be judged as passed, otherwise they will be judged as failed.

[0027] This multi-level verification mechanism can effectively ensure the standardization of data access. At the same time, when the protocol needs to be updated, it is only necessary to add new protocol version support on the server side and formulate corresponding rules. It has strong scalability and maintainability.

[0028] S3. Obtain the request verification result, extract the request package body for the access request package that passes the request verification, and generate a security access chain based on the extracted request package body; The step of generating a security access chain according to the extracted request packet body comprises: Get the basic information in the request package body; The first chain is formed using the request type, request target, request span, timestamp and requester information in the basic information; According to the requester information and the request target, the requester's request frequency for the request target is obtained from the server side and recorded as the server frequency; Obtain metadata of the request target, the metadata including type, permission number, window time, allowed frequency and authentication identifier; wherein the permission number corresponds to a permission table, the permission table includes permission users and corresponding span permissions, and the authentication identifier is used to indicate whether supplementary authentication is required; The second chain is formed using the server frequency and metadata of the requested data; The first chain and the second chain are combined to obtain a safety access chain.

[0029] In this embodiment, for the access request packet that passes the request verification, the server needs to further process it to generate a secure access chain. The generation process of the secure access chain involves the construction and combination of two main chains.

[0030] First, the server extracts basic information from the request package body, including request type, request target, request span, timestamp, and requester information. This information will be organized into the first chain in a predetermined format to record the basic characteristics of this request.

[0031] Next, the server will query the user's historical access records to the target data based on the requester information and the request target, and calculate the server frequency. This frequency can be measured according to time intervals such as days and hours, such as calculating the number of visits in the last day, the number of visits in the last hour, or the number of visits in other time intervals. At the same time, the server will obtain the metadata information of the request target. Metadata is usually set when the data is generated, and it contains multiple attributes used to describe the data. In this embodiment, it is specifically: type, which describes the nature and classification of the data; permission number, which is associated with the permission table and is used to determine the scope of access rights of different users; window time, which specifies the time window in which data is allowed to be accessed, such as 8:00 to 20:00; allowed frequency: the maximum number of accesses allowed to the data, which can be measured according to time intervals such as days and hours; authentication identification: whether additional identity authentication is required, usually for more important data, this is indicated as yes.

[0032] The permission table is an important configuration table that records the users with access rights and the corresponding span permissions. The users with permissions can be identified by user ID or department. Span permissions refer to the time span that the user can access the current data, such as the user can access data within seven days. This can precisely control the user's data access scope. The server organizes the obtained server frequency and these metadata information into the second chain.

[0033] Finally, the server combines the first chain and the second chain to form a complete security access chain. This security access chain contains the basic characteristics of the request, the user's access behavior characteristics, and the security control requirements of the data, providing a decision basis for subsequent access control.

[0034] S4. Perform access verification based on the generated security access chain, including time window verification, data access permission verification, and access frequency verification; The time window verification includes obtaining the timestamp and window time in the security access chain, and determining whether the timestamp is within the window time; If not, the time window verification fails; if so, the time difference is obtained by subtracting the current time from the timestamp to determine whether the time difference is within the preset time difference range; If yes, the time window verification passes; if no, the time window verification fails; The data access right verification includes: obtaining the permission number and requester information in the security access chain, obtaining the permission table according to the permission number, and querying whether the requester is a permission user in the permission table; If not, the data access permission verification fails; if so, the corresponding span permission is obtained to determine whether the requested span in the security access chain is within the span permission; If yes, the data access permission verification is passed; if no, the data access permission verification is failed; The access frequency verification includes: obtaining the server frequency and the allowed frequency in the security access chain, and determining whether the request frequency is not greater than the allowed frequency. If so, the access frequency verification passes; if not, the access frequency verification fails.

[0035] In this embodiment, the server needs to perform triple verification on the generated security access chain: time window verification, data access permission verification and access frequency verification. Only by passing these three verifications at the same time can the legitimacy and security of data access be ensured.

[0036] Time window verification mainly controls the timeliness of requests. First, extract the timestamp and window time from the security access chain to determine whether the timestamp is within the valid window time range. If it is not within the window time, it means that the time data does not allow the request, and the verification is directly judged to be unsuccessful. If it is within the window time, the time difference between the current time and the timestamp is further calculated, and it is compared with the preset time difference range. The preset time difference range can be set according to actual business needs, for example, it can be set to 5 minutes or 10 minutes. Only when the time difference is within the preset range can the time window verification be judged to be passed, which can effectively prevent replay attacks and expired requests.

[0037] Data access permission verification mainly ensures that the requester has appropriate access permissions. First, obtain the permission number and requester information from the security access chain, and query the corresponding permission table through the permission number. The permission table records all users with access permissions and their corresponding span permissions. First, check whether the requester is in the permission table. If not, it means that the user does not have any access permissions, and the verification is directly judged to be unsuccessful. If the requester is in the permission table, further obtain the corresponding span permissions and compare them with the requested span. Only when the requested span is within the allowed span permissions can the permission verification be judged to be successful. This multi-level permission control mechanism can accurately manage the access permissions of different users to different data ranges.

[0038] Access frequency verification controls the access frequency by comparing the server frequency with the allowed frequency. The two frequency values ​​are obtained from the security access chain and compared. Only when the server frequency does not exceed the allowed frequency can the frequency verification be considered passed. This mechanism can effectively prevent the risk of excessive load or data leakage caused by frequent access.

[0039] This triple verification mechanism forms a strict access control system. Time window verification ensures the timeliness of the request; permission verification ensures that the visitor has appropriate permissions; and frequency verification prevents excessive access. By adjusting the parameters of each verification link, such as the time difference range, span permissions, and allowed frequency, the strictness of data access can be flexibly controlled according to actual needs, ensuring data security while taking into account availability and flexibility.

[0040] S5. Obtain access verification results. When data access permission verification, access frequency verification, and time window verification are all passed, identity authentication is performed according to the security access chain. The steps of performing identity authentication according to the secure access chain include: Obtain digital certificates and verify digital certificates; When the digital certificate verification fails, it is determined that the identity authentication fails; When the digital certificate verification is successful, the authentication identifier of the secure access chain is obtained; If the authentication flag is no, it is determined that the identity authentication is passed; If the certification mark is yes, then supplementary certification is performed; If the supplementary authentication passes, the identity authentication is determined to be passed; otherwise, the identity authentication fails.

[0041] The steps of the supplementary certification include: Obtain the public key in the digital certificate, generate a random challenge code on the server side, and combine the challenge code and generation time into the information to be signed; The information to be signed is sent to the client, which uses the private key to digitally sign the information to be signed and returns the signature result to the server; The server uses the public key to decrypt the signature result, and determines whether the decrypted signature result is consistent with the information to be signed, and whether the difference between the generation time in the decrypted signature result and the current time is within a preset range; When both of the above judgment results are yes, the supplementary authentication is judged to be passed; otherwise, the supplementary authentication is judged to be failed.

[0042] In this embodiment, after the request passes the time window verification, data access permission verification and access frequency verification, identity authentication is performed to further ensure the security of data access. The identity authentication process includes two levels: basic digital certificate verification and optional supplementary authentication.

[0043] First, obtain the digital certificate in the request package body and verify it. Digital certificate verification usually includes certificate chain verification, certificate validity period check, certificate revocation status query, etc. If the digital certificate verification fails, it will be directly judged as identity authentication failure and subsequent data access requests will be rejected.

[0044] When the digital certificate is verified, the authentication mark will be obtained from the security access chain. The authentication mark is used to identify whether supplementary authentication is required. This mechanism allows different levels of security protection to be adopted for data of different importance. If the authentication mark is no, it means that the basic digital certificate verification is sufficient and the identity authentication is directly determined to be passed. If the authentication mark is yes, a more stringent supplementary authentication is required. The specific process of supplementary authentication is as follows: The server first extracts the user's public key from the digital certificate and generates a random challenge code. The challenge code is usually a random string of sufficient length to ensure its unpredictability. The server combines the challenge code and its generation time into the information to be signed.

[0045] The server sends the information to be signed to the client. After receiving the information to be signed, the client uses its private key to digitally sign the information. This process proves that the client does have the private key that is paired with the public key in the certificate, thereby proving the authenticity of its identity. The client returns the signature result to the server. After receiving the signature result, the server uses the public key obtained previously to decrypt it and performs two important verifications: verifying whether the decrypted content is completely consistent with the original information to be signed to ensure the correctness of the signing process; and checking whether the difference between the generation time obtained after decryption and the current time is within a preset reasonable range (such as 30 seconds) to prevent delay attacks.

[0046] Only when both verifications are passed, the supplementary authentication will be judged as passed, and then the entire identity authentication process will be judged as passed. This multi-level identity authentication mechanism can effectively prevent security threats such as identity forgery and replay attacks. At the same time, through the setting of authentication identifiers, corresponding authentication strategies can be flexibly adopted for data of different security levels, which not only ensures security but also avoids excessive authentication overhead.

[0047] S6. Obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

[0048] The steps of generating the encryption key include: obtaining the request type, timestamp, requester information and server frequency in the security access chain; generating the encryption key using a key generation algorithm according to the request type, timestamp, requester information and server frequency; The steps for generating the decryption key include: obtaining the request type, requester information and request target in the access request package, obtaining the request frequency of the requester for the request target recorded by the client and recording it as the client frequency; generating the decryption key using the same key generation algorithm based on the request type, timestamp, requester information and client frequency in the access request package.

[0049] In this embodiment, when the request passes the identity authentication, the system will enter the data transmission stage. To ensure the security of data transmission, the server and the client adopt an encryption and decryption mechanism based on dynamic keys. The characteristics of this mechanism are that the key is dynamically generated with each request, and the server and the client can independently generate paired encryption keys and decryption keys.

[0050] The encryption key generation process on the server side is as follows: extract key information from the secure access chain, including: request type, timestamp, requester information, and server frequency. The server uses a predetermined key generation algorithm and uses this information as input parameters to generate the encryption key used for this data transmission. The key generation algorithm can be used in the following way: concatenate the input parameters in a fixed order, calculate the concatenation result using a secure hash function (such as SHA-256), use the hash result as a seed, and generate the final encryption key through a key derivation function (such as PBKDF2).

[0051] The client's decryption key generation process corresponds to this: it obtains relevant information from the local, including: request type, timestamp, requester information, and client frequency (the access frequency of the access target recorded locally on the client). It uses the same key generation algorithm as the server, and uses this information as input parameters to generate the decryption key. Since the client and server use the same algorithm and corresponding parameters, they can generate paired keys.

[0052] This dynamic key generation mechanism has the following advantages: the key changes dynamically with the request. Even if the key of a certain communication is cracked, it will not affect the security of other communications. There is no need for explicit key exchange, which reduces the risk of interception. By taking the access frequency as one of the parameters, the key generation process is associated with the user's access behavior. If the local and server records are inconsistent, the correct decryption key cannot be generated, which increases security.

[0053] In this embodiment, the server uses the generated encryption key to encrypt the requested data, and a symmetric encryption algorithm such as AES can be used. The encrypted data is sent to the client through a secure channel. After receiving the encrypted data, the client uses the generated decryption key to decrypt it, thereby obtaining the original data. Example 2

[0054] See also Figure 2 The present invention provides a power cloud data security access system, which is used to implement a power cloud data security access method, including: A request packet construction module, used for the client to construct and send an access request packet to the power cloud data, wherein the access request packet includes a request packet header and a request packet body; A request verification module is used for receiving an access request packet at the server side and performing request verification on the access request packet according to the request packet header; A security chain generation module is used to obtain the request verification result, extract the request package body for the access request package that has passed the request verification, and generate a security access chain based on the extracted request package body; An access verification module is used to perform access verification based on the generated security access chain, including data access permission verification, access frequency verification, and time window verification; The identity authentication module is used to obtain access verification results. When the data access permission verification, access frequency verification and time window verification are all passed, identity authentication is performed according to the security access chain; The data security transmission module is used to obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

[0055] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the units is only one, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0056] The above description is only a specific implementation mode of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

[0057] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for secure access to power cloud data, characterized in that: include: S1. The client constructs and sends an access request packet for power cloud data, wherein the access request packet includes a request packet header and a request packet body; S2. The server receives the access request packet and verifies the access request packet according to the header of the request packet; S3. Obtain the request verification result, extract the request package body for the access request package that passes the request verification, and generate a security access chain based on the extracted request package body; S4. Perform access verification based on the generated security access chain, including time window verification, data access permission verification, and access frequency verification; S5. Obtain access verification results. When data access permission verification, access frequency verification, and time window verification are all passed, identity authentication is performed according to the security access chain. S6. Obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

2. A method for secure access to electric power cloud data according to claim 1, characterized in that: The request packet header includes the data transmission protocol version number and checksum; the request packet body includes basic information and a digital certificate; the basic information includes request type, request target, request span, timestamp and requester information.

3. A method for secure access to electric power cloud data according to claim 2, characterized in that: The request verification includes: Calculate the checksum of the access request packet and compare the calculated checksum with the checksum provided in the request packet header; if they are the same, perform protocol verification; if they are different, determine the request verification result as failed; The protocol verification includes: obtaining a data transmission protocol version number and comparing it with a list of data transmission protocol version numbers supported by the server; If the same data transmission protocol version number is not found, the request verification result is judged as failed; If the same data transmission protocol version number is found, the transmission protocol rule corresponding to the data transmission protocol version number is extracted, and the request packet is checked to see whether it complies with the transmission protocol rule; If it meets the requirements, the request verification result is judged as passed; if it does not meet the requirements, the request verification result is judged as failed.

4. A method for secure access to electric power cloud data according to claim 3, characterized in that: The step of generating a security access chain according to the extracted request packet body comprises: Get the basic information in the request package body; The first chain is formed using the request type, request target, request span, timestamp and requester information in the basic information; According to the requester information and the request target, the requester's request frequency for the request target is obtained from the server side and recorded as the server frequency; Obtain metadata of the request target, the metadata including type, permission number, window time, allowed frequency and authentication identifier; wherein the permission number corresponds to a permission table, the permission table includes permission users and corresponding span permissions, and the authentication identifier is used to indicate whether supplementary authentication is required; The second chain is formed using the server frequency and metadata of the requested data; The first chain and the second chain are combined to obtain a safety access chain.

5. A method for secure access to electric power cloud data according to claim 4, characterized in that: The time window verification includes obtaining the timestamp and window time in the security access chain, and determining whether the timestamp is within the window time; If not, the time window verification fails; if so, the time difference is obtained by subtracting the current time from the timestamp to determine whether the time difference is within the preset time difference range; If yes, the time window verification passes; Otherwise the time window verification fails; The data access right verification includes: obtaining the permission number and requester information in the security access chain, obtaining the permission table according to the permission number, and querying whether the requester is a permission user in the permission table; If not, the data access permission verification fails; if so, the corresponding span permission is obtained to determine whether the requested span in the security access chain is within the span permission; If yes, the data access permission verification is passed; if no, the data access permission verification is failed; The access frequency verification includes: obtaining the server frequency and the allowed frequency in the security access chain, and determining whether the request frequency is not greater than the allowed frequency. If so, the access frequency verification passes; if not, the access frequency verification fails.

6. A method for secure access to electric power cloud data according to claim 5, characterized in that: The steps of performing identity authentication according to the secure access chain include: Obtain digital certificates and verify digital certificates; When the digital certificate verification fails, it is determined that the identity authentication fails; When the digital certificate verification is successful, the authentication identifier of the secure access chain is obtained; If the authentication flag is no, it is determined that the identity authentication is passed; If the certification mark is yes, then supplementary certification is performed; If the supplementary authentication passes, the identity authentication is determined to be passed; otherwise, the identity authentication fails.

7. A method for secure access to electric power cloud data according to claim 6, characterized in that: The steps of the supplementary certification include: Obtain the public key in the digital certificate, generate a random challenge code on the server side, and combine the challenge code and generation time into the information to be signed; The information to be signed is sent to the client, which uses the private key to digitally sign the information to be signed and returns the signature result to the server; The server uses the public key to decrypt the signature result, and determines whether the decrypted signature result is consistent with the information to be signed, and whether the difference between the generation time in the decrypted signature result and the current time is within a preset range; When both of the above judgment results are yes, the supplementary authentication is judged to be passed; otherwise, the supplementary authentication is judged to be failed.

8. A method for secure access to electric power cloud data according to claim 7, characterized in that: The steps of generating the encryption key include: obtaining the request type, timestamp, requester information and server frequency in the security access chain; generating the encryption key using a key generation algorithm according to the request type, timestamp, requester information and server frequency; The steps for generating the decryption key include: obtaining the request type, timestamp, requester information and request target in the access request package, obtaining the request frequency of the requester for the request target recorded by the client and recording it as the client frequency; generating the decryption key using the same key generation algorithm based on the request type, timestamp, requester information and client frequency in the access request package.

9. A power cloud data security access system, used to implement a power cloud data security access method as described in any one of claims 1 to 8, characterized in that: include: A request packet construction module, used for the client to construct and send an access request packet to the power cloud data, wherein the access request packet includes a request packet header and a request packet body; A request verification module is used for receiving an access request packet at the server side and performing request verification on the access request packet according to the request packet header; A security chain generation module is used to obtain the request verification result, extract the request package body for the access request package that has passed the request verification, and generate a security access chain based on the extracted request package body; An access verification module is used to perform access verification based on the generated security access chain, including data access permission verification, access frequency verification, and time window verification; The identity authentication module is used to obtain access verification results. When the data access permission verification, access frequency verification and time window verification are all passed, identity authentication is performed according to the security access chain; The data security transmission module is used to obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

Images