Our IT apps team came up with this idea in our
SaaS AWS OS, applications & DBAs accounts
which they plan to authenticate with Google
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
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?