Login Security Question from Application Host's POV 1102
jaybo last edited by
Greetings. I work for a company that hosts an HR/payroll web application used by hundreds of companies all over the US.
I’m part of a 8 person ‘team’ that develops custom reports for the application. Customers often call back with various technical problems (which only appeared in the live application), data issues that need examining, a new dependent that does not show up properly, etc.
We have always had a master login/password for the app known only by employees of my company, but lately, upper management does not want to give us this username/password due to ‘security’ or ‘sox issues’. Instead, we’ve been instructed to ask the customer to use their login.
I would think that this is a much more egregious violation, since if we accidentally botched some data, an audit would make it look as though that customer botched the data, opening him/her up to liability.
Obviously, we have lots of dba’s that have the sysadmin privileges needed to do their job and this master login for the application seems no different.
From a sox point of view, does anyone know of any problem with employees of my company using a master login to go in and troubleshoot?? Is this allowed?
We don’t have a test environ that mimics the live and restoring database backups for every situation that arrises is not really feasible. Any feedback is much appreciated.
dbpublic last edited by
Its hard to give a concrete answer without more details but in general I think there were two key ideas that need to be considered.
First, your client is still ultimately reasonable for the actions occuring on any of their financial systems. If your company has direct access into their payrole system, the client needs to be able to prove your company didn’t do anything that could create financial inaccuracies (intentional or unintentional). If this move to forcing the customers to fix the problem, ends your companies unrestricted access to their systems, the controls for this application are essentially pushed back onto your client. They are then able to develop controls to safe guard the financial information from their side.
Second, if your company still has access you could be asked to prove that your companies controls are SOX compliant since your client won’t be able to create controls for actions on your side (ignoring the role of financial controls located in the business).
Hopefully that made sense and wasn’t too far off.
ugogirl last edited by
Does the application allow your clients to disable user ids?
If so, then one possible option is that the master login is kept disabled. When a problem arises, the client enables the master login and changes the password (they would probably need to establish a process and a log to note who at your company would be using this account with date). The client would need to communicate via phone the new password to the person troubleshooting the issue. Once the issue is resolved, then the client disables the user id and records this action in the log. if a log were pulled for logins then for that id it should match the log the customer is keeping.
alternatively the client sets up a new user id each time a problem exists for the person troubleshooting and then deletes it or disable it when not in use.
it is painful but it is important to have accountability and traceability…need to know who is logging in and what they are doing.
jaybo last edited by
thanks for the feedback. I’m still fighting with some people at our company about this. The issue of pushing full control back on the customer isn’t really possible–we host the app and we fix things that get messed up. There will always be some people in our company that know the master login.
I’m not sure if the customer can alter the master password, but they can disable the master login. By default it’s enabled and most leave it enabled.
Theoretically, a log should be kept of all usages, etc. etc. but the reality is that it’s not feasible for them or for us.
I’m not sure what the ideal solution is.