SAN security questions

Hi,
I am new to the topic of SANs and would like to learn more about the
same, especially from the security perspective. Considering that SANs allow
for stogare from heterogenous environments, i.e. storage managed in native
Windows format of NTFS while clients vary from Windows to UNIX and Novell.
How is security managed in such environments? More specifically, how do I
restrict a set of data (in the form of files) to a set of users?

Considering that the files are stored in NTFS format, the notions of NT
security of ACEs etc. will not be applicable for UNIX and Novell users. So
how do I ensure authorized access in such cases? I have read about the
concepts of LUN masking and zoning. Since these talk in very abstract terms,
I do not understand how they will help me to set up a completely secure
environment for my SAN. Also what tools or suites are available for such
security concerns?

Thanks in advance,
Madz

(Madz) wrote in
m:

I am new to the topic of SANs and would like to learn more about
the
same, especially from the security perspective. Considering that SANs
allow for stogare from heterogenous environments, i.e. storage managed
in native Windows format of NTFS while clients vary from Windows to
UNIX and Novell. How is security managed in such environments? More
specifically, how do I restrict a set of data (in the form of files)
to a set of users?

You don't.

Considering that the files are stored in NTFS format, the notions
of NT
security of ACEs etc. will not be applicable for UNIX and Novell
users. So how do I ensure authorized access in such cases? I have read
about the concepts of LUN masking and zoning. Since these talk in very
abstract terms, I do not understand how they will help me to set up a
completely secure environment for my SAN. Also what tools or suites
are available for such security concerns?

LUN masking and zoning is as strict and factual as it gets. No standard SAN
solution offers file-level sharing of files, only LUNs and devices.
Operating systems of different types will need some other (software) way of
sharing the files (across LAN or SAN) - the SAN itself won't.


--
/Jesper Monsted

Madz wrote:
Hi,
I am new to the topic of SANs and would like to learn more about
the same, especially from the security perspective. Considering that
SANs allow for stogare from heterogenous environments, i.e. storage
managed in native Windows format of NTFS while clients vary from
Windows to UNIX and Novell. How is security managed in such
environments?

But standard SANs don't do this, a Novell server seeing an NTFS disk has no
way to read the data, anymore than it could if a Windows NTFS disk was
inserted directly into the server. What you are thinking of as standard SAN
feature is in actual fact an optional extra in the form of a SAN aware
shared filesystem.

More specifically, how do I restrict a set of data (in
the form of files) to a set of users?

If you are talking about a standard SAN (i.e. no shared devices) then tools
that come with array will typically provide some form of LUN masking so that
each server only sees the LUNs specifically assigned to it. If you are
talking about a shared SAN filesystem, then the method varies depending on
the product.


Considering that the files are stored in NTFS format, the notions
of NT security of ACEs etc. will not be applicable for UNIX and
Novell users. So how do I ensure authorized access in such cases? I
have read about the concepts of LUN masking and zoning.

Precise methods used in LUN Masking vary from one vendor to antoher, but
typically it involves binding a LUN to a specific FC-HBA World Wide Name
(WWN) which is a 64bit integer unique to each HBA (like a MAC address for an
Ethernet card.) So the array then only shows a specific LUN in response to a
query from the associated HBA, no other HBA in any server knows that the LUN
exists.


--
Nik Simpson

On Tue, 28 Sep 2004 13:24:06 -0400, "Nik Simpson"
wrote:

Madz wrote:
Hi,
I am new to the topic of SANs and would like to learn more about
the same, especially from the security perspective. Considering that
SANs allow for stogare from heterogenous environments, i.e. storage
managed in native Windows format of NTFS while clients vary from
Windows to UNIX and Novell. How is security managed in such
environments?

But standard SANs don't do this, a Novell server seeing an NTFS disk has no
way to read the data, anymore than it could if a Windows NTFS disk was
inserted directly into the server. What you are thinking of as standard SAN
feature is in actual fact an optional extra in the form of a SAN aware
shared filesystem.

While I (reluctantly) accept this as the most common usage, I am sadly
aware that this is a consequence of marketing "expansion".

In the beginning, when we said "SAN" we meant shared data, not just
shared hardware, just as "LAN" implies shared services, not just
shared wiring (and hubs, switches, etc.)

The contrasting approach (in the beginning) was NAS, which is clearly
different from (e.g.) a disk with an iSCSI interface, although that
does literally fit the acronym!

Marketroids, of course, from the hardware companies grabbed the term
and loosened it to mean "way of sharing one pool of storage among
several hosts".

Malc.

Hi all,
Thanks for the responses!! Much appreciated.

So I now gather than securing a SAN is not a generic thing, because
the files that are stored are themselves not is a standard format, nor
will the clients be from one single OS. So I guess I will have to use
some shared file system like CIFS so that users from multiple
platforms can access my files in a standard way while I can authorize
who can see what? Am I right here?

What are the SAN aware common file systems that I can use? Is CIFS
an example? Are there any more which scale better? What security
concerns arise from such shared file system installations?

Also what tools are available that allow me to manage my files
better in a SAN?

Thanks in advance,
Madz



wrote:

Madz wrote:
Hi,
I am new to the topic of SANs and would like to learn more about
the same, especially from the security perspective. Considering that
SANs allow for stogare from heterogenous environments, i.e. storage
managed in native Windows format of NTFS while clients vary from
Windows to UNIX and Novell. How is security managed in such
environments?

But standard SANs don't do this, a Novell server seeing an NTFS disk has no
way to read the data, anymore than it could if a Windows NTFS disk was
inserted directly into the server. What you are thinking of as standard SAN
feature is in actual fact an optional extra in the form of a SAN aware
shared filesystem.

While I (reluctantly) accept this as the most common usage, I am sadly
aware that this is a consequence of marketing "expansion".

In the beginning, when we said "SAN" we meant shared data, not just
shared hardware, just as "LAN" implies shared services, not just
shared wiring (and hubs, switches, etc.)

The contrasting approach (in the beginning) was NAS, which is clearly
different from (e.g.) a disk with an iSCSI interface, although that
does literally fit the acronym!

Marketroids, of course, from the hardware companies grabbed the term
and loosened it to mean "way of sharing one pool of storage among
several hosts".

Malc.

On Tue, 28 Sep 2004 11:53:57 -0700, Malcolm Weir wrote:



In the beginning, when we said "SAN" we meant shared data, not just
shared hardware, just as "LAN" implies shared services, not just
shared wiring (and hubs, switches, etc.)

I never heard it this way. SAN is just "networked" storage. Nobody I've
ever talked to thought that external storage hardware would somehow allow
a non-shared file system and OS to suddenly, magically, allow multiple
hosts to share the same data files.


Marketroids, of course, from the hardware companies grabbed the term
and loosened it to mean "way of sharing one pool of storage among
several hosts".


Not sure what you mean here either. These two ideas are not mutually
exclusive. In fact, SAN *does* allow you to pool storage among several
hostrs. At least it does for all definitions of "pool" that I've ever
heard in use.

--- jls
The preceding message was personal opinion only.
I do not speak in any authorized capacity for anyone,
and certainly not my employer.
(get rid of the xxxz in my address to e-mail)

On 29 Sep 2004 03:36:03 -0700, (Madz) wrote:

Hi all,
Thanks for the responses!! Much appreciated.

So I now gather than securing a SAN is not a generic thing, because
the files that are stored are themselves not is a standard format, nor
will the clients be from one single OS. So I guess I will have to use
some shared file system like CIFS so that users from multiple
platforms can access my files in a standard way while I can authorize
who can see what? Am I right here?

This is NOT a feature of SAN technology. Sharing data files simultaneously
between hosts and OSes is a function above hardware level. Unless the OSes
in use are intimately aware of each other host using the same files/data,
they will never be able to securely, reliably, work together.

SAN is storage, not file systems. SAN LUNs appear as devices to your
hosts. Unless you hosts and their OS understand that other hosts (and
oses) are sharing the data in some way, they can never have simultaneous
access to the LUN.


What are the SAN aware common file systems that I can use? Is CIFS
an example? Are there any more which scale better? What security
concerns arise from such shared file system installations?

File systems do not, generally, know or care what the underlying storage
hardware is - direct attached or SAN attached. They tend to be completely
ignorant of the physical characteristics of the storage.

You are confusing file systems and storage subsystems.


Also what tools are available that allow me to manage my files
better in a SAN?


There are lots of tools available, but often what you choose depends on the
vendor of storage platform you're using.

--- jls
The preceding message was personal opinion only.
I do not speak in any authorized capacity for anyone,
and certainly not my employer.
(get rid of the xxxz in my address to e-mail)

Madz Wrote:
Hi,
I am new to the topic of SANs and would like to learn more about the
same, especially from the security perspective. Considering that SANs
allow
for stogare from heterogenous environments, i.e. storage managed in
native
Windows format of NTFS while clients vary from Windows to UNIX and
Novell.
How is security managed in such environments? More specifically, how do
I
restrict a set of data (in the form of files) to a set of users?

Considering that the files are stored in NTFS format, the notions of
NT
security of ACEs etc. will not be applicable for UNIX and Novell users.
So
how do I ensure authorized access in such cases? I have read about the
concepts of LUN masking and zoning. Since these talk in very abstract
terms,
I do not understand how they will help me to set up a completely
secure
environment for my SAN. Also what tools or suites are available for
such
security concerns?

Thanks in advance,
Madz


Back to your original question :-)

For what you're trying to do, the best is a NAS environment. What kind
of Storage you use for your NAS is up to you and your requirements, can
be internal, externel via SCSI oder FibreChannel attached.
Regarding the Security apart from Domain ACL's have a look at the
Datafort from Decru or similar Appliances, which offer encryption, role
separation and user access restrictions.

Rgds,

/dev/null


--
/dev/null


------------------------------------------------------------------------
/dev/null's Profile: http://www.storagecommunity.com/foru...r.php?userid=3
View this thread: http://www.storagecommunity.com/foru...read.php?t=213

On Wed, 29 Sep 2004 18:57:06 GMT, jlsue
wrote:

On Tue, 28 Sep 2004 11:53:57 -0700, Malcolm Weir wrote:

In the beginning, when we said "SAN" we meant shared data, not just
shared hardware, just as "LAN" implies shared services, not just
shared wiring (and hubs, switches, etc.)

I never heard it this way.

Which doesn't change what I wrote, though, does it?

SAN is just "networked" storage.

Now, yes. Then, no. That's the point, see?

Nobody I've
ever talked to thought that external storage hardware would somehow allow
a non-shared file system and OS to suddenly, magically, allow multiple
hosts to share the same data files.

Well, duh!

Look: a NAS is more than just a pile of hardware with network
interfaces. A LAN is more than just a pile of Ethernet hardware.
Both of those things imply software, too.

By the current definition, *every* FC or SCSI disk can be a "SAN".
You can plug that single disk into multiple initiators, and they all
can access it. With SCSI, you'd be limited to 15 hosts with one disk,
and with FC-AL you could have 125 hosts for your single disk.

(And before you suggest that is a silly thing to do, IBM's HACMP/6000
used shared parallel SCSI devices as a failover technology, in about
1995. But we didn't call it a "SAN" precisely *because* multiple
hosts couldn't share the same data files).

Marketroids, of course, from the hardware companies grabbed the term
and loosened it to mean "way of sharing one pool of storage among
several hosts".

Not sure what you mean here either.

What I wrote. The expansion of "SAN" to _not_ imply concurrent shared
data access came about because marketing people at companies like EMC
(for whom I worked, at the time) jumped on the bandwagon.

These two ideas are not mutually
exclusive. In fact, SAN *does* allow you to pool storage among several
hostrs. At least it does for all definitions of "pool" that I've ever
heard in use.

Well, double duh!

Of *course* it does: a single parallel SCSI disk can be shared between
two hosts quite trivially (well, aside from the non-trivial stuff like
handling bus resets...): all you do is decide that one host mounts one
partition, and the other mounts another, and voila! (for almost every
host except Windows) you're happily using a pool of storage amongst
multiple host!

By today's usage, that single disk qualifies as a "SAN".

To understand the initial usage of the term, you have to understand
that SAN was the alternative to NAS: with NAS, you served storage by
abstracting the filesystem into a network one (such as NFS). With
SAN, you served it by using a multi-host-aware filesystem (such as
CXFS). In either case, the applications used, and shared, files. Not
chunks of disk.

--- jls

Malc.

On Wed, 13 Oct 2004 12:01:17 -0700, Malcolm Weir wrote:

[...] snip uninspiring diatribe

Of *course* it does: a single parallel SCSI disk can be shared between
two hosts quite trivially (well, aside from the non-trivial stuff like
handling bus resets...): all you do is decide that one host mounts one
partition, and the other mounts another, and voila! (for almost every
host except Windows) you're happily using a pool of storage amongst
multiple host!

I've worked in server and storage for just about 20 years. Shared
filesystems/shared scsi was never called a SAN. SAN - as a real term -
specifically came to be, as I recall it, when fibre channel came about.

Technically, DEC's CI-based storage for VMSclusters was the original SAN,
completely with fully cooperative, shared filesystem among the servers.
Way back before SCSI-1 even (say, around 1984 or there abouts). It was a
proprietary network protocol to communicate among hosts and storage.


By today's usage, that single disk qualifies as a "SAN".


Not by any terminology I've ever seen used, it hasn't.

To understand the initial usage of the term, you have to understand
that SAN was the alternative to NAS: with NAS, you served storage by
abstracting the filesystem into a network one (such as NFS). With
SAN, you served it by using a multi-host-aware filesystem (such as
CXFS). In either case, the applications used, and shared, files. Not
chunks of disk.


If you've got some industry publications that refered non-NAS as SAN, I'd
be interested in seeing them. Non-NAS, before FC, was always
direct-attached-storage in my experience.

--- jls
The preceding message was personal opinion only.
I do not speak in any authorized capacity for anyone,
and certainly not my employer.
(get rid of the xxxz in my address to e-mail)