The problem

The SSH key management system has made the login of users under given accounts far too easy. As a cosequence, our security posture may have slipped by quite a bit. As examples, large amount of users are allowed to log under root with no clear reason for it and users were found to have access ... while they left STAR long time ago.

Observations / cases

• Very wide range of access under root not all justified. Examples:

  • Dmitry has access to the stargw, Web servers, etc … why? Ideally, mysql should be able to be controlled under the mysql account and PHP scripts should NOT be installed under root (this a known problem and probably why in this case, the access spread to the Web servers). This  separation of privilege and realm need to be revisited.

  • Gene has access to many db nodes as “root” but unlikely manages the nodes. Why? Would a restriction of a “mysql” user be enough? Same as above, likely the issue is that there are files and actio not possible under a specific account.

  • Jerome has access to the fgt-ops nodes? Why? Because he helped with a STAR infrastructure issue. But why this is still there? DO we need special cases with an expiration time. jeromel also has access to a wide range of db nodes such as dbbak, db03, fc4, etc ... If Gene has access there, does Jerome need to have it? What is the likelyd that (Gene)+Wayne+Matt+Dmitry are all away at the same time? Even if so, other access can be possible (direct root access, added key when needed).

• On the opposite, very wide range of users under onlmon. This has created convenience (shared development) but also, created two situations namely (a) user leave and still have associations with the onlmon account and (b) the developed scripts are nowadays untraceable (see this post).

  • Proposed: if expiration is in place, we could set a long term expiration (8-10 months or more but < 1 year) of key association to the onlmon account. We would then pro-actively re-assess our user association to this generic / multi-purpose account and avoid association inflation. It would also be another way to resolve problem (a).

• Illegal associations: matthew <-> ahrem for example violates our principle of preserving the account name for easier tracing. Account ahrem should be enough for testing.

Improvements / actions

• Check on all nodes the existence of a mysql account and under which account the Web server is running. Make sure the files belong to that user + use secondary groups wherever applies (onlmon-like shared development scripts)
  • Note: At the RCF, a stradb secondary group (gid=3239) exists and was created for a similar intent
     
• Remove any account (non-group accounts) used for testing (i.e. matthew, ...). Group accounts should be indicated clearly in NIS. Perhaps a scheme a-la RCF would be useful ("Office" has a contact person name and a #G#)
   
• Extend the SSH key management to allow check of the STAR PhoneBook for expired users and remove their key association. This is likely possible (and only require a back trace of their RCF user name - since we mandated for STAR users to request a RCF account, this should be possible)
  • Action items include back-fill of RCF username in the PhoneBook, the the check on expiration time should be straight forward
     
• Extend the SSH key management system to allow key associations with an expiration time (jeromel for root@fgt-ops for a month's time for example)
  • Status: discussed with Dmitry the following requirements:
    • A user make a request, request has a default expiration (may be a choice from a drop-down) / lifetime + upon approval, administrator may alter the expiration time
    • Possibly, a "reason for the request" field is added and will be saved on the ogs.
    • Upon expriation, the user is un-associated with the acocunt he requested association for (in my example, jeromel association to root @ fgt-ops would expire with a month's time)
    • Account may be set to NOT expire