Zone security considerations for SANs: overcoming inadvertent overwrites - Storage Networking

Computer Technology Review, Oct, 2002 by Christine Taylor Chudnow

Securing a SAN from external assaults is not particularly hard, since most SANs are located behind thick firewalls with zealously guarded network access. The real challenge to SAN security is not external predatory assault, but inadvertent overwriting. Overwriting isn't sexy, but it can be catastrophic.

The problem is native to SANs' any-to-any connectivity. SANs connects hosts and storage devices over a network fabric and creates virtual storage pools from multiple sources. Like a spider web, all sorts of SAN elements can see each other over the fabric, hosts, storage subsystems, libraries, switches, hubs, routers and host bus adapters. To place some order on the incipient chaos, SANs use unique identifiers called logical unit numbers (LUNs). Located in SCSI buses, each LUN under the SCSI-2 specification can support up to eight LUNs per target. Units represent a variety of storage elements, including individual disks, groups of disks, or individual parts of multiple disks defined by a RAID controller or other intelligent storage controller. (The eight-LUN limit is expanding as newer protocols expand LUN addressing capabilities. SCSI-3 specifies an encoded 64-bit identifier, although both storage device and its host's HBA must use SCSI-3 to use the expanded LUN capability.

LUNs allow SANs to break its storage down into manageable pieces. For example, storage management software virtually partitions a 12GB disk into two or three segments of 3 or 4GB each, each with its own LUN identifier. It then assigns each LUN to one or more servers in the SAN. If a LUN is not mapped to a given server, that server cannot see or access the LUN. But the servers that can are not always polite about it. Here's how it works: When the SAN initializes its SCSI systems, each SCSI bus's HBA driver will discover the targets that are attached to the bus. In turn, the targets report the LUNs they are connected to, and the HBA passes on the numbers to the initiating systems. These systems can then access the LUN-addressed storage units. The problem is that SCSI-2 allows multiple initiators to access the same LUNs at the same time--with each host initiating a different operation. This results in multiple initiators overwriting each other's data, which is never a good thing in a SAN. Or anywhere else.

Operating systems do offer native levels of LUN protection. UNIX can assign user access rights to specific LUNs and protect them that way, so as long as the UNIX environment consistently observes the same rights, they'll secure their LUNs. Windows NT handles LUN security by writing a signature on each one and guarding it against duplication. Unfortunately, Windows NT has a whatever-I-see-is-mine mentality, and assumes that each LUN it finds must belong to the Windows scheme. This overrides the UNIX security features, and mass chaos ensues. This type of problem is critical in SAN environments, which might sport hundreds of HBAs, storage subsystems and controllers, and supports hundreds to millions of nodes.

Several technologies are available to handle LUN security. Hu Yoshida, Hitachi Data System's CTO, lists the four primary approaches to securing LUN-addressable data:

Host software: When servers request data from a storage pool, host-based middleware intercepts I/O requests and routes them over the network to a specialized file server. This file server reserves target LUN identities before passing on the request to the storage pool host, and releases them when the operation is complete.

Host bus adapter utilities: HBA utilities use small bits of software code called drivers to mask LUNs. LUN masking keeps the unit numbers invisible to unauthorized hosts, and is based on the unique WorldWide Name (WWN) that is stamped on Fibre Channel node chip sets.

Switch zoning: Provides LUN masking down to the port level for all nodes that the switch can see. All hosts connected to the same port will see all the LUNs that port addresses, though the switch cannot mask individual LUNs that belong to the port.

Mapping within a storage controller: Maps Fibre Channel HBA WWNs against the controller's LUNs. This allows multiple host bus adapters (HBAs) to access different LUNs through the same storage port.

Host Software

In this model, middleware intercepts 110 requests from requesting servers (initiators) and redirects them to a controlling file server. This server processes file pointers, secures and locks the LUNs, and sends the I/O request to the actual storage pool host. Host software centrally manages security and locking through to the block level by managing allocations, authorizations, authentications, and locks. The server communicates across the SAN using standard file systems such as NTSF, though some vendors such as Data Direct use proprietary file systems.

For example, Tivoli's SANergy is a SAN redirector that assigns a SAN server to act as a metadata controller (MDC). The MDC receives the 110's data request, identifies its targets such as logical disks on a RAID array, mounts the requested LUNs, formats them with their native file system, and handles the redirected file requests. Although this process takes an extra step, the MDC only transmits file pointers, not the entire file. And since SAN speeds are so much faster than LANs, latency is not an issue. Other approaches are less extensive: HP/Transoft, for example, uses a Qlogic HBA and modified driver to allow users to drag and drop LUNs between Windows NT systems without rebooting. The software presents a storage pool as a single logical unit.