Ezine

This article can also be found in the Premium Editorial Download "Storage magazine: Is it time for SAN/NAS convergence?."

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

Isn't hard zoning the same as port-based zoning?

    Requires Free Membership to View

    Login

No, it's not. Given Brocade Communications Systems Inc.'s predominance in the market, I'm blaming them for this wide misconception. Consider the following quotes from the Brocade Zoning User Guide (Version 2.2 for the SilkWork 2800): "In a hard zone, sometimes referred to as a port zone, zone members are specified by physical port number ... In a soft zone, at least one zone member is specified by a [world-wide name] WWN."

However, they also say that in soft zoning, "the switch does not control data transfer, so there is no guarantee against data transfer from unauthorized zone members."

This sure sounds like Brocade thought that soft zoning and WWN-based zoning were the same (as well as confusing hard zoning with port zoning). While they are still separate concepts, it's true that up until now, Brocade only offered hardware enforcement (hard zoning) in a port-based zone. You couldn't do hardware enforcement with a WWN-based zone. Therefore, while the two pairs of terms weren't synonymous--they were inseparable.

Consider these restatements of the above manual quotes to bring them in line with what I've been writing: "In a hard zone, sometimes incorrectly referred to as a port zone, zone members are specified by physical port number [because Brocade didn't offer hardware enforcement of WWN-based zones] ... In a soft zone, at least one zone member is specified by a WWN [therefore, if you specify a WWN name as any member of a zone, you will get soft--or nonenforced--zoning because Brocade didn't offer hardware enforcement of WWN-based zones]."

However, in the recent releases of Brocade switches, this is no longer the case. As shown in the specification sheet for the Brocade 12000, you can now specify hardware enforcement based on a WWN, port or even a LUN. Therefore, you can now have hard zoning with a WWN-based zone.

Although SANs can be designed in a secure manner, chances are that your SAN wasn't designed that way. Why? Neither soft zoning nor WWN-based zoning offer bulletproof security, and using them together is an invitation to disaster. And yet, most SANs use both, because that's what your SAN vendor told you to do.

This second part of my series on SAN security will explain the real differences between hard and soft zoning, as well as the differences between soft zoning and WWN-based zoning because the two are often confused with each other. Let's start with a quick review of my previous article, "Protect your SAN from attack," in the August issue of Storage.

There are five aspects of security: authentication, authorization, encryption, integrity and auditing. Authentication makes sure that a server requesting a block of data really is the server that it says it is. Authorization verifies that this server is allowed to view that block of data. Encryption ensures that if authentication or authorization are somehow defeated, the data won't be used by the wrong party. Integrity ensures that when the server gets the block of data it requested, that block actually contains valid data. Lastly, auditing allows for the verification of all of the other aspects, looking for possible security breaches.

This article is mainly concerned with authentication, because without it, there's no way to verify integrity, not much point in encrypting the data and almost no point in giving different servers different authorization. If any server can masquerade as any other server, what's the point?

In the old days of direct-attached storage (DAS), there was no reason to secure the storage. You couldn't get to the storage unless you went through the server. Authorization was built into SCSI, but it was only done to ensure that requests for data were sent to the correct device. No efforts were made to verify that the entity sending or requesting the data was allowed to do so. SCSI assumed that the request was coming from a valid server because someone would have to physically disconnect the SCSI cable from Apollo and plug it into Elvis' SCSI card in order to be able to access Elvis' storage. However, in storage networks, if you don't configure things correctly, it's possible for any server connected to the SAN to see any other server's storage.

This was first published in September 2003

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