The 12 Commandments of File Sharing

File shares can be a vital exchange point for collaborative user files that are too large to send as email attachments. Aside from the convenience of easy user access, these shares typically exist on a server with redundant storage solutions, which minimizes the potential of losing data through disk failure because you can back up data centrally rather than having to back up each user's client PC. (Anyone who has paid a data-recovery service $1000 to $3000 to pull crucial data from a failed desktop PC hard disk can appreciate the value of file-server storage redundancy.)

For these reasons, file shares are a commonly used resource. However, file sharing is also a highly vulnerable practice, and if you don't know what you're doing, you can put corporate data at risk. I've discovered that many systems administrators don't really understand how share and NTFS permissions interact and don't have a solid overall plan for their shared-folder resources. To help you analyze your current shared-folder environment and perhaps pick up a few new best practices, I've put together the following 12 commandments of file sharing.

1. Develop Standard Permissions
Although each share owner will eventually grant customized permissions to particular groups on that share, you need to develop a standard group of permissions to put on all shared folders when you create them. Typically, this set of permissions will be Administrators and System-Full Control. Also, consider using a Global Deny group that specifies Deny for all permissions settings. (See commandment 9 for an explanation of this group.)

2. Keep the Permissions Simple
A simple permissions structure is easier to manage. Yes, you can create 47 groups to manage a file share and assign permissions at a number of different levels, but is doing so a good idea? If you don't help share owners think through the initial structural requirements for their file-share permissions, you're doing them a disservice. Often, the requirements that share owners start out with are actually an unrealistic wish list that will make managing the share point difficult for both IT and the share's owner.

When a share owner outlines an elaborate permissions structure, try to see whether you can achieve similar results with a simpler approach. In some cases, the owner will be a manager who will explain that he or she needs to protect data from employees. Statements such as "We need to keep Jim from seeing this data because he might misuse it" or "We can't give Sally Change permissions because last year she accidentally dragged one of our key data folders off the server onto her desktop" indicate that some past training problems or departmental politics are driving the requirements for overly complex share permissions. Perhaps a better solution is for Jim to take an ethics course or for Sally to get some basic computer-etiquette training.

3. Use Security Groups
The Microsoft certification training courses encourage the use of security groups instead of individual user accounts for assigning permissions. Most of you start out diligently following that advice, but things can quickly deteriorate into a permissions free-for-all, and you begin assigning permissions to individual users. After you begin the slide down this slippery slope, administrative overhead can become a nightmare. If additional users require similar permissions, you have to duplicate or clone user permissions with a third-party tool such as Small Wonders Software's Security Explorer. If the file share is large, flowing down the cloned permissions can take hours. Unless you keep detailed documentation, you might lose track of which permissions a user actually has and you'll need to use your third-party tool to create reports that contain that information. To avoid these pitfalls, the best approach is to always assign permissions at the group level.

4. Give Groups Succinct and Intuitive Names
Give your security groups names that identify the permissions that group members have and which file shares those permissions apply to. This naming approach gives you a direct mapping of groups to file-share locations and makes life easier for the security or Help desk team that will populate the group with new employees after the initial group and share are set up. Try to keep the names to fewer than 20 characters and avoid spaces and ampersands (&). These steps will make command-shell scripting operations to assign or capture share permissions easier because some commands, such as the Net Localgroup command, don't support names longer than 20 characters. Table 1 shows how you can make a relatively short security group name communicate the share and subfolder location and the permissions the group has on that folder.

   Previous  [1]  2  3  4  Next