Fibre Channel (FC) has more security mechanisms built-in than most people realize. They are largely underutilized and misunderstood, so SANs are said to be a security problem. This Storage Basics issue will explore FC zones: the easiest and most incorrectly configured feature of FC switches.
Any decent FC switch will allow you to configure zones. Zoning is very similar to Ethernet VLANs: it lets you fence off traffic. Zoning is more effective than VLANing because there's no chance that traffic will "leak" between the partitions.
An FC Zone is much more than a VLAN, conceptually. Zones seem more complex at first glance, but hidden within their complexity is simplicity. A device node, or WWN, can live in multiple zones at the same time. This capability should really be abused! Creating sane and manageable zone configurations requires a certain structure — more on that in a minute.
There are two types of zones: soft and hard.
Soft zoning means that the switch will place WWNs of devices in a zone, and it doesn't matter what port they're connected to. If WWN Q, for example, lives in the same soft zone as WWN Z, they will be able to talk to each other. Likewise, if Z and A are in a separate zone, they can see each other, but A cannot see Q. This is the complexity part; a feature that isn't widespread in Ethernet switches.
The concept of soft zones is not hard to grasp. It simply means that the enforcement relies on the WWN of the node in the fabric. The benefit to using soft zones is that you can connect to any port on a switch, and know that you'll have access to the other nodes you're supposed to see.
Is this a good thing? No. Not at all. Starting with the manageability aspect, softly-zoned environments are a mess. You need to know where a node is connected for maintenance purposes. If soft zones are used, there can be no port description on the switch, because it will likely become out of date quickly. Next, soft zoning imposes certain security risks. Nobody, as far as everyone believes, has ever seen a hacker attempting to spoof WWNs, but it is possible. Changing a device's WWN so that it's zoned differently would be quite difficult, since the attacker would have to know what WWN is allowed to access the zone he wants. You don't leave switch configurations in publicly-accessible places, do you?
Hard zones are more like VLANs in the Ethernet world. You place the port into a zone, and anything connecting to that port is in the zone, or zones, which are configured for that port. Sure, it is less secure in the event of a physical attack where someone is able to move fiber connections. However, do you really need to worry about that? The preferred configuration for SAN bliss is thusly: hard zoning on the switches, and WWN restrictions for LUN access on the targets. Your storage array should employ WWN masking, so that multiple initiators can be zoned such that they can both see the target.
People dream up some horrific zoning schemes. Grouping similar operating systems together may seem like a good idea, but it makes no sense in reality. Back in the day people used to scare easily at the thought of Windows servers being zoned together with storage arrays that other OSes use. Windows pops up a "do you want to initialize this new volume?" dialog when it sees new LUNs, and if the click-happy Windows administrator decided to say yes, he just destroyed someone else's LUN. With LUN masking on the storage array this is not a concern.
Zoning Best Practices
Many schools of thought for zoning best practices exist. Most agree that soft zones are a nightmare, and they are. We're going to assume hard zoning from this point on. Remember, each node should have two HBAs, but each HBA will be in a different fabric, on different switches, for redundancy. Each switch should have the same zoning configuration.
The "single initiator zones" camp believes that you should create zones based on the initiator. This means that each zone will contain a single host, or initiator. Multiple storage array ports can be added to the zone without violating the single initiator rule — arrays are the targets. This method makes the most sense, because you can quickly see which arrays your host can access in the configuration.
Others like to zone based on their targets. After all, each target will allow a certain number of hosts to access it, so we may as well just create a little mini-network out of all these like-minded initiators. Some storage administrators get nervous with the thought of multiple initiators being able to see each other, but it's nice in some situations. When a server reboots, other servers in the same zone will report that "node X disappeared from fabric" in syslog. The benefit to target-based zones is that you can quickly see which hosts have access to a specific target.
Remember, each "zone" is really just a two (or more)–way communication mapping between nodes. One port on a storage array will likely live in multiple zones (in single-initiator style zones), each containing hosts, AKA initiators.
Some people like to skip zoning altogether. For stability reasons alone, this is not recommended. A fabric reset will cause everyone to re-login at the same time, and fabric updates get sent to everyone. The potential for security issues exist as well, but in reality it's rookie mistakes that you must be most wary of.
Your zone configuration decisions are very important, so take some time to decide which style of hard zoning works best in your environment.
Article courtesy of Enterprise Networking Planet