What if you had to let someone go tomorrow for some unforeseen reason. Would you know all of the points that this person or company has access to? How can you be certain unless you keep track of these locations?
Even if you know all the locations, do you understand the impact of modifying the users access? Was this users access tied to a critical cron job? Was this user account tied to MySQL access for performing monthly billing? What if this employee happened to own one of your domain names? Surprisingly, we see scenarios like this too often.
It is unfortunate, but we have seen it many times where a developers permissions are ingrained into an application or process. Modifying the access rights could make the site stop working instantly or even worse – later in the week/month/year when identifying the cause can become more difficult.
To start, you may want to perform a simulated scenario. They key point to this scenario is to start documentation as you work through the process. Identify a user, and try to determine all of the user accounts and passwords that they may have access to.
Next, work with your existing team and have them collaborate on the documentation, having everyone list areas they have access to or known areas that need improvement as it relates to access management.
An example list of user access points
- SSH – production, development, EC2 instances
- MySQL – production, development, RDS AWS instance
- Registrar Login information
- Email account
- WordPress Logins
- Documentation Portal
- Wireless networking keys
- CRM login
- Spam and Virus Filtering management portals
- Colocation Management Interface
- Colocation facility access
- VPN account
- DNSStuff.com login credentials
- Safari online book store
- Amazon AWS management interface
- Local cron job to generate monthly reports for management team
- Twitter, or Facebook management accounts
- Cisco switches / routers
- Phone systems
- Bitbucket, Github or SVN accounts
- Credit card payment gateways accounts
- Online bank account and credit card portals
As you can see, the list can go on and on. Try remembering all of this in an urgent scenario.
Documentation is the key to making this potentially disastrous scenario a no brainer.
As you go through this scenario, begin to identify areas where improvement is needed and put together a plan to correct these issues. Depending on the complexity of your environment these issues may be solved quickly or take months to complete.
To maintain your documentation, you should be performing this activity at least twice per year.
To add a little more to the conversation, do you use the same passwords on multiple sites? What if one of these passwords were compromised, would you know all of the locations that you need to change your password?
What have you done to combat this issue in your company?
Linux Server Management Solutions
Give us a call at 888-877-7118 or request a proposal so you can start focusing on growing your business, rather than supporting your servers.