On Fri, 29 Jun 2012, Florian Heigl wrote:
2012/6/26 Michael C Tiernan <[email protected]>:
----- Original Message -----
From: [email protected]
auditing release of the password (who got the password when, and who
approved it)
One of the things that I never hear discussed during conversations like this is
how exceptions are handled. Some of the exceptions I'd want to hear discussed
include:
How business continuity is maintained across catastrophic events.
How, when everything else has hit the fan, can "I" a "trusted admin" working in
the data center get access into our systems where even the networking is down? There are times that
in preparation of bring up the data center from a dead stop, I need to log into some systems and
run fsck's (or other such tasks) before everything else is live.
Been there.
Loved Quest VAS coredumping without networking rendering the local
root password useless.
Yeah, having the passwords centralized on the network is great when
everything is working, but when they aren't.....
This is why we have been running three layers of access control for
several years.
Layer 1 manages the user passwords
We were running Power Password (now discontinued) that published the
passwords to the local machine (Hitachi-ID has a tool that works this
way). The passwords worked and users could login (unless it was password
change time) even if the network was down.
We are currently using Quest VAS which is a PAM plugin that talks to an AD
server in real-time
Layer 2 manages privileged access under normal conditions.
We were running Power Broker. Think of this as a super sudo, central
administration and enforcement (so that root users on a box could disable
it, but not change it or affect it's logs), including the option for
keystroke logging so you can see what you admins actually did (as opposed
to what they thought they did in some cases :-)
After being aquired, we are in the process of downgrading to sudo (the
fact that the keystroke logs can capture sensitive information scared
people, so they decided it was better to be ignorant than to have a place
the had the possiblity of being mined for info, plus they are 'really
busy' with other things and this let them avoid a lot of work)
Layer 3 manages the true root passwords and only gets invoked when things
are broken enough that layers 1 and 2 aren't working. The real root access
is only to be used long enough to get the box back up and running
properly. This requires that it change the actual password on the box so
that it can be used at the console in single-user mode when the box is
completely unable to talk to anything. Since this layer is rarely used
(once or twice a month across about a thousand servers and growing), we
can have more stringent controls around this (multiple approvals, etc)
We started off with a password list in an envelope in a safe. Policy said
that whenever it was opened, all passwords on the list needed to be
changed. When we got to a couple hundred servers this became unworkable
:-)
We then moved to each password being sealed individually, so that only one
password needed to be changed when it was accessed.
These suffered from all the normal problems others have described.
We then installed Power Keeper (a OEM version of the E-DMZ product), and
it worked, but every upgrade broke the world and it was incredibly
expensive.
We have now moved to Hitachi-ID Privilaged Access Manager and are very
happy with it. It's incredibly flexible, you can script anything that can
be accessed via telnet, SSH, or HTTP(s), plus it included many connectors
to proprietary systems (databases, ticketing systems, windows, etc)
David Lang
Can I, after getting the root password of a system in an emergency, flag a password as "exposed"
but not "compromised" requiring the password to be changed and re-synced at the next possible
opportunity when "normal" operation has been restored.
Love this!!!!
I'll think about that. Flagging the password as exposed is really a nice idea.
Two real world mechanisms I saw
a) trusted admin is authorized to break system via single user mode.
This worked for years(!!!!) without ever needing to know the root pw.
It also ensured it was changed back at some point because people would
miss their root :>
Of course the extra reboots and risk cost money.
b) password in envelope safe. The key here was to not be allowed to
open the save. Someone handed the envelope out.
This is very failure prone.
The password in the envelope will not always match the one in the server.
There will not always be a password for the server you need one for.
There is a good chance you'll need the password for the same server a
few years later, and it will still be missing or, worse, the same.
I think the rule here is to avoid having processes made by people that
don't have to be awake / around when it all comes down in flames.
Because then they'll never implement the part where they have to adjust things.
Is there a way to generate password displays using clear concise (unabigous) language for
reading over the phone or other verbal exchange including, should it be required,
printing. (i.e. Password=bwFq display as "[bravo][whisky][FOXTROT][golf]")
Passwords made with APG are quite useful there, it also prints the
verbal version at generation time.
Of course that doesn't make a tool yet.
In my toyground i have some freaking crazy appliance from a shop named
IMPRIVATA that seems to do a professionalized version of password
management, up to where two people have to "sign off" your logging in.
Of course, that also isn't great once everything is broken.
Florian
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
