The data centers today have several choices, with the advantages and disadvantages of their own. Here is a summary of what each option can provide, and where it fails:
Group Logon IDs:
Most of the conventional systems have this set-up in place. A single logon ID is shared by an operational team, with the grants accessed to certain levels. The activities performed by this ID can be viewed, monitored and controlled easily. However, there is a limitation for the members to play around with the system, owing to the restricted access. This works well for sensitive data handling, but fails where a deeper understanding of the operating system is required.
These IDs are similar to the Group logon IDs, but with more granularity. It is a common practice to grant Firecall ID to the team members who need an exceptional level of system access. There is more flexibility as well, associated to these IDs. While the logon can be performed by a single identification, there can be two Firecall IDs existing further to perform two different tasks. This offers various levels of security at different granular levels.
Defects Of Group Logon and Firecall IDs:
Both the set-ups have similar defects. While the auditing is easier and can be continually monitored, it is impossible to identify who accessed the system with the particular ID, if the situation demands so. The personal identification is lost and the root cause analysis gets tougher with this process.
Another major disadvantage with both of these IDs is when the emergency arises. Imagine a situation when the operational team is all ready to present a business report, and the group logon ID fails to work! The single ID allowing the access to the system when changed or forgotten all of a sudden may create havoc during run-time operations. The only resort leads the team to wait for the administrator to revoke the login.
With Firecall IDs, there is an additional requirement of approvals. If this involves too much documentation as per the company’s norms, the normal process gets delayed and can be utterly frustrating.
With the specific monitoring grants provided in the form of normal IDs, if the security teams need to restrict any changes or updates to the existing system, there arises the concept of alternate IDs. The authoritative control is given to the alternate IDs, which can be used whenever necessary. This is an easier and more flexible manner to control any changes to the system, which is considered stable.
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.
With the efficiency of Alternate IDs understood, and the flexibility of the normal IDs used to the best possible extent, the data centers may adopt a few processes to ensure a seamless working. This bridges the concerning gap between security and operational teams, by granting needed security all the time to the right individuals, and also keeping the sensitive data under check.
The Recommended Processes:
- Most of the application and system programmers are required to monitor the run-time environment. The ‘read’ access to them is all that is demanded at the basic levels of production tasks. This poses no security threat, and allows continuous monitoring as well.
- The software used to control Firecall and Group Logon IDs must have a mechanism that intimates the administrator as soon as the login fails. This ensures that the admin stays aware of situation and helps in logging into the system with a new identification, created with no delay.
- There must be the highest level of authority that is provided with the complete system access. By ‘complete’, it means all levels of access to the system that can take control when the environment goes ‘bad’. This is very likely when the bigger Organizations work on overloaded servers too often.
- The technical support team must be contacted as soon as the situation seems to slip out of control. At the least, this team can guide on how to preserve the data that is not yet lost.