[ale] Security best practice - Remove or disable user accounts?

[mike at trausch.us (Michael B. Trausch)]

On Thu, 2008-08-07 at 12:32 -0400, Jeff Lightner wrote:
> At a former job the policy was to disable rather than remove user
> accounts.
> 
> However, on checking for ?best practices? I don?t find any indication
> why this should be and find several references to removing them
> completely.
> 
> Does anyone know of a best practice that explains why disabling would
> be preferable to removing?

Long story short, I think that removing accounts is something that
should be done later, and disabling sooner, at least for most types of
systems.  More on that below.  I don't think that there is any "best
practice" that I am aware of that concretely explains one over the
other, but given that both types of accounts are equivalent in terms of
having access to the system (neither one can be directly logged into in
a properly functioning system), I think that there can be many arguments
for going in either direction.

The single best reason that I can think of to disable accounts is to
maintain history and consistency in things like log files and records.
Eventually, they can be purged.  This is probably more for application
software and the like, though, as opposed to operating systems, but it
could really apply to either, in many circumstances.

Take, for example, an application that someone uses to fill out trouble
tickets all day long.  User accounts are created on them, tickets are
filled out, and those tickets are linked to the person that created them
by reference.  Referencing data is faster and smaller than duplicating
it, so it makes sense.  When that person leaves, do you delete their
account and then deal with all the orphaned tickets?  You could, but
you're going to lose some history that way.  The log files probably
contain a user ID or login name, and the history should, as well.  The
comments left on the ticket by that user will be the same way.

One of the better ways to handle it is to disable the user account such
that it cannot be logged in or activated through some application or
operating-system sanctioned sudo-like mechanism (or, in the case of the
lack of the latter, that it becomes an automatically-triggered red flag
if something is done with the user account).  Then, once all the records
that the person had anything to do with are moved to archives, the user
account can be expunged from the production system and live on only in
the archives.  The upside to this process is that a simple utility to
check the database consistency and answer questions like, "What if user
X were removed from the system" will be able to tell if you'd
inadvertently create some inconsistency in the database if the user
account were removed.  You can do things like that on the operating
system, too, see if there are any files outside of their ${HOME} that
they owned before getting rid of their user accounts entirely.

The other upshot of doing it this way is that you can't then have
another user come around that has the same username as the old user did,
until that old username is no longer relevant in the system.  Once
everything has been moved off to the archives that pertained to the old
user, a new user with that same name can be created, and there will be
little to no confusion surrounding the identity of the account and its
relation to certain records, because those records won't be in the
production system to cause the confusion to begin with.  You could
potentially get around this by having a historic username list, but that
just duplicates information unnecessarily given that the historic
usernames and their identities will be resolvable in the archives,
simply due to the fact that any time the username is referenced, the
user account information stored in the database snapshot will be valid.

If you use some sort of rotating system that ensures that there is zero
deletion of data, you may have to come up with something slightly more
complex, and it's possible that deletion of user accounts would be
increasingly difficult, leaving the only option to be to archive them as
well and just have them disabled for any type of usage, maybe purging
only data that is older than a certain threshold (like 10 years) when it
no longer has dependencies on it from any data that may be fresher than
that.