“Once my data is in your storage environment, how do I know it’s safe?”
This is one of the most common questions we hear from potential customers, and it’s not surprising. That’s why we wrote this blog post: to provide background on security in a traditional Fibre Channel environment as well as how security is practically handled in the modern Internet Small Computer Systems Interface (iSCSI) framework, which communicates over existing networks, rather than requiring its own infrastructure like traditional Fibre Channel.
And while there are numerous ways that storage providers might keep your data safe and secure, there is one key point to make from the start: Using a wide variety of available tools in combination is the best way to keep your storage secure.
(Note that the information in this blog post pertains to both dedicated and multitenant storage environments.)
The Old School: Fibre Channel
Fibre Channel storage has typically been used to present block storage to compute hosts. This is separate from the production networking and uses a separate medium, electronics and protocol.
Fibre Channel security usually entails configuring LUN zoning or LUN masking (a LUN being the logical unit of disk or a partition off a larger physical array). Fibre Channel adapters have a unique address burned in, which is known as a World Wide Name (WWN).
In LUN zoning, the Fibre Channel switching fabric is configured to prevent hosts from communicating with one another, meaning that WWNs can only communicate with the WWNs used for the SAN arrays. In effect, this acts as a firewall that prevents the hosts from communicating with anything but the storage array.
LUN masking adds more security by further limiting a WWN’s ability to communicate, restricting its communication to a specific LUN. Thus, a group of VMWare hosts would have the WWNs from their FC adapters limited to only communicate with a specific LUN. This further prevents the hosts from being able to communicate with anything except their own assigned LUN.
Ensuring Data Security in iSCSI Environments
In iSCSI, each host server is an iSCSI Initiator and the SAN is an iSCSI Target. Similar to the WWN system in Fibre Channel, iSCSI uses an iSCSI Qualified Name (IQN). Unlike WWNs, the IQN is made up of four fields that can be configured by the administrator. Those fields are:
Field 1: “IQN”
Field 2: Date, in YYYY-MM format, e.g., “2018-07”
Field 3: a reverse of the DNS domain, e.g., “com.eugene”
Field 4: an optional target name, e.g., “storage.vmware.datastore1.xyz”
All together this would look like “Iqn.2018-07.com.eugene:storage.vmware.datastore1”
A dedicated VLAN is used for iSCSI communications between trusted hosts and targets. Having an isolated network is a primary security step to protect hosts, targets and data.
An iSCSI initiator first needs to authenticate. Typically, Challenge-Handshake Authentication Protocol (CHAP) is used. The two endpoints exchange a hash from the CHAP ID, which consists of a challenge and a secret password.
Once the host iSCSI initiator has authenticated using CHAP, then the IQN is used for authorization. Think of it this way: Once a host’s identity is authenticated, it needs to ask for access to a specific iSCSI resource. Like Fibre Channel LUN Masking, a SAN array will limit a target LUN to only specific IQNs.
The typical security measures for iSCSI SAN deployments
A CHAP-based handshake between iSCSI initiator (client) and iSCSI Target (storage system) might be sufficient for some implementations. Taking it one step further, modern storage systems also offer domain segmentation, where a restricted group of iSCSI clients (IQNs) are associated with a specific set of IPs that a client inquiry may come from. Then, based on successful CHAP authentication, those IQNs are allowed to discover and communicate with the group of LUNs on the target system (e.g., Host A with IQN Y and coming from the IP 10.x.x.x and with the valid CHAP authentication passed).
It’s important to note here that iSCSI is a clear text protocol. In order to ensure the secure transmission of data between the client and its target storage, all of the above security measures are required and equally important to be in place.
In certain scenarios, depending on the networking topology in place, additional security can be introduced at the networking layer, where only specific hosts (with specific MAC addresses) that are associated with specific networking adapters may initiate an ISCSI connection with a pre-defined source and target IP space within storage network isolated VLAN. (These techniques are similar to SpoofGuard.)
Typically, depending on the storage system implementation model and its type, at-rest data encryption is realized through either hardware or software encryption methods.
Hardware-based encryption is associated with self-encrypting drives and requires a special type of hard drive to be used in the storage system. If for any reason the data is attempted to be accessed on such a hard drive outside of its storage platform (e.g., removed from the storage unit shelf), it will be in an encrypted state.
Software-based encryption, as its name suggests, uses software-driven encryption methods, while leveraging the offload of the actual encryption instructions to the underlaying hardware (AES-NI and similar CPU technology). The minimum encryption level recommended for software-based encryption is AES-256. A major benefit of software-based encryption is a lower cost for a solution that delivers the same level of encryption seen with hardware-based solutions.
With the right tools, vendors and implementations, iSCSI is as secure as any other storage system. And while there are many available security tools, the combination of all these tools will put you in the best position long-term to secure your storage environment.
When it comes to securing your block storage, there are no half-measures, and a trusted service provider like INAP will be able to provide valuable insight and tools to make sure your data is fully secured from start to finish.