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