|
Posted by Roger Abell [MVP] on November 24, 2006, 3:52 pm
Please log in for more thread options oops - one somewhat critical miswording corrected below . . .
> Personally I feel it is best to use whatever one has available
> to effectively accomplish a security objective. That is, by
> voluntarily electing to not use a layer of protection (or potential
> protection) one is electing to use less of a safeguard than is possible.
>
> Now, in your specific case, if there are no errors in NTFS permissions
> then what is defined as allowed is all that will be allowed. If someone
> could have permissions within the NTFS area (and all in that area is set
> with permissions as should be), then it would not matter whether the store
> was separate or within a single share - that is, if they could get past
> the
> NTFS grants (again, and I emphasize, assuming that these are as intended)
> then they would also be able to pass the preceding sharelevel test in
> either
> design. However, if the NTFS permissions do become other than intended,
> then (depending on what is used at the share level for the separate share
> scenario) quite possibly in the single share design inappropriate access
> might be allowed whereas the separate share design would have blocked
> the access attempt at the share level. Remember in evaluating this that
> there
> are two scenarios to consider - incorrect NTFS on some part and incorrect
> membership in groups.
>
> What I would recommend is that you build a security template that only
> contains NTFS permissions for the shared area(s) - I say (s) due to the
> next part of this. This template can be used to evaluate the storage area
> to determine whether any part of it, down to a single file, has NTFS
> permissions set differently from the planned. The template can also be
> applied in order to set the permissions per spec. Use of the template
> can be automated with secedit. Although the template could be imported
> into a GPO I would not recommend that.
>
> OK, so use of the template can rule out the one possibility that would
> justify the HR director's concerns.
>
> Were I in your case, I would identify the stores of high concern for
> privacy, compliance, etc.. These I would not just make separate shares,
> but I would also make the only shares from the partition on which each
> is stored. To present the view that you are after, with a single mapping
> for all I would map a DFS root, and into this all shares would tie-in.
> There are now three, not just two, levels of control. There are still the
> NTFS and share level permissions, but now there is also the NTFS
> permissions on the DFS skeleton that you could use. The highly sensitive
> stores are prescribed to be the only shares on their individual
> permissions
on their individual partitions (not permissions!)
> in order to prevent inadvertant NTFS permissions misalignment due to
> users doing an intra-partition move (which retains the explicit NTFS
> permissions). I would still have a template (or a few if multiple servers
> source out the shares) that specifies the NTFS permissions for all that is
> tied into the DFS and the DFS skeleton. (Note that in the
> template/templates
> one can also specific Audit failed access attempts by Everyone for all or
> any part of the store). Finally, I would then strongly suggest that use
> of
> ABE (access based enumeration) be considered, as well as making the
> DFS redundant by adding a second replica set to it.
>
>
>>I work for a compagny of 800 users.
>>
>> We used to have 348 shares containing departmental data. No need to
>> say it was hell to manage rights and especially login scripts.
>>
>> I've done a big clean-up and managed to bring everything into 1 share
>> and give specific ntfs rights to each departments, ie.: accounting, hr,
>> sales, etc. I'm mapping that drive to everyone in the company and
>> everyone has the "List" right at the root folder to see every
>> department name.
>>
>> I'm also wrapping my permission in global security groups. IE.:
>> Security_Production_Read group has list permission on the root folder
>> and read permission on the Production folder. This way, admins don't
>> have to log on the server to give permission to a department folder to
>> a user.
>>
>> Ex:
>> \Server\Departments$\Accounting
>> \Server\Departments$\Human Resources
>> \Server\Departments$\Production
>>
>> When I told the HR Director I wanted to move his data in the a share
>> that everyone in the compagny sees, he really didn't like that idea.
>> He's afraid that if a mistake is made assigning rights, it could go
>> unoticed and his data would be compromised.
>>
>> So my question really is, Is it an acceptable security practice to map
>> a drive containing folders with sensitive data to all the company if
>> access to the sensitive folders is controlled with NTFS permissions.
>>
>> Thanks for your input.
>>
>
>
| 
XML Sitemap