我有一个缓存预热脚本,我想启动以响应某个服务器端事件。该脚本需要用户凭据才能执行其工作(只读帐户)。到目前为止,我一直避免自动化这个过程,因为我不想在服务器上存储任何凭据,但我已经到了我真的需要自动化这个过程的地步。服务器是 CentOS 6。
我知道存储任何凭证都是一种风险,所以我很好奇行业标准是什么,如果我每次需要运行此过程时都不能在终端输入凭证。
更新 根本问题:如果不能明文存储凭据,还有哪些其他选择?
我有一个缓存预热脚本,我想启动以响应某个服务器端事件。该脚本需要用户凭据才能执行其工作(只读帐户)。到目前为止,我一直避免自动化这个过程,因为我不想在服务器上存储任何凭据,但我已经到了我真的需要自动化这个过程的地步。服务器是 CentOS 6。
我知道存储任何凭证都是一种风险,所以我很好奇行业标准是什么,如果我每次需要运行此过程时都不能在终端输入凭证。
更新 根本问题:如果不能明文存储凭据,还有哪些其他选择?
为避免完全使用凭据,请将缓存预热脚本的触发器与服务器端事件分离。
这个概念是:
由于持久化进程可以通过 cron 或作为缓存预热脚本用户拥有的守护进程运行,因此您只需设置一次,无需传递用户帐户凭据。
共享位置:
确定服务器端事件和需要运行缓存预热脚本的用户都可以访问和写入的共享位置。在具有数据库的系统中,这可能是配置表中的变量。但这也可能只是目录中的一个文件,两个用户都是 +rw 并且被服务器端事件触及。
设置标志:
如果您使用的是数据库,则设置标志的一个示例是,如果您有一个包含键和值列的变量表,将特定键的值设置为 1。如果它是一个文件,那么它将是一个文件的存在。
附带好处:
如果您需要限制缓存预热脚本的运行频率,您始终可以在持久化进程中实现逻辑以跟踪脚本上次运行的时间,以防止出现问题时过度使用。
您可以轻松地从其他服务器端事件添加多个缓存预热脚本触发器,因为触发脚本的方法隐藏在共享位置界面后面。
关于更新:如果不能明文存储凭据,还有哪些其他选项?
通常,一旦实体想要对服务进行身份验证,该实体必须具有身份验证令牌。也就是说,如果您正在使用密码身份验证并希望自动执行此操作,则必须以某种方式以明文形式访问密码 - 否则您需要另一个令牌将其从“安全”形式转换为明文。
回到你原来的问题,考虑谁、为什么以及如何有人可能(想要)滥用凭据总是很好的(例如,如果它们在纯文本文件中,只有运行缓存预热脚本的用户才能读取)。事实证明,保护它没有多大意义,或者项目的整体安全概念存在缺陷。
您可能想询问Security SE - 您可能会在那里更深入地回答。