The set-up
When you install DB2 you obviously have an all-powerful instance owner ID and password. The best option, once you’ve got DB2 up and running, is to ensure that no-one, except essential support staff, has access to it. From past experience we have come across DB2 sites that have only the one userid for all users to use and, frighteningly, use the same password in all environments.
What this means of course is
- If you’re a user who has ever connected to the DEV environment, you can now get straight in to Production
- You can (if malicious) harvest sensitive data or drop critical objects
- You can (even if entirely benign) put in place features or structures that you think might help Production run, but which will actually knacker it completely
- You have the ability to submit ad-hoc queries that you think might be handy but that will actually stop your Production services dead :
“I wonder how many rows are in that table? Maybe if I submit SELECT * FROM Largest_Table_in_the_Database it will tell me.
Well, it doesn’t look like that’s going to respond any time soon; guess I’ll go home and see if its worked in the morning”
And, consequently, about 3 a.m. the entire batch suite comes down with a series of locking and timeout errors
- And finally, of course, no-one can tell who did any of this because everyone is using the same ID
The Moral
Build a security strategy into your database from the word go. Design a set of users, groups and roles and implement them in Dev. Use that design as a template for your other environments and don’t let anyone have any more database authority than they actually need to do their job.
Sign-up to receive DB2 Support Nightmare updates or download our previous series ‘Top 10 DB2 Support Nightmares and How to Avoid Them‘ here.