Admin Alert: Things to Think About in a Power i Development Environment
June 22, 2011 Timothy Prickett Morgan
Working in both public and private companies during my career, I’ve been subjected to my share of IT audits. My impression is that while auditors are usually very savvy about your production environment, there are other issues that maybe they should be looking at but don’t. If your production environment is in tip-top shape, audit-wise, here are some other things you might consider looking at to avoid trouble.
Why Aren’t Auditors More Interested in Development Environment Infrastructure?
Not to give anyone ideas, but I’ve always wondered why auditors don’t investigate development environments as seriously as they audit production environments. After all, a sloppy development environment can create all kinds of issues, such as:
Here are some fairly common security-breach situations that can occur with a poorly designed test environment.
My experience is that it’s fairly common practice to refresh a development environment with data from a production system backup tape. After all, how better to test a planned software change than with actual production data? Development system data may be a little older than production system data, but many times it is recycled production system data and should be protected as such.
Cloning production data to a development environment can create a number of issues, including:
Now while the idea of a production environment is to let your programmer and contractors make changes without putting production data at risk, you can also inadvertently set up some of the situations outlined here, if you’re not careful. Here are some common sense procedures for protecting recycled production in a test environment.
Development Environment Versus Development Partition Versus Development Machine
Most shops host development environments in one of the following ways.
There are pros and cons with each type of implementation, but the most dangerous setup is to host your development environment on the same machine as your production box, where access is controlled through menu options, user profiles, and library lists. This architecture has many of the data issues listed above. However, because both production and test versions of your software reside on the same machine, it’s easier to corrupt data by overlaying or refreshing production files when you’re trying to refresh your test data.
Authority can also become a problem with having production and test environments on the same machine. If your programmers need to be security officers or have all object authority because they literally need to access every object in the test environment, this may not be a good alternative. If you can, it’s generally better if you host your test environment on a different partition than your production data.
It’s usually fairly easy to create a second test partition on your production machine, and that will satisfy any requirements to physically separate production and test data. The minimum requirements you need for a second partition are a spare Ethernet card and some leftover disk drives, memory, and CPU. And for a test partition, you may not even need that much memory or CPU. Depending on the amount of CPW on your production hardware, you may be able to create a workable test environment by just using .1 to .25 of a processor. After all, you probably won’t have a lot of users on the test environment and sub-second response time usually isn’t an issue here.
Hosting a test environment on a separate partition avoids a lot of the authority and production-test data confusion you might find when hosting it on a production machine. The downside, however, is that it’s more expensive to run third-party software applications on a second partition. You may have to buy separate licenses to run each of your third-party applications on a second partition. Many packages will offer a cheaper development license for running their software on a test partition, but a large number of the major packages do charge you extra for running their software on a second partition.
Running your test environment on a separate iSeries, System i, or Power i machine is equivalent to running it on a second partition, security-wise. However, it will be much more expensive to run third-party applications on a second machine because with the exception of replication software, you won’t be able to piggyback your software licenses from your production partition to a second test machine. Running your test environment on a separate machine also means that you have to have access to a separate machine, which may not be the case for smaller companies. If you have a Capacity Back-Up (CBU) system, it might be tempting to put your development partition on the CBU, freeing up your production machine to totally concentrate on business needs. However, if you set up a development partition on your CBU machine, you may be violating your IBM license agreement for using the CBU, which generally states that you are only using the machine for backup, not production purposes.
For security and practicality, your best choice for hosting your test environment is to put it on a separate partition on your production. This way, you can securely put up a wall between your test and production systems and you can keep your external licensing costs down at a reasonable rate.