CN107948235B - JAR-based cloud data security management and audit device - Google Patents

Abstract

The invention discloses a JAR-based cloud data security management and audit device, which comprises: the cloud data management module is used for reading, writing and updating data by a data owner, updating a user list and performing log audit operation, wherein malicious behaviors are detected and terminated before an unauthorized user views plaintext data, and when someone accesses the data of the server, automatic log recording is triggered through an access strategy of JAR; and the log security audit module is used for storing the log on the CSP through the log format of the Attestation, ensuring the security of the log through the whole structure of the chain log, and inquiring data access or specific files or user behaviors through the access strategy of JAR. The device can provide an automatic and reliable log recording mechanism through an access strategy of JAR, ensure that data access generates records and protects the data from key abuse attack, effectively realize the authenticity and integrity of the records and effectively improve the safety of the data.

Description

JAR-based cloud data security management and audit device

Technical Field

The invention relates to the technical field of cloud storage and data security protection, in particular to a JAR (Java Archive) based cloud data security management and auditing device.

Background

With the development of cloud services, more and more users start to use the cloud storage service. Simply stated, cloud storage is an emerging solution for putting storage resources on the cloud for human access. In terms of data access, the problem with existing cloud storage technologies is mainly whether cloud storage can provide sufficient accessibility if large-scale data request or data recovery operations are performed. In terms of data Security, a cloud storage server has been a target for hacker intrusion, and in recent years, a CSP (Content Security Policy) has a report of data loss and leakage accidents, and in consideration of the poor reputation of the CSP, a cloud user is concerned about losing control over the data of the CSP, and the unreliability of the CSP and log records causes many problems in cloud storage. Most cloud service providers prepare security protection schemes, but the data security problem in cloud storage still exists objectively and needs to be solved.

In the related art, as a main method for coping with the problem of the CSP, log recording enables tracking of data usage, facilitating data security check. As a common type of logging, the log is generated by a CSP with a logging mechanism and stored in the cloud. In untrusted clouds, either malicious users or CSPs have the ability to make false or broken logs, preventing evidence of leaking data from being left behind. Therefore, how to build an automatic and reliable log record in an untrusted cloud faces a serious challenge. In recent years, research on trusted cloud records in an untrusted cloud focuses on integrity protection of logs, digital signatures and hash chain mechanisms have been introduced into reliable log recording formats, and authenticity of recorded logs can be effectively guaranteed by adopting an automatic recording mechanism.

However, the most advanced automatic log recording technology still has some problems, such as the automatic recording mechanism is designed for a distributed storage system, and does not fully utilize the capacity of the CSP, which causes a huge burden on log communication and storage of a data owner; also for example, to protect user privacy in the log content, log encryption mechanisms are inefficient in both space and time, and untrusted CSPs can raise the problem of key abuse attacks. It should be noted that, through collusion with the CSP, a malicious user can directly access the encrypted data stored on the CSP without generating any record, and decrypt the data with the leaked decryption key, which results in low security of the data and poor authenticity and integrity of the record.

Disclosure of Invention

The present invention is directed to solving, at least to some extent, one of the technical problems in the related art.

Therefore, the invention aims to provide a cloud data security management and auditing device based on JAR, which can ensure that data access generates records and protects the data from key abuse attack, effectively realizes the authenticity and integrity of the records, and effectively improves the security of the data.

In order to achieve the above object, an embodiment of the present invention provides a cloud data security management and audit device based on JAR, including: the data management module is used for realizing reading, writing and updating of data by a data owner, updating a user list and performing log audit operation, wherein malicious behaviors are detected and terminated before an unauthorized user checks plaintext data, and when someone accesses the data of the server, automatic log recording is triggered through an access strategy of JAR; and the log security audit module is used for storing the log on the CSP through the log format of the Attestation, and ensuring the security of the log through the whole structure of the chain log so as to inquire data access or inquire an appointed file or user behavior through the access strategy of the JAR.

The cloud data security management and audit device based on JAR of the embodiment of the invention can realize the functions of JAR-based data access control, data operation-oriented log generation, log integrity maintenance, log-based security audit and the like, and provides an automatic and reliable log recording mechanism through an access strategy of JAR, so that data access is ensured to generate records and protect the data from key abuse attack, the authenticity and integrity of the records are effectively realized, and the security of the data is effectively improved.

In addition, the JAR-based cloud data security management and auditing apparatus according to the above embodiments of the present invention may further have the following additional technical features:

further, in an embodiment of the present invention, the access policy of the JAR includes: the server side checks the request authority, generates a log in a preset format, and after the log in the preset format is added to the existing log, the server generates a corresponding permission or alias message after the complete execution of all the contents of the generated log in the preset format is completed, so as to ensure that all data modification has log records.

Further, in one embodiment of the present invention, the log format of the Attestation is as follows:

wherein the log information is kept in plain text at the service provider and the operation logs of the different data are recorded in a common log file.

Further, in an embodiment of the present invention, the whole structure of the chained log is as follows:

ChainHash＝hash(AttestBody,prevChainHash)。

further, in one embodiment of the invention, when each Attestation content is changed, the whole log chain is broken, so that malicious behaviors threatening data security are positioned according to the broken positions of the hash chain.

Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.

Drawings

The foregoing and/or additional aspects and advantages of the present invention will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:

fig. 1 is a schematic structural diagram of a JAR-based cloud data security management and auditing apparatus according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of an overall framework of a cloud data management and automatic logging tool, according to one embodiment of the invention;

FIG. 3 is a schematic illustration of JAR-based data access control according to one embodiment of the present invention;

FIG. 4 is a schematic diagram of a ServerJAR-based automatic logging mechanism, according to one embodiment of the present invention;

fig. 5 is a schematic diagram of an information update process of Owner according to an embodiment of the present invention;

FIG. 6 is a diagram illustrating a data access process of a Client according to one embodiment of the invention;

figure 7 is a schematic diagram of Owner's log query process according to one embodiment of the present invention.

Detailed Description

Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are illustrative and intended to be illustrative of the invention and are not to be construed as limiting the invention.

In order to achieve reliable cloud data management and automatic logging, it is first ensured that the network communication protocol and the service deployment environment are relatively reliable. For this embodiment of the present invention, SSL (Secure Socket Layer, Secure Socket Layer protocol communication) and Amazon AWS EC2(EC2, Elastic computer Cloud, Amazon Elastic computing network Cloud) are used to perform Cloud service environment deployment. Therefore, prior to introducing the JAR-based cloud data security management and auditing apparatus, SSL and Amazon AWS EC2 are first introduced.

The SSL protocol is developed by Netscape to ensure the safety of data transmission on Internet, and data encryption technology is used to ensure that data is not intercepted and eavesdropped during the transmission process on network. The SSL Protocol is located between a TCP (Transmission Control Protocol)/IP (Internet Protocol, Protocol for interconnection between networks) Protocol and various application layer protocols, and provides security support for data communication. There are many advantages to using the SSL protocol for network communication: (1) providing a higher security assurance. SSL ensures the security of data transmission over the network using data encryption, authentication and message integrity verification mechanisms. (2) Various application layer protocols are supported. Although SSL was originally designed to address web security issues, since SSL is located between the application layer and the transport layer, it can provide security guarantees for any application layer protocol based on a reliable connection such as TCP. (3) The deployment is simple. SSL has become a global standard for authenticating the identity of Web sites and Web page viewers in networks, and for encrypted communications between browser users and Web servers (World Wide Web, www or www).

In addition, the AWS EC2 is a system that allows users to rent cloud computers to run applications. A simple Web service interface on the AWS EC2 allows a user to easily acquire and configure resources. The AWS EC2 has the following advantages: (1) and (4) completely controlling. The user may have full control over his or her own instances, have administrator or root user access to each instance, and may interact with these instances as with any other machine. The user may save the data in the boot partition while stopping running the instance, and then restart with a Web services API (Application Programming Interface). The use of the Web services API also allows remote restart of the instance, as well as access to the instance console output. (2) The operation is reliable. Amazon EC2 provides a very reliable environment in which alternative instances can start quickly and in a predictable manner. The service runs on amazon certified network infrastructure and data centers. (3) And (4) safety. Amazon EC2 works in conjunction with Virtual Private Cloud (VPC) to provide secure and powerful networking functions for the user's computing resources. The user's computing instance is located in Amazon VPC, which has a user-specified IP range. The user can decide which instances to disclose to the internet and which to keep private. The security group and network ACL (Access Control List) allow the user to Control inbound and outbound network Access to and from their instance. (4) The expansibility is good. Amazon EC2 can be used with Amazon Simple Storage Service (Amazon S3), Amazon Relational Database Service (Amazon RDS) and Amazon Simple Queue Service (Amazon SQS) to provide complete computation, query processing and Storage solutions for a variety of applications.

The following describes a JAR-based cloud data security management and auditing apparatus according to an embodiment of the present invention with reference to the accompanying drawings.

Fig. 1 is a schematic structural diagram of a cloud data security management and auditing apparatus based on JAR according to an embodiment of the present invention.

As shown in fig. 1, the JAR-based cloud data security management and audit apparatus 10 includes: cloud data management module 100 and log security audit module 200.

The cloud data management module 100 is configured to implement reading, writing, and updating of data by a data owner, update a user list, and perform log audit operation, where malicious behaviors are detected and terminated before an unauthorized user views plaintext data, and when someone accesses data at a server, automatic log recording is triggered by an access policy of JAR. The log security audit module 200 is configured to store the log on the CSP in the log format of Attestation, and ensure the security of the log through the whole chain-like log structure, so as to query data access or query a specified file or a user behavior through the access policy of JAR. The device 10 can provide an automatic and reliable log recording mechanism through an access policy of JAR, ensure that data access generates records and protects data from key abuse attack, effectively realize authenticity and integrity of the records, and effectively improve safety of the data.

It can be understood that the device 10 according to the embodiment of the present invention may use a programmable Java JAR file coupled to data to encapsulate an access policy, and ensure that data access by JAR will trigger authentication and automatic log recording of local JAR, thereby implementing effective management on cloud data. Meanwhile, a reliable log format called 'Attestation' is designed in a log-based security audit tool, so that cloud storage is more reliable.

Specifically, the device 10 of the embodiment of the present invention designs a cloud data security management and audit tool for a data sharing environment based on a programmable Java JAR, and the device 10 is divided into two modules: cloud data management module 100 and log security audit module 200. In the cloud data management module 100, the embodiment of the present invention defines a user as three different identities: data Owner (Owner), service provider (CSP), sharing User (User). The cloud data management module 100 can implement reading, writing, updating, user list updating and log auditing operations of the owner on data. Meanwhile, a legal user has the right to read data, can apply for accessing a certain file or a part of the file, and can also update the identity of the user to assist safe data access.

That is, as shown in fig. 2, cloud data management module 100 is supported by an automatic and reliable logging mechanism, and may employ a programmable Java JAR file coupled with the data to encapsulate the access policy, ensuring that data access by JAR will trigger authentication and automatic logging of local JAR. The embodiment of the invention defines the User in the data sharing environment into three different identities, namely a data Owner (Owner), a service provider (CSP) and a sharing User (User), and defines the behaviors of the different identities according to the User identity. The embodiment of the invention uses SSL protocol to carry out data communication, because SSL can ensure the safety and the integrity of data transmission. Three different identities, namely data Owner (Owner), service provider (CSP) and sharing User (User), are explained in detail below.

First, as shown in FIG. 3, the data owner: jar and resource files. Owner encrypts the data and generates a JAR for the data for access and management. The owner side functions are: updating data files, updating user access control lists, auditing server data and acquiring server activity data. Owner has writing authority to data, and can update information stored in the cloud. The information updated by Owner can be further classified into 2 types: and storing the user list in the data block of the Server end and the Server JAR. The updating processes of the two types of information are consistent, and the difference exists only in the process that the owner generates the new version information and the updating process that the server receives the new version information.

Next, as shown in fig. 3, the sharing user: the client side is composed of a client _10.JAR and a resource file, and the client side accesses data by using the JAR corresponding to the role of the client side but cannot acquire the complete authority of the data. The client functions include: request data and update versions. The deployment of the Client JAR is mainly completed by public network transmission, a method of writing a data decryption key (asymmetric encryption) in a Client JAR code can be adopted, a protection mechanism of Java for the code is utilized, and a mode of transmitting an asymmetric encryption key through symmetric encryption is replaced, so that the data encryption performance similar to the traditional symmetric-asymmetric encryption combination mode is achieved. The legal client has the right to read the data, and in the data requesting module, the client sends a request to the server, and can obtain the data file uploaded by the file owner on the server after the server is authenticated. The Client can apply for accessing a certain file or a part of a file, and can also update the identity of the Client to assist safe data access. Whenever the file owner updates the version of the JAR, the client can update its JAR file through the update version module. And obtaining the new HashID of the client after the authentication of the server.

Finally, as shown in fig. 3, the service provider: JAR is a functional program of the server, provides a cloud environment for data storage, manages access and update of the data through JAR corresponding to the role of the server, and records log information. The service functions for the client are as follows: sending data services and updating client services. The data owner side service functions are as follows: file data update service, user access control list update service, statistics user activity service, and statistics server activity service. The device 10 of the embodiment of the present invention deploys the server on Amazon AWS EC2 (Amazon elastic computing network cloud).

Further, in order to solve the problem that CSP colludes with malicious users and skips Server JAR to directly send data to unauthorized users, the embodiment of the invention provides a process of requesting permission check, and before the unauthorized users can actually check plaintext data, malicious behaviors are detected and terminated. Meanwhile, in order to ensure that automatic recording is inevitably triggered when a user accesses data of a server side, and automatic log recording is realized, the embodiment of the invention designs an access strategy based on JAR. In addition, in the log security audit module 200, the embodiment of the invention designs a reliable log format called "Attestation", and a large amount of logs can be directly stored on the CSP without encryption. Meanwhile, the embodiment of the invention designs and realizes a chain-shaped log integral structure to ensure the safety of the log. The log security audit module 200 can realize two log query functions, namely a data access query function and a specified file or user behavior query function, based on the JAR-packaged access policy.

Further, in an embodiment of the present invention, the access policy of JAR includes: the server side checks the request authority, generates a log in a preset format, and adds the log in the preset format to the existing log, so that after the complete execution of all the contents of the generated log in the preset format is completed, the server generates a corresponding permission or alias message to ensure that log records exist in all data modification.

That is, the server executes the request permission checking process, and generates a log in a fixed format, and adds the log to an existing log. When the complete content of the generated log is executed correctly, the server can generate a corresponding permission or alias message, which ensures that all data modifications have log records.

Specifically, as shown in fig. 4, the automatic logging mechanism according to the embodiment of the present invention needs to go through a process of requesting permission check, and encapsulates an access policy by JAR, and when a user accesses data of a server, automatic logging is inevitably triggered. The access policy in the ServerJAR mainly consists of the following steps: accept request, check permissions, get data, generate log, return permission and data or alias.

First, an owner or a client sends a request of a data access or log audit request. Second, the server is awakened for authentication upon receipt of the request, and the server authorizes the user by checking whether the user's hashID is before the expiration date, and whether the user is in the shared user list. And finally, when the Server JAR reads the request and identifies the authorized user, triggering automatic log recording, generating an Attestation related to the current request-permission, and after the verification is passed, generating a permission message and sending the permission message to the request end, wherein the data access or log audit operation can be continued. Furthermore, if a user or CSP attempts to violate a protocol by circumventing JAR, the data access will fail. And if the access user has no authority, sending the alias message to the request end after generating the log.

Optionally, in one embodiment of the invention, the log format of Attestation is as follows:

wherein the log information is kept in plain text at the service provider and the operation logs of the different data are recorded in a common log file.

That is, log information is kept in plain text at the service provider, and operation logs of different data are recorded in one common log file. The generation of the log information is closely related to an interaction mechanism so as to ensure that the log mechanism can accurately record data operation behaviors in the whole data security framework.

In particular, embodiments of the present invention devise a reliable log format called "Attestation" that allows a large number of logs to be stored directly on the CSP without encryption. The plaintext authentication format reduces the storage cost, flexible generation and authorization processes are beneficial to fast data access, and meanwhile, the embodiment of the invention designs and realizes a chain log integral structure based on a hash chain so as to ensure the safety and integrity of the log. The log security audit module 200 can realize two log query functions, namely a data access query function and a specified file or user behavior query function, based on the JAR-packaged access policy.

The generation of the log is based on a "request-permission" mechanism of data access control. The log data format named "Attestation" is as follows:

it should be noted that, in the Attestation structure, an "ACT" field is used to record a behavior type, and a "blockHash" is a hash value of a data block involved in the operation process, and can match a log with current data. The "UserInfo & DataInfo" is used to indicate the object of the behavior, and the field content may be a data file name, a data block name, and a user name according to the type of the behavior. "User HashID" indicates the source of the action, i.e., the requestor of the data operation. ACT, blockHash, UserInfo & DataInfo, from the body of the request message, the same as the corresponding request message. "Time of Access" is the service provider system Time at the Time of log information generation. The "ChainHash" is a field designed to ensure the safety and reliability of log data. "Signature" is the digital Signature of the service provider that generated this log record. The CSP uses "#" between the various fields as a delimiter when storing log records.

Wherein the log information is kept in plain text at the service provider, mainly because the structure of the Attestation itself ensures its own robustness. Secondly, the log is mainly used for recording data security events in the framework, and sensitive information in the log, such as user identity information and data information, is represented by using hash values, so that the data security problem is not caused by leakage of log information. Finally, the ciphertext search technology in the prior art has high requirements on computing resources, and the plaintext representation has good availability for scenes which may need frequent log query. In addition, operation logs of different data are recorded in a common log file. This is mainly due to the following two considerations: firstly, the public log storage can reduce the computing resource requirement brought by file reading during log query; the second is that a large number of Attestation will form a longer hash chain, which makes it difficult for a malicious user or service provider to hide malicious behavior by modifying the log. The log information is closely related to the data operation request, but not related to specific data operation behaviors, so that illegal data operation intentions can still be completely recorded by a log mechanism, and a data owner can discover potential malicious users and malicious behaviors through the log.

Optionally, the whole structure of the chained log is as follows:

ChainHash＝hash(AttestBody,prevChainHash)。

in the log recording tool, the integrity and tamper resistance of log information are the key points for ensuring that the log can accurately describe data security events and achieve the aim of maintaining data security. The embodiment of the invention designs and realizes a chain-shaped log integral structure for ensuring the safety of the log. In Attestation, a ChainHash field is designed to maintain the overall security of the log. The ChainHash uses ACT, UserID, BlockID, Nonce and Time fields of the log information main body and the ChainHash field in the previous Attestation to add and carry out Hash conversion once again so as to obtain the ChainHash value of the log record. The latest chainHash will be kept in Server JAR as a parameter for calculating the chainHash value of the next attesting. Finally signed by the Server JAR, and then the chainHash is appended to the end of the existing annotation under the Server JAR run directory. Wherein the content of the first and second substances,

ChainHash＝hash(AttestBody,prevChainHash)。

optionally, in an embodiment of the present invention, when each Attestation content is changed, the whole log chain is broken, so as to locate malicious behaviors threatening data security according to the broken position of the hash chain.

That is, the closely related log chain structure makes the entire log chain break when each Attestation content changes. The embodiment of the invention can position the malicious behavior threatening the data security according to the broken position of the Hash chain.

Specifically, the log-based security audit is designed and realized on a data management platform, and two log query functions, namely a data access query function and a specified file or user behavior query function, are realized. The two functions respectively correspond to a server activity data acquisition module and an audit server data acquisition module of the owner end. The file owner can obtain the latest activity data on the server by the acquisition server activity data module, wherein the latest activity data comprises the times and the time of data request of a client on the server, the user and the time of the last request and the times and the time of illegal requests. The result of the data access query is a data security briefing. The data owner can request the server to send a data security briefing, visually know the security condition of the data through the data security briefing, and determine whether detailed query on data security events is necessary or not. And when the data owner considers that the data security is threatened or the complete operation log of the data needs to be checked for other reasons, a query log request needs to be made to the service provider according to an interaction mechanism. This is the data module of the auditing server at the owner end, and the owner of the file can audit the activity information of a specific file and a specific user on the server.

It should be noted that, in the embodiment of the present invention, data, log information, and related information for log query and log integrity maintenance are stored in a file storage manner, and the information is stored in a resource folder of a server. A folder with the same name is established in the resource folder for each data. For example, the data content and related information of a data file myFile are stored in a myFile folder.

Wherein the blocks folder stores all encrypted data blocks of the file. The userkey folder is used for storing public-keys of the users. The method is used for the server side to verify the identity of the user. Txt is used to store a data oplog related to the current data. Txt is used for storing the ChainHash in the latest attribute information and is used for generating the ChainHash in the next attribute information without reading a relatively larger attribute. Txt is used to store the data block information of myFile response. Txt is used for storing response information of the CSP to the data access request, and because the response information includes a main body of the request information, the request information does not need to be additionally stored. Txt is used to store the results of data owner requests to query the log.

In addition, the communication scheme adopted by the device 10 of the embodiment of the present invention includes: (1) owner's sendMessage () method sends no more than 1024 bytes at a time through WritableByteChannel until the end of the content. (2) The receivepermission message () of Owner reads 1024 bytes at most from the cache at a time through the ReadablebyteChannel, the former is used for receiving the permission sent by the client, reading the end stop and returning the permission character string. (3) And the receiveFile () method is used for receiving the query result FILE sent by the owner, deleting the FILE and the FILE-END identifier and returning the FILE content in the form of character strings. (4) The sendFile () and sendMessage () methods of the Server send no more than 1024 bytes at a time through the writeable bytechannel until the end of the content. (5) The method of receiveFiles () and receiveMessage () of the Server reads 1024 bytes at most from the cache each time through ReadableByteChannel until the content is finished, and returns the received data in the form of a character string. (6) The Client's sendMessage () method sends no more than 1024 bytes at a time through writeable bytechannel until the content is finished. (7) The Client's receiveserverData () method always reads a maximum of 1024 bytes from the cache at a time through readableByteChannel, receives the "end" identifier to stop, and returns the received permission and data, or alias, in a string of a specific format.

In addition, in an embodiment of the present invention, the data management implementation step includes:

(1) as shown in fig. 5, the information updating process of Owner includes:

and (1) initializing. And loading the certificate, creating and initializing an SSLContext instance, and establishing a connection between the owner and the server.

And sending the request. Owner actively sends a request message to server through a SendMessage () method. The fixed format of the Request is: ACT # owerID # dataID # nonce # signature, where "#" is a delimiter, dividing the request into 5 fields. If the data block is requested to be updated, the value of the ACT field is UPDATE, and the value of the dataID field is filename _ blockID; if the user list is requested to be updated, the value of the ACT field is ACL, and the value of the dataID field is filename _ user _ version, where "_" is a delimiter inside one field of the request. The nonce is a 6-bit random number and the signature is a signature of owner.

And thirdly, replying the request. The Server receives the request through the receiveMessage () method, and enters into the attest _ and _ permit phase, that is: verifying the legality of the request, generating attestmation and permission for the legal request, adding attestmation to a related chain, recording the permission to the server locally, then replying the permission to the owner through a sendMessage () method, sending an 'end' mark, and ending the permission content. The format of permission is PERMITT _ ACT # ownerID # blockID # nonce # signature, where "#" is a delimiter. ACT, owerID, blockID and nonce have the same values as the request, and signature is a signature of CSP.

And fourthly, receiving the permission. Owner receives the permission sent back by server through a receivepermission message () method, and the internal program verifies whether the permission signature is correct.

And fifthly, uploading and updating. If the owner internal program confirms that the permission signature is correct, the updated content is presented in a file form. At this time, the upload button of the owner interface is activated, and the update content can be uploaded by the SendMessage () method by clicking.

Sixthly, updating JAR. The Server respectively receives the update content and the signature uploaded by the owner after verifying that the update content and the signature are respectively received through the receiveFiles () method and the receiveMessage () method. The server verifies the message signature and if correct, updates the corresponding information. The entire process of Owner updating the information ends.

(2) As shown in fig. 6, the data access process of the Client includes:

and (1) initializing. And loading a certificate, creating and initializing an SSLContext instance, and establishing a connection between the client and the server.

And sending the request. The Client sends a request field to the server through a sendMessage () method. The fixed format of the request is: ACT # clientID _ version # blockID # nonce # signature. Wherein "#" is a separator between request fields; "_" is a separator inside the user identity field, indicating that the user's identity is commonly identified by both the clientID and version parts. If data access is requested, the value of the ACT field is READ, the clientID uses the safe hashID, and the version is the version number of the current hashID; if the identity update is requested, the value of the ACT field is VERSION, the clientID uses a specific userID, and the VERSION still has the VERSION number of the current hashID of the user. The nonce is a 6-bit random number and the signature is the signature of the client.

And thirdly, verifying the request. The Server receives the request through a receiveMessage () method, extracts the user identity and checks whether the signature of the request is correct. For the data access request, it is also checked whether the request is from a legitimate user.

Fourthly, the request is replied. If the signature is correct and the user main body in the data access request is a legal user, the program of the server generates attesting and permission, adds attesting to the related chain, records the permission locally to the server, then replies the permission to the client through a sendMessage () method, and then sends the requested data. If the server program identifies that the client is not a legal user, the server generates the alias information, the alias information is stored and sent to the client through sendMessage (), and the sending of the information is finished by end.

Receiving the recovery. The Client receives the permission and the data sent back by the server through a receiveServerData () method, or receives the alias, and the internal program continues to process the alias.

(3) As shown in fig. 7, the log query process of Owner includes:

and (1) initializing. And loading the certificate, creating and initializing an SSLContext instance, and establishing a connection between the owner and the server.

And sending the request. Owner actively sends a request field to a server through a SendMessage () method, the fixed format of the request is ACT # owerID # target # nonce # signature, and "#" is the separation between fields. If the query is a data ACCESS query, the value of ACT is ACCESS, and the value of target is filename; if the file is a specified file or a user behavior QUERY, the ACT value is QUERY, the target value is userInfo & dataInfo, and "&" is a connector inside the target field.

And thirdly, replying the request. The Server receives the request through the receiveMessage () method, and executes the corresponding program according to the content of the request, namely: verifying the legality of the request, generating attesting and permission for the legal request, adding attesting to a related chain, recording the permission to the server locally, then replying the permission to the owner through a sendMessage () method, and sending an end mark to end the content of the permission.

Fourthly, replying to the inquiry. The JAR program of the Server also executes the query process and temporarily stores the query result in a local file. Subsequently, the server sends the query result in the format of "FILE" + query result FILE content + "FILE-END" through the sendMessage () method.

Receiving permission. Owner receives the permission sent back by server through receivePermissionMessage () method, then continues to receive the inquiry result sent from the communication link through receiveFile () method, and stops after receiving 'FILE-END'. The internal program then verifies whether the permission and the signature of the query result are correct. If the query is correct, a view button of the owner interface is activated, and a readable query result can be obtained by clicking. The whole process of the owner query access log ends.

Further, in another specific embodiment of the present invention, the step of implementing JAR-based cloud data security management and audit includes:

(1) owner's block update. Since data is stored in blocks at the server side, the winner can only upload the affected data blocks when the data is modified in a small range. And the Owner records the number of the data block needing to be rewritten in the request, and in the uploading updating process, the modified plaintext data is symmetrically encrypted by an Advanced Encryption Standard (AES) at the Owner end and then is sent to the server. When the Server updates the data block, the new encrypted data block is used to replace the original data, and for each new block, the Server program also updates the block Hash information in the Server JAR.

(2) Owner's user list update. Owner authorizes new users or revokes access rights of existing users by updating the user list. The first line of the user list is a sharing group information summary, which comprises a version number, a total number of users and a legal number of users. From the second row, the record of each row represents the authority of the user whose userID is the row number minus 2, for example, the record of the second row represents the authority of the user whose userID is 0. If the user is legal, the record value is the hashID of the user, and if the user is illegal, the record value is REVOKED. In the uploading updating process, a new user list is sent to the server, and the server replaces a user list record in the server JAR with the content of the new user list.

(3) For legal data uploading or downloading requests, the attest _ and _ permit module of the Server can generate corresponding permission only after the whole content of makeAttest () is executed correctly, which ensures that all data modifications have log records to be checked. In the makeAttest () method,

i. firstly, extracting an ACT, data information and a request main body from a request by a program;

calculating the hash of the corresponding data according to the data information, and recording the hash as a blockHash;

adding time, calculating chainHash and a signature, and generating an attesting in a fixed format;

finally, attestion is stored locally, appended to existing logs.

(4) And authenticating the user identity of the Server. The Server sends back a permission or a initiative message to the user after authenticating the user identity. In the structure of the messages of permission and initiative, "#" is a delimiter between fields; "_" is a separator inside the user identity field, with the concatenated characters forming together a complete permission or default field. The user identity, data and nonce fields of Permission and denoial are all consistent with the request.

If the request is a data access, the permission format is:

PERMIT_READ#hashID_version#blockID#nonce#signature。

if the request is an identity update, the permission format is:

PERMIT_VERSION#userID_version#blockID#nonce#signature。

and if the user main body in the data access request is not a legal user, the sever generates the personal information. If the user main body in the request provides the latest version of hashID and the identity does not exist in the user list, the format of the alias information is as follows:

REF_READ#FORBIDDEN_hashID_userVer#dataIndex#nonce#signature。

if the user agent in the request uses the hash ID of the expired version, the format of the alias information is as follows:

REF_READ#OBSOLETE_hashID_userVer#dataIndex#nonce#signature。

(5) client's data access in receiving a reply, the permission is followed by the encrypted data blocks specified in the request. The client program is decrypted by using the key information in the program, and the decrypted data block is displayed for the user. If the information is the alias information with OBSOLELETE field, the program prompts the user to request the server for identity update; if the personal information with FORBIDDEN field is received, the program will indicate no access right and then automatically exit.

(6) And updating the identity of the Client. In the process of receiving the reply, the data following the permission is the latest version hashID encrypted by the public key of the user corresponding to the userID in the request, and the client JAR decrypts the message by using the private key of the user to obtain the data with the format: userID # version # hashID, "#" is a separator between fields. And the program verifies whether the userID obtained by decryption is consistent with the userID in the client JAR, and after verification, the program replaces the local userID file with the received reply message.

(7) And querying data access. In the corresponding request, the value of ACT is ACCESS. The program of the Server extracts the target file name in the request, and then queries the attribute and the dental record corresponding to the file. In authentication, the record with "READ" as the ACT value is successful data access, and the summary of the data access request which is not allowed is stored in the alias. The statistical content of the Server comprises: the number of times the file is accessed, the total number of users accessing the file, the last visitor, the last access time, the number of times the file is denied access, and the last time the file is denied access. The statistical content is stored in an accessReport file in clear text and is sent to the owner. Through the above, the data owner can grasp the case that the data is legally and illegally used within one time period.

(8) Queries specify files or user behavior. In the corresponding request, the value of ACT is QUERY. The program of the Server extracts the target file name and the target user name in the request, retrieves all relevant records in the attribute, then generates an attribute file, and sends the attribute file to the owner. Owner's program translates this file into a format that is easy to read, including: and deleting verification information such as the signature and converting the hashID of the user into the userID.

According to the cloud data security management and audit device based on JAR provided by the embodiment of the invention, the functions of JAR-based data access control, data operation-oriented log generation, log integrity maintenance, log-based security audit and the like can be realized, an automatic and reliable log recording mechanism is provided through an access strategy of JAR, a record is generated and protected from key abuse attack in data access, the authenticity and integrity of the record are effectively realized, and the security of the data is effectively improved.

In the description of the present invention, it is to be understood that the terms "central," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," "circumferential," and the like are used in the orientations and positional relationships indicated in the drawings for convenience in describing the invention and to simplify the description, and are not intended to indicate or imply that the referenced devices or elements must have a particular orientation, be constructed and operated in a particular orientation, and are therefore not to be considered limiting of the invention.

Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "a plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.

In the present invention, unless otherwise expressly stated or limited, the terms "mounted," "connected," "secured," and the like are to be construed broadly and can, for example, be fixedly connected, detachably connected, or integrally formed; can be mechanically or electrically connected; they may be directly connected or indirectly connected through intervening media, or they may be connected internally or in any other suitable relationship, unless expressly stated otherwise. The specific meanings of the above terms in the present invention can be understood by those skilled in the art according to specific situations.

In the present invention, unless otherwise expressly stated or limited, the first feature "on" or "under" the second feature may be directly contacting the first and second features or indirectly contacting the first and second features through an intermediate. Also, a first feature "on," "over," and "above" a second feature may be directly or diagonally above the second feature, or may simply indicate that the first feature is at a higher level than the second feature. A first feature being "under," "below," and "beneath" a second feature may be directly under or obliquely under the first feature, or may simply mean that the first feature is at a lesser elevation than the second feature.

In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention, and that variations, modifications, substitutions and alterations can be made to the above embodiments by those of ordinary skill in the art within the scope of the present invention.

Claims (3)

1. A cloud data security management and audit device based on JAR is characterized by comprising the following components:

the cloud data management module is used for reading and writing and updating data by a data owner, updating a user list and performing log audit operation, wherein malicious behaviors are detected and terminated before an unauthorized user views plaintext data, and when someone accesses data of a server, automatic log recording is triggered through an access policy of JAR (JAR), wherein operation logs of different data are recorded in a public log file, and the access policy of JAR comprises the following steps: the server side checks the request authority, generates a log in a preset format, and after the log in the preset format is added to the existing log, the server generates a corresponding permission or alias message after the complete correct execution of all the contents of the generated log in the preset format is completed, so as to ensure that all data modification has log records; users in a data sharing environment are defined as three different identities: the data Owner Owner, the service provider CSP and the sharing User define the behaviors of different identities according to the User identity, specifically:

data owner: JAR and resource file constitute by an Owner, Owner encrypts data, and for data generation for access and management JAR, Owner's function has: updating data files, updating user access control lists, auditing server data and acquiring server activity data; the Owner has writing authority to the data, and can update the information stored in the cloud, and the information updated by the Owner is further divided into 2 types: the data block stored in the Server end is consistent with the user list in the Server JAR, and the updating processes of the two types of information are consistent; wherein, the information updating process of the owner comprises the following steps: initializing, sending a request, replying the request, receiving permission, uploading update and updating JAR, specifically:

firstly, initializing: loading a certificate, creating and initializing an SSLContext instance, and establishing connection between an owner and a server;

secondly, sending a request: the Owner actively sends a Request message to the server through a SendMessage () method, wherein the fixed format of the Request is as follows: ACT # owerID # dataID # nonce # signature, wherein "#" is a delimiter, dividing the request into 5 fields; if the data block is requested to be updated, the value of the ACT field is UPDATE, and the value of the dataID field is filename _ blockID; if the user list is requested to be updated, the value of the ACT field is ACL, the value of the dataID field is filename _ user _ version, wherein _ "is a separator inside one field of request, nonce is a 6-bit random number, and signature is the signature of owner;

③ replying the request: the Server receives the request through a receiveMessage () method, enters an attest _ and _ PERMIT stage, verifies the legitimacy of the request, generates attesting and permission for the legal request, adds the attesting to a related chain, records the permission to the Server locally, then replies the permission to the ower through a sendMessage () method, sends an 'end' mark, the content of the permission ends, the format of the permission is PERMIT _ ACT # owerID # blockID # notice # signature, wherein, '#' is a separator; ACT, owerID, blockID and nonce have the same values as the request, and signature is a signature of CSP;

receiving permission: owner receives the permission sent back by server through a receivepermission message () method, and an internal program verifies whether the permission signature is correct;

uploading and updating: if the inside program of the owner confirms that the permission signature is correct, then the updated content is presented in a file form, at this time, an upload button of the owner interface is activated, and the updated content can be uploaded by a SendMessage () method by clicking;

updating JAR: after verifying that the Server respectively receives the updated content and the signature uploaded by the Owner through the receiveFiles () method and the receiveMessage () method, the Server verifies the message signature, if the message signature is correct, the corresponding information is updated, and the whole process of updating the information by the Owner is finished;

sharing users: the client side consists of a client _10.JAR and a resource file, and the client uses the JAR corresponding to the role of the client side to access the data but cannot acquire the complete authority of the data; the client functions include: requesting data and updating versions, wherein the deployment of the Client JAR is mainly completed by public network transmission, a method of writing a data decryption key in a Client JAR code is adopted, and a mode of transmitting an asymmetric encryption key through symmetric encryption is replaced by a protection mechanism of Java for the code, so that the data encryption performance of the combination of symmetric-asymmetric encryption is achieved; the legal client has the right to read the data, and in the data requesting module, the client sends a request to the server and obtains a data file uploaded by a file owner on the server after the server is authenticated; the Client applies for accessing a certain file or a part of the file, and updates the identity of the Client to assist safe data access; when the file owner updates the JAR version, the client updates the JAR file of the client through the version updating module, and obtains a new HashID of the client after the client is authenticated by the server;

the service provider: JAR is a functional program of the server, provides a cloud environment for data storage, manages access and update of the data through JAR corresponding to own roles, and records log information; the service functions for the client are as follows: the data sending service and the client updating service have the following service functions for a data owner: file data updating service, user access control list updating service, user activity counting service and server activity counting service;

and the log security audit module is used for storing the logs on the CSP through the log format of the Attestation, ensuring the security of the logs through the whole structure of the chain-shaped logs, and inquiring data access or inquiring a specified file or user behavior through the access strategy of the JAR, wherein when the content of each Attestation is changed, the whole log chain is broken, so that the malicious behavior threatening the data security is positioned according to the broken position of the Hash chain.

2. The JAR-based cloud data security management and auditing apparatus according to claim 1, where the Attestation's log format is as follows:

wherein the log information is maintained at the service provider in clear text.

3. The JAR-based cloud data security management and auditing apparatus according to claim 1, where the chain-like log overall structure is as follows:

ChainHash＝hash(AttestBody,prevChainHash)。

Images