Techniques are described for logically isolating data I/O requests from different operating systems (OSes) for a same multi-tenant storage system (MTSS). Techniques provide for OSes and the MTSS to obtain security tokens associated with the OSes. In an embodiment, an OS uses a security token to generate an authentication token based on the contents of a data input/output (I/O) request and sends the authentication token to the MTSS along with the data I/O request. When an MTSS receives such data I/O request, MTSS retrieves its own copy of the security token associated with the OS and generates its own authentication token based on the contents of the received data I/O request. If the authentication token generated by the MTSS matches the authentication token generated by the OS, then the data I/O request is successfully authenticated. Otherwise, if the authorization tokens fail to match, then the data I/O request has been compromised. For example, either the contents of data I/O request has been tampered with, or an entity other than the OS, has sent the data I/O request in the first place. Accordingly, the data I/O request may not be serviced by the MTSS.
Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method comprising: a storage system processing a plurality of requests from a plurality of operating systems to store data on a persistent storage managed by the storage system, the processing comprising: receiving a request over a network to store particular data from an operating system of the plurality of operating systems, the request comprising the particular data to be written to the persistent storage and an operating system authentication token; querying for a storage security token based on identification information about the operating system; determining validity of the operating system authentication token by: computing a storage authentication token based on the storage security token queried for and the particular data in the request; comparing the storage authentication token with the operating system authentication token; if the operating system authentication token is determined to be valid, then the particular data is processed on the persistent storage according to the request.
A storage system validates data write requests from multiple operating systems (OSes) to prevent unauthorized access. It receives a write request, including data and an OS-generated authentication token. The system identifies the OS and retrieves a corresponding stored security token. It then independently computes its *own* authentication token based on the received data and the retrieved security token. If the two authentication tokens match, the write request is considered valid and the data is stored; otherwise, the request is rejected, ensuring only authorized OSes can write data.
2. The method of claim 1 , further comprising: identifying from the request a requested portion of the persistent storage to store the particular data in; determining the identification information about the operating system from allocation information of the requested portion of the persistent storage.
In the method for validating data write requests, as described in claim 1, the specific storage location requested for writing data is used to determine the identity of the requesting operating system. The system examines the metadata associated with the storage allocation to identify which operating system is permitted to write to that location. This allocation information then provides the identification information of the operating system, linking the request to its authorized storage space.
3. The method of claim 1 , further comprising determining the identification information about the operating system from information in the request.
The method also involves figuring out what operating system is being used based on information included in the request.
4. The method of claim 1 , wherein the storage security token is stored on an authentication system in association with the identification information about the operating system.
In the method for validating data write requests, as described in claim 1, the security tokens used to authenticate operating systems are stored in a separate, dedicated authentication system. This system maintains a mapping between operating system identification information (e.g., name, address) and their corresponding security tokens, enabling the storage system to query and retrieve the correct token for validation.
5. The method of claim 1 , wherein the request comprises additional data that is not used in the computing the storage authentication token, and the method further comprising: if the operating system authentication token is determined to be valid, then the additional data along with the particular data is processed on the persistent storage according to the request.
In the method for validating data write requests, as described in claim 1, the data write request includes additional data beyond what's used for authentication. If the operating system authentication token is successfully validated, this *additional* data is also written to the persistent storage *along with* the primary data. This allows the request to carry control information or other metadata without affecting the authentication process.
6. The method of claim 1 , further comprising: prior to the querying: identifying from the request a requested portion of the persistent storage to store the particular data in; identifying an allocated portion of the persistent storage associated with the identification information about the operating system; wherein the allocated portion has been allocated to the operating system prior to the receiving of the request; if the requested portion is different from the allocated portion of the persistent storage, preventing further processing of the particular data in the requested portion of the persistent storage according to the request.
In the method for validating data write requests, as described in claim 1, *before* validating the authentication token, the storage system checks if the requested storage location matches the location previously allocated to the requesting operating system. If the requested location differs from the allocated location, the storage system prevents the write operation, even *before* authentication token validation, preventing unauthorized access to other OS's allocated storage space.
7. The method of claim 1 , wherein the request is caused by execution of a storage input/output (I/O) command in the operating system to persistently store the particular data and the execution of the storage I/O command causes the operating system to perform: retrieving an operating system security token that was generated by an authentication system and stored on the authentication system in association with the identification information about the operating system; computing the operating system authentication token using the particular data and the operating system security token; and transmitting to the storage system the request comprising the operating system authentication token and the particular data.
In the method for validating data write requests, as described in claim 1, the write request originates from an operating system's standard storage I/O command. Executing this command triggers the operating system to: 1) retrieve its security token from a central authentication system; 2) compute the authentication token using this security token and the data to be written; and 3) send the write request, including the data and the computed authentication token, to the storage system for validation.
8. The method of claim 7 : wherein the storage I/O command is executed by a guest operating system running on a virtual computer system running on the operating system, wherein a sub-portion, of a portion of the persistent storage that is exposed to the operating system, is exposed to the guest operating system, and wherein the execution of the storage I/O command causes the guest operating system to perform: retrieving a guest OS security token that was generated by the authentication system and stored on the authentication system in association with guest identification information about the guest operating system; computing a guest operating system authentication token using the particular data and the guest OS security token; and requesting the operating system to transmit to the storage system the request comprising the guest operating system authentication token and the particular data.
In the method for validating data write requests, as described in claim 7, a *guest* operating system, running inside a virtual machine on a *host* operating system, initiates the write request. The guest OS uses a similar process: retrieving its *own* security token, computing an authentication token, and then requesting the host OS to forward the data and token to the storage system. The host OS exposes only a subset of its storage to the guest OS.
9. The method of claim 8 further comprising: querying for a guest storage security token of the sub-portion based on the guest identification information about the guest operating system; determining validity of the guest operating system authentication token by: computing a storage sub-portion authentication token based on the guest storage security token of the sub-portion and the particular data in the request; comparing the storage sub-portion authentication token with the guest operating system authentication token; if the guest operating system authentication token is determined to be valid, then storing the particular data on the persistent storage according to the request.
In the method for validating data write requests involving guest operating systems, as described in claim 8, the storage system performs *another* layer of authentication specifically for the guest OS. It queries for a security token associated with the *guest* OS and the specific storage *sub-portion* it's trying to access. It then computes *another* authentication token, compares it to the guest OS's token, and only proceeds with the write operation if *both* the host and guest OS authentication checks pass.
10. The method of claim 1 , wherein the identification information includes at least one of the following: internet address, Small Computer System Interface (SCSI) name, a media access control (MAC) address, a world-wide name (WWN), host name or a fully qualified domain name.
In the method for validating data write requests, as described in claim 1, the "identification information about the operating system" can be any unique identifier, including but not limited to: its internet address (IP address), SCSI name, MAC address, World Wide Name (WWN), hostname, or Fully Qualified Domain Name (FQDN). These identifiers allow the storage system to distinguish between different operating systems and retrieve the correct security tokens.
11. One or more non-transitory computer-readable media storing instructions, wherein the instructions include instructions, which when executed by one or more hardware processors, cause: a storage system processing a plurality of requests from a plurality of operating systems to store data on a persistent storage managed by the storage system, the processing comprising: receiving a request over a network to store particular data from an operating system of the plurality of operating systems, the request comprising the particular data to be written to the persistent storage and an operating system authentication token; querying for a storage security token based on identification information about the operating system; determining validity of the operating system authentication token by: computing a storage authentication token based on the storage security token queried for and the particular data in the request; comparing the storage authentication token with the operating system authentication token; if the operating system authentication token is determined to be valid, then the particular data is processed on the persistent storage according to the request.
A storage system validates data write requests from multiple operating systems (OSes) to prevent unauthorized access. It receives a write request, including data and an OS-generated authentication token. The system identifies the OS and retrieves a corresponding stored security token. It then independently computes its *own* authentication token based on the received data and the retrieved security token. If the two authentication tokens match, the write request is considered valid and the data is stored; otherwise, the request is rejected, ensuring only authorized OSes can write data. These steps are performed by executing instructions on computer-readable media.
12. The one or more non-transitory computer-readable media of claim 11 , wherein the instructions further include instructions, which when executed by said one or more hardware processors, cause: identifying from the request a requested portion of the persistent storage to store the particular data in; determining the identification information about the operating system from allocation information of the requested portion of the persistent storage.
In the computer-readable media instructions for validating data write requests, as described in claim 11, the specific storage location requested for writing data is used to determine the identity of the requesting operating system. The system examines the metadata associated with the storage allocation to identify which operating system is permitted to write to that location. This allocation information then provides the identification information of the operating system, linking the request to its authorized storage space.
13. The one or more non-transitory computer-readable media of claim 11 , wherein the method further comprises determining the identification information about the operating system from information in the request.
In the computer-readable media instructions for validating data write requests, as described in claim 11, the identification of the operating system is derived directly from information included within the write request itself. Instead of relying on storage allocation metadata, the request explicitly contains identifying information about the operating system, such as its name or ID, which the storage system uses to retrieve the corresponding security token.
14. The one or more non-transitory computer-readable media of claim 11 , wherein the storage security token is stored on an authentication system in association with the identification information about the operating system.
In the computer-readable media instructions for validating data write requests, as described in claim 11, the security tokens used to authenticate operating systems are stored in a separate, dedicated authentication system. This system maintains a mapping between operating system identification information (e.g., name, address) and their corresponding security tokens, enabling the storage system to query and retrieve the correct token for validation.
15. The one or more non-transitory computer-readable media of claim 11 , wherein the request comprises additional data that is not used in the computing the storage authentication token and wherein if the operating system authentication token is determined to be valid, then the additional data along with the particular data is processed on the persistent storage according to the request.
In the computer-readable media instructions for validating data write requests, as described in claim 11, the data write request includes additional data beyond what's used for authentication. If the operating system authentication token is successfully validated, this *additional* data is also written to the persistent storage *along with* the primary data. This allows the request to carry control information or other metadata without affecting the authentication process.
16. The one or more non-transitory computer-readable media of claim 11 , wherein the instructions further include instructions, which when executed by said one or more hardware processors, cause: prior to the querying: identifying from the request a requested portion of the persistent storage to store the particular data in; identifying an allocated portion of the persistent storage associated with the identification information about the operating system; wherein the allocated portion has been allocated to the operating system prior to the receiving of the request; if the requested portion is different from the allocated portion of the persistent storage, preventing further processing of the particular data in the requested portion of the persistent storage according to the request.
In the computer-readable media instructions for validating data write requests, as described in claim 11, *before* validating the authentication token, the storage system checks if the requested storage location matches the location previously allocated to the requesting operating system. If the requested location differs from the allocated location, the storage system prevents the write operation, even *before* authentication token validation, preventing unauthorized access to other OS's allocated storage space.
17. The one or more non-transitory computer-readable media of claim 11 , wherein the request is caused by execution of a storage input/output (I/O) command in the operating system to persistently store the particular data and the execution of the storage I/O command causes the operating system to perform: retrieving an operating system security token that was generated by an authentication system and stored on the authentication system in association with the identification information about the operating system; computing the operating system authentication token using the particular data and the operating system security token; and transmitting to the storage system the request comprising the operating system authentication token and the particular data.
In the computer-readable media instructions for validating data write requests, as described in claim 11, the write request originates from an operating system's standard storage I/O command. Executing this command triggers the operating system to: 1) retrieve its security token from a central authentication system; 2) compute the authentication token using this security token and the data to be written; and 3) send the write request, including the data and the computed authentication token, to the storage system for validation.
18. The one or more non-transitory computer-readable media of claim 17 : wherein the storage I/O command is executed by a guest operating system running on a virtual computer system running on the operating system, wherein a sub-portion, of a portion of the persistent storage that is exposed to the operating system, is exposed to the guest operating system, and wherein the execution of the storage I/O command causes the guest operating system to perform: retrieving a guest OS security token that was generated by the authentication system and stored on the authentication system in association with guest identification information about the guest operating system; computing a guest operating system authentication token using the particular data and the guest OS security token; and requesting the operating system to transmit to the storage system the request comprising the guest operating system authentication token and the particular data.
In the computer-readable media instructions for validating data write requests, as described in claim 17, a *guest* operating system, running inside a virtual machine on a *host* operating system, initiates the write request. The guest OS uses a similar process: retrieving its *own* security token, computing an authentication token, and then requesting the host OS to forward the data and token to the storage system. The host OS exposes only a subset of its storage to the guest OS.
19. The one or more non-transitory computer-readable media of claim 18 , wherein the instructions further include instructions, which when executed by said one or more hardware processors, cause: querying for a guest storage security token of the sub-portion based on the guest identification information about the guest operating system; determining validity of the guest operating system authentication token by: computing a storage sub-portion authentication token based on the guest storage security token of the sub-portion and the particular data in the request; comparing the storage sub-portion authentication token with the guest operating system authentication token; if the guest operating system authentication token is determined to be valid, then storing the particular data on the persistent storage according to the request.
In the computer-readable media instructions for validating data write requests involving guest operating systems, as described in claim 18, the storage system performs *another* layer of authentication specifically for the guest OS. It queries for a security token associated with the *guest* OS and the specific storage *sub-portion* it's trying to access. It then computes *another* authentication token, compares it to the guest OS's token, and only proceeds with the write operation if *both* the host and guest OS authentication checks pass.
20. The one or more non-transitory computer-readable media of claim 11 , wherein the identification information includes at least one of the following: internet address, Small Computer System Interface (SCSI) name, a media access control (MAC) address, a world-wide name (WWN), host name or a fully qualified domain name.
In the computer-readable media instructions for validating data write requests, as described in claim 11, the "identification information about the operating system" can be any unique identifier, including but not limited to: its internet address (IP address), SCSI name, MAC address, World Wide Name (WWN), hostname, or Fully Qualified Domain Name (FQDN). These identifiers allow the storage system to distinguish between different operating systems and retrieve the correct security tokens.
Cooperative Patent Classification codes for this invention. Click any code to explore related patents in that topic.
July 30, 2015
May 23, 2017
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.