Secure software defined storage

Providing secure software defined storage includes identifying data directed to be stored in a software defined storage location, intercepting the data, performing a security operation on the intercepted data, and transmitting the data to the software defined storage.

Embodiments described herein generally relate to data privacy, and more specifically to providing secure software defined storage.

BACKGROUND ART

As computing technology increases, data is increasingly stored in “the cloud” rather than on a readily identifiable device. For example, software defined storage (SDS) systems provide virtual storage spaces for computing systems and/or workloads (e.g., applications or operating systems) executing on a computing system. Each computing system or workload may be responsible for applying its own security and or access control policies to data stored by the SDS system. However, some computing systems or workloads (e.g., server-less architecture workloads) may not be configured to provide such security solutions. Accordingly, data stored by an SDS system may be subjected to varying levels of security enforcement or no security enforcement.

DESCRIPTION OF EMBODIMENTS

As used herein, the term “programmable device” can refer to a single programmable device or a plurality of programmable devices working together to perform the function described as being performed on or by the programmable device.

As used herein, the term “medium” refers to a single physical medium or a plurality of media that together store what is described as being stored on the medium.

As used herein, the term “network device” can refer to any programmable device that is capable of communicating with another programmable device across any type of network.

One or more embodiments provide a method to provide secure software defined storage. In software defined storage systems, hardware may be abstracted by middleware. A software layer between an application and a physical storage device may provide the application access to the storage device without the application “being aware” of where the physical storage device is located. To illustrate, the software layer may map a virtual storage device referenced by the application to the physical storage device. In some implementations, the virtual storage device corresponds to more than one physical storage device. In other examples, the software layer maps more than one virtual storage device to a single physical storage device. Thus, the application may “see” a different number of devices than an actual number of hardware devices on which data of the application is stored.

In one or more embodiments, security enforcement is tied to data rather than a computing workload (e.g., application or operating system) that uses the data. Security inspection and enforcement may be performed in a software defined storage architecture so that the security functionality is delivered seamlessly and irrespective to a type of platform (e.g., computing system, workload etc.) from which the data is accessed. According to one or more embodiments, the software defined storage architecture includes a security module and a virtualization module. The security module may intercept access requests (e.g., data reads and/or writes) to data stored by the software defined storage architecture. The data may correspond to one or more data blocks or one or more files. The security module may then perform security functions on the data prior to the data being released to a requesting computing system or workload or written to one or more storage devices. In one or more embodiments, the security module generates additional data associated with the data for later use. As an example, the security module may index rights associated with the data or analyze the data to determine a classification of the data. The additional data may be stored with the data on the physical storage devices or may be stored in a separate server for lookup when the data is accessed again.

Referring to the figures,FIG. 1an example infrastructure100in which embodiments may be implemented is illustrated schematically. The infrastructure100contains computer networks102. The computer networks102may include many different types of computer networks available today, such as the Internet, a corporate network, a Local Area Network (LAN), or a personal network, such as those over a Bluetooth connection. Each of the computer networks102can contain wired or wireless programmable devices and operate using any number of network protocols (e.g., transmission control protocol/Internet protocol). The computer networks102may be connected to networking devices108(e.g., gateways, routers, access points, etc.), end user computers106, and computer servers104. The networking devices108may be implemented in any device or combination of devices. In some examples, the networking devices180include a firewall or intrusion protection system.

The infrastructure100also includes cellular network103for use with mobile communication devices. The cellular network103supports mobile phones and many other types of mobile devices via one or more cellular access points120,130,140. In the illustrated example, the infrastructure100includes a mobile phone110, a laptop112, and a tablet114. The mobile phone110, the laptop112, and the tablet114are examples of mobile devices. A mobile device such as the mobile phone110may interact with one or more mobile provider networks (e.g., the computer networks102, the cellular network103, etc.) as the mobile device moves. Each of the computer networks102may contain a number of other devices typically referred to as Internet of Things (microcontrollers, embedded systems, industrial control computing modules, etc.) devices. In the illustrated example, an Internet of Things device150is included in one of the computer networks102. Although referred to as a single cellular network, the cellular network103may correspond to a more than one cellular network that may be associated with different carriers. The mobile devices110,112, and114, the servers104, the end user computers106, the Internet of Things device150, or a combination thereof may interact with each other via one or more of the computer networks102and the cellular network103.

FIG. 2is a diagram illustrating an example system for providing secure software defined storage, according to one or more embodiments.FIG. 2includes a client205, a network200, a server210, and network storage units215A-215N (collectively referred to as network storage215). The client205includes a memory220and a processor225. The memory220may include one or more software or firmware modules executable by processor225A. For example, memory220may include computer readable instructions (e.g., associated with an application or operating system) executable by processor225to initiate transmission of one or more data requests over the network200to the server210. The data requests may include a write request that includes data to be stored in a virtual storage space. As another example, the data requests may include a read request to access data from the virtual storage space.

In the illustrated example, the server210includes a memory230and a processor235. The memory230includes a security module245and a virtualization module240. The virtualization module240is executable by the processor235to provide a virtual storage space accessible to the client205. The virtual storage space corresponds to one or more of the network storage units215A-215N. The virtualization module240may provide the virtual storage space by mapping data requests (e.g., reads and/or writes) from the virtual storage space to one or more of the network storage units215A-215N. That is, in one or more embodiments, the virtualization module240may define and manage the software defined storage across network storage215. The virtualization module240may, in response to a read request, identify a physical location of data and retrieve the data from its physical location (e.g., at one of the network storage units215A-215N). Conversely, the virtualization module240may, in response to a write request, determine a physical location to write the data, index the data, and write the data to the determined physical location.

The security module245is executable by the processor235to intercept the data requests issued from the client205and to perform one or more security operations. The security module245may intercept the data requests prior to the data requests reaching the virtualization module240. Accordingly, the security module245may perform a security operation prior to data being written to or retrieved from the network storage215. Examples of security operations performed by the security module245in response to a write request include sanitizing data, analyzing data to determine a classification, determining access rights associated with data, performing a malware scan on data, blocking a write of data determined to be malicious, encrypting written data using per-tenant and/or per-application keys, and the like. Examples of security operations performed by the security module245in response to a read request include enforcing access controls based on data classification, applying controlling mechanisms to data, sanitizing data, decrypting data, and the like. In one or more embodiments, performing a security operation to data may result in additional data. For example, if the data is analyzed to determine a classification, that classification may be additional data. That additional data may be packaged with the data to be written to network storage215. Alternatively, the additional data may be stored locally at the server210, in a different area of the network storage215, or at another device accessible via the network200. If the client205(or another client) submits a read request for data that has already been classified, the security module245may look up the stored classification rather than analyzing the data to determine the classification again.

Thus,FIG. 2illustrates a system that applies one or more security operations to data independently of an application or operating system accessing (e.g., reading or writing) the data. Accordingly, the system illustrated inFIG. 2may enable consistent application of security operations to data stored using a software defined storage architecture.

FIG. 3is a flowchart illustrating a method for providing secure software defined storage. In the example illustrated inFIG. 3, the method is performed by a system that includes the client205, the server210, and the network storage215ofFIG. 2. Further, the system includes an additional client300. The additional client B300may correspond to an additional network device communicably connected to the other devices over the network200illustrated inFIG. 2. Alternatively, the additional client300may correspond to a virtual client provided by a device that provides the client205, the server210, the network storage215, or a combination thereof.

The method ofFIG. 3begins at305, when the client205transmits a write request including data for network storage to the server210. The write request indicates a virtual storage space. As an example, the write request may identify network storage215rather than a particular one of the network storage units215A-215N. The method continues at310, when the security module245intercepts the data intended for network storage. “Intercepting” the data includes receiving the data at the security module245prior to the virtualization module240determining a physical location to store the data, indexing the data, sending the data for storage, performing other tasks associated with software defined storage management, or a combination thereof.

At315, the security module245performs a security operation on the data. As an example, the security module245may perform a malware scan on the data. The security module245may also anonymize the data, classify the data, apply protection mechanisms (e.g., access rights), and the like. Performing the security operation on the data results in processed data. The processed data may be the same as or different from the data. To illustrate, the processed data may correspond to an anonymized version of the data, an encrypted version of the data, a version of the data including access rights information, a version of the data including additional data, another version of the data, or a combination thereof.

In the example ofFIG. 3, performing the security operation includes classifying the data at320and, at325, generating metadata identifying the classification. Performing the classification operation may include comparing the data to one or more data models using one or more machine learning techniques. In some implementations, performing the classification operation includes analyzing content of the data to determine whether the data is encrypted, whether data loss prevention is to be applied to the intercepted data, whether the intercepted data includes malware, or a combination thereof. For example, the security module245may analyze the data to determine whether the data includes personally identifiable information (e.g., social security numbers, birthdates, etc.). In response to determining that the data includes personally identifiable information, the security module245may determine to apply one or more data loss prevention rules to the data. The one or more data loss prevention rules may be used by the security module245to control which devices/applications have access to the data. In another example, in response to determining that the data includes malware (e.g., ransomware, trojans, etc.) the security module245may transmit an alarm message to an administrator application executing at the server210or another device. In addition or in the alternative, the security module245may delete the data or quarantine the data. In some implementations, the security operation is performed on a block by block basis. To illustrate, the security operation may be applied to a first block of the data and to a second block of the data. Thus, each block of a data file may be individually classified by the security module245. In other implementations, the security operation may be performed on a per data file basis.

In one or more embodiments, metadata (i.e., additional data) is included in the processed data. Alternatively, or additionally, in one or more embodiments, the metadata may be stored in a different location for later retrieval. As an example, the classification information may be stored locally by the server210, or somewhere else in the network storage215.

At330, and the server210transmits the processed data to the network storage215. To illustrate, the virtualization module240may identify a physical storage space in the network storage215based on the virtual storage space indicated by the write request, based on an identity of the client205, based on an identity of an application or operating system executed by the client205, or a combination thereof. The virtualization module240may further index the processed data for later retrieval. The server210may transmit the processed data to the physical storage space identified by the virtualization module240.

The method continues at350, and the additional client300transmits a read request for data to the server210. The read request is received by the server210at355. Then, at360, the virtualization module240obtains the data from network storage. In one or more embodiments, the data may be the data previously processed by security module245at315. Thus, at365, the security module245may perform a security operation on the data. In one or more embodiments, performing the security operation may include performing a scan on the data, anonymizing the data, analyzing assigned rights to the data, or determining a classification of the data. As described above, the classification data may previously have been determined and stored for later retrieval. Thus, in one or more embodiments, performing a security operation on the data may include obtaining a previously-determined classification of the data. In some implementations, the security module245intercepts the read request and performs a security operation before the virtualization module240obtains the data from the network storage. For example, the security module245may determine whether the additional client300, an application executing at the additional client300, an operating system executing at the additional client300, a user of the additional client300, or a combination thereof is authorized to access the processed data. The security module245may be configured to refrain from forwarding the read request to the virtualization module240in response to determining that the additional client300, the application executing at the additional client300, the operating system executing at the additional client300, the user of the additional client300, or a combination thereof is not authorized to access the processed data. In addition or in the alternative, the security module245may determine whether to forward data received from the virtualization module240to the additional client300.

The security module245may determine whether to forward a request to the virtualization module240and/or whether to forward data to the additional client300based on the metadata generated at325. To illustrate, the security module245may determine (e.g., based on the metadata previously generated at325) that the data is subject or more data loss prevention rules. In response to determining that the additional client300satisfies the one or more data loss prevention rules, the security module245may determine to provide the data to the additional client300.

At370, the data is provided to the additional client300based on the security. Providing the data to the additional client300based on the security may include providing the data to the additional client300as modified by the security module245and/or providing the data to the additional client300in response to the security module245determining that the additional client300may access the data. In an illustrative example, in response to the security module245determining that the additional client300may access the data at365the server210transmits the data to the additional client300. Then, at375, the additional client300receives the data from network storage215.

FIG. 4is an example flow diagram400illustrating a network flow for data in a secure software defined storage solution. The flow begins with a user application attempting to access software-defined storage. The user application may correspond to the client205. The user application may access the software-defined storage, for example, with a read or write request. Depending on the system architecture, the user application may access the software-defined storage in a variety of ways. For example, as shown in the far left, the user application may access an abstraction layer, represented by a cloud, configured to provide the distributed storage through a web-based application programming interface (API). The abstraction layer may include one or more devices. In some implementations, the abstraction layer corresponds to the server210.

Alternatively, the user application may access the abstraction layer through a system call to a kernel, such as the Linux kernel. The kernel interacts with a virtual file system. The virtual file system may provide an additional abstraction layer on top of a file system of the kernel, and may enable the user application to access various storage devices, such as those shown at the bottom of the architecture diagram, in a unique way. The virtual file system may provide a unitary view of storage across multiple devices, according to one or more embodiments. That is, the virtual file system may represent physical storage at a plurality of devices in network storage as a single virtual storage space. The virtual file system links virtual addresses to a physical addresses in the network storage. In one or more embodiments, a network file system (NFS), a common Internet file system (CIFS), or a special purpose filesystem in user space (FUSE) client may provide protocols that allow the virtual file system to access the storage via the one or more devices. In an alternate embodiment, a general purpose file system, XFS, fourth extended file system (ext4) or the like may use different protocols to access the abstraction layer.

The abstraction layer represented by the cloud indicates various modules that are configured to provide software data storage services. The various modules may include a mirroring or eraser coding module, which is configured to provide data redundancy. The modules may also include a stripping or data distribution and partitioning module, which may determine how data is split and distributed across a network. For example, a single data set may be partitioned and distributed among the various storage resources shown in the architecture diagram. Another potential module includes a load balancing module, which may manage volumes of data across the various devices. The modules may further include a data integrity checker and self heal agent module that may ensure that the data remains fully complete in the network storage. The data integrity checker and self heal agent module may utilize data redundancies generated by the mirroring or eraser coding module to verify the data. The modules may further include a cache and data tier module, which may provide a cache for the abstraction layer. The NFS/CIFS Server emulators may provide a virtualized storage layout to interface with the physical media.

A security inspection and enforcement module may sit alongside the other modules in the abstraction layer. The security inspection and enforcement module may correspond to the security module245ofFIG. 2. According to one or more embodiments, the security inspection and enforcement module may provide security functionality, such as malware scans and data classification. In one or more embodiments, the security inspection and functionality module may analyze the data prior to the data being handled by other modules, such as the mirroring or stripping modules. The security inspection and enforcement module may also store data regarding its analysis for later review. As an example, the security inspection and enforcement module may perform a classification operation on the data in order to classify the type of data or a security level associated with that data. That information may be stored with the data, or in another location such that upon a read request of the data, the security inspection and enforcement module may simply review the previously generated classification data rather than re-analyzing the data.

Referring now toFIG. 5, a block diagram illustrates a programmable device600that may be used within a network device, such as the client205, the server210, the additional client300, or a combination thereof in accordance with one or more embodiments. The client205, the additional client300, the server210, or a combination thereof may not include all of the elements ofFIG. 5. The programmable device600illustrated inFIG. 5is a multiprocessor programmable device that includes a first processing element670and a second processing element680. While two processing elements670and680are shown, an embodiment of programmable device600may also include only one such processing element.

Programmable device600is illustrated as a point-to-point interconnect system, in which the first processing element670and second processing element680are coupled via a point-to-point interconnect650. Any or all of the interconnects illustrated inFIG. 5may be implemented as a multi-drop bus rather than point-to-point interconnects.

As illustrated inFIG. 5, each of the processing elements670and680may be multicore processors, including first and second processor cores (i.e., processor cores674aand674band processor cores684aand684b). Such cores674a,674b,684a,684bmay be configured to execute instruction code in a manner similar to that discussed above in connection withFIGS. 1-4. However, other embodiments may use processing elements that are single core processors as desired. In embodiments with multiple processing elements670,680, each processing element may be implemented with different numbers of cores as desired.

Each processing element670,680may include at least one shared cache646. The shared cache646a,646bmay store data (e.g., instructions) that are utilized by one or more components of the processing element, such as the cores674a,674band684a,684b, respectively. For example, the shared cache may locally cache data stored in a memory632,634for faster access by components of the processing elements670,680. In one or more embodiments, the shared cache646a,646bmay include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), or combinations thereof.

WhileFIG. 5illustrates a programmable device with two processing elements670,680for clarity of the drawing, the scope of the present inventions is not so limited and any number of processing elements may be present. Alternatively, one or more of processing elements670,680may be an element other than a processor, such as an graphics processing unit (GPU), a digital signal processing (DSP) unit, a field programmable gate array, or any other programmable processing element. Processing element680may be heterogeneous or asymmetric to processing element670. There may be a variety of differences between processing elements670,680in terms of a spectrum of metrics of merit including architectural, microarchitectural, thermal, power consumption characteristics, and the like. These differences may effectively manifest themselves as asymmetry and heterogeneity amongst processing elements670,680. In some embodiments, the various processing elements670,680may reside in the same die package.

First processing element670may further include memory controller logic (MC)672and point-to-point (P-P) interconnects676and678. Similarly, second processing element680may include a MC682and P-P interconnects686and688. As illustrated inFIG. 6, the MCs672and682couple the processing elements670,680to respective memories, namely a memory632and a memory634, which may be portions of main memory locally attached to the respective processors. While the MC logics672and682are illustrated as integrated into the processing elements670,680, in some embodiments the memory controller logic may be discrete logic outside the processing elements670,680rather than integrated therein.

The processing element670and the processing element680may be coupled to an input/output (I/O) subsystem690via respective P-P interconnects676and686through links652and654. As illustrated inFIG. 6, the I/O subsystem690includes P-P interconnects694and698. Furthermore, the I/O subsystem690includes an interface692to couple the I/O subsystem690with a high performance graphics engine638. In one embodiment, a bus (not shown) may be used to couple the graphics engine638to the I/O subsystem690. Alternately, a point-to-point interconnect639may couple these components.

In turn, the I/O subsystem690may be coupled to a first link616via an interface696. In one embodiment, the first link616may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another I/O interconnect bus, although the scope of the present inventions is not so limited.

As illustrated inFIG. 5, various I/O devices614,624may be coupled to the first link616, along with a bridge618which may couple the first link616to a second link620. In one embodiment, the second link620may be a low pin count (LPC) bus. Various devices may be coupled to the second link620including, for example, a keyboard/mouse612, communication device(s)626(which may in turn be in communication with the computer network603), and a data storage unit628such as a disk drive or other mass storage device which may include code630, in one embodiment. The code630may include instructions for performing embodiments of one or more of the techniques described above. Further, an audio I/O624may be coupled to second link620.

Note that other embodiments are contemplated. For example, instead of the point-to-point architecture ofFIG. 5, a system may implement a multi-drop bus or another such communication topology. Although the links616and620are illustrated as busses inFIG. 5, any desired type of link may be used. Also, the elements ofFIG. 5may alternatively be partitioned using more or fewer integrated chips than illustrated inFIG. 5.

Referring now toFIG. 6, a block diagram illustrates a programmable device700according to another embodiment. Certain aspects ofFIG. 5have been omitted fromFIG. 6in order to avoid obscuring other aspects ofFIG. 6.

FIG. 6illustrates that processing elements770,780may include integrated memory and I/O control logic (“CL”)772and782, respectively. In some embodiments, the772,782may include memory control logic (MC) such as that described above in connection withFIG. 5. In addition, the CL772,782may also include I/O control logic.FIG. 6illustrates that not only may the memories732,734be coupled to the CL772,782, but also that I/O devices744may also be coupled to the control logic772,782. Legacy I/O devices715may be coupled to the I/O subsystem790by interface796. Each of the processing elements770,780may include multiple processor cores, illustrated inFIG. 6as processor cores774A,774B,784A, and784B. As illustrated inFIG. 6, the I/O subsystem790includes P-P interconnects794and798that connect to P-P interconnects776and786of the processing elements770and780with links752and754. The processing elements770and780may also be interconnected by link750and interconnects778and788, respectively.

The programmable devices depicted inFIGS. 5 and 6are schematic illustrations of embodiments of programmable devices which may be utilized to implement various embodiments discussed herein. Various components of the programmable devices depicted inFIGS. 6 and 7may be combined in a system-on-a-chip (SoC) architecture.

It is to be understood that the various components of the flow diagrams described above, could occur in a different order or even concurrently. It should also be understood that various embodiments of the inventions may include all or just some of the components described above. Thus, the flow diagrams are provided for better understanding of the embodiments, but the specific ordering of the components of the flow diagrams are not intended to be limiting unless otherwise described so.

Program instructions may be used to cause a general-purpose or special-purpose processing system that is programmed with the instructions to perform the operations described herein. Alternatively, the operations may be performed by specific hardware components that contain hardwired logic for performing the operations, or by any combination of programmed computer components and custom hardware components. The methods described herein may be provided as a computer program product that may include a machine-readable medium having stored thereon instructions that may be used to program a processing system or other electronic device to perform the methods. The term “machine readable medium” used herein shall include any medium that is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methods described herein. The term “machine readable medium” shall accordingly include, but not be limited to, tangible, non-transitory memories such as solid-state memories, optical and magnetic disks. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, module, logic, and so on) as taking an action or causing a result. Such expressions are merely a shorthand way of stating that the execution of the software by a processing system causes the processor to perform an action or produce a result.

It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. As another example, the above-described flow diagrams include a series of actions which may not be performed in the particular order depicted in the drawings. Rather, the various actions may occur in a different order, or even simultaneously. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the inventions should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.