[consulting] Restrict Group Access to one User Login Account

[Eric Goldhagen]

At 1:22 PM -0400 10/8/09, Brian Vuyk wrote:
>I agree - if the accounts aren't meant to be personal, don't hold any
>personal information, then where is the harm, other than it's not a use
>case most Drupal developers don't have in mind?
>
>One of my past clients had ~3000 users worldwide over ~10 departments.
>It was much easier for them to use 10 generic, per-department accounts
>to access various data than manage 3000 separate user accounts.
>
>Brian

Much of the work I do involves private information, so I'm coming 
from a perspective that puts user and data security over what on the 
surface seems easier.

It's simply a bad practice and should only be done if there is no 
other way around it.

Using shared accounts violates one of the primary rules of security, 
you should be able to tie one login to one person so you can control 
and audit their access over time.

Given some time, I could give a ton of reasons. Off the top of my 
head, here's a few: By sharing an account, you have no ability to 
keep information associated with that account private (don't assume 
that users won't be stupid and accidently post information that 
should remain private); you have no way of allowing people to 
reset/change passwords after they login from public computers that 
could be doing key logging or after they leave their notebook with 
the passwords in a cab, in fact as this thread shows, you have to 
explicitly put in effort to remove the ability of a user from setting 
their own or resetting their own password or else one person could 
lock everyone else out. There is no ability to log what actions were 
done by what people and audit use of the system. With every extra 
person sharing the account the risk of compromise or the account 
being used by non-approved people grows.

Even if there is no private info there now, you have no idea what 
people might end up doing over time. It's a good idea to always 
follow security "best practices"

What does your past client do when someone is fired? Wouldn't it be 
more sane to be able to turn off one account, rather than force an 
entire department to remember a new password?

Just because it's "easier" does not mean it's a good idea or 
something that should be done without looking at all other options 
before making the decision.

I helped an organization clean up the mess created by a disgruntled 
ex-employee a few years ago, after that they realized that it was far 
better to deal with the extra burden of individual accounts rather 
than face the possibility of having their entire operation brought to 
a standstill for a few days.

This does not mean that I can't see any situations where it might be 
the way to go, just that shared accounts always make me uncomfortable.

--Eric

>
>Sam Cohen wrote:
>>
>>  On Thu, Oct 8, 2009 at 12:18 PM, Eric Goldhagen <eric at openflows.com
>>  <mailto:eric at openflows.com>> wrote:
>>
>>
>>      I have to agree with all the folks that think it's a terrible idea to
>>      share accounts.
>>
>>
>>  I don't get it.   Maybe there's something I don't understand. Why is
>>  it such  a terrible idea to share accounts?  It seems to me the risk
>>  of something happening is next to nothing.  I mean, I'm not advocating
>>  it as a general practice, but I fail to see why it would be such a
>>  problem or what types or risks it poses.
>>
>>  Sam
>>
>>  ------------------------------------------------------------------------
>>
>>  _______________________________________________
>>  consulting mailing list
>>  consulting at drupal.org
>>  http://lists.drupal.org/mailman/listinfo/consulting
>>  
>
>_______________________________________________
>consulting mailing list
>consulting at drupal.org
>http://lists.drupal.org/mailman/listinfo/consulting


-- 
-------------------------------------------
Openflows Community Technology Lab, Inc.
New York | Toronto | Montreal | Vienna
http://openflows.com
People are intelligent. Machines are tools.