Buat standar keamanan data center Anda

Set data center security standards to harmonize IT, business goals

IT operations teams and security teams often are at battle. Data center security standards can largely affect the people who run the systems. Tighten security too much and administrators can't do their jobs.

Application and systems programmers need authority to operate the system and to detect and fix problems. At the same time, corporations must guard against unauthorized distribution of customer, employee or other confidential information. In the interest of availability, enterprises restrict the chances of anyone making arbitrary, unscheduled or malicious changes. So, how do shops reconcile protecting data and availability while maintaining suitable access for technical support? 

Data centers have several choices in identity management, including group logon IDs, firecall IDs and alternate IDs. Let's take a look at each security measure and any associated issues.

Group logon IDs. Some shops consolidate powerful access into one logon ID that members of a functional team share. You can control access to the group ID by requiring a technician to enter an approved change number before gaining access.

This scheme has several advantages. First, every action performed by these IDs can be easily logged and audited. It also takes the power away from individuals and, depending on the controls put around the group ID, means that any changes to the system must be deliberate, scheduled and reviewed.  

Firecall IDs. Similar to group IDs, firecall IDs have a limited scope and lifetime. In general, a programmer who requires exceptional access must either check out or create a firecall ID. Additional controls may include a one-time generated password and an expiration time that limits its lifespan.

Like group IDs, firecalls can be heavily audited, and IT security can put all sorts of controls around the process for getting one. In addition, firecall access can be more granular than a group ID. For instance, while one group ID may be able to update system datasets and reorganize databases; security may set up two different firecall IDs for each distinct function.

Alternate IDs. With alternate IDs, power still rests with the individual. But instead of having full access all of the time, security teams strip the more powerful abilities from the normal ID and move them to alternate IDs. This allows technical support personnel to monitor the system with their regular ID without being able to change anything. Instead, any modifications require logging onto his or her alternate ID.

Alternate ID's provide more flexibility than firecall IDs or group IDs. They also grant faster access to update authority; however, they are harder to control.

Contending with firecall ID and group ID

Both firecall and group IDs share some problems. First, while both IDs can be heavily audited, they also make some change more anonymous. For instance, IBM's Interactive System Productivity Facility (ISPF) stores the ID of the last person to update a partition dataset (PDS) member in the library's directory. In this case, ISPF records stores the firecall or group ID, but the person using it is unknown.

Firecall IDs have an additional disadvantage with the checkout process, because sometimes a shop needs them in an emergency. If the method for getting a firecall ID takes too long or requires too much documentation or levels of approval, a short outage could easily become a long one.

Group IDs have a similar defect. Imagine having an outage in the middle of the day and the only ID powerful enough to fix it is locked up by someone who left for the day.

Here are a few best practices for maintaining secure and available data centers:

• Allow application and systems programmers to monitor production. Despite all the recent developments in automation and "autonomic" systems, computers still need active monitoring to reach extreme availability levels. Done correctly, read access should not pose any danger to availability.
• When comparing the three options, alternate IDs could be the best option. Alternate IDs can be logged -- just like group and firecall logons -- and they preserve some audit trails that are built into the system. Alternate IDs also allow support personnel to act quickly, when needed.
• If a shop wants to use firecall or group IDs, they should build a process that hits the sweet spot between effective controls and speedy access. In addition, the software that controls firecall IDs should have the highest availability goals in the enterprise.
• A department may want to designate a few dependable people with full powers in production to serve as the cavalry when things go badly. While this effectively short-circuits all the other attempts at control, it does provide for quicker problem resolution if something should happen.

Trust the technical support personnel. They dislike outages as much as management and are dedicated to the success of the enterprise.

About the author:

Robert Crawford spent 29 years as a systems programmer, covering CICS technical support, Virtual Storage Access Method, IBM DB2, IBM IMS and other mainframe products. He programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. Crawford is currently an operations architect based in south Texas, establishing mainframe strategy for a large insurance company.captainwhacks@yahoo.com