RE: Designing file server file/folder structure.

["Murda Mcloud" <murdamcloud () bigpond com>]

Hey Nick, I find this quite difficult to implement easily and
'automatically' too.
We're in virtually the same boat and have department names linked to
security groups so that at some level it's easy for the logon script.
We use a CASE SELECT statement to filter which groups get which drives and
this is helpful for the main departments. I've been thinking of creating
'special' case sec groups so that they can have access to other dept drives
or just certain folders within other depts' drives. Eg
Case "ADMIN+ACCTS"
            WSHNetwork.MapNetworkDrive "I:", "\\joeserver\ADMIN",PERSISTENT
                
I'm drawing up a venn diagram to try and visualize what goes on. If I was
smart enough I could make some software to make the venn diagram the gui for
something that set perms and added users or depts. to the correct groups.
Unfortunately I'm not ;-)
            
The 'worst' thing is if there is a single file several levels down in one
dept that another dept require. I can give access to just that file and no
others but it is unwieldy as it seems to become very ad hoc.
Then of course, the other factors such as setting more granular perms.

The other side of the coin is educating users to put their files in the
right places.
"If you don't want people to read your stuff put it here. If you couldn't
care less put it here. If they can read but not change put it here."
Most of the time, because speed trumps security, then the files just end up
J:\AnywhereIfeltLikeatTheTime.

How many staff evals have I seen on the totally shared drives? 






> > -----Original Message-----
> > From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
> > On Behalf Of Nick Vaernhoej
> > Sent: Tuesday, October 07, 2008 6:35 AM
> > To: security-basics () securityfocus com
> > Subject: Designing file server file/folder structure.
> >
> > Hi,
> >
> > I have a request for ideas about how to design the folder structure on a
> > Win2K3/NTFS share.
> > What we have inherited is a  D:\ drive with a number of folders named
> > according to departments, each folder is then mapped to a drive letter
> > in a logon script.
> > Each department has access to their own drive in addition to a drive
> > everyone has access to.
> >
> > Now about 10 years have passed and just about everyone has access to
> > just about all shares because at some point an individual needed access
> > to a file or two within a department drive where they don't initially
> > belong. Perhaps the file needed access to was too sensitive to be placed
> > on the company share.
> >
> > So, after pushing for a long time I am finally making some headway in
> > acceptance of redoing the layout.
> >
> > Ideally we end up with department folders accessible only to department
> > staff, but beyond this any layout I can think of doesn't scale well.
> > My though is to begin a folder structure where folders are named based
> > on who has access, like:
> > "DepartmentA - DepartmentB"
> > If permissions are set right you only get to see folders where you have
> > files related to what you do. However, with 20 departments or so, what
> > happens when seven'ish departments needs access to a file. Folder names
> > become quite long and I doubt this scales well should the company grow
> > significantly.
> >
> > The server holds roughly 1.2TB of miscellaneous flat file data. Word
> > docs, excel spreadsheets, PDF's etc. etc. Nothing fancy. And we are a
> > Windows shop.
> >
> > What works for others?
> > Do you at some point lean back and say I can't get permissions as
> > granular as I like without being a serious nuisance to the end users?
> >
> > I feel this is rather trivial but I can't seem to come up with a
> > solution that is somewhat future proof.
> >
> > Thank you
> >
> > Nick
> >
> > This electronic transmission is intended for the addressee (s) named
> > above. It contains information that is privileged, confidential, or
> > otherwise protected from use and disclosure. If you are not the intended
> > recipient you are hereby notified that any review, disclosure, copy, or
> > dissemination of this transmission or the taking of any action in
> > reliance on its contents, or other use is strictly prohibited. If you
> > have received this transmission in error, please notify the sender that
> > this message was received in error and then delete this message.
> > Thank you.