Ezine

This article can also be found in the Premium Editorial Download "Storage magazine: Exploring the most innovative midrange systems."

Download it now to read this article plus other related content.

The three faces of security
There are three primary concerns for data security: confidentiality, integrity and availability. Each has its own challenges, and each can be addressed with different solutions.
Confidentiality is focused on restricting the visibility of data. To ensure confidentiality, you should limit access through passwords and encryption.

    Requires Free Membership to View

    Login

Integrity ensures that data can't be modified without authorization. Access control is critical, but accounting is also important. Logging writes to a secure log server can help to identify the cause of scrambled data, and checksums can be employed to detect changes. But beware: A weakness was recently demonstrated in the popular MD5 checksum algorithm.
Availability is the most visible aspect of security, as well as the most common failure. Availability is protected differently than confidentiality and integrity. Standard practices for high availability include redundancy, protection of configuration and management interfaces, and the simple act of deploying highly reliable equipment.
Designing for security
The No. 1 consideration when designing an IP SAN is to treat it like an FC SAN. One of the things that makes FC so strong is that FC networks are small, tightly controlled and separated from other applications. The same precepts should be followed when designing the IP SAN: Only use iSCSI over private, tightly controlled LANs.

"The best IP SAN is an independent LAN using dedicated Ethernet switches," says Sanrad's Sante. So-called "air-gap" LANs are entirely disconnected from other Ethernet networks, and don't share the same hardware. At the very least, segmented VLANs and IP subnets should be employed to keep other traffic types away from your storage. And don't forget to secure the management interfaces on non-routed networks. Ideally, you should create a separate subnet for network management and allow only authorized users to access it through a VPN and firewall.

Without a tightly controlled, segmented network, iSCSI traffic and usage is likely to "leak" out of the data center. It's dangerous to allow PCs to access iSCSI devices from other parts of the network. One of the first things I did when testing an iSCSI array was to mount a LUN on my laptop over wireless Ethernet. Although functional, this type of connectivity is a security nightmare. Therefore, limit the reach of the IP SAN to the data center.

Follow these policies
If you're considering deploying iSCSI, you should follow these policies:

  • Build a SAN, not a LAN. Treat iSCSI just as you would treat FC. Build a dedicated network for storage, and don't share switches or network cards between storage and other network traffic.
  • Divide and conquer. Use ACLs and other LUN masking techniques to limit access to iSCSI LUNs to only valid clients.
  • Lock the door. Use a separate, strong CHAP password for each iSCSI client and consider changing the passwords periodically.
  • Restrict management. Use role-based security and accounting in management applications; limit even your own access to avoid accidents; and build a separate firewalled subnet for management interfaces.
  • Encrypt data. Consider using client-based encryption to protect data across the network and on the disk, but be careful with your encryption keys.

Policy vs. practicality
Security policies shouldn't be so difficult to administer that they're ignored. Put another way, security measures must not be so extreme as to encourage non-compliance.

For example, the management of IP Security (IPsec) keys is one area where practicality might outweigh security. Unless an automated key management system is in place, the headache of tracking keys could cause the system to be bypassed altogether. Similarly, enforcing both strong passwords and requiring frequent password changes often leads people to adopt a system of sequential passwords or, even worse, of leaving unsecured passwords on slips of paper or in computer files. Adopting a policy of strong passwords or one of frequent changes is often preferable to trying to enforce both.
These policies aren't difficult to adopt, but care should be taken to ensure that they're easy to administer. If it becomes burdensome to apply security policies, they may be circumnavigated or ignored (see Policy vs. Practicality, this page). Adding storage devices that aren't networked with FC to the SAN yields dividends, including improved disk utilization and enhanced stability with more systems using enterprise-class hardware. There's also more flexibility to provision storage devices where they're most needed and to deploy advanced features like array-based replication, mirroring and clustering. The key is facing the fact that security is a critical factor in all storage architectures, whether they are based on FC or IP and Ethernet.

This was first published in March 2005

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top