Small children love the game of peek-a-boo. The lesson being taught by this play exercise is that objects do not disappear just because we aren’t observing them. When thinking about DB2 Data Security and Data Governance, there is an excellent corollary here. Just because data isn’t easily observable does not mean it doesn’t exist.
As a consultant, I am frequently asked to explain how I discovered databases or data objects that had not been documented or provided to me. The answer is simple; much like the child who learns the reality of object permanence, I observe systems with an understanding that just because a data object is not documented, that does not mean it doesn’t exist.
Think about how you maintain your environments, especially your Dev and Test environments. Do you always have strong controls in place to ensure that you have documented every possible data object? If not, then you may have a data governance issue that may lead to a DB2 security issue which could result in a loss or compromise of data.
Think again about those environments and how they were “stood up”. Were they built in haste to meet a deadline? Have they been greatly modified by developers and/or testers who are under deadline pressure? Were standards relaxed in order to meet a project timeline? Meeting deadlines and timelines often requires shortcuts, but some of those shortcuts can lead to security risks as well as change control challenges.
If you don’t know that data exists, then how can you protect it? If you don’t know what data exists beyond your DB2 databases, how can you know if it is as risk? Take a lesson from a children’s game and observe the reality that a solid Data Governance approach is foundational to Database Security.