The Basics of SAN Security, Part I
Today, as organizations continue to broaden their reach to business partners and customers around the globe, they expose their IT systems to an ever wider range of potential security threats. Furthermore, data theft, eavesdropping, fraud, and hacker attempts increasingly threaten secure electronic information exchange within the enterprise and across public networks (e.g, such as the Internet).
Because IT systems are only as secure as the weakest link in the network, organizations need to consider outsourcing their data storage security needs to one vendor, which will help them develop a comprehensive security plan and architecture that helps ensure safe, reliable data processing throughout a Storage Area Network (SAN).
In other words, an organization needs an integrated solution that addresses a wide variety of potential security threats-thus, enabling a robust, mission-critical SAN infrastructure.
In this, the first part of a two part article on SAN security, I will look at some of the basic principles you need to be aware of when securing your SAN.
Increasing Security Concerns
The recent terrorist attacks of 9-11 and the explosion in e-business activity and Internet commerce has provided organizations with unlimited opportunities for developing new information delivery channels. At a minimum, online expansion opens up a whole new world of possibilities, such as increased efficiency, reduced costs, improved enterprise-wide communications, shorter time-to-market, and wider market reach. Organizations must be careful, however, to balance their need to expand with their ability to protect enterprise data.
Furthermore, organizations found it much more difficult to effectively secure their critical business networks, applications, and data, as the popularity of distributed client/server networks steadily rose throughout the 1990s. The potential frequency and severity of computer security incidents has only increased, because of the emergence and growth of public networks such as the Internet. As a result, for organizations participating in the e-business arena, information security is perhaps the greatest concern.
Organizations should fully define their security requirements for a SAN fabric by establishing a set of security domains, while identifying the potential points of vulnerability in their networks. These domains typically define different categories of communications that must be protected by the fabric security architecture. These domains include:
Administrator-to-security management domain: Between administrators and their management applications.
Host-to-switch domain: Between host servers and their Host Bus Adapters (HBAs), and the connected switches.
Security management-to-fabric domain: Between management applications and the switch fabric.
Switch-to-switch domain: Between interconnected switches.
Administrator-to-Security Management Domain
Administrator access controls work in conjunction with security management
functions. Because security management impacts the security policy and configuration of the entire SAN fabric, administrator-level fabric password access provides primary control over security configurations.
Individual device ports are bound to a set of one or more switch ports using access control lists (ACLs) in host-to-switch communications. Device ports are specified by world wide name (WWN) spoofing, which typically represent HBAs.
Security Management-to-Fabric Domain
A security management function should encrypt appropriate data elements (along with a random number) with the switch's public key. The switch then decrypts the data element with its private key.
The switches should enforce the security policy in secure switch-to-switch communications. By using digital certificates and ACLs, the security management function initializes switches. Switches exchange these credentials during mutual authentication, prior to establishing any communications. This practice ensures that only authenticated and authorized switches can join as members of the SAN fabric or a specific fabric zone. Furthermore, this authentication process prevents an unauthorized switch (for example, a switch in a co-location scenario) from attaching to the fabric through a port. Basic inter-fabric switch-to-switch security includes, but is not limited to: Mutual authentication performed between two switches using public key technology and digital certificates; and, switch alarms (such as Simple Network Management Protocol (SNMP) trap notifications) for authorized security management or other system managers.
With the preceding discussion in mind, let's now turn to multiple technologies and methodologies that are used to provide the highest level of security for SANs. The following discussion is about data access and security; fabric management and protection technologies; and, methodologies that provide security and management for storage area networks.
Data Integrity and Security
SAN implementations make data highly accessible; as a result, heightened network security and processes optimized for data transfers are needed. Fabric zoning establishes the way devices in the SAN interact, establishing a certain level of management and security.
So What Is Zoning?
Zoning is a fabric-centric enforced method of creating barriers on the fabric to prevent set groups of devices from interacting with each other. SAN architectures provide port-to-port connections among servers and storage devices through bridges, switches, and hubs. Zoning sets up efficient methods of managing, partitioning, and controlling pathways to and from storage devices on the SAN fabric; as a result, storage resources are maximized, and data integrity and data security are maintained. Additionally, zoning enables heterogeneous devices to be grouped by operating system, and further demarcation based on application, function, or department.
There are two types of zoning: Soft zoning and Hard zoning.
Soft zoning uses software to enforce zoning. The zoning process uses the name server database located in the fibre-channel switch. As previously mentioned, the name server database stores port numbers and world wide names (WWN) used to identify devices during the zoning process. The devices in the database receive Registered State Change Notification (RSCN) when a zone change is made. In order to change related communication paths, each device must correctly address the RSCN. Any device that does not correctly address the RSCN (yet continues to transfer data to a specific device after a zoning change), will be blocked from communicating with its targeted device.
For a specific zone, hard zoning uses only WWNs to specify each device. So that the switch can regulate data transfers by verified zone, hard zoning requires each device to pass through the switch's route table. For example, if two ports are not authorized to communicate with each other, the route table for those ports is disabled, and the communication between those ports is blocked.
Configuring Zoning Components
Zone configurations are based on either the WWN of the device or the physical port that the device plugs into. Zoning components include:
- Zone members.
- Zone sets.
A zone is made up of servers and storage devices on the SAN fabric that can access each other through managed port-to-port connections. Devices in the same zone can recognize and communicate with each other, but not necessarily with devices in other zones, unless a device in that zone is configured for multiple zones.
Zone members are devices within the same assigned zone. Zone member devices are restricted to intra-zone communications, meaning that these devices can only interact with members within their assigned zone. Unless a device is configured for multiple zones, a zone member interacting with devices outside its assigned zone is not permitted.
Identifying Zone Members
Zone members are recognized by port number or world wide name (WWN). As previously explained, a WWN is a 64-bit number that uniquely identifies zone members.
A group of zones that function together on the fabric, are known as a zone set. Each zone set can accommodate up to 256 zones. All devices in a zone see only devices assigned to their zone, but any device in that zone can be a member of other zones.
Now, let's look at the zoning limitation of logical unit number (LUN) masking. Today, fabric zoning cannot mask individual tape or disk logical unit numbers (LUNs) that sit behind a device port.
LUN masking is a Redundant Array of Independent (or Inexpensive) Disks (RAID) system-centric enforced method of masking multiple LUNs behind a single port. By using World Wide Port Names (WWPNs) of server HBAs, LUN masking is configured at the RAID-array level. LUN masking also allows disk storage resource sharing across multiple independent servers. A single large RAID device can be sub-divided to serve a number of different hosts that are attached to the RAID through the SAN fabric with LUN masking. So that only one or a limited number of servers can see that LUN (e.g., disk slice, portion, unit), each LUN inside the RAID device can be limited.
LUN masking can be done either at the RAID device (behind the RAID port) or at the server HBA. It is more secure to mask LUNs at the RAID device, but not all RAID devices have LUN masking capability. Therefore, in order to mask LUNs, some HBA vendors allow persistent binding at the driver-level.
Persistent binding is a host-centric enforced way of directing an operating system to assign certain small computer system interface (SCSI) target IDs and LUNs. For example, a specific host will always assign an SCSI target ID to the first router it finds, and LUNs to three tape drives attached to the router. Operating systems and upper-level applications (such as backup software) typically require a static or predictable SCSI target ID for their storage reliability; and, persistent binding affords that happening.
Fabric-to-fabric security technologies permit Access Control Lists (ACLs) to allow or deny the addition of a new switch to the fabric. By controlling whether routed packets are forwarded or blocked at the router Interface are how access lists filter network traffic. For example, access lists can allow one host the right to access a certain part of the network and deny another host that same access. Access control lists provide a basic level of security for accessing the network.
So, for authenticating the identity of a new switch, Public Key Infrastructures (PKI) technology can be applied as a mechanism. Additionally, so that a new, out of-the-box switch does not become a non-secured access point, fabric-wide security databases help to ensure that all new authorized switches added to the fabric inherit fabric-wide security policies.
To allow or deny a particular host's Fibre Channel (FC) HBA from attaching to a specific port, host-to-fabric security technologies can apply ACLs at the port-level of the fabric. This would prevent an unauthorized intruder host from attaching to the fabric via any port. The host's ability to log into the fabric is explicitly defined and is allowed with this model.
To ensure that a trusted and secure management console-to-fabric communications layer exists, management-to-fabric technologies can use PKI and other encryption (such as md5) technologies. PKI and other encryption help ensure that the management console or framework used to control the fabric is authentic and authorized. In addition, encryption methodologies can restrict the number of switches on the fabric from which management and configuration changes are propagated to the rest of the fabric. That will create a SAN with a minimal number of security control points.
Configuration Integrity Technologies
Finally, configuration integrity refers to technologies that ensure propagated fabric configuration changes only come from one location at a time, and are correctly propagated to all switches in the fabric with integrity. The use of a a distributed lock manager is one way of ensuring that a serial and valid configuration change is enabled on the fabric.
Summary and Conclusions
Part I of this article has emphasized in no uncertain terms that locked doors are no longer sufficient to protect vital information, as new information delivery channels transcend traditional borders. Organizations, more than ever (while enabling flexibility and growth to provide the proper balance for the corporate security strategy and policy organizations) need to leverage advanced security solutions that minimize risk.
Therefore, by delivering shared storage in open, non-proprietary environments via any-to-any connectivity, SAN implementations make data highly available. Unless well thought out security policies are put into place to manage how devices interact within the SAN, the advantage of any-to-any connectivity can be a liability. In order to ensure data integrity, and to prevent unwanted access from unauthorized systems and users, shared storage in a SAN environment requires safeguards. Part I of this article briefly explored some of the technologies and their associated methodologies used to ensure data integrity, and to protect and manage the fabric. Each technology has advantages and disadvantages; and, each must be considered based on a well thought out SAN security strategy, developed during the SAN design phase.
Moreover, it is unwise to expect that the required level of security can be achieved from any one of the previously discussed technologies, independent of all others. Therefore, in order to ensure that the SAN is secure from unauthorized systems and users, the astute outsourced information storage architect (vendor) clearly understands that in a heterogeneous SAN environment (with diverse operating systems and vendor storage devices), that some combination or all of the aforementioned technologies could be required.
Finally, as the SAN infrastructure evolves and as new technologies emerge, the SAN security strategy must be periodically addressed. All in all, this will ensure that the proper level of security is maintained and the SAN fabric is properly managed.
But, wait! I'm not finished yet! A discussion of SAN security would not be complete without briefly touching on Fibre Channel security; and the benefits of SAN security itself. In Part II of this article we'll briefly discuss the Fibre Channel security areas to manage: configuration management, SAN access, and authentication and authorization. Finally, Part II also discusses the further realization of the benefits of securing Fibre Channel technologies and SANs.
See All Articles by Columnist John Vacca