Security improvements within DB2 make it essential to do a security review of old existing and new practices and applications that are executing in your environment. While helping to review a system recently, several findings highlighted many interesting items from previous administrators, applications and associated vendors. Since this was an internal audit, the issues were handled inside the DBA department.
First, it became apparent that several years of different administrators had different ideas on the scope and limits for other DBAs, application DBAs and application developers. This showed up in various IDs, some for people no longer with the company, with very powerful rights to some of the biggest applications within the shop. While it is great to have many people, administrators and applications personnel supporting your environment, some of the authority and capabilities were overkill for the situation.
Next, the applications mix was typical. There were many DB2 CICS high performance applications executing the majority of the business transactions. There were other legacy web applications using languages such as Cold Fusion, CGI scripts and PHP. Then there were the other new SOA applications providing web services to business partners and other batch and on line applications. Each of these applications had their own security design and execution profile. While each having their own was nice, the set up provided a number of IDs and situations that required unique monitoring. Some consolidation could help, and we scheduled it to limit the number of IDs doing the same functions.
The DB2 CICS applications were the most secure with years of execution experience. The legacy web applications provided the most variety and diversity of security through cobbling together different IDs and security schemes for different parts of the applications. It seemed as if there was a special ID for every different and type of component. Again we consolidated the IDs to the proper different levels to limit the number of IDs exposed in the systems.
Then the SOA applications that had to interact and execute within diverse environments had the most wide open security set up. The security scheme used for these applications was a real concern as these modules interacted with a number of application areas. The SOA modules required deep analysis to understand their usage and security needs. We refined the security for these security IDs and took away some of the extra authorities and rights to different resources.
Some other considerations were some of the IDs left over from doing proof-of-technology testing for new vendor products. Some of these user IDs had big time access to applications and system resources that could have been very dangerous. Make sure to remove these types of testing IDs whenever removing a product from your systems.
Security is very important and needs review periodically. Make sure to do a comprehensive review yourself before a security breach happens or your upper management decides to do one on your systems and you cannot handle the issues internally.
Leave a Reply