Your current arrangement sounds like a shared password keystore.
Your problem is essentially the difference between centralised and decentralised access control:
- When access control is per server or service, the maintenance of the access control is centralised per service and reflects an effort of
O(N) where N = amount of services
for the company.
- When access control is per person, the maintenance of the access control is decentralised from the standpoint of ICT assets and reflects an effort of
O(N) where N = amount of staff
for the company.
It is likely that the amount of services you initially had grew faster than the amount of staff and hence the second option was more appealing.
But now the amount of staff or turnover of the staff is higher than the amount of services and is costing you more to maintain than server/service-based access control lists would. The tipping point being O(N).services + O(1).service
versus O(N).people + O(1).people
as the initial O(1)
overhead of each new service or person would have masked the long term shift in effort.
So it becomes a question of security vs your company's shared work culture. You can shift across to the now possibly cheaper server and service access control approach, and you will gain additional auditing benefits in the process; but the shift will require a lot of migration effort and a hierarchical "unflattening" of your company's work culture.
If we go back to the days of physical keys and filing cabinets, the difference is between the team all sharing the same cabinet key versus just a couple of people having the cabinet key.
I don't think you have much of a choice regarding a shift towards to server/service ACLs once you have more staff or role volatility than servers - but you can reduce the ACL overhead through systematic use of client certificates:
- Convert their RSA key pairs into self-signed client certificates.
- Add or remove their public certificate from servers and services directly or from a centralised role-based LDAPS authentication service.
- (Optional) Convert key pairs into certificates signed by the company private Root CA to enforce routine expiration and stop people from generating access credentials you are unaware of (i.e. breaking the audit chain).
Client certificates have the benefit of being more secure than passwords and having a wide range of embedded meta-data without needing real-time access to the LDAP server.