Access Zone Design question

Question

Hello

Our company just signed the deal on two Isilon Clusters, active plus replica/stby. Mainly used for CIFS/SMB and Legal Compliant archiving. I now started reading heavily into design considerations regarding access Zones and system partitioning and have a question which seems unanswered by the design and implementation guides.

Maybe some of you can shed some light

I think I understand the principles of SmartConnect/DNS Zones, IP Pools, Access Zones and Groupnets. Nothing too difficult here (actually quite cool and clever from an architectural perspective).

We are one Company, run one Network (heavily segmented/segregated for security reasons) and use only one AD with integrated DNS as authentication source. No need for Access Zone partitioning from this point of view, in theory.

What I would like to achieve from a security perspective though, is the following:

- Client A (Subnet/VLAN "A") can access Isilon Management via Firewall only.
- Client A (Subnet/VLAN "A") can access Isilon NFS Exports from within same Subnet/VLAN.
- Client A (Subnet/VLAN "A") can access Isilon CIFS Share 1 via Firewall only.
- Client B (Subnet/VLAN "B") can access Isilon CIFS Share 1 via Firewall only.
- Client C (Subnet/VLAN "C") can access Isilon CIFS Share 1 via Firewall only.
- Client C (Subnet/VLAN "C") can access Isilon CIFS Share 2 from within same Subnet/VLAN.

Please see the following image as a graphical representation.

High Level Access Zone Design.jpg

This should be doable by the following high level config, right?

SmartConnect/DNS-Zone "management.isilon.mydomain.com" -> pool0 VLAN/subnet "Mgmt" -> Acess Zone "System" -> groupnet0
SmartConnect/DNS-Zone "nfs.isilon.mydomain.com" -> pool1 VLAN/subnet "A" -> Acess Zone "System" -> groupnet0
SmartConnect/DNS-Zone "cifs1.isilon.mydomain.com" -> pool2 VLAN/subnet "B" -> Access Zone "access1" -> groupnet0
SmartConnect/DNS-Zone "cifs2.isilon.mydomain.com" -> pool3 VLAN/subnet "C" -> Access Zone "access2" -> groupnet0

As long as basic/general IP routing is respected (specially from point of view Isilon) this "multitenant" like partitioning should also work from within one single Network with one single AD and integrated DNS environment. All from within groupnet0.

Is there an easier way of achieving this? My guess is no, since every access enumeration from a specific client/user against one specific access zone would always result in a list of "all" shares the current client/user has permission to within the specific access zone. So, shares that I want users to only be able to access through Firewall would be "exposed" in the local subnet. No hiding/exclusion possible.

DELL-Sam L · Answer

Hello CendresMetaux, Here is the link to the Security Configuration Guide. https://dell.to/3obYXwp

CendresMetaux · Answer

Hi DELL-Sam L

Thanks for your reply. I already read the Security Best Practices document and unfortunately it does not help wrt my question.

What I need is a way to completely "hide" some shares that a device/user has access right so (wrt acl and share permissions) from within the same subnet while having other shares being visible from within the same subnet.

Sort of what one one would do with separating shares to two fileservers: one fileserver in the same subnet where access from the client/user is "direct" (with no firewall with content inspection in between) and the other fileserver in a different subnet (with a firewall with content inspection in between).

Example use case: One SMB share on user/device VLAN for %homedir%, one SMB fileshare on DMZ VLAN for data exchange between security zones where all traffic passes a firewall with deep SMB inspection. Neither share should be available in any form in the "other" security zones / VLANs.

In a classic file server scenario I would simply run two separate fileservers; one in each VLAN with one SMB share respectively.

In an Isilon file server scenario, I would simply partition my Isilon cluster into multiple access zones and "link" the shares to the correct access zone, right? With "smart" use of SC Zone/DNS delegation (in case of above scenario something in the likes of "sc-lan.isilon.mydomain" and "sc-dmz.isilon.mydomain") and IP pool + access zone linking, the "same" Isilon would be visible and accessible by clients as if it was separate fileserver entities...? And hereby effectively prevent access to shares which reside on the "other" (access zone) entity since every share is bound one single access zone only.

I hope it is somehow possible to interpret what I am trying to explain

DELL-Josh Cr · Answer

Your plan sounds fine and should work.

Isilon

Access Zone Design question

Was this post helpful?