This article first appeared in "Storage" magazine in their March issue. For more articles of this type, please visit www.storagemagazine.com.
What you will learn from
this tip: A few different ways to lock down your iSCSI SAN, and the limitations of each.
There are five specific ways to lock the door to an iSCSI SAN. Each one can help to secure your IP SAN, but also has its limitations. Used in concert, however, these methods can vastly increase the security of your storage.
1. Use access control lists (ACLs). ACLs allow an administrator to limit who can see what in an IP SAN. Most systems support ACLs based on IP address, which is a good start but simple to defeat. Another method is to use the initiator name of an iSCSI client. Like an FC world wide name (WWN) or Ethernet media access control (MAC) address, an initiator name should be a unique identifier for each iSCSI host bus adapter (HBA) or software initiator. However, like a WWN or MAC address, initiator names are simple to override, especially with software-based iSCSI drivers. ACLs, like FC LUN masking, should be seen primarily as a means of dividing storage resources among clients, not as a strong security method.
2. Use a strong authentication scheme. Authentication protocols like Challenge Handshake Authentication Protocol (CHAP) securely identify clients with user names and passwords. Passwords are never sent over the network in plain text, and the protocol is widely trusted by network administrators. But the passwords must be stored at each end of the connection, sometimes even in a plain text file. Remote Authentication Dial-In User Service (RADIUS) moves password authentication off the iSCSI target to a central authority, but can be tricky to set up and clients can still be breached.
3. Secure management interfaces. One important lesson from the world of FC security is to focus on securing the management interfaces for storage devices. No matter how secure the SAN is, a user of the management application can reassign storage to change, snoop or destroy data. Keep management interfaces on secure LANs and use strong passwords for management accounts. Make sure your vendors don't leave backdoor accounts with well-known passwords. Role-based security and activity accounting can be helpful forensic tools; if your storage system supports these techniques, use them.
4. Encrypt exposed network traffic. IP security (IPsec) is a standard protocol for encrypting and authenticating IP packets. IPsec supports two encryption modes: Transport and Tunnel. Transport mode encrypts only the data portion (payload) of each packet, but leaves the header untouched. The more secure Tunnel mode encrypts both the header and the payload. On the receiving side, an IPsec-compliant device decrypts each packet. For IPsec to work, the sending and receiving devices must share a public key. Vendors and consultants recommend using IPsec to encrypt all iSCSI traffic that leaves a secure network. It can be a strong security measure, but can also greatly impact network performance. For this reason, software implementations of IPsec should be avoided unless absolutely necessary.
5. Encrypt data at rest. Strong encryption of data on disk is widely available and proven. The question is whether this task occurs on the client (an encrypting file system), in the network (an encryption appliance) or on the storage system. A strong case can be made for the first option -- most enterprise operating systems (including Windows and Linux) have excellent file system-based encryption technologies, and encrypting data before it reaches the network ensures that it's encrypted all the way through the wire. If the CPU overhead of such a scheme is a concern, moving the task of encryption to a network- or array-based device is a possibility, although some data protection is lost. One word of caution: Encryption can also lock you out of your own data if you lose the key.
Read the whole tip in Storage magazine.
For more information:
Fast Guide: iSCSI
About the author: Stephen Foskett is the director of strategy services at GlassHouse Technologies, Framingham, Mass.
This was first published in April 2005