随着您的扩展,对所有产品进行推送更新将变得不可行.

>您必须跟踪每个客户,每个客户可能都有不同的防火墙配置.
>您必须通过客户的防火墙创建传入连接,这需要端口转发或其他类似的机制.这对您的客户来说是一个安全风险

相反,让您的产品定期“拉”他们的更新,然后随着您的成长,您可以在服务器端添加额外的容量.

怎么样？

正如您所建议的那样,此问题已得到解决.这是我能想到的几种方法.

> using apt：使用带有自定义PPA和源列表的内置apt系统. How do I setup a PPA?

> Con：除非您使用像启动板这样的公共托管服务,否则设置自己的apt PPA打包系统并不适合胆小者.

>使用ssh：为每个产品生成SSH公钥,然后将该设备的密钥添加到更新服务器.然后,只需让您的软件rsync / scp所需的文件.

> Con：必须跟踪(并备份！)您发送的每个产品的所有公钥.
> Pro：比原始下载更安全,因为可以访问更新的唯一设备是安装了公钥的设备.

>原始下载签名检查：

>在某处发布已签名的更新文件(Amazon S3,FTP服务器等)
>您的产品会定期检查要更改的更新文件,然后下载/验证签名.
> Con：根据您的部署方式,文件可以公开访问(这可能使您的产品更容易进行逆向工程和黑客攻击)

> ansible：Ansible是管理系统配置的绝佳工具.它在木偶/厨师的领域,但是无代理(使用python)并且被设计为幂等的.如果部署您的软件需要复杂的bash脚本,我会使用这样的工具来降低执行更新的难度.

当然,还有其他方法可以做到这一点..但它带给我一个重要的观点.

签名/验证您的更新！

无论您做什么,都必须有一个机制来确保您的更新没有被篡改.恶意用户可以在上述任何配置中模拟您的更新服务器.如果您没有验证更新,那么您的框更容易入侵并进入.

执行此操作的一种好方法是签署更新文件.您必须维护证书(或向某人付费),但您可以在发送之前在每台设备上安装指纹,以便他们可以拒绝已经被篡改的更新.

物理安全

当然,如果有人可以物理访问客户的部署,他们可以轻松接管服务器.但至少他们无法攻击其他部署！物理安全可能是您客户的责任.

If you would for a moment,imagine what would happen if you used a
large OpenVPN network for updates… They could then use the
compromised server to attack every instance on the VPN

安全

无论你做什么,安全性都需要从一开始就建立起来.不要在这里偷工减料 – 如果你这样做,你最后会后悔的.

完全保护此更新系统超出了本文的范围,如果您或您团队中的某个人不熟悉该领域,我强烈建议您聘请顾问.值得每一分钱.