We've looked in a previous How To at how to deal with users on a personal basis in order to protect corporate systems against misuse and security problems. The personal side of user management is, of course, merely half of the story - there's plenty of technology out there that we can use to help us nail down the integrity of our corporate systems.
Role-based file permissions
The first obvious thing we need to do is lock down the file and directory permissions on our networked systems so that only the people who need access to something have that access. Generally speaking, this means setting the access controls on our various servers so that each person's access is restricted appropriately.
Role-based permissions are all about defining who can see what, based not on who they are, but on what they do. Corporate systems are generally provided based on the job in hand, not the personality of the person using them - so access to the sales contact database would be granted to sales staff, access to the yearly budget figures might be granted only to accounting staff of a particular grade, or higher, and so on. Although there is an initial administrative overhead in defining the permissions that relate to each role, once they're defined it's generally easy to use them since you merely drop people into the appropriate groups (roles) and they magically have access to everything they need to do their jobs.
You do, of course, have to permit some ad-hoc working. You do sometimes find individuals who have more than one role in the company, or who need one-off access to some resource or other because they're working on a project that requires it. No problem, just define the appropriate roles and implement the permissions – but try to consider everything within the bigger organisational picture and attempt to keep ad-hoc stuff to a minimum.
The next step up from file access is application access. With modern tools such as domain-wide profiles and licence control, it's perfectly feasible to provide users in a given role access, not just to specified filestore areas but also to particular applications. So, as well as giving the sales staff access to the sales contact database, you'd probably allow them to run the ACT/GoldMine/Maximiser installation as well, whereas you wouldn't give this feature to (say) the guys in Engineering. By using concepts such as roaming profiles you can even provide a location-independent desktop to each user (so that wherever they log in, the PC is reconfigured to run the software they need and to populate the desktop with all the stuff they've put there). Although if you're taking this approach you need to do some planning (if you're not careful, you'll find that every time a user logs in it copies 300MB of crap across the network just because that's what the user happened to dump on their desktop last time they were logged in).
One obvious way to prevent user password sharing is to prevent users from logging in on more than one PC at once. So even if a user does shout their password to their friend, the latter gets a "You're already logged in" message. Naturally, this doesn't prevent someone from logging in under someone else's ID when the ID's rightful owner isn't there but it's a start. To extend the concept, you could even dictate that particular users are only permitted to log in on particular PCs, but again this isn't foolproof (someone else could use that person's ID when they're away) and it can cause support headaches if someone's PC blows up and they need to log in somewhere else while the unit is being repaired.
Integrated directory services
It's absolutely essential to run as few user databases as you can get away with, since it can be an administrative nightmare to maintain separate login databases for the fileservers, accounts system, dial-in box, VPN server, and so on. The reason is simple - if you manage users in a single place, you can change their privileges in a single place. Not only this, but it makes the process of dealing with staffing changes foolproof. Although some systems aren't inherently integratable, it's commonly possible to use standards such as LDAP to connect ancillary devices into a directory service, such as Active Directory or NDS.
The main bugbear for the average person joining a company is to have to wait for access to the computer systems. After all, there's no acceptable reason why access can't have been granted before they joined - it's just that in many cases adding someone to the company involves a number of separate operations to be carried out, often by different people, to set up (say) their phone extension, dial-in access, application access, finance system access and such like. If you have everything in a single directory service, it's a simple case of defining a user ID, dropping it in the right roles, and perhaps adding a couple of hand-coded items, such as the phone extension number they'll be using and their office location. From the IT department's point of view it may even be possible to save some time by offloading this user creation department to the HR people, as they're the ones who know when someone joins.
Similarly, when someone leaves, there's often a delay between them going and the IT department knowing that they've gone - particularly if it's a senior person who's been fired. If the HR department is able to disable user access, or if the company has a sensible policy of trusting the IT department and keeping them informed, the risk of an ex-employee's access rights being misused, subsequently, is minimised.
Sometimes we find system issues that can't be managed using the facilities that come as standard with systems, such as directory and application access control. The classic example is the sending of emails containing dodgy attachments (e.g. company-confidential information) or libellous words. In such circumstances, it makes sense to employ additional software controls to monitor both incoming and outgoing messages to watch for illicit content.
Logging and reporting
Taking this concept further, it's important that we monitor as much as possible of what goes on in our systems. Although often not something we want to consider, there may well be the need to draw on our system usage records for disciplinary reasons - either to prove that a member of staff was using a particular program at the time that it was used in an illegal way, or even to prove their innocence. So it's essential to use whatever logging functionality we have available, and to archive logs assiduously, so that they're kept for an appropriate length of time but are reasonably accessible should we need to refer to them.
Precisely what you choose to log depends largely on how you, and the management, think you might use the information. Resist the temptation to store everything that goes on, because you'll find yourself with terabytes of pointless rubbish to wade through. Instead, choose your logging levels sensibly for each service that you do log, and consider running daily scripts that process verbose logs and pull out summary data for long-term storage.
Once you've educated your users, use technology to reinforce what the users can and can't do. Use your systems' built-in file permissions control systems; control application execution where you can; make sure that you store logging information comprehensively and conveniently; and consider using third party software to control any other security-related aspects of your system (such as e-mail content) that your systems' built-in features can't cope with.