面试题：ElasticSearch启动脚本的环境变量安全加固

Question

ElasticSearch启动脚本依赖一些环境变量，在安全加固场景下，怎样确保这些环境变量不会引入安全风险？比如，如何防止恶意用户通过篡改环境变量来执行恶意代码，阐述具体的检测与防范措施。

Answer 1

1. 检测措施
   • 定期审计环境变量配置文件：
     • 定期检查ElasticSearch启动脚本所依赖的环境变量配置文件（如.bashrc、.profile等，具体取决于系统环境）。使用diff工具对比当前配置文件与备份的安全版本，若有差异则进行详细分析。例如，假设备份文件为original_profile，当前文件为.profile，可以执行diff original_profile .profile命令查看差异。
     • 检查文件权限，确保只有授权用户（如root或ElasticSearch运行账户）有写权限。使用ls -l命令查看文件权限，如-rw - r - - r - - 1 root root 1234 .bashrc表示只有所有者root有写权限。
   • 监控环境变量的运行时修改：
     • 在ElasticSearch启动脚本中添加环境变量监控代码。例如，在脚本开头使用export HOOK_FUNCTION=monitor_env_vars，然后定义monitor_env_vars函数来记录环境变量的修改操作。在函数中可以使用date获取时间，echo将环境变量修改信息输出到日志文件，如echo "$(date): Environment variable $1 has been modified to $2" >> env_var_monitor.log。
     • 使用系统工具如auditd（在Linux系统中）来监控环境变量相关文件和进程操作。配置auditd规则，如-w /path/to/env/vars/file -p wa -k elasticsearch_env，其中-w指定监控的文件，-p wa表示监控写和属性修改操作，-k指定一个标签以便在日志中识别。然后通过查看/var/log/audit/audit.log日志来分析环境变量相关的操作。
2. 防范措施
   • 限制环境变量的作用域：
     • 在启动脚本中使用local关键字（如在Bash脚本中）来声明环境变量，将其作用域限制在脚本内部。例如local ES_HOME=/usr/share/elasticsearch，这样即使外部环境变量被篡改，脚本内部的关键环境变量仍能保持安全。
     • 避免在启动脚本中直接使用全局环境变量，而是通过脚本内部的逻辑来赋值关键变量。如从配置文件中读取路径并赋值给脚本内部变量，而不是直接依赖系统的PATH等全局变量。
   • 对环境变量进行验证：
     • 在启动脚本中添加对环境变量的验证逻辑。对于路径类环境变量，使用if语句结合test命令（如if! test -d "$ES_HOME"; then echo "ES_HOME is not a valid directory"; exit 1; fi）检查路径是否存在且为目录。
     • 对于其他类型的环境变量，如版本号等，使用正则表达式进行验证。例如，假设ES_VERSION环境变量应该符合x.y.z格式，可以使用if! echo "$ES_VERSION" | grep -E '^[0 - 9]+\.[0 - 9]+\.[0 - 9]+$'; then echo "Invalid ES_VERSION format"; exit 1; fi。
   • 使用安全的启动机制：
     • 使用systemd（在支持的Linux系统中）来管理ElasticSearch服务。在systemd服务配置文件（如/etc/systemd/system/elasticsearch.service）中，通过Environment字段设置环境变量，并且设置ProtectSystem=full等选项来限制服务对系统的访问，防止恶意环境变量修改导致的攻击。
     • 对启动脚本进行签名（如使用GPG签名），在启动时验证脚本的完整性，确保脚本未被篡改，进而保证环境变量配置的安全性。可以使用gpg --detach - sign - a startup_script.sh生成签名文件startup_script.sh.asc，启动时使用gpg --verify startup_script.sh.asc startup_script.sh验证脚本。