What's your opinion on access to the Production or Live Systems by non sys-admins?
Do you think this access should be provided with nominal usernames?
Do you think access to the log files or the databases should be allowed?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
Apply the Principle of Least Privilege. If they need access to do the job, you give them the access. But you only give the access they need. If they don't need access to do the job, you don't give it to them.
This doesn't just protect the person (can't be accused of overstepping his/her bounds), but also protects the organization, should the user's account be compromised.
As to why they shouldn't be given such access...
I agree with the above but I would like to add that shared user accounts are not a good idea at all. You cannot track down who did what in the logs, and you cannot control who shares what passwords with who.
Configure a group with specific access control, and give each non-admin who needs access to the systems their own account, with only the access they need to do their jobs.
From a DBA standpoint, access to production systems for users should be strictly limited, and this includes developers. Users should only be able to see the data they need and this would ideally be provided via views, not direct access to tables.
Developers, likewise, should be able to see the data in production, but not alter any tables. Any changes should be done in test (or dev) first, then scripted and ran on production by the DBA.
For development, if possible supply them with a copy of the live system and provide a way to push database changes back to the development copy at will. You will find that many of your developers will be more productive with access to "real" data, and you will feel safe knowing that they don't have access to the live system.
I am also of the belief that there is no real reason to store certain sensitive data beyond the transaction. For example, credit card transactions... grab the data and send it to the merchant processing system... but don't save it in the database, instead just store the last 4 digits of the card and the transaction id from the merchant system. This way when an exploit is found and a fix generated (I know, like that never happens), you have the confidence that no one could have stolen any of this data from your database.
I fully agree with H. Brian Kelley's answer featuring the Principle of Least Privilege.
But I'd like to mention that it goes hand in hand with my own home-baked Principle of Shared Responsibility for Screw-Ups. That is, anyone with the ability to admin the server should also have their phone number added to the server's on-call list. So now this non-sysadmin can also know the joy of the 2AM "something's broken" phone call.
Depending on the criticality of the production server, yes I think the non-sysadmin should have to use a second, privileged account for his/her access to the system - just like I do (eg, I use one account for my daily email and normal-user activities; another for my sysadmin activities). The user now must explicitly change to the higher priv level, and that will help prevent slipups.
And yes there are cases where log (view only) access should be allowed. Obviously when that person needs to see the output to do his/her job better, you want to lean towards giving the access. Re-think this if the log contains really sensitive information such as customer personal or financial data.
You might consider some level of formal/informal training on the security aspects of privileged access whenever you're granting it.
Yes. Full root access (granted via sudo ALL). And they get to be added to the oncall rotation, too.
Many companies have one sysadmin who is on call 24/7, even for application issues. Some companies are fortunate and have two. It is completely unreasonable to expect that one person do all the day-to-day operations work and respond to system alerts at all hours of the night.
However, many companies have a fair number of developers that are responsible for the application code running on the systems. Many of them may even have experience doing operations.
No, they shouldn't be responsible for the mail system, unless it ties directly in with the application they work on. But there should be a clear run-book of things to quickly reason about so they can either gather information for the sysadmin, or even solve themselves if simple enough.
Everyone's job is to enable the business.