Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Top 5 DB2 Support Nightmares 2018 #1

253 views

Published on

In part 1 of our new series of DB2 Support Nightmares we look at the implications of only having one userid for all users to use and the frighteningly consequences.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Top 5 DB2 Support Nightmares 2018 #1

  1. 1. Top 5 DB2 Support Nightmares & How to Avoid Them - 2018 #1
  2. 2. Part 1 - Single User Access 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.
  3. 3. 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.
  4. 4. What this means 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
  5. 5. Also… 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”
  6. 6. So then…. 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
  7. 7. The Moral of the Story 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.
  8. 8. www.triton.co.uk

×