Link to home
Start Free TrialLog in
Avatar of sunhux

asked on

innovative way of accounts management (minimal/no creation/deletion of accounts)

Our IT apps team came up with this idea in our
SaaS AWS OS, applications & DBAs accounts
which they plan to authenticate with Google
MFA authenticator.

As number of staff rarely change (one staff who
leaves will be replaced with only 1 staff) or even
less (say 4 staff leaves, due to cost cutting, will
only replace with 3 staffs), the number of accts
will rarely change/increase.

The idea is:

a) create accounts with names that are generic
    ie doesn't reflect specific IT staff's name.  Eg:
    For DBAs, create dba1, dba2
    For Unix admins,  create ux1, ux2
    For apps admins, app1, ... ,app5

b) each of the above account is assigned to
    only 1 IT staff (ie no sharing of accounts) &
    when a staff leaves, that account's password
    is reset (or possibly disabled) till a new staff
    comes in, the account with the changed
    password is given to the new staff.
    If there's no new staff to replace that position,
    we'll just disable that account.

c) We'll maintain an Excel, so that we know at
    any one time, who is holding which account.
    dba1 > jean   dba2> anna
    ux1>  john     ux2> carl
    app1> ann   app2 > may   app3> joe

    So when Carl leaves & is taken over by a
    new staff  Jon,  the ux2 account will be
    given to Jon.

d) I can't think of any shortfall other than:
 - if we want to know offhand who is the staff
    currently login using an account, we'll have
    to refer to the Excel.
 - in annual accounts review to review if there's
   any dormant accounts to be removed, gut
   feel is there will be lack of visibility from  a
   glance if an account is truly offboarded

e) was told IAM will be used in AWS.  For
   privileged accounts, we plan to lodge the
   credentials into CyberArk SaaS which
   requires approval.

The key question I have is:  will auditors
accept such a set-up/process?  Virtually
the accounts review is just by reviewing
the Excel & not at the OS/DB/apps level.

Any shortfalls anyone can see that audits
will fault us for adopting this?
Avatar of David Johnson, CD
David Johnson, CD
Flag of Canada image

For DBAs, create dba1, dba2
    For Unix admins,  create ux1, ux2
    For apps admins, app1, ... ,app5

I would not associate username with roles
Avatar of btan

Actually even with the name mapping, it is still considered generic as it is reusable and not unique. Using a process is prone to mistake and may well be not govern so auditor is likely not going to buy in.

What make it worst is that the activity log will not be verifiable evidence as it is subjected to clarity of mapping which is non technical, the issue of JIT account reduce risk with stipulated period and acceptable for audit purpose taking a risk based and least privileged approach.

Better to have risk assessment and acceptance done for coverage of approved decision.


6. Manage Generic User Accounts

Sometimes it is useful for training, testing and other purposes to have generic user accounts set up on your network. However, a generic user account – without an actual person assigned to it – is a security risk.

Make sure to delete generic user accounts that are no longer being used, and do not assign Admin rights or rights to mission-critical systems to generic user accounts. If you need to create generic user accounts, change their preselected options (to, for example, use strong passwords) so that an attacker cannot gain access to your resources by using default settings.

 Regularly review the generic user accounts on your system and delete whichever ones are no longer necessary to maintain.
PAM’s (Privileged Access Management) aim is to solve the generic privileged user accounts problem. PAM combined with PBAC provides the full control and visibility required for those generic accounts.  

7. Disable Unnecessary User Accounts

Keep a clean IAM system by removing unused and unnecessary user accounts. These accounts tend to build up over time, creating a larger attack surface that could lead to a data breach.
  • Delete dormant accounts – keeping inactive users in the system opens it up to a potential threat. Any user that has not used their account for a long period of time is likely to no longer be a part of your organization and should be deleted.
  • Remove users from groups that they shouldn’t be part of – users who changed roles or have new responsibilities in your organization should only be part of relevant user groups.
  • Review group policies – take a look at the access policy definitions for every group and make sure that they are appropriate for that group.
  • Delete unnecessary or exposed user login details – if a user has access credentials to resources that they don’t need access to, or if you are aware that a user’s access credentials have been compromised, remove them from the system. This reduces the threat of accidental exposure to sensitive information and potential breaches
Access to anything should be done via groups, not users. Once the groups have been properly setup, it is easy to add the appropriate groups to those users who need that access. Setting up a new user user that reflects the real user is fast, you just need to add him to the correct groups. If a user leaves the company, you just disable his account, but leave him on the system, at least for some time. That way it is easier to recall his history, & that is what auditors will often need. If you just have general accounts, you don't have a reliable history...
Avatar of sunhux


> I would not associate username with roles
Ok, will just name them as 'hazy' as possible,
eg: d1, d2, o1, o2, ...

BTan, can share the source of sections 6 &
 7 checklist indicated above?  From NIST
or ..... ?

Avatar of btan

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial