WO2025102725A1 - File access method and apparatus, file access permission determination method and apparatus, and related devices - Google Patents

Abstract

Provided in the embodiments of the present application are a file access method and apparatus, and a related device, which are applied in the technical field of data security. In the method, a first device acquires a file access request which is triggered by a request object for a target file, acquires permission policy information of the request object, and executes access control on the access of the request object to the target file according to the permission policy information of the request object. The permission policy information of the request object is determined on the basis of file label policy information of the target file and the file access request of the request object. In this way, a policy corresponding to a file label, i.e., file label policy information, can be used, so as to realize fine-grained data protection with a file as the granularity. Further provided in the present application are a file access permission determination method and apparatus, and a related device, which are applied to a second device. The second device decrypts the file label policy information, and determines the permission policy information, such that the degree of security of the file label policy information can be improved, thereby improving the degree of security of the target file.

Description

File access method, file access permission determination method, device and related equipment

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 16, 2023, with application number 202311534765.9 and invention name “File access method, file access permission determination method, device and related equipment”, the entire contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the field of data security technology, and in particular to a file access method, a file access permission determination method, a device, and related equipment.

Background Art

In the process of using data, malicious attacks such as leakage, tampering and extortion often occur, which poses a security risk. It is necessary to adopt certain security protection methods to protect data and prevent data from being attacked.

At present, the attack detection method is usually adopted to timely discover and deal with attacks to improve the security of data. However, there are many types of attacks, and it is difficult to discover various attacks through detection methods, and the effect of defending against attacks cannot meet the needs of data security.

Summary of the invention

The present application provides a file access method and a file access permission determination method, aiming to achieve data protection of files at the file granularity when users access files. In addition, the present application also provides corresponding devices, computing devices, computer-readable storage media and computer program products.

In a first aspect, the present application provides a file access method. The method is applied to a first device. The first device obtains a file access request for a target file triggered by a request object. The file access request includes access operation information, and the access operation information is used to describe the access operation that the request object needs to perform on the target file. The request object is a user who requests to access the target file. The request object is a system user of an operating system program of the first device, or an application user of an application program. The first device obtains permission policy information of the request object. The permission policy information is determined based on the file tag policy information of the target file and the file access request, and is used to indicate the permission of the request object to operate the target file. The file tag policy information corresponds to the file tag of the target file, and is used to describe the control policy for the access operation on the target file. The file tag includes one or more security dimension tags. The file tag is set by the manager of the target file or generated based on the file attributes of the target file. The first device performs access control on the request object to access the target file according to the permission policy information. Based on the file tag, data protection with file granularity can be realized, and the security of file access can be improved. File-centric data security protection can reduce security issues such as file tampering and leakage to a certain extent, and improve the protection of file integrity and confidentiality.

In a possible implementation, the first device generates the permission policy information of the request object according to the file tag policy information of the target file and the file access request of the request object.

In a possible implementation, the second device generates permission policy information of the request object. The first device sends a permission request for the target file to the second device. The permission request includes the file label policy information of the target file, the access operation information and the public key of the request object. The file label policy information of the target file is encrypted by the public key of the target file. The first device obtains the permission information fed back by the second device. The permission information includes a first ciphertext. The first ciphertext includes a ciphertext obtained by encrypting the permission policy information of the request object using the public key of the request object. The permission policy information of the request object is obtained by the second device using the private key of the target file, the file label policy information of the target file and the access operation information. The first device decrypts the first ciphertext using the private key of the request object to obtain the permission policy information of the request object. The second device decrypts the file label policy information of the target file using the private key of the target file and determines the permission policy information. The first device does not need to have the private key of the target file, thereby reducing the security problem of the file label policy information being tampered with after the private key of the target file possessed by the first device is leaked, improving the security level of the file label policy information, and thereby improving the security level of the target file. Furthermore, the file tag policy information and permission policy information exchanged between the first device and the second device are both encrypted information, thereby reducing the risk of information leakage during the interaction between the first device and the second device.

In one possible implementation, the target file is encrypted using a file encryption key. The file encryption key is encapsulated in the file tag policy information of the target file. The permission information obtained by the first device also includes a second ciphertext obtained by encrypting the file encryption key using the public key of the requesting object. Before executing access control on the requesting object's access to the target file according to the permission policy information of the requesting object, if it is determined based on the permission policy information that the requesting object has access rights, the first device uses the file encryption key to decrypt the target file. The file encryption key is obtained by the first device decrypting the second ciphertext using the private key of the requesting object. Encrypting each file in this way improves the file's security. Security level. Using a file's unique key can also effectively reduce the security threat to multiple files caused by key leakage when encrypting with a unified key.

In a possible implementation, the first device further obtains the file tag of the target file, and generates the file tag policy information of the target file based on the file tag and the tag policy template. In this way, the file tag policy information can be automatically generated according to the file tag of the target file and using the tag policy template.

In one possible implementation, the tag policy template is obtained from the second device.

In a possible implementation, the user who sets the file label policy information can also customize and update the file label policy information. The first device obtains the customized label policy information for the target file; and uses the customized label policy information to update the file label policy information of the target file. In this way, the customized adjustment of the file label policy information can be achieved, the flexibility of configuring the file label policy information is improved, and it is convenient to configure the file label policy information that meets the file protection requirements for the file.

In a possible implementation manner, the first device is a host.

In a possible implementation manner, the method is applied to an application layer of the first device, or to a system layer of the first device, or to an application layer and a system layer of the first device.

In a possible implementation, the first device is a storage device. The request object triggers a file access request through a third device connected to the first device. The first device obtains a file access request for a target file sent by the third device and triggered by the request object. The file access request is encapsulated by the third device using a security protocol. The first device unpacks the file access request using the security protocol. In this way, the security protocol can be used to protect the security of the file access request, thereby improving the security of the file.

In a possible implementation, the first device generates feedback file information according to the permission policy information of the request object and the access operation information of the request object, and sends the feedback file information encapsulated by the security protocol to the third device. The security protocol is used to improve the security of information transmitted between the first device and the third device.

In a possible implementation, the method is applied to a system layer of a first device, and the application is a preset security application.

In a second aspect, the present application provides a method for determining file access rights. The method is applied to a second device. The second device obtains a permission request for a target file sent by the first device. The permission request includes file label policy information of the target file, access operation information, and the public key of the request object. The file label policy information is encrypted by the public key of the target file and is used to describe the control policy for the access operation on the target file. The file label policy information corresponds to the file label of the target file. The file label is set by the manager of the target file or generated based on the file attributes of the target file. The file label includes one or more labels of security dimensions. The request object is the system user of the operating system program of the first device, or the application user of the application program. The second device decrypts the file label policy information using the private key of the target file, and determines the permission policy information of the request object based on the file label policy information and the access operation information of the target file. The permission policy information is used to describe the permission policy of the request object for the access operation of the target file. The second device encrypts the permission policy information of the request object using the public key of the request object to obtain the first ciphertext, and sends the permission information including the first ciphertext to the first device. The second device uses the private key of the target file to decrypt the file label policy information of the target file and determine the permission policy information, which can avoid the first device having the private key of the target file, reduce the security issues caused by the leakage of the private key of the target file possessed by the first device, improve the security of the file label policy information, and thus improve the security of the target file. In addition, the file label policy information and permission policy information exchanged between the first device and the second device are both encrypted information, which improves the security of the information in the interaction process between the first device and the second device and reduces the risk of information leakage during the interaction process between the first device and the second device.

In one possible implementation, the target file is encrypted using a file encryption key. The file encryption key is encapsulated in the file tag policy information of the target file. The second device also uses the public key of the request object to encrypt the file encryption key to obtain a second ciphertext. The permission information sent by the second device to the first device also includes the second ciphertext. The second device sends the encrypted file encryption key to the first device, so that the first device can decrypt the target file based on the file encryption key and control the access of the request object. Using a key unique to the target file can also effectively avoid security threats to multiple files caused by key leakage caused by encryption using a unified key, thereby improving the data security of the target file.

In a possible implementation, the second device further provides the first device with a label policy template. In response to obtaining the label policy template acquisition request sent by the first device, the second device sends the label policy template to the first device.

In a possible implementation manner, the second device is a server or a management device.

In a third aspect, the present application provides a file access device, which is applied to a first device, and includes: an acquisition module for acquiring a file access request for a target file triggered by a request object, the file access request including access operation information, and the access operation information is used to obtain a file access request for a target file triggered by a request object. The method comprises the following steps: a first device for describing an access operation that a requesting object needs to perform on a target file; the requesting object is a system user of an operating system program of a first device, or an application user of an application program; a processing module for obtaining permission policy information of the requesting object, the permission policy information being determined based on file tag policy information of the target file and a file access request; the file tag policy information corresponds to a file tag of the target file, the file tag policy information is used to describe a control policy for access operations to the target file, and the permission policy information is used to indicate the permission of the requesting object to operate the target file; the file tag includes one or more security dimension tags, the file tag is set by the administrator of the target file or generated based on the file attributes of the target file; and a control module for executing access control on the requesting object's access to the target file according to the permission policy information.

In a possible implementation, the processing module is specifically configured to generate permission policy information of the request object according to the file tag policy information of the target file and the file access request of the request object.

In one possible implementation, the processing module is specifically used to send a permission request for a target file to a second device, where the permission request includes file label policy information of the target file, access operation information, and a public key of a requesting object, where the file label policy information of the target file is encrypted by the public key of the target file; obtaining permission information fed back by the second device, where the permission information includes a first ciphertext, where the first ciphertext includes a ciphertext obtained by encrypting the permission policy information of the requesting object using the public key of the requesting object, where the permission policy information of the requesting object is processed by the second device using a private key of the target file, the file label policy information of the target file, and the access operation information; decrypting the first ciphertext using the private key of the requesting object to obtain the permission policy information of the requesting object.

In one possible implementation, the target file is encrypted using a file encryption key, which is encapsulated in the file tag policy information of the target file. The permission information also includes a second ciphertext encrypted by the file encryption key using the public key of the requesting object. The processing module is also used to decrypt the target file using the file encryption key if it is determined, based on the permission policy information, that the requesting object has access rights. The file encryption key is obtained by decrypting the second ciphertext using the private key of the requesting object.

In a possible implementation, the acquisition module is further used to acquire the file tag of the target file; the generation module is used to generate the file tag policy information of the target file based on the file tag and the tag policy template.

In one possible implementation, the tag policy template is obtained from the second device.

In a possible implementation, the acquisition module is further used to acquire custom label policy information for the target file; the generation module is further used to update the file label policy information of the target file using the custom label policy information.

In a possible implementation manner, the first device is a host.

In a possible implementation manner, the apparatus is applied to an application layer of the first device.

In a possible implementation manner, the apparatus is applied to a system layer of a first device.

In a possible implementation manner, the application is a preset security application.

In one possible implementation, the first device is a storage device, and the acquisition module is specifically used to obtain a file access request for a target file sent by a third device and triggered by a request object, and the file access request is encapsulated by the third device using a security protocol; and the file access request is unpacked using the security protocol.

In a possible implementation, the control module is specifically used to generate feedback file information according to the permission policy information of the request object and the access operation information of the request object, and send the feedback file information encapsulated by the security protocol to the third device.

In a fourth aspect, the present application provides a device for determining file access rights, which is applied to a second device, and the device includes: an acquisition module, which is used to obtain a permission request for a target file sent by a first device, the permission request includes file label policy information of the target file, access operation information and a public key of the request object, the file label policy information is encrypted by the public key of the target file, the file label policy information corresponds to the file label of the target file, the file label policy information is used to describe the control policy for the access operation on the target file, the file label includes one or more security dimension labels, the file label is set by the administrator of the target file or generated based on the file attributes of the target file, the request object is the system user of the operating system program of the first device, or the application user of the application program; a decryption module, which is used to decrypt the file label policy information using the private key of the target file; a determination module, which is used to determine the permission policy information of the request object based on the file label policy information and the access operation information of the target file, the permission policy information is used to describe the permission policy of the request object for the access operation of the target file; an encryption module, which is used to encrypt the permission policy information of the request object using the public key of the request object to obtain a first ciphertext; a sending module, which is used to send the permission information to the first device, the permission information including the first ciphertext.

In one possible implementation, the target file is encrypted using a file encryption key, and the file encryption key is encapsulated in the file tag policy information of the target file. The encryption module is also used to encrypt the file encryption key using the public key of the request object to obtain a second ciphertext, and the permission information also includes the second ciphertext.

In a possible implementation, the sending module is further configured to send the label policy template to the first device in response to obtaining a label policy template acquisition request sent by the first device.

In a possible implementation manner, the second device is a server or a management device.

In a fifth aspect, the present application provides a computing device cluster, the computing device cluster includes at least one computing device, each computing device includes a processor and a memory; the memory is used to store instructions, and when the computing device cluster is running, the processor in each computing device executes the instructions stored in the memory, so that the computing device cluster executes the file access method in the above-mentioned first aspect or any possible implementation of the first aspect, or executes the file access permission determination method in the above-mentioned second aspect or any possible implementation of the second aspect. It should be noted that the memory can be integrated into the processor or can be independent of the processor. Each computing device may also include a bus. The processor is connected to the memory via a bus. The memory may include a readable memory and a random access memory.

In a sixth aspect, the present application provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computing device cluster (the computing device cluster includes at least one computing device), the computing device cluster executes the file access method in the above-mentioned first aspect or any possible implementation of the first aspect, or executes the file access permission determination method in the above-mentioned second aspect or any possible implementation of the second aspect.

In the seventh aspect, the present application provides a computer program product comprising instructions, which, when running on a computing device cluster (the computing device cluster includes at least one computing device), enables the computing device cluster to execute the file access method in the above-mentioned first aspect or any possible implementation of the first aspect, or execute the file access permission determination method in the above-mentioned second aspect or any possible implementation of the second aspect.

Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1a is a schematic diagram of a scenario provided in an embodiment of the present application;

FIG1b is a schematic diagram of another scenario provided in an embodiment of the present application;

FIG1c is a schematic diagram of an interaction between a first device and a second device provided in an embodiment of the present application;

FIG2a is a schematic diagram of another scenario provided in an embodiment of the present application;

FIG2b is a schematic diagram of another scenario provided in an embodiment of the present application;

FIG2c is a schematic diagram of another interaction between a first device and a second device provided in an embodiment of the present application;

FIG3a is a schematic diagram of a scenario provided in an embodiment of the present application;

FIG3b is a schematic diagram of another scenario provided in an embodiment of the present application;

FIG3c is a schematic diagram of another interaction between a first device and a second device provided in an embodiment of the present application;

FIG4a is a schematic diagram of another scenario provided in an embodiment of the present application;

FIG4b is a schematic diagram of another scenario provided in an embodiment of the present application;

FIG4c is a schematic diagram of another interaction between a first device and a second device provided in an embodiment of the present application;

FIG5 is a schematic diagram of a flow chart of a file access method provided in an embodiment of the present application;

FIG6 is a flow chart of another file access method provided in an embodiment of the present application;

FIG. 7 is a schematic diagram of a process for generating file tag strategy information for a target file provided by an embodiment of the present application;

FIG8 is a schematic diagram of a file tag strategy provided by an embodiment of the present application;

FIG9 is a schematic diagram of another process of generating file tag strategy information of a target file provided by an embodiment of the present application;

FIG10 is a schematic diagram of the structure of a file access device provided in an embodiment of the present application;

FIG11 is a schematic diagram of the structure of a device for determining file access rights provided in an embodiment of the present application;

FIG12 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

FIG13 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

FIG. 14 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application.

DETAILED DESCRIPTION

The scheme in the embodiments provided in this application will be described below in conjunction with the drawings in this application.

The terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances. This is just a way of distinguishing objects with the same attributes when describing the embodiments of this application.

Data is a relatively important asset, containing important information of individuals or enterprises. In the process of using data, it is necessary to prevent data from being attacked to avoid data leakage, data tampering or data unavailability. At present, attack detection algorithms are usually built in dimensions such as network, host and storage. Detection algorithms are used to detect attack behaviors in a timely manner and process them to maintain data security. However, the attack behaviors that can be detected by the detection algorithm are limited. It can only identify currently known attack behaviors and it is difficult to detect unknown attacks. There are still security risks. In addition, the detection algorithm has detection errors, which may affect the normal operation of the business that processes data. The method of using detection algorithms to detect attacks is difficult to meet the needs of data security.

Based on this, an embodiment of the present application provides a file access method applied to a first device. The first device obtains a file access request including access operation information for a target file triggered by a request object. The first device obtains permission policy information of the request object. Among them, the permission policy information of the request object is determined based on the file tag policy information of the target file and the file access request of the request object. The file tag policy information corresponds to the file tag of the target file. The file tag policy information is used to describe the control policy for the access operation on the target file. The first device performs access control on the request object's access to the target file according to the permission policy information. The use of file tag policy information can achieve security protection for data with file as the granularity. In this way, data-centric security protection is achieved, which can reduce the security risks of tampering, leakage and extortion faced by files to a certain extent. In addition, the file tag can be configured based on the security protection requirements of the file, thereby achieving flexible configuration of file tag policy information to meet the security requirements of different files.

The embodiments of the present application do not limit the deployment mode of the file access method and the file access permission determination method. As some examples, referring to Figures 1a to 4c, the embodiments of the present application provide four application scenario schematic diagrams.

As an example, referring to FIG1a, the file access method provided in the embodiment of the present application can be applied to a tag policy client or a tag policy software development kit (Software Development Kit, SDK), and deployed in the application of the first device, that is, deployed in the application layer of the first device. The first device is, for example, a host. The request object requesting access to the target file can be an application user of the application of the first device, or a system user of the operating system program of the first device. The scenario shown in FIG1a can be, for example, a scenario in which the application has an independent user system. The application layer of the first device implements control over access to files by the application user of the application of the first device or the system user of the operating system program.

In one possible implementation, the application layer of the first device includes a tag policy client or a tag policy software development kit, which obtains a file access request for a target file triggered by a request object, generates permission policy information of the request object based on the file tag policy information of the target file and the file access request of the request object, and performs access control on the request object's access to the target file according to the permission policy information.

In another possible implementation, as shown in FIG1b, the first device interacts with the second device to implement access control to the target file. An embodiment of the present application provides a method for determining file access rights. The method for determining file access rights can be applied to a tag policy service, or a tag policy management component, and deployed on a second device. The second device is, for example, a server. Referring to FIG1c, this figure is a schematic diagram of the interaction between a first device and a second device provided in an embodiment of the present application. The application layer of the first device includes a tag policy client or a tag policy software development kit, including an initialization module, a file tag generation module, a file tag policy information generation module, an access request processing module, and an access operation control module. The tag policy service of the second device, or the tag policy management component, includes an initialization module and a permission information determination module. The initialization module of the first device interacts with the initialization module of the second device to implement initialization authentication, that is, identity authentication and certificate issuance. The file tag generation module of the first device is used to generate a file tag based on a user trigger, or automatically generate a file tag, and send a tag policy template acquisition request to the second device to obtain the tag policy template fed back by the second device. The file tag policy information generation module of the first device generates file tag policy information of the target file based on the file tag and the tag policy template. The access request processing module of the first device is used to send a permission request to the permission information determination module of the second device based on the acquired file access request triggered by the request object. The permission information determination module of the second device parses the file tag policy information based on the permission request, determines the permission policy information of the request object, and sends permission information including the permission policy information of the request object encrypted using the public key of the request object to the first device. The access operation control module of the first device is used to control the access operation of the request object based on the permission policy information of the request object included in the permission information.

As another example, referring to FIG2a, the file access method provided in the embodiment of the present application can be applied to a tag kernel module and deployed in the operating system program (OS) of the first device, that is, deployed in the system layer of the first device. The first device is, for example, a host. Among them, the request object requesting access to the target file can be the system user of the operating system program of the first device, or the application user of the application. The scenario shown in FIG2a is, for example, a scenario in which the application and the OS have a unified user system, or the user system of the application can be synchronized to the user system of the OS, or the application does not have an independent user system. The system of the first device The system layer implements the control of application users of application programs or system users of operating system programs accessing files.

In one possible implementation, the system layer of the first device includes a tag kernel module that obtains a file access request for a target file triggered by a request object, generates permission policy information of the request object based on the file tag policy information of the target file and the file access request of the request object, and performs access control on the request object's access to the target file according to the permission policy information.

In another possible implementation, as shown in FIG2b, the first device interacts with the second device to implement access control on the target file. The file access permission determination method provided in the embodiment of the present application can be applied to a tag policy service, or a tag policy management component, deployed on a second device. The second device is, for example, a server. As shown in FIG2c, this figure is a schematic diagram of another interaction between a first device and a second device provided in an embodiment of the present application. The system layer of the first device includes a tag policy client or a tag policy software development kit, including an initialization module, a file tag generation module, a file tag policy information generation module, an access request processing module, and an access operation control module. The tag policy service of the second device, or the tag policy management component, includes an initialization module and a permission information determination module. The interaction process between the first device and the second device is similar to the example corresponding to FIG1c above, and will not be repeated here.

As another example, referring to FIG3a, the file access method provided in the embodiment of the present application can be applied to the label kernel module, and the label policy client or the label policy SDK, and deployed in the OS and application of the first device, that is, deployed in the system layer and application layer of the first device. The first device is, for example, a host. Among them, the request object requesting access to the target file can be the system user of the operating system program of the first device, or the application user of the application. The scenario shown in FIG3a is, for example, a business scenario with high security requirements. The system layer and the application layer of the first device collaborate to implement control over access to files by the application user of the application, or the system user of the operating system program.

In one possible implementation, the tag kernel module of the first device, and the tag policy client or tag policy SDK, obtain a file access request for a target file triggered by a request object, generate permission policy information of the request object based on the file tag policy information of the target file and the file access request of the request object, and perform access control on the request object's access to the target file according to the permission policy information.

In another possible implementation, as shown in FIG. 3b, the first device interacts with the second device to implement access control to the target file. The file access permission determination method provided in the embodiment of the present application can be applied to a tag policy service or a tag policy management component deployed on the second device. The second device is, for example, a server.

Refer to Figure 3c, which is a schematic diagram of another interaction between a first device and a second device provided in an embodiment of the present application. The system layer and application layer of the first device include a label policy client or a label policy software development kit, including an initialization module, a file label generation module, a file label policy information generation module, an access request processing module, and an access operation control module. The label policy service of the second device, or the label policy management component, includes an initialization module and a permission information determination module. The interaction process between the first device and the second device is similar to the example corresponding to Figure 1c above, and will not be repeated here.

As another example, referring to FIG. 4a , the scenario shown in FIG. 4a is applicable to a storage scenario. The file access method provided in an embodiment of the present application can be applied to a tag kernel module and deployed in a first device. The first device is, for example, a storage device. The first device is also connected to a third device. The third device is, for example, a production host. A requesting object requesting access to a target file accesses the target file stored in the first device through a third device. The first device and the third device communicate via a security protocol. The first device also includes a security protocol server. The third device includes a security protocol client. The security protocol server and the security protocol client are used to encapsulate or unpack transmission information using a security protocol to achieve communication between the first device and the third device. In this way, the requesting object can complete the access operation to the target file stored in the first device on the third device.

In one possible implementation, the tag kernel module of the first device obtains a file access request for a target file triggered by a request object, generates permission policy information of the request object based on the file tag policy information of the target file and the file access request of the request object, and performs access control on the request object's access to the target file according to the permission policy information.

In another possible implementation, as shown in FIG4b, the first device interacts with the second device to implement access control on the target file. The file access permission determination method provided in the embodiment of the present application can be applied to a tag policy service, or a tag policy management component, deployed on the second device. The second device is, for example, a management device for a storage device. Referring to FIG4c, this figure is a schematic diagram of another interaction between a first device and a second device provided in an embodiment of the present application. The first device includes a tag policy client or a tag policy software development kit, including an initialization module, a file tag generation module, a file tag policy information generation module, an access request processing module, and an access operation control module. The first device also includes a security protocol server. The tag policy service of the second device, or the tag policy management component, includes an initialization module and a permission information determination module. The third device A and the third device B include a security protocol client. The first device and the second device The interaction process between the devices is similar to the example corresponding to Figure 1c above, and will not be repeated here. The security protocol client of the third device A is used to obtain the file tag selected by the user, and uses the security protocol to encapsulate the file tag and send it to the first device. The security protocol server of the first device uses the security protocol to decapsulate the file tag, and sends the file tag to the file tag generation module. The security protocol client of the third device A is used to obtain the file access request triggered by the request object, and uses the security protocol to encapsulate the file access request and send it to the first device. The security protocol server of the first device uses the security protocol to decapsulate the file access request and sends the file access request to the access request processing module. In this way, it is possible to control the access to files by the request object, that is, the application user of the application of the third device, or the system user of the operating system program.

It should be noted that the application scenarios shown in the above Figures 1a to 4c are only examples, and the application scenarios of the file access method and the file access permission determination method provided in this application are not limited to the application scenarios shown in Figures 1a to 4c.

Next, various non-limiting specific implementations of the file access method and the file access permission determination method provided by the present application are described in detail.

Referring to Fig. 5, this figure is a schematic flow chart of a file access method provided in an embodiment of the present application. The method is applied to a first device and includes S501-S503.

S501: The first device obtains a file access request for a target file triggered by a request object.

The request object is an object that requests access to a target file stored in the first device through the first device. The embodiment of the present application does not limit the identity of the request object. The request object is, for example, a user. As an example, the user is an application user of an application program of the first device, or a system user of an operating system program of the first device. In addition, the request object is, for example, a user and a program process. The program process is a process in which a user triggers a file access request.

It should be noted that in some possible implementations, the user who is the object of the request needs to pass security authentication.

In a possible implementation, a first device establishes a connection with a second device. During the initialization phase, the first device exchanges user information with the second device to complete authentication of the user. The authentication process includes two processes: identity authentication and the second device issuing a certificate to the first device. During the identity authentication process, the first device sends object information of an object involved in file access. As some examples, the first device sends user information of a user logged in to the application, or user information of a user logged in to the operating system program of the first device.

The second device authenticates the object based on the acquired object information and sends the authentication result to the first device. The first device determines the object that has passed the security authentication based on the authentication result. If the request object is already an authenticated object, the first device can determine whether the request object has passed the security authentication based on the authentication result. In the case where the request object has passed the security authentication, the first device processes the file access request for the target file triggered by the request object. If the request object has not passed the security authentication, the first device does not process the file access request for the target file triggered by the request object. If the request object is an unauthenticated object, such as a user who logs in to the first device for the first time, the first device sends the user information of the request object to the second device. The second device authenticates the request object based on the acquired user information of the request object and sends the authentication result of the request object to the first device. The first device can determine whether the request object has passed the security authentication based on the authentication result of the request object. In the case where the request object has passed the security authentication, the first device processes the file access request for the target file triggered by the request object. If the request object has not passed the security authentication, the first device does not process the file access request for the target file triggered by the request object.

In another implementation, taking the application scenarios shown in FIG. 2a and FIG. 3a as an example, the file access method provided by the embodiment of the present application is applied to the system layer of the first device. That is, the file access method is executed by the operating system program of the first device. The request object can be an application user of an application deployed by the first device. After obtaining the file access request triggered by the application user, the system layer of the first device first verifies whether the application to which the application user belongs is a safe application. For example, based on a pre-established application whitelist. The application whitelist includes information about safe applications. Determine whether the application user is an application user of an application included in the application whitelist. If the application user is an application user of an application included in the application whitelist, the first device processes the file access request for the target file triggered by the application user. If the application user is not an application user of an application included in the application whitelist, the first device does not process the file access request for the target file triggered by the request object. In this way, it is possible to implement security authentication of the application to which the application user belongs, limit applications that access files, prevent malicious processing of files by applications, such as deleting files, and improve the security of files.

The target file stored in the first device is a file that pre-configures the file label policy information. The file label policy information corresponds to the file label of the target file. The file label can be set based on the attributes of the file and the need for file protection. The file label policy information is used to describe the control policy for access operations on the target file. The file label policy information is used to indicate the permission policy that needs to be followed to access the target file. The target file is protected by the file label policy information.

The present application embodiment does not limit the configuration method of the file tag policy information of the target file. In a possible implementation method, it can be The owner or manager of the target file directly configures it. In another possible implementation, the owner or manager of the target file edits and generates it. The embodiment of the present application provides a specific implementation method for generating file tag policy information of a target file, please refer to the following for details.

The file access request includes access operation information. The access operation information includes the object information of the request object and the operation information of the request object requesting to perform an access operation on the target file. As an example, the object information of the request object may be, for example, the account information and object type of the request object. For example, the request object is a user, and the account information is the user's account. The object type may be, for example, a system user or an application user. Different types of request objects are distinguished to facilitate determining the permission policy information of different types of request objects, implement access control on different types of request objects, and improve the security of data. In some possible implementations, the object information of the request object also includes the process information of the program process that triggers the file access request, such as the process number. The operation information may include, for example, the type of access operation.

S502: The first device obtains permission policy information of the request object.

The permission policy information of the request object is used to indicate the permission of the request object to operate the target file. The permission policy information of the request object is determined based on the file tag policy information of the target file and the file access request of the request object.

The embodiments of the present application do not limit possible implementation methods for the first device to obtain permission policy information.

In a possible implementation, the first device generates permission policy information of the request object according to the file tag policy information of the target file and the file access request of the request object.

Based on the acquired access operation information, the first device determines the permission policy information related to the access operation information from the file tag policy information of the target file, and obtains the permission policy information of the request object. The permission policy information of the request object is used to indicate the permission of the request object to operate the target file.

As an example, the file label policy information of the target file includes the operations that can be performed on the target file for different security dimensions. As an example, the file label policy information of the target file includes policy information of four security dimensions: file sensitivity, access user, access process, and the business type to which the file belongs. Among them, the policy information of the sensitivity of the file includes encryption protection for top-secret files. The policy information of the access user includes that users of type U1 have all operation permissions, users of type non-U1 are denied access, users of type U2 have read and write permissions, and users of type U3 have print permissions. The policy information of the access process includes that processes of type P1 have all permissions, and processes of type non-P1 are denied access. The policy information of the business type to which the file belongs restricts the sending of files including financial data to non-financial personnel.

The access operation information includes that the user type to which the request object belongs is U1 type, and the type of access operation is a read operation. Taking the file label policy information of the above-mentioned target file as an example, the first device determines based on the access operation information and the file label policy information that the request object of type U1 has all operation permissions. The permission policy information of the request object is to have all operation permissions. As another example, the access operation information includes that the user type to which the request object belongs is U3 type, and the type of access operation is a read operation. Taking the file label policy information of the above-mentioned target file as an example, the first device determines based on the access operation information and the file label policy information that the request object of type U3 has the permission for printing operations. The permission policy information of the request object is to have the permission for printing operations.

In another possible implementation, the first device interacts with the second device to obtain the permission policy information of the request object sent by the second device. Referring to FIG. 6 , the above S502 specifically includes the following steps:

S5021: The first device sends a permission request for the target file to the second device, where the permission request includes access operation information, a public key of the request object, and file tag policy information of the target file encrypted by the public key of the target file.

After obtaining the file access request for the target file, the first device sends a permission request for the target file to the second device. The second device can determine permission information for the request object to access the target file based on the file tag policy information and access operation information of the target file.

The permission request includes the file tag policy information of the target file, the access operation information included in the file access request, and the public key of the request object. The file tag policy information of the target file is encrypted by the public key of the target file.

The file label policy information of the target file is determined in advance based on the data protection needs of the target file. The file label policy information of the target file is generated by the first device and protected by encrypting the public key of the target file. The first device does not have the private key corresponding to the public key of the target file, thereby avoiding the decryption of the file label policy information of the target file locally on the first device, and preventing the attacker from using the private key of the target file to decrypt and tamper with the file label policy information after the first device is attacked. This can improve the security of the file label policy information, thereby improving the security of the target file.

The public key of the target file can be a key set in advance by the owner of the target file, or generated based on the information of the owner of the target file. As an example, the public key of the target file is the public key of the organization to which the owner of the target file belongs, such as a company or a group. Pertains to an organization's management and access to files.

In addition, the public key of the request object can be a public key preset by the request object. The embodiment of the present application does not limit the generation method of the public key of the request object. As an example, the public key of the request object is generated based on the relevant information of the request object.

S5022: The second device obtains a permission request for the target file sent by the first device, where the permission request includes access operation information, a public key of the request object, and file tag policy information of the target file encrypted by the first public key.

S5023: The second device decrypts the file tag policy information using the private key of the target file.

The private key of the target file is the decryption key of the public key of the target file. The private key of the target file is, for example, a key pre-set by the owner of the target file, or is, for example, a key generated based on the information of the owner of the target file. As an example, the private key of the target file is, for example, the private key of the organization or institution to which the owner of the target file belongs. This makes it easy for organizations and institutions to manage files in a unified manner. The second device uses the private key of the target file to decrypt the file label policy information generated by the first device. The first device does not have the decryption key, which can avoid the problem of decryption key leakage caused by the attack on the first device, thereby improving the security of the file label policy information and thereby improving the security of the target file.

S5024: The second device determines the permission policy information of the request object based on the file tag policy information and access operation information of the target file.

The second device obtains the file tag policy information and access operation information of the target file based on the obtained permission request for the target file. The second device can determine the permission policy information related to the access operation information from the file tag policy information of the target file based on the access operation information, and obtain the permission policy information of the request object. The permission policy information of the request object is used to indicate the permission of the request object to operate the target file.

S5025: The second device encrypts the permission policy information of the request object using the public key of the request object to obtain a first ciphertext.

After determining the permission policy information of the request object, the second device uses the public key of the request object to encrypt the permission policy information of the request object to obtain the first ciphertext. The encrypted permission policy information of the request object has a high security level and can prevent the permission policy information from being maliciously obtained during the interaction between the second device and the first device to a certain extent.

S5026: The second device sends permission information including the first ciphertext to the first device.

S5027: The first device obtains the permission information fed back by the second device.

S5028: The first device decrypts the first ciphertext using the private key of the request object to obtain the permission policy information of the request object.

The embodiment of the present application does not limit the generation method of the public key of the request object and the private key of the request object. After obtaining the permission information, the first device uses the private key of the request object to decrypt the first ciphertext included in the permission information to obtain the permission policy information of the request object. The permission policy information of the request object indicates the permission of the request object to operate the target file.

By using the public key of the target file to encrypt the file label policy information, the security of the file label policy information stored in the first device can be improved. The second device decrypts the file label policy information and analyzes it to obtain the permission policy information. The first device does not need to decrypt the file label policy information locally, which can avoid the risk of an attacker using the decryption key obtained from the first device to maliciously tamper with the file label policy information, thereby improving the security of the file label policy information and further improving the security of the target file.

S503: The first device performs access control on the request object's access to the target file according to the permission policy information of the request object.

The first device can determine the permission of the request object to access the target file based on the permission policy information of the request object. The first device performs access control on the request object to access the target file according to the permission policy information of the request object.

Based on the above S501-S503 related contents, it can be known that fine-grained file label policy information and permission policy information based on files can achieve protection for target files, realize data-centric security protection, improve the protection of data integrity and confidentiality, and to a certain extent reduce the security risks of files being tampered with, leaked and blackmailed.

In some scenarios, the target file has a confidentiality requirement. The confidentiality requirement of the target file can be configured through the file label policy information of the target file. The first device determines that the target file has a confidentiality requirement based on the file label policy information generated for the target file. The first device encrypts the target file using a file encryption key. The embodiment of the present application does not limit the method for generating the file encryption key. As an example, the file encryption key is a randomly generated symmetric key. The file encryption key corresponds one-to-one to the file to be encrypted. This can improve the security of each file that needs to be encrypted, and can also ensure the security of other files when the file encryption keys of some files are cracked. In one possible implementation method, the file encryption key is encapsulated in the file label policy information of the target file, and the file label policy information of the target file is encrypted using the public key of the target file to protect the file encryption key and the file label policy information.

In the implementation method in which the second device determines the permission policy information of the request object, after obtaining the file label policy information encrypted by the public key of the target file, the second device uses the private key of the target file to decrypt the file label policy information to obtain the file label policy information and File encryption key. The second device also uses the public key of the requesting object to encrypt the file encryption key to obtain a second ciphertext. The second device sends permission information including the first ciphertext and the second ciphertext to the first device. Based on the second ciphertext of the obtained permission information, the first device can use the private key of the requesting object to decrypt the second ciphertext to obtain the file encryption key. If the first device determines that the requesting object has access rights to the target file based on the permission policy information, the target file is decrypted using the file encryption key obtained by decrypting the second ciphertext so that the requesting object can operate on the target file. In this way, further encryption processing of the target file can be achieved, thereby improving the data security of the target file.

The above is a method for implementing target file access using the file tag policy information of the target file. The following provides a possible specific implementation method for generating the file tag policy information of the target file.

See FIG. 7 , which is a schematic diagram of a process for generating file tag strategy information of a target file provided by an embodiment of the present application. The method includes S701-S703:

S701: The first device obtains a file tag of a target file.

The file tag of the target file is a tag set for the target file. The file tag includes one or more security dimension tags. It should be noted that the file tag of the target file is determined based on a tag template. The tag template is a template of a pre-set configuration file tag. As an example, the tag template includes multiple selectable file tags. The file tag of the target file is selected from the tag template.

The embodiments of the present application do not limit the manner of generating a file tag for a target file. In one possible implementation, the generation of a file tag for a target file is triggered by the manager of the target file. The manager of the target file is a user with authority to manage the target file. The manager of the target file is, for example, the owner of the target file. The user can generate a file tag by selection or input. In another possible implementation, the first device automatically generates a file tag based on the file attributes of the target file. File attributes include, for example, file type, file generation time, and file priority. As an example, a file tag for a target file is automatically generated based on a pre-set tag generation rule and the file attributes of the target file. The tag generation rule includes, for example, a correspondence between file attributes and file tags.

As an example, see Figure 8, which is a schematic diagram of a file labeling strategy provided in an embodiment of the present application. The label template includes labels of four security dimensions, namely sensitivity labels, user labels, access process labels, and outbound permission labels. Sensitivity labels include, for example, top secret, confidential, internal, public, and personal. User labels include, for example, U1 type. Access process labels include P1 type. Outbound permission labels include financial data and sales data.

Based on the user's selection instruction for the file tag, the file tag is determined from the tags included in the tag template, or the file tag is automatically generated based on the tags included in the tag template. For example, as shown in FIG8 , a top secret tag, a U1 type tag, a P1 type tag, and a financial data tag are selected from the tag template.

S703: The first device generates file tag policy information of the target file based on the file tag and the tag policy template.

The tag policy template is a policy template pre-configured by the tag policy management user. The present application embodiment does not limit the specific content of the tag policy template. As an example, the tag policy template includes policies corresponding to tags of four security dimensions: sensitivity, user, access process, and outbound permissions.

The tag policy template corresponds to the tag template. The tag policy template includes tag policy information corresponding to each tag included in the tag template.

Referring to Figure 8 as an example, the label policy template includes label policy information of four security dimensions, including label policy information corresponding to each label included in the label template. Sensitivity policy information includes: 1. Encryption for top secret or confidential files; 2. No encryption for public files; 3. Top secret files are not allowed to be printed or copied; 4. Only the user to whom they belong has the right to use personal files. User policy information includes: 1. U1 type users have all permissions; 2. Other types of users are denied access to top secret and confidential files; for public files, all types of users have all permissions. Access process policy information includes: 1. P1 type processes have all permissions; 2. Other processes are denied access to top secret or confidential files; for public files, all types of processes have all permissions. Outbound permission policy information includes: 1. Financial data can only be sent internally by financial personnel; 2. Public data does not restrict outbound permissions.

The first device obtains the tag policy information of the file tag of the target file from the tag policy template, integrates the tag policy information of the file tag, and obtains the file tag policy information of the target file.

As an example, the file tag of the target file is matched with the tag template included in the tag policy template, and the file tag policy information of the tag template consistent with the file tag of the target file is used as the file tag policy information corresponding to the file tag of the target file.

As shown in Figure 8, the first device can determine the file label policy information corresponding to the file label of the target file from the label policy template, that is, the file label policy information of the target file, including: 1. Sensitivity policy information: top secret file encryption; 2. Access user policy information: U1 type users have all permissions, and other types of users are denied access; 3. Access process policy information: P1 type processes have all permissions, and other processes are denied access; 4. Outbound permission policy information: limit outbound sending to non-financial personnel.

After obtaining the file label policy information of the target file, the first device can encapsulate the file content of the target file, the file label of the target file, and the file label policy information of the target file into a protected file. The embodiment of the present application does not limit the implementation method of encapsulating files. As an example, the file content of the target file, the file label of the target file, and the file label policy information of the target file are encapsulated into one file. As another example, the file content of the target file, the file label of the target file, and the file label policy information of the target file are respectively encapsulated into three interrelated files. The file label policy information of the target file can be encrypted by the first public key.

Based on the above S701 and S703, it can be known that the file label and file label policy information that meet the data security requirements of the target file can be configured more flexibly to achieve fine-grained security protection for the file and meet the security requirements of different files and access files for different object types. In addition, the file label policy information can be configured using file labels and label policy templates to improve the efficiency of configuring the file label policy information.

The embodiment of the present application does not limit the source of the label policy template.

In a possible implementation, the tag policy template is pre-configured in the first device.

In another possible implementation, the label policy template is obtained by the first device from the second device. Referring to FIG. 7 , the method may further include S7021 to S7023.

S7021: The first device sends a label policy template acquisition request to the second device.

The tag policy template acquisition request is used to obtain the tag policy template. The tag policy template is a policy template pre-configured by the tag policy management user. The embodiment of the present application does not limit the specific content included in the tag policy template. As an example, the tag policy template includes policies corresponding to tags of four security dimensions: sensitivity, access user, access process, and outbound permissions.

S7022: In response to obtaining the label policy template acquisition request sent by the first device, the second device sends the label policy template to the first device.

The second device stores the tag policy template.

S7023: The first device obtains the label policy template sent by the second device.

Furthermore, based on the file tag policy information generated based on the tag policy template, the file tag policy information can also be customized and adjusted.

See Figure 9, which is a schematic diagram of another process for generating file tag policy information of a target file provided by an embodiment of the present application. The method is applied to a first device and a second device, and in addition to the above S701-S703, further includes S704 and S705.

S704: The first device obtains custom tag policy information for the target file.

In one possible implementation, the first device displays an editing control for editing file label policy information. The user can input custom label policy information for the target file through the editing control. Custom label policy information, for example, includes added additional label policy information. As an example, taking the file label policy information of the target file shown in Figure 8 as an example, the additional label policy information includes newly added access user policy information: U2 type users have read permission and write permission, U3 type users have read permission, write permission and print permission, P2 type processes have read-only permission, and P3 type processes have read permission and write permission. Custom label policy information, for example, includes revised label policy information. The revised label policy information includes the label policy information that needs to be modified for the file label policy information of the target file, as well as the modified label policy information.

S705: The first device updates the file label policy information of the target file using the custom label policy information.

In this way, the target file can be flexibly adjusted based on the rapid configuration of the file label policy information of the target file, so that the generated file label policy information of the target file is more in line with the data security requirements of the target file.

In addition, in a storage scenario, as shown in FIG4a, the first device is a storage device. The storage device is connected to a third device. The third device is, for example, a production host. The production host is a host connected to the storage device and capable of accessing data stored in the storage device. The storage device and the production host interact through a security protocol. The embodiments of the present application do not limit the type of security protocol. As an example, the security protocol is a Network Attached Storage (NAS) protocol, or an Object Storage Service (OBS) protocol.

In a possible implementation, the request object uses a third device connected to the first device to access the file. The request object triggers a file access request for the target file on the third device. The third device encapsulates the file access request using a security protocol. The third device sends the encapsulated file access request to the first device. The first device unpacks the obtained file access request using the security protocol.

In addition, when performing access control on the target file accessed by the request object according to the permission policy information of the request object, the first device generates feedback file information according to the permission policy information of the request object and the access operation information of the request object. The third device obtains the feedback file information and decapsulates the feedback file information using the security protocol.

By using the security protocol to encapsulate and decapsulate the information exchanged between the first device and the third device, the security of the interaction between the first device and the third device can be improved, and the security requirements for accessing files can be met.

In the process of configuring the file tag policy information of the target file for the file of the storage device, the file tag of the target file can be generated by the user of the third device or automatically triggered by the third device. The third device uses the security protocol to encapsulate the file tag of the target file and sends the encapsulated file tag of the target file to the first device. The first device obtains the file tag of the target file encapsulated by the security protocol.

The first device decapsulates the file tag of the encapsulated target file using the security protocol to obtain the file tag of the target file.

The present application also provides a file access device 1000, which is applied to a first device, as shown in FIG10 , and includes:

an acquisition module, configured to acquire a file access request for a target file triggered by a request object, wherein the file access request includes access operation information, and the access operation information is used to describe the access operation that the request object needs to perform on the target file; the request object is a system user of an operating system program of the first device, or an application user of an application program;

A processing module is used to obtain the permission policy information of the request object, the permission policy information is determined based on the file label policy information of the target file and the file access request; the file label policy information corresponds to the file label of the target file, the file label policy information is used to describe the control policy for the access operation on the target file, and the permission policy information is used to indicate the permission of the request object to operate the target file; the file label includes one or more security dimension labels, and the file label is set by the administrator of the target file or generated based on the file attributes of the target file;

A control module is used to perform access control on the request object's access to the target file according to the permission policy information.

In a possible implementation, the processing module is specifically configured to generate permission policy information of the request object according to the file tag policy information of the target file and the file access request of the request object.

In one possible implementation, the processing module is specifically used to send a permission request for the target file to a second device, the permission request including file label policy information of the target file, the access operation information and the public key of the request object, the file label policy information of the target file being encrypted by the public key of the target file; obtaining permission information fed back by the second device, the permission information including a first ciphertext, the first ciphertext including a ciphertext obtained by encrypting the permission policy information of the request object using the public key of the request object, the permission policy information of the request object being processed by the second device using the private key of the target file, the file label policy information of the target file and the access operation information; decrypting the first ciphertext using the private key of the request object to obtain the permission policy information of the request object.

In one possible implementation, the target file is encrypted using a file encryption key, and the file encryption key is encapsulated in the file tag policy information of the target file. The permission information also includes a second ciphertext encrypted by using the public key of the request object. The processing module is also used to decrypt the target file using the file encryption key if it is determined that the request object has access rights based on the permission policy information. The file encryption key is obtained by decrypting the second ciphertext using the private key of the request object.

In a possible implementation, the acquisition module is further used to acquire a file tag of the target file;

A generating module is used to generate file tag policy information of the target file based on the file tag and the tag policy template.

In a possible implementation, the tag policy template is obtained from the second device.

In a possible implementation, the acquisition module is further used to acquire custom tag policy information for the target file;

The generating module is further used to update the file label policy information of the target file by using the custom label policy information.

In a possible implementation manner, the first device is a host.

In a possible implementation manner, the apparatus is applied to an application layer of the first device.

In a possible implementation manner, the apparatus is applied to a system layer of the first device.

In a possible implementation manner, the application is a preset security application.

In a possible implementation, the first device is a storage device, and the acquisition module is specifically used to obtain a file access request for a target file sent by a third device and triggered by a request object, and the file access request is encapsulated by the third device using a security protocol; and the file access request is unpacked using the security protocol.

In a possible implementation, the control module is specifically configured to generate feedback file information according to the permission policy information of the request object and the access operation information of the request object, and send the feedback file encapsulated by the security protocol to the third device. information.

Among them, the acquisition module, the processing module and the control module can all be implemented by software, or can be implemented by hardware. Exemplarily, the implementation of the acquisition module is introduced below by taking the acquisition module as an example. Similarly, the implementation of the processing module and the control module can refer to the implementation of the acquisition module.

As an example of a software functional unit, the acquisition module may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the acquisition module may include code running on multiple hosts/virtual machines/containers. It should be noted that the multiple hosts/virtual machines/containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts/virtual machines/containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with similar geographical locations. Generally, a region may include multiple AZs.

Similarly, multiple hosts/virtual machines/containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

As an example of a hardware functional unit, the acquisition module may include at least one computing device, such as a server, etc. Alternatively, the acquisition module may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

The multiple computing devices included in the acquisition module can be distributed in the same region or in different regions. The multiple computing devices included in the acquisition module can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the acquisition module can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

It should be noted that, in other embodiments, the acquisition module can be used to execute any step in the file access method, the processing module can be used to execute any step in the file access method, and the control module can be used to execute any step in the file access method. The steps that the acquisition module, the processing module, and the control module are responsible for implementing can be specified as needed. The full functions of the file access device are realized by respectively implementing different steps in the file access method through the acquisition module, the processing module, and the control module.

The present application also provides a device 1100 for determining file access rights, which is applied to a second device. As shown in FIG11 , the device includes:

an acquisition module, configured to acquire a permission request for the target file sent by the first device, the permission request including file label policy information of the target file, access operation information, and a public key of a request object, the file label policy information being encrypted by the public key of the target file, the file label policy information corresponding to a file label of the target file, the file label policy information being used to describe a control policy for access operations on the target file, the file label including labels of one or more security dimensions, the file label being set by an administrator of the target file or generated based on a file attribute of the target file, and the request object being a system user of an operating system program of the first device, or an application user of an application program;

A decryption module, used to decrypt the file tag policy information using the private key of the target file;

A determination module, used to determine the permission policy information of the request object based on the file tag policy information of the target file and the access operation information, wherein the permission policy information is used to describe the permission policy of the request object for the access operation of the target file;

An encryption module, used to encrypt the permission policy information of the request object using the public key of the request object to obtain a first ciphertext;

A sending module is used to send permission information to the first device, where the permission information includes the first ciphertext.

In one possible implementation, the target file is encrypted using a file encryption key, and the file encryption key is encapsulated in the file tag policy information of the target file. The encryption module is also used to encrypt the file encryption key using the public key of the request object to obtain a second ciphertext, and the permission information also includes the second ciphertext.

In a possible implementation, the sending module is further configured to send the label policy template to the first device in response to obtaining a label policy template acquisition request sent by the first device.

In a possible implementation manner, the second device is a server or a management device.

Among them, the acquisition module, decryption module, determination module, encryption module and sending module can be implemented by software, or can be implemented by hardware. Exemplarily, the implementation of the acquisition module is introduced below by taking the acquisition module as an example. Similarly, the implementation of the decryption module, determination module, encryption module and sending module can refer to the implementation of the acquisition module.

As an example of a software functional unit, the acquisition module may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the acquisition module may include code running on multiple hosts/virtual machines/containers. It should be noted that the multiple hosts/virtual machines/containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts/virtual machines/containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with similar geographical locations. Generally, a region may include multiple AZs.

Similarly, multiple hosts/virtual machines/containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

As an example of a hardware functional unit, the acquisition module may include at least one computing device, such as a server, etc. Alternatively, the acquisition module may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

The multiple computing devices included in the acquisition module can be distributed in the same region or in different regions. The multiple computing devices included in the acquisition module can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the acquisition module can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

It should be noted that, in other embodiments, the acquisition module can be used to execute any step in the method for determining file access permissions, the decryption module can be used to execute any step in the method for determining file access permissions, the determination module can be used to execute any step in the method for determining file access permissions, the encryption module can be used to execute any step in the method for determining file access permissions, and the sending module can be used to execute any step in the method for determining file access permissions. The steps that the acquisition module, decryption module, determination module, encryption module and sending module are responsible for implementing can be specified as needed. The full functions of the file access permission determination device are realized by respectively implementing different steps in the method for determining file access permissions through the acquisition module, decryption module, determination module, encryption module and sending module.

The present application also provides a computing device 1200. As shown in FIG. 12 , the computing device 1200 includes: a bus 1202, a processor 1204, a memory 1206, and a communication interface 1208. The processor 1204, the memory 1206, and the communication interface 1208 communicate with each other through the bus 1202. The computing device 1200 may be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 1200.

The bus 1202 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, FIG. 12 is represented by only one line, but does not mean that there is only one bus or one type of bus. The bus 1202 may include a path for transmitting information between various components of the computing device 1200 (e.g., the memory 1206, the processor 1204, and the communication interface 1208).

Processor 1204 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP) or a digital signal processor (DSP).

The memory 1206 may include a volatile memory, such as a random access memory (RAM). The processor 1204 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

The memory 1206 stores executable program codes, and the processor 1204 executes the executable program codes to respectively implement the aforementioned The functions of the acquisition module, the processing module and the control module are implemented to realize the file access method. That is, the memory 1206 stores instructions for executing the file access method.

Alternatively, the memory 1206 stores executable codes, and the processor 1204 executes the executable codes to respectively implement the functions of the aforementioned acquisition module, decryption module, determination module, encryption module, and sending module, thereby implementing the file access method. That is, the memory 1206 stores instructions for executing the file access permission determination method.

The communication interface 1208 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1200 and other devices or communication networks.

The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

As shown in Fig. 13, the computing device cluster includes at least one computing device 1200. The memory 1206 in one or more computing devices 1200 in the computing device cluster may store the same instructions for executing the file access method.

In some possible implementations, the memory 1206 of one or more computing devices 1200 in the computing device cluster may also store partial instructions for executing the file access method. In other words, the combination of one or more computing devices 1200 may jointly execute instructions for executing the file access method.

It should be noted that the memory 1206 in different computing devices 1200 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the file access device. That is, the instructions stored in the memory 1206 in different computing devices 1200 can implement the functions of one or more modules among the acquisition module, the processing module and the control module.

In some possible implementations, one or more computing devices in the computing device cluster can be connected via a network. The network can be a wide area network or a local area network, etc. FIG. 14 shows a possible implementation. As shown in FIG. 14 , two computing devices 1200A and 1200B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 1206 in the computing device 1200A stores instructions for executing the functions of the acquisition module. At the same time, the memory 1206 in the computing device 1200B stores instructions for executing the functions of the processing module and the control module.

The connection method between the computing device clusters shown in Figure 14 can be considered to be that the file access method provided in this application needs to process a large amount of data, so the functions implemented by the processing module and the control module are considered to be executed by the computing device 1200B.

It should be understood that the functionality of the computing device 1200A shown in FIG14 may also be accomplished by multiple computing devices 1200. Similarly, the functionality of the computing device 1200B may also be accomplished by multiple computing devices 1200.

The embodiment of the present application also provides another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similar to the connection mode of the computing device cluster described in Figures 13 and 14. The difference is that the memory 1206 in one or more computing devices 1200 in the computing device cluster can store the same instructions for executing the file access permission determination method.

In some possible implementations, the memory 1206 of one or more computing devices 1200 in the computing device cluster may also store some instructions for executing the method for determining file access permissions. In other words, the combination of one or more computing devices 1200 may jointly execute instructions for executing the method for determining file access permissions.

It should be noted that the memory 1206 in different computing devices 1200 in the computing device cluster may store different instructions for executing part of the functions of determining the file access rights. That is, the instructions stored in the memory 1206 in different computing devices 1200 may implement the functions of one or more of the acquisition module, the decryption module, the determination module, the encryption module, and the sending module.

The embodiment of the present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes a file access method or a file access permission determination method.

The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute a file access method, or instruct the computing device to execute a file access permission determination method.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the present invention. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that the technical solutions described in the above embodiments can still be applied to the present invention. The technical solution may be modified, or some of the technical features may be replaced by equivalent ones; however, these modifications or replacements do not make the essence of the corresponding technical solution deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims (22)

A file access method, characterized in that the method is applied to a first device, and the method comprises: Acquire a file access request for a target file triggered by a request object, the file access request including access operation information, the access operation information being used to describe an access operation that the request object needs to perform on the target file; the request object is a system user of an operating system program of the first device, or an application user of an application program; Acquire the permission policy information of the request object, the permission policy information is determined based on the file tag policy information of the target file and the file access request; the file tag policy information corresponds to the file tag of the target file, the file tag policy information is used to describe the control policy for the access operation on the target file, and the permission policy information is used to indicate the permission of the request object to operate the target file; the file tag includes one or more security dimension tags, and the file tag is set by the administrator of the target file or generated based on the file attributes of the target file; Access control of the request object to the target file is performed according to the authority policy information. The method according to claim 1, characterized in that the obtaining the permission policy information of the request object comprises: The permission policy information of the request object is generated according to the file tag policy information of the target file and the file access request of the request object. The method according to claim 1, characterized in that the obtaining the permission policy information of the request object comprises: Sending a permission request for the target file to the second device, the permission request including the file tag policy information of the target file, the access operation information, and the public key of the request object, wherein the file tag policy information of the target file is encrypted by the public key of the target file; Acquire permission information fed back by the second device, the permission information including a first ciphertext, the first ciphertext including a ciphertext obtained by encrypting permission policy information of the request object using the public key of the request object, the permission policy information of the request object being obtained by the second device using the private key of the target file, the file tag policy information of the target file, and the access operation information; The first ciphertext is decrypted using the private key of the request object to obtain the permission policy information of the request object. The method according to claim 3 is characterized in that the target file is encrypted using a file encryption key, the file encryption key is encapsulated in the file tag policy information of the target file, the permission information also includes a second ciphertext obtained by encrypting the file encryption key using the public key of the request object, and before performing access control on the request object's access to the target file according to the permission policy information of the request object, the method also includes: If it is determined based on the permission policy information that the request object has access rights, the target file is decrypted using the file encryption key, where the file encryption key is obtained by decrypting the second ciphertext using the private key of the request object. The method according to claim 1, characterized in that the method further comprises: Get the file tag of the target file; Based on the file tag and the tag policy template, file tag policy information of the target file is generated. The method according to claim 5 is characterized in that the label policy template is obtained from the second device. The method according to claim 5, characterized in that the method further comprises: Obtaining custom tag policy information for the target file; The file label policy information of the target file is updated using the custom label policy information. The method according to claim 1, characterized in that the first device is a host. The method according to claim 8 is characterized in that the method is applied to the application layer of the first device. The method according to claim 8 or 9 is characterized in that the method is applied to the system layer of the first device. The method according to claim 10, characterized in that the application is a preset security application. The method according to claim 1, wherein the first device is a storage device, and obtaining a file access request for a target file triggered by a request object comprises: Acquire a file access request for a target file that is triggered by a request object and sent by a third device, wherein the file access request is encapsulated by the third device using a security protocol; The file access request is unsealed using the security protocol. The method according to claim 12, characterized in that the access to the requested object is performed according to the permission policy information. The access control of the target file is as follows: Feedback file information is generated according to the permission policy information of the request object and the access operation information of the request object, and the feedback file information encapsulated by using a security protocol is sent to the third device. A method for determining file access rights, characterized in that the method is applied to a second device, and the method comprises: Obtaining a permission request for the target file sent by the first device, the permission request including file label policy information of the target file, access operation information, and a public key of a request object, the file label policy information being encrypted by the public key of the target file, the file label policy information corresponding to a file label of the target file, the file label policy information being used to describe a control policy for access operations on the target file, the file label including labels of one or more security dimensions, the file label being set by an administrator of the target file or generated based on file attributes of the target file, and the request object being a system user of an operating system program of the first device, or an application user of an application program; Decrypting the file tag policy information using the private key of the target file; Determine the permission policy information of the request object based on the file tag policy information of the target file and the access operation information, wherein the permission policy information is used to describe the permission policy of the request object for the access operation of the target file; Encrypting the permission policy information of the request object by using the public key of the request object to obtain a first ciphertext; Sending permission information to the first device, where the permission information includes the first ciphertext. The method according to claim 14, characterized in that the target file is encrypted using a file encryption key, and the file encryption key is encapsulated in the file tag policy information of the target file, and the method further comprises: The file encryption key is encrypted using the public key of the request object to obtain a second ciphertext, and the permission information also includes the second ciphertext. The method according to claim 14, characterized in that the method further comprises: In response to obtaining the label policy template acquisition request sent by the first device, a label policy template is sent to the first device. The method according to any one of claims 14 to 16 is characterized in that the second device is a server or a management device. A file access device, characterized in that the device is applied to a first device, and the device comprises: an acquisition module, configured to acquire a file access request for a target file triggered by a request object, wherein the file access request includes access operation information, and the access operation information is used to describe the access operation that the request object needs to perform on the target file; the request object is a system user of an operating system program of the first device, or an application user of an application program; A processing module is used to obtain the permission policy information of the request object, the permission policy information is determined based on the file label policy information of the target file and the file access request; the file label policy information corresponds to the file label of the target file, the file label policy information is used to describe the control policy for the access operation on the target file, and the permission policy information is used to indicate the permission of the request object to operate the target file; the file label includes one or more security dimension labels, and the file label is set by the administrator of the target file or generated based on the file attributes of the target file; A control module is used to perform access control on the request object's access to the target file according to the permission policy information. A device for determining file access rights, characterized in that the device is applied to a second device, and the device comprises: an acquisition module, configured to acquire a permission request for the target file sent by the first device, the permission request including file label policy information of the target file, access operation information, and a public key of a request object, the file label policy information being encrypted by the public key of the target file, the file label policy information corresponding to a file label of the target file, the file label policy information being used to describe a control policy for access operations on the target file, the file label including labels of one or more security dimensions, the file label being set by an administrator of the target file or generated based on a file attribute of the target file, and the request object being a system user of an operating system program of the first device, or an application user of an application program; A decryption module, used to decrypt the file tag policy information using the private key of the target file; A determination module, used to determine the permission policy information of the request object based on the file tag policy information of the target file and the access operation information, wherein the permission policy information is used to describe the permission policy of the request object for the access operation of the target file; An encryption module, used to encrypt the permission policy information of the request object using the public key of the request object to obtain a first ciphertext; A sending module is used to send permission information to the first device, where the permission information includes the first ciphertext. A computing device cluster, characterized in that it includes at least one computing device, each computing device includes a processor and a memory; The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device so that The computing device cluster executes the method according to any one of claims 1-13, or executes the method according to any one of claims 14-17. A computer program product comprising instructions, characterized in that when the instructions are executed by a computing device cluster, the computing device cluster executes the method described in any one of claims 1 to 13, or executes the method described in any one of claims 14 to 17. A computer-readable storage medium, characterized in that it includes computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 13, or executes the method according to any one of claims 14 to 17.