Storage area networks (SANs) are supposed to make data available to more users more easily, by linking multiple...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
storage devices on a dedicated network. But, as so often happens, the needs for user access bumps up against the need to keep that data secure.
Currently, with most SANs in only limited use, the greatest risk isn't hacking but simple mistakes, such as a Windows and Unix server overwriting the same data. But as more users and administrators share space on SANs, it will become harder to secure the physical devices (such as RAID arrays or tape libraries) and logical resources (such as volumes on disks) within the SAN. Then there is the threat of spoofing, where a hacker assumes the identity of a user or administrator to break into a storage network.
What follows is a breakdown of the areas of vulnerability and the tools storage managers have now (and can expect) to secure their SANs. These vulnerabilities include the user, the application server/host and the storage administrator.
The user: While not strictly part of the storage network, there's always a threat that a user with legitimate access to some data on a SAN could then surf through other data or use administrative tools to open the SAN to others. For now, storage managers have to rely on whatever authentication and access control (such as passwords) is applied at the application or network levels.
The application server/host: Again, basic security rules apply, such as updating all patches to the server and doing what you can to "harden" the operating system against attack.
Between the server and the storage switches: Here's where you can use existing management tools for at least some security. One is LUN (logical unit) masking, which restricts the portions of a storage array that any host can see. Zoning divides the storage network into groups of servers, switches or storage arrays that can communicate only within their zone.
"Soft" zoning, also known as software-based zoning or name-server zoning, determines which ports are members of a zone by examining their port numbers or WWNs (World Wide Names), a unique numeric identifier assigned to a device. "Hard" zoning relies on the switches' route table to prevent any traffic at all to devices whose WWNs aren't in its route table.
"Persistent binding" directs an operating system to always use the same logical route from the host to a specific LUN on the network. Still another approach is Virtual SANs, or VSANS, which Cisco Systems Inc. plans to introduce later this year. VSANs are multiple separate Fibre Channel SANs running on the same hardware infrastructure, says Thomas Nosella, manager of technical marketing for Cisco's storage technology group. If one VSAN is compromised, he says, the vulnerability will reach "only as far as that virtual SAN."
One weakness in relying on management tools for security, says Wayne Lam, vice president of storage management vendor FalconStor Software, Inc., is that they can be compromised by anyone who gets administrative rights to the network. That makes the storage administrator a key factor in SAN security.
The storage administrator: With relatively small SAN deployments, many customers can keep SANs on separate networks, managed by consoles protected by locked doors accessible by only a few administrators. But as SANs serve more departments within an organization, more administrators will need various levels of administrative rights to them.
Two major vendors provide such capabilities in the equipment they sell to storage suppliers such as EMC Corp., IBM and Hewlett-Packard Co. Brocade Communications Systems Inc.'s Secure Fabric OS is a system of trusted switches that use key-based encryption and authentication to ensure administrators and users are accessing only proper parts of the storage fabric. McData Corp. uses database-locking techniques to limit access to zoning parameters to one authorized administrator at a time, as well as digital signatures to authenticate those administrators.
To ensure that only legitimate administrators can change the configuration of specific parts of the storage network, Cisco also plans Role-Based Access Control that will govern the types of commands different users can carry out on the system. A number of vendors are planning to use Version 3 of SNMP (the Simple Network Management Protocol) as a security tool.
FalconStor takes a centralized approach to storage management and storage security. FalconStor's IPStor is a specialized storage server that is roughly comparable to the central file server in a local area network and provides public key infrastructure-based security credentials for each device or each administrator, says Lam.
To the extent that storage traffic flows over IP networks, customers can use the well-proven IPsec protocol, which provides authentication and encryption of network traffic. On the Fibre Channel side, a version of IPSec for Fibre Channel, called FCSec, is under development, as is the digital certificate-based Switched Link Authentication Protocol (SLAP) to create "trusted" switches. Many observers say encryption, of either data or of SAN management traffic, will be most critical for IP-based storage networks that extend further than Fibre Channel networks and are more susceptible to IP-based Web hacking tools.
Even as standards bodies hammer out security protocols, storage managers should be sure the "powerhouses" of Brocade and McData support those standards, says Scott Robinson, chief technology officer of Datalink Corp. in Chanhassen, Minn, which designs and builds storage systems. "If they're not on board together" supporting a standard, he says, customers risk incompatibilities between their products.
It might too soon for you to be facing actual SAN security threats. But it's not too soon to begin preparing for them, sometimes with the storage management tools you already have in hand.
About the author
Robert L. Scheier writes frequently about storage from Boylston, Mass. He can be reached at firstname.lastname@example.org