Sponsors
Sponsor Products
Isilon Access Zones w/ a single AD? Why?
posted by Rob LaRose  on Aug. 18, 2017, 10:45 a.m. (1 month, 1 day ago)
3 Responses     0 Plus One's     0 Comments  

Happy Friday, SSAors.
We're working through some models here to meet MPAA and other data-security/segregation requirements. Using Access Zones and treating each project team as a separate "tenant" on its own network is one avenue we're looking at, but I keep coming back to the question of whether there's any real benefit to it when (in our case) all zones will use the same AD authentication source.
Applying ACLs at the share level to allow only network X to access share X accomplishes that, and the shine of Access Zones fades away for me after that's handled.
Am I missing some other big benefit to Access Zones in this scenario?
Welcome the thoughts of the hive mind, especially if you're using Access Zones already.
--Rob


--Rob LaRose
engineer |rock paper scissors
245 5th ave 23rd floor new york ny 10016| O212 255 6446



Thread Tags:
  discuss-at-studiosysadmins 

Response from Julian Firminger @ Aug. 21, 2017, 5:35 a.m.
FUN ADDITION
Im not sure that MPAA would sign off on this but you could also do this, and be as safe as above.
Subnet: External = VLAN100 = public ip range 150.150.150.0/28Pool: Pool-External = 150.150.150.5-10 (static) via sip 150.150.150.4Zone: /ifs/some/larger/infra/ = \\web-mounts.domain.localShares:/ifs/some/larger/infra/teams/team-zone1/team-share1/content/public/publish \\web-mounts.domain.local\team1 SMB perm: DOMAIN\web-servers = full/ifs/some/larger/infra/teams/team-zone2/team-share2/content/public/publish \\web-mounts.domain.local\team2 SMB perm: DOMAIN\web-servers = full
ACL: /ifs/some/larger/infra/teams/team-zone2/team-share2/content/public/publishDOM\team1-users inherited dir_gen_allDOM\team1-readers inherited dir_gen_readDOM\web-servers dir_gen_all,object_inherit,container_inherit
This would then provide you with an externally accessible, public mountspace (in this case SMB):\\web-mounts.domain.local\ Team1 Team2 Team3
Then youve given each team the capacity to manage their own external footprint, without ever giving them access to anything external or passing files to another network or to a webmaster et al.


Julian Firminger

Senior Systems AdministratorUnited Broadcast FacilitiesAmsterdam, The Netherlands

On Mon, Aug 21, 2017 at 11:15 AM, julian firminger <justdigitalfilm@gmail.com> wrote:
Rob,
This depends a bit on the problem you are trying to solve. Access zones (attached to pools) in the simplest terms improves on SMB permissions in that credentials can be shared by hoomans, but access to VLANs is controlled by you.
Example./ifs/some/larger/infra/teams/team-zone1 = \\team-zone1.domain.local/ifs/some/larger/infra/teams/team-zone2 = \\team-zone2.domain.local
/ifs/some/larger/infra/teams/team-zone1/team-share1 = \\team-zone1.domain.local\team-share1 SMB permission DOM\team1-users = full SMB permission DOM\team1-readers = read/ifs/ some/larger/infra/teams/team-zone2/team-share2 = \\team-zone2.domain.local\team-share2 SMB permission DOM\team2-users = full SMB permission DOM\team2-readers = read
Pool: pool-team1 = 10.10.50.11-20 (static) in subnet VLAN50, via sip: 10.10.50.1\\team-zone1.domain.localPool: pool-team2 = 10.10.60.11-20 (static) in subnet VLAN60, via sip:10.10.60.1 \\team-zone2.domain.local
Now, for a user in team 1 to access team 2 resources, you cant just put them in the group DOMAIN\team-2-users. You also have to put them on a workstation that is in vlan60. Or have a port group on a fw that will allow traffic from that workstation to route to vlan60. (assuming you have an openly routed network but ports must traverse a fw).
The DC (say in VLAN40) is routable by both networks and holds A-Records for the two SmartConnect IP addresses. When either try and resolve the zone address, the DC forwards the request to the appropriate Isilon subnet and directs the workstation to start session setup to the Isilon resource directly, layer 2. Thus the workstation never has full or partial access to resources outside of its team. And, as an added bonus, youre not drowning the routing interface on any switch anymore. The teams are layer2 to their own resources.
In addition we can then also:
/ifs/some/larger/infra/ = \\content-processing.domain.localNFS alias /content-processing = /ifs/some/larger/infra/teams/content-processing = Client list 10.10.70.*
Pool: pool-content-proc = 10.10.70.11-20 (dynamic) in subnet VLAN70, via sip: 10.10.70.1 \\content-processing.domain.local
(note this requires OneFS v8 or later). Here youve now created a backend for render or whatever. That is network and zone independent from the teams and that resides in your MPAA approved locked datacenter with an armed guard and TSA style strip searches for entrants to the room. From our understanding, the MPAA is ok with this kind of logical separation. If the switch infrastructure is physically separated at the workstation end (and sw acls or port settings are properly configured) then the whole Isilon, including each zone, is all covered in the locked room. Ergo, no user can physically gain access to data in another team, even though inside the datacenter, the separation is logical.
If youre really paranoid, you can have multiple domains, defined as multiple groupnets on Isilon (v8 or later) or alternatively you can put RODCs in each vlan and route nbname/dns over a fw from a protected DC where you make changes. Additionally you can harden the DCs OU structure so that only members of the team-ou can even read that OU to resolve names within it.
Buuuut, it comes down to the problem youre trying to solve. And that regardless of what you do, the DC and the Isilon itself will have to be all-powerful and securing those resources is paramount.


Julian Firminger

Senior Systems AdministratorUnited Broadcast FacilitiesAmsterdam, The Netherlands

On Fri, Aug 18, 2017 at 4:41 PM, Rob LaRose <rlarose@rockpaperscissors.com> wrote:

Happy Friday, SSAors.
We're working through some models here to meet MPAA and other data-security/segregation requirements. Using Access Zones and treating each project team as a separate "tenant" on its own network is one avenue we're looking at, but I keep coming back to the question of whether there's any real benefit to it when (in our case) all zones will use the same AD authentication source.
Applying ACLs at the share level to allow only network X to access share X accomplishes that, and the shine of Access Zones fades away for me after that's handled.
Am I missing some other big benefit to Access Zones in this scenario?
Welcome the thoughts of the hive mind, especially if you're using Access Zones already.
--Rob


--Rob LaRose
engineer |rock paper scissors
245 5th ave 23rd floor new york ny 10016| O212 255 6446



To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe



0 Plus One's     0 Comments  
   

Response from Julian Firminger @ Aug. 21, 2017, 5:20 a.m.
Rob,
This depends a bit on the problem you are trying to solve. Access zones (attached to pools) in the simplest terms improves on SMB permissions in that credentials can be shared by hoomans, but access to VLANs is controlled by you.
Example./ifs/some/larger/infra/teams/team-zone1 = \\team-zone1.domain.local/ifs/some/larger/infra/teams/team-zone2 = \\team-zone2.domain.local
/ifs/some/larger/infra/teams/team-zone1/team-share1 = \\team-zone1.domain.local\team-share1 SMB permission DOM\team1-users = full SMB permission DOM\team1-readers = read/ifs/ some/larger/infra/teams/team-zone2/team-share2 = \\team-zone2.domain.local\team-share2 SMB permission DOM\team2-users = full SMB permission DOM\team2-readers = read
Pool: pool-team1 = 10.10.50.11-20 (static) in subnet VLAN50, via sip: 10.10.50.1\\team-zone1.domain.localPool: pool-team2 = 10.10.60.11-20 (static) in subnet VLAN60, via sip:10.10.60.1 \\team-zone2.domain.local
Now, for a user in team 1 to access team 2 resources, you cant just put them in the group DOMAIN\team-2-users. You also have to put them on a workstation that is in vlan60. Or have a port group on a fw that will allow traffic from that workstation to route to vlan60. (assuming you have an openly routed network but ports must traverse a fw).
The DC (say in VLAN40) is routable by both networks and holds A-Records for the two SmartConnect IP addresses. When either try and resolve the zone address, the DC forwards the request to the appropriate Isilon subnet and directs the workstation to start session setup to the Isilon resource directly, layer 2. Thus the workstation never has full or partial access to resources outside of its team. And, as an added bonus, youre not drowning the routing interface on any switch anymore. The teams are layer2 to their own resources.
In addition we can then also:
/ifs/some/larger/infra/ = \\content-processing.domain.localNFS alias /content-processing = /ifs/some/larger/infra/teams/content-processing = Client list 10.10.70.*
Pool: pool-content-proc = 10.10.70.11-20 (dynamic) in subnet VLAN70, via sip: 10.10.70.1 \\content-processing.domain.local
(note this requires OneFS v8 or later). Here youve now created a backend for render or whatever. That is network and zone independent from the teams and that resides in your MPAA approved locked datacenter with an armed guard and TSA style strip searches for entrants to the room. From our understanding, the MPAA is ok with this kind of logical separation. If the switch infrastructure is physically separated at the workstation end (and sw acls or port settings are properly configured) then the whole Isilon, including each zone, is all covered in the locked room. Ergo, no user can physically gain access to data in another team, even though inside the datacenter, the separation is logical.
If youre really paranoid, you can have multiple domains, defined as multiple groupnets on Isilon (v8 or later) or alternatively you can put RODCs in each vlan and route nbname/dns over a fw from a protected DC where you make changes. Additionally you can harden the DCs OU structure so that only members of the team-ou can even read that OU to resolve names within it.
Buuuut, it comes down to the problem youre trying to solve. And that regardless of what you do, the DC and the Isilon itself will have to be all-powerful and securing those resources is paramount.


Julian Firminger

Senior Systems AdministratorUnited Broadcast FacilitiesAmsterdam, The Netherlands

On Fri, Aug 18, 2017 at 4:41 PM, Rob LaRose <rlarose@rockpaperscissors.com> wrote:

Happy Friday, SSAors.
We're working through some models here to meet MPAA and other data-security/segregation requirements. Using Access Zones and treating each project team as a separate "tenant" on its own network is one avenue we're looking at, but I keep coming back to the question of whether there's any real benefit to it when (in our case) all zones will use the same AD authentication source.
Applying ACLs at the share level to allow only network X to access share X accomplishes that, and the shine of Access Zones fades away for me after that's handled.
Am I missing some other big benefit to Access Zones in this scenario?
Welcome the thoughts of the hive mind, especially if you're using Access Zones already.
--Rob


--Rob LaRose
engineer |rock paper scissors
245 5th ave 23rd floor new york ny 10016| O212 255 6446



To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


0 Plus One's     0 Comments  
   

Response from Julian Firminger @ Aug. 18, 2017, 11:20 a.m.
Hi Rob,
We do this kind of segmentation using a "collection" of FW rule, VLAN, swACL, isi subnet, isi access zone, smb perm, file ACL. It's a lot of work. It's robust as hell. I can stretch segments of the storage outside of our building, even into the public domain and be assured of hard separation OR even, co-existancy where external actors can have limited access to protected resources for transit/delivery via a different network segment with their own ACLs and permissions. It works spectacularly well.
Would be happy to discuss off line with you... sometime other than can-o-clock Friday. :)

Julian Firminger

Senior Systems AdministratorUnited Broadcast FacilitiesAmsterdam, The Netherlands

On Fri, Aug 18, 2017 at 4:41 PM, Rob LaRose <rlarose@rockpaperscissors.com> wrote:

Happy Friday, SSAors.
We're working through some models here to meet MPAA and other data-security/segregation requirements. Using Access Zones and treating each project team as a separate "tenant" on its own network is one avenue we're looking at, but I keep coming back to the question of whether there's any real benefit to it when (in our case) all zones will use the same AD authentication source.
Applying ACLs at the share level to allow only network X to access share X accomplishes that, and the shine of Access Zones fades away for me after that's handled.
Am I missing some other big benefit to Access Zones in this scenario?
Welcome the thoughts of the hive mind, especially if you're using Access Zones already.
--Rob


--Rob LaRose
engineer |rock paper scissors
245 5th ave 23rd floor new york ny 10016| O212 255 6446



To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


0 Plus One's     0 Comments