OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Why does PAM exist?

Steven -- Appreciate the follow-up and what you say makes sense.

Given the potential for damage by superuser accounts, it does seem like accountability is needed especially there.

What happens now seems like this is a case of the "experts" doing what they keep others from doing -- sort of like doctors who smoke tobacco.

I wonder also if part of the problem is that makers of infrastructure systems have never been pressed to provide the hooks necessary to implement fine-grained access to different admin functions, which would make role-based (duties-based) access easier for an IAM system to implement. Some (all?) PAM systems hack authorization by assigning admin users permissions to run specific executables, which has some value. But IAM (ABAC) systems like Axiomatics (and perhaps others) implement analogous strategies, using query re-write, for example, to limit access based on table metadata (cols) or content (cell values). Presumably they could do something similar for access to specific executables or combinations of executables and parameters.

In any case, to your point about over-provisioning of access to sysadmins: it seems a good deal of grief could be eliminated in sysadmins could be blocked from accessing business data in the clear. Presumably, only business types need to see that.  Â

In the (little bit of non-hands-on) research I've done on PAM offerings one glaring problem seemed to be that the authentication required to check out and use the superuser credentials was not itself particularly strong, i.e., it was password based. (Reminds me of pins protecting soft certs.)

As for the bootstrapping issue, I guess you can't have the IAM system protect the other systems until somebody installs the IAM system. But then that goes for the PAM system, too.

At this point I am still inclined to believe that it would be a good idea for major "relying parties" (i.e. customers like governments and large corporations) to establish a goal being able to use one system and one set of policies to control admin-account access as well as "user" access to info resources and functions.

Again, thanks for the follow-up!


On 1/30/2020 5:10 PM, Steven Legg wrote:

Hi Martin,

This is an elaboration on my answer to your question during the TC conference
call: why does Privileged Access/Account Management exist?

IMO, the simple answer is that PAM exists because superuser accounts exist.
Superuser accounts tend to be shared accounts used by a number of administrators
who all know the password. One problem with this is ensuring that only the right
people know the current password as the composition of the group of administrators
changes over time. If someone leaves the group then the password should be changed
and all the remaining group members informed, but that is easier said than done
and often skimped. Another problem is monitoring and auditing what individual
administrators are doing. Since they are all using the same login credentials we
can't associate any particular action with any particular person.

A PAM solution addresses these problems by changing the privileged account
password for each session (and keeping it hidden) and recording who created the
session and the actions they performed because the administrators log in to the
PAM solution as themselves.

The shared superuser account is the essential problem. The obvious alternative is
to have the administrators authenticate using individual identities and to manage
the access controls to give each administrator the access they need. When an
administrator leaves, their account can be disabled/removed (by another
administrator with the access rights to do so) and, assuming all user actions are
recorded, we know who did what when. We still need a way to bootstrap the
initial identities and access controls and this is something that a superuser
account has traditionally been used for. However, there has been a tendency to
attach all sorts of administrative activities with the superuser account, to the
extent that some administrative actions can only be performed by the superuser
account. A reason applications might do this is to avoid having to address
managing access rights for administrative activities.

So inadequate or non-existent support for managing access rights for
administrative actions forces administrative users to use a common superuser
account and, consequently, PAM is a thing. At least, that's the way I see it.

Martin F Smith
BFC Consulting, LLC
McLean, VA
703 389-3224 mobile

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]