跨服务器作业的安全隐患及其解决方案

试想,如果在您的数据中心有一台HP-UX服务器运行应用程序, 另一台Solaris服务器运行Oracle数据库。应用程序会产生一些数据, 一旦生成, 需上载到Solaris机器上, 并装入数据库中。
假设数据的上载是由HP-UX上的用户查理(登陆名charlie)用sftp进行的, 其所用的Solaris上的用户为数据库管理员帐号山姆 (登陆名sam)。
现在我们来看看这样的安排有哪些安全风险。

首先, 用sftp本身有两个密码泄密的风险:
1. 同机上凡用同样用户名登陆的人, 或以超级用户登陆的人,均可用tusc命令窃取当你在用sftp登陆时所输
   入的密码。
2. 心怀不轨的超级用户使用者可将sftp命令替换, 从而窃取密码。

其次, 若查理可用sftp通过数据库管理员帐号山姆将数据传送到Solaris服务器上, 那他也能用sftp修改山姆的.profile文件或.ssh/authorized_keys文件, 可以想象这可能产生多么严重的后果, 特别是当该数据库存的是顾客的存款信息。另外,若查理可传送该文件,则他也可看该文件的内容,当文件的内容包含一些需保密的内容时,这也会造成极大的隐患。

WZIS软件公司对此有一完美的解决方案. 在此解决方案中, 用到了WZIS软件公司的两项产品:
1. Autossh:         该软件包包含两种用以ssh登陆自动化的工具:
      •        assh:        用以无约束的ssh登陆自动化。
      •        asshc:      会对所执行的命令进行备案的ssh登陆自动化的工具。
2. CaclMgr:        一种类似sudo但可用于系统及作业自动化的, 并更安全的授权软件。

以下是WZIS软件公司的解决方案, 该方案不仅解决了上面所发现的安全问提, 还可给您节省费用实现作业自动化:
•    在HP-UX服务器上建一个新的除可读数据文件无其它特殊权限的帐号, 假定名为userc。
•    写一个SHELL文本程序/usr/local/bin/auto_data_load, 内容如下:
   #!/bin/sh
   cat 数据文件|/usr/local/bin/asshc sam@SunMachine “cat >/DP/DF;
   command_for_load_data_into_database”
•    chmod 755 /usr/local/bin/auto_data_load
•    su userc
•    /usr/local/secbin/cacl -a charlie /usr/local/bin/auto_data_load
•    ssh-keygen
   生成一对新的密钥, 并将passphrase以两人控制, 以确保任何人都无法获的完整的passphrase.
•    将.ssh/id_dsa.pub 或 .ssh/id_rsa.pub中的内容添加到Solaris服务器上~sam/.ssh/authorized_keys文
   件中。
•    运行ssh sam@SunMachine uname –a
   以确认以密钥进行的登陆一切完好。
•    将.ssh/id_dsa 或.ssh/id_rsa改名成asshc.key
•    /usr/local/bin/asshckey sam@SunMachine
   建立以AES算法加密的passphrase文件, 供以后用asshc进行ssh自动登陆使用。
•    /usr/local/bin/asshc sam@SunMachine “uname –a;ls”
   以确认自动登陆无问题。
•    退出userc
•    修改/etc/passwd文件, 将userc 的shell属性改成 /bin/false. 并可将该用户的口令改成非法.

在此之后, charlie虽然无权阅读文件内容,但却可用:
        /usr/local/secbin/cacl -e userc /usr/local/bin/auto_data_load
完成从数据传送到数据加载进数据库的一揽子作业, 并可将此完全自动化，节省人工成本并消除由人工所可能产生的失误，一举多得。
我们的assh及asshc可抗系统调用跟踪, 并可检测特洛伊木马的攻击.
以此设置, 无人可通过charlie的帐号对文件传输的功能进行滥用. 甚至是超级用户都无法直接经由userc滥用此功能。