Abstracting Database Passwords in Batch Scripts
Even when a Siebel implementation does not need to be SOX compliant, it is still important to develop and maintain processes to reduce errors and fraud. Separation of duties (SoD) is an important security principle in any enterprise application environment. For example, it is often best to prevent Siebel Developers from having administrative access, and to prevent Siebel Administrators from changing code.
One potential vulnerability is that command-line server manager connections require a username and password that authenticate against the Siebel database. People with this information can use a third-party tool to access and manipulate the Siebel database. In a production environment, administrators need these passwords, but they should be restricted as much as possible, especially from developers.
Scripts invoking the Siebel Server Manager command-line interface can be a powerful tool for automating server tasks, but connecting to the command-line interface on a Windows server requires the following syntax:
The solution to this problem is to isolate passwords and other environment-specific information from the script itself.
Consider the following excerpt from a Windows shell script:
One potential vulnerability is that command-line server manager connections require a username and password that authenticate against the Siebel database. People with this information can use a third-party tool to access and manipulate the Siebel database. In a production environment, administrators need these passwords, but they should be restricted as much as possible, especially from developers.
Scripts invoking the Siebel Server Manager command-line interface can be a powerful tool for automating server tasks, but connecting to the command-line interface on a Windows server requires the following syntax:
srvrmgr /g gateway1 /e enterprise1 /s server1 /u sadmin /p sadminIn the above command the /u and /p arguments require a valid username and password using database authentication. A batch script containing this information challenges the SoD principle. Either an administrator manipulates the script to insert the password, or a developer does. Either way, the roles become blurred.
The solution to this problem is to isolate passwords and other environment-specific information from the script itself.
Consider the following excerpt from a Windows shell script:
call E:\secure\envvariables.cmdIn the envvariables.cmd file, the following:
E:\sba80\siebsrvr\BIN\srvrmgr /g %gateway_server% /e %enterprise_server% /s %siebel_server% /u %eimuserid% /p %eimpassword%
@set gateway_server=PRODGTWYIt doesn't matter how much complex logic is added to the shell script containing the srvrmgr command, user names and passwords are segregated from the logic in a file that can only be modified by the system administrator. Moreover, environment information is also segregated, so the script can be migrated through UAT and Production without modification.
@set enterprise_server=Siebentprod
@set siebel_server=Siebprodbat1
@set eimuserid=EIMIMPORT
@set eimpassword=SecurePwd
תגובות
הוסף רשומת תגובה