Restic: 支持非对称备份

对之前讨论的简要回顾：

• 用于电子邮件服务器的备份或日志数据的远程备份，以防此类服务器受到威胁。 已从服务器粉碎的敏感数据可能存在于备份中，并且能够拒绝攻击者访问此类历史数据可能很有用。 同时还讨论了拥有一个具有能力系统的“blob 网络服务器”可能很有用，该系统允许您根据需要配置仅附加/只读/读写访问。 使用非对称加密技术将无需再使用一组对称密钥来发布功能，并且还可能简化功能系统的实现。
• 在多台机器的设置中，_one_ 备份密钥可用于访问多个备份数据集，而无需管理多个对称密钥。 如果使用诸如 Daniel Bernstein 的 Curve25519 之类的密码系统，则此类密钥可能来自密码短语，这意味着您可以使用一个主密码短语来管理由（可能很大）数量的不同安全域创建的备份。 虽然当然可以使用n对称密钥和加密密钥存储来实现类似的东西。

@heipei仅供参考，您可能想订阅此问题

好吧，最明显和最紧迫的用例不是让已经闯入您的生产系统（备份客户端）并知道如何从那里使用 restic 的攻击者删除备份。

仅使用非对称加密几乎是不可能的。 这里的重点是旧的备份内容（不一定是元数据）对于闯入服务器的攻击者不应该是可用的。

对于这些场景，通过实施非对称加密可以实现数据机密性( write-only )。

数据完整性是一个稍微不同的野兽：
虽然您可以使用非对称加密（和一次性签名方案）来证明给定的数据集未被更改，但您无法阻止其完全删除或替换。 这是一个需要append-only （和read-only ，对于某些部分）的存储系统的问题。
多亏了在 *nix 上使用 ssh 等后端实现的自由访问控制相对简单（使用chmod 、 chown 、 chattr +i 、 chattr +a来配置访问策略）。 append-only备份甚至不需要加密以防止攻击者读取它们（例如，这是rsyslog所做的一部分），但这突然使备份服务器成为一个有趣的目标，并且将敏感数据克隆到更多设备并不能完全提高保持数据机密性的几率。

实施非对称加密将使人们能够在愚蠢的、不受信任的系统上进行这种备份，这是restic的全部意义之一（除了改进的重复数据删除和所有其他不错的功能）。 我希望这个阐述可以澄清我的观点。

我们对https://github.com/restic/restic/issues/187#issuecomment -101974306 中描述的两个案例感兴趣。 我订阅这个线程来关注这个。

关于数据完整性：AFAIK，您可以通过仅授予您的 IAM 凭证PutObject和GetObject权限，但保留DeleteObject权限，在 Amazon S3 上实现append-only行为允许。

关于数据机密性，我想提一个通过使用对称加密实现的攻击场景：
如果攻击者在受害者使用restic执行备份的某个时间点控制了受害者的用户帐户，他可以：

• 窃取受害者的restic密钥
• 窃取受害者的 IAM 凭证/sftp 登录名/...

然后，攻击者可以立即从受害者的系统中清除其攻击的任何痕迹，从而降低被检测到的可能性。 由于他窃取了远程存储系统的静态密钥和凭据，受害者将方便地向他提供任何（备份的）未来数据：我们的攻击者只需要不时地从远程存储系统下载和解密新的备份时间。

非对称加密可以通过允许受害者存储用于离线恢复备份的密钥来帮助防止这种情况。

关于数据完整性：AFAIK，您可以通过仅授予您的 IAM 凭证 PutObject 和 GetObject 权限，但保留 DeleteObject 权限，在 Amazon S3 上实现仅追加行为。

不幸的是， PutObject还赋予您覆盖先前上传文件的权限。 那么，也许这不是完整的数据完整性？

非对称加密还允许使用像 yubikey 等的 OpenPGP 密钥。

今天我意识到我真的不希望在 restic 中支持非对称加密，而是支持不在存储库中存储密钥。 我知道有效地使用非对称加密意味着 restic 可以上传新备份而无需读取存储库，这非常棘手。

所以，对我来说，如果我可以在没有 restic 的情况下处理对称密钥就好了，并且无论使用什么复杂的 KDF，它都不会以任何方式上传到存储库。

我的用例是作为多个服务器的系统管理员。

在攻击者恶意破坏（或勒索软件加密）所有数据（包括备份）的服务器遭到入侵的情况下，非对称备份是保护备份的唯一方法。

这需要通过仅附加存储层或类似于 rdiff-backup 具有 --restrict-update-only 选项的方式的服务器守护程序来提供服务器端支持。 目前我通过使用备份服务器上备份存储库的只读快照（通过 sftp 访问）来解决这个问题。

（也许相关）：在 Linux 中可以通过目录上的append-only标志（禁用取消链接）以及文件上的immutable标志来实现仅附加。 负责设置这些标志的命令分别是chattr +a /path/to/directory和chattr +i /path/to/directory/myfile01 。

我的用例是#533 - 无人值守备份。 如上所述，非对称加密只是其中一种方法，但它似乎是解决问题的第一个明显解决方案。

在 repo 位于远程服务器上的情况下 - 只有 repo 上的本地命令应该能够忘记/修剪。

静态备份应与该系统的唯一密钥连接，仅具有恢复/备份权限。

在 repo 位于远程服务器上的情况下 - 只有 repo 上的本地命令应该能够忘记/修剪。

这应该通过在 repo 级别限制对删除/修改文件的访问来实现。 我认为 restic 管理这些权限超出了范围（甚至不安全）。 毕竟，有人可以删除 repo 甚至密钥，从而使整个 repo 变得无用，而不管 restic 客户端是否允许该操作。

关于防止备份数据被攻击服务器的人破坏：rest-server 最近通过 PR https://github.com/restic/rest-server/pull/28获得了“仅附加模式”，可以完全防止这种情况。

我的用例是将许多系统备份到同一个存储库，从而在所有这些机器上获得重复数据删除的优势，但是一个系统（及其备份脚本）的妥协不允许攻击者读取其他系统的备份。

我正在寻找的功能是拥有“备份”密钥，使系统能够写入（备份）和读取（恢复）但不能进行任何管理（例如修剪、添加密钥甚至查看其他与 $backup_key 无关的键、（用户）或快照）。 （虽然通过比较备份时间可能会进行旁道攻击，但他们是否可以确定数据的存在对我来说并不重要，只是他们无法勒索我的数据并且无法查看其他用户。）我希望备份（仅）密钥的持有者能够向前滚动他们自己的密码短语。 因此，与michbsd 的请求不同，我可以使用特权密钥从非本地计算机进行管理。 （使用 SELinux 多年，我现在是 MAC 粒度的粉丝）感谢阅读。 （对不起，如果这应该有它自己的问题。）有了这个功能#ResticKillsRansomware

使用此功能#ResticKillsRansomware

一般来说，面向拉的备份（相对于面向推送的备份）可以解决勒索软件，对吗？ :)

可能，但是这会提供远程访问并添加另一个攻击向量。 我是如何设计它的，我的备份服务器是用来保存数据的，永远不应该访问我的生产环境。 功能域的明确划分。

我猜测 Restic 不是解决方案，因为它旨在直接对备份存储库进行操作。

也许你可以用各种中间人服务器做点什么。 让您的生产机器将 tarball 上传到服务器，然后让另一个系统下载 tarball，解压缩它们，并在本地备份内容。 每一方只能访问中间服务器。 这将相当简单，无需对 Restic 进行任何修改。 它也可能更安全、更健壮，因为仅接收 Restic 模式中的任何错误都可能使备份容易受到受损备份客户端的攻击。

我正在寻找的功能是拥有“备份”密钥，使系统能够写入（备份）和读取（恢复）但不能进行任何管理（例如修剪、添加密钥甚至查看其他与 $backup_key 无关的键、（用户）或快照）。 （虽然通过比较备份时间可能会进行旁道攻击，但他们是否可以确定数据的存在对我来说并不重要，只是他们无法勒索我的数据并且无法查看其他用户。）我希望备份（仅）密钥的持有者能够向前滚动他们自己的密码短语。 因此，与 michbsd 的请求不同，我可以使用特权密钥从非本地计算机进行管理。 （使用 SELinux 多年，我现在是 MAC 粒度的粉丝）感谢阅读。 （对不起，如果这应该有它自己的问题。）有了这个功能#ResticKillsRansomware

虽然这可能不是你想要的，但你可以看看rest-server 。 它具有仅附加模式，可防止删除和修改现有备份。

虽然这可能不是你想要的，但你可以看看 rest-server。 它具有仅附加模式，可防止删除和修改现有备份。

我什至没有意识到存在。 乙：

我看到两个结构性的东西（和稍微不同的攻击者模型），我想在这里转储。

目前，restic（主要）与“哑”存储（本地、s3、b2、gcs、azure，除了带有--append-only的 REST 服务器之外的所有内容）交互。 它可以在后端保存、列出、获取和删除数据。 这是备份所必需的，因此需要提供访问后端所需的凭据。 从好的方面来说，restic 几乎可以使用任何存储，限制很少。 不利的一面是，一旦攻击者获得对服务器的访问权限，他们就可以轻松提取访问后端的凭据和静态密码，从而为他们提供所有可能性：从存储库中解密历史数据、修改数据、删除整个存储库。

当我们添加非对称加密时，这种情况下攻击者的唯一区别是他们无法从存储库中解密历史数据。 其他一切，尤其是删除所有数据，仍然是可能的。 所以“只添加非对称加密”并不是全部。

另一个想法是不直接访问“哑”存储，而是通过自定义服务器实现间接访问。 我们尝试了这个想法，并为REST 服务器添加了--append-only选项，它可以被看作是访问本地硬盘上的“哑”存储的“适配器”。 我有几个关于如何改进这个想法的想法，不一定是使用 REST 服务器。

例如，我想为通过一对文件描述符（例如 stdin/stdout）说话的后端定义一个协议。 然后我们可以在远程机器上通过 SSH 运行的程序中实现这一点，就像我们在 sftp 后端所做的那样。 服务器实现然后可以决定在哪里存储数据（本地，s3，b2，等等）和应用哪些限制（例如“只添加读取旧数据或添加新数据”，除了锁定文件之外无法删除任何内容。服务器例如，可以在使用特定用户帐户或 SSH 密钥通过 SSH 登录时通过ForceCommand启动。

单独拥有“非哑”存储不会帮助攻击者从存储库读取数据（至少在不更改存储库格式的情况下不会），但会阻止删除存储库中的所有数据。

因此，总而言之，为了最好地防御攻击者接管使用 restic 进行备份的服务器，我认为我们需要同时实现（非哑存储和非对称加密）。 这是一个长期目标:)

我将把这段文字复制到本期的第一条评论中，这样更容易找到。

是的，进一步思考这一点，我同意 asym 加密对于防御收购不是那么有用——它对于无人值守的备份更有用（#533）。

拥有本机通信协议可能很有用，但我不确定您从当前的 REST 服务器中获得了什么 - 您能扩展一下吗？ 阁楼/博格那里去：有一个客户端-服务器“专有”（如，博格专用）协议存在，并且可以实现为客户提供一些限制。 是的，这依赖于 ForceCommand 和“borg serve”受限标志......在 borg 文档中有一些

当然，保护备份免受受感染客户端的最自然方法是简单地不允许客户端自己执行备份，而是让服务器从备份中提取文件，“bacula 式”（“它来自晚上并从您的计算机中吸取精华”，对于那些记得那个朗朗上口的短语的人）。 在 borg 中似乎也没有详细记录或优雅的方法来执行此操作，常见问题解答指向https://github.com/borgbackup/borg/issues/900作为对该主题的讨论。 此处在#299 中对此进行了跟踪，此处尚未提及。

长话短说，我将保持非对称加密支持的重点简单：使异地密钥存储和自动备份更容易。 还有其他方法可以保护受感染的客户端，我认为拉式支持是最有趣的一种。 事实上，在我的最佳备份解决方案中，我让所有客户端将他们的备份推送到中央服务器，然后从主备份服务器拉取异地服务器。 这边走：

1. 备份服务器不需要所有机器上的 root 访问权限
2. 然而，即使他们能够弄乱备份，机器的妥协仍然是可以恢复的

我实际上觉得奇怪的是，这个问题变成了“我想防止客户被接管”——也许我们在这里混淆了解决方案和问题。 :)

你好，

似乎这个问题不仅与非对称加密备份有关，而且与不同的攻击向量有关。
我没有阅读代码，所以我真的有一个幼稚的问题，但我的用例主要是关于能够在不公开密钥的情况下备份数据（通过使用备份所有者的离线私钥的公钥）。 对于那个用例，它容易实现吗？

我对这个主题的理解是，现在所有的 blob 都使用相同的密钥加密，并且效果很好。
如果我们像 OpenPGP 那样使用非对称加密，那么制作的每个快照都会生成一个用公钥加密的对称密钥，并将其添加到存储库中。 但我想问题在于，为了能够发现要删除重复的内容和要备份的内容，您应该能够首先阅读信息，因此您还需要私钥。 那正确吗？
如果是这样的话，一些零知识证明可以帮助沿着这些路线吗？

@dolanor请不要在此问题中添加新的用例或问题，请使用论坛提问。 此外，现在谈论实现细节还为时过早。

我已经更新了第一篇文章中的摘要。 同时添加了rclone后端，这可以用作如上所述的“适配器”，并通过例如 SSH 进行访问。

不利的一面是，一旦攻击者获得对服务器的访问权限，他们就可以轻松提取访问后端的凭据和静态密码

我希望这是一个错字：你们这里是加密的密钥文件材料，不是吗？ 希望获得服务器访问权限的攻击者无法访问明文密码。 他们能做的最糟糕的事情是尝试暴力破解或猜测用于解密存储库的主加密和身份验证密钥的“用户密码”。

如果这是正确的，我强烈建议您再次更改摘要以进行澄清，因为这样说确实看起来很糟糕。 :)

希望获得服务器访问权限的攻击者无法访问明文密码。 他们能做的最糟糕的事情是尝试暴力破解或猜测用于解密存储库的主加密和身份验证密钥的“用户密码”。

我猜这取决于确切的情况：如果您手动输入密码，对。 另一方面，如果您正在执行预定的自动备份，则“用户密码”必须存储在服务器上的某个位置。

而且，当然，攻击者可能会将 Restic 二进制文件替换为泄露输入的密码并等待您输入的二进制文件。 你不能相信一个受感染的系统。

“用户密码”必须存储在服务器上的某个地方。

“服务器”是指“我们正在运行的机器是我们保存数据的机器”还是“从备份接收/存储数据的机器”？

这是相当模棱两可的，也是我担心的根源：我不介意备份客户端（我们正在备份的正在运行 restic 的机器）具有明文密码：无论如何，整个数据集都在那里，所以如果它受到损害，数据是反正妥协了。 但我当然希望备份服务器无法访问明文！

“服务器”是指“我们正在运行的机器是我们保存数据的机器”还是“从备份接收/存储数据的机器”？

我们正在运行的机器取决于我们保存数据的机器。

我明白你的意思，你是对的，这是模棱两可的。 根据我对 Restic 模型的了解，我的理解与您的相同，我对此非常确定，但我不能给您想要的明确确认。

摘要中提到了 REST 服务器的--append-only选项。 也许这应该仍然是唯一官方推荐的仅追加备份的方法，但最好记录下 restic 中的哪些文件需要可写才能正常操作，以帮助确定如何设置其他方法。

如果data 、 index 、 keys和snapshots允许文件创建但不允许修改或删除，我相信restic backup会正常工作（ config也受到保护）。 但是，我认为locks需要允许删除，以便存储库不会被永久锁定。 此外，一些仅追加的实现（如 ext4 和 xfs 文件系统的属性）不是递归的，因此需要先预先生成data的 256 个两个字符的子目录，然后需要生成该属性设置在他们身上。

一些后端（如 S3）不支持仅追加，但支持可以达到相同效果的对象版本控制。 但是，这需要仔细检查访问控制模型。 例如，B2 具有允许对象版本控制的生命周期规则，但备份到 B2 所需的 API 密钥具有修改生命周期规则的能力（B2 还没有真正的权限系统）。

旁白：我可能遗漏了一些东西，但如果非对称加密只是保护历史数据免受破坏客户端的攻击者的侵害，那么这似乎是一个低优先级的问题。 拥有它会很好，但在大多数情况下，当前数据比以前的版本更有价值（尽管有时会意外备份、删除但没有清除有价值的东西）。

@willsALMANJ很好的观察。 对于 S3，我想知道是否可以记录反对版本以允许获取恢复给定快照所需的 blob 的连贯视图（尽管您可以根据它们的内容验证它们，所以不是非常重要）。

回复：你的最后一段：

• 除了您提到的“解密历史事物”场景之外，非对称加密的主要好处是能够将来自多个独立机器的备份存储在同一个备份存储库中，而无需提供单独的密钥（这需要每次将备份密钥存储在某处）安装新的客户端机器）。 如果您使用共享密钥，则会出现令人讨厌的威胁场景，其中客户端 1 可以读取客户端 2 的数据，这并不理想。

@fd0我想我有一个不错的非对称加密方案，使用 HMAC 寻址和派生的共享秘密。 还有一些关于不泄露数据的服务器端垃圾收集的想法，不确定你是否感兴趣，但如果你有兴趣，我很想谈谈它。

我不知道我是否在这里遗漏了什么，但是我在 S3 存储上使用此策略设置成功运行了 restic。 它不会阻止攻击者读取数据，但会阻止他删除 vom。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::kvasir"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::backup/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::backup/locks/*"
    }
  ]
}

然后从具有写入权限的受信任设备运行 prune/forget 命令。 我还在每个 restic 存储库中创建了两个密钥。 一个用于服务器，一个用于受信设备，以便受信设备可以锁定攻击者（但攻击者不能，因为他无法删除密钥/*）。

编辑：对不起，忽略了这已经讨论过。 不想劫持这个线程。
PutObject 实际上能够覆盖对象，因此这不是保护备份的解决方案。

@freswa我不是 S3 专家，所以我不确定这是否正确，但在本次讨论中提出的观点是PutObject权限可用于覆盖您的数据，这同样糟糕作为删除它。 在我上面的帖子中，我指出您可以通过使用对象版本控制来解决这个问题（不要让备份系统访问删除版本）。

@andrewchambers我有点被其他东西淹没了，一旦我们真正实施了这个，让我们谈谈你的想法！ 是的，我有兴趣 ;)

所以，这个问题是关于（最终）实现非对称备份，而不是后端存储的访问配置。 谢谢！ :)

@fd0希望这能解释我的意思https://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers ：以防万一你还没有遇到只写问题（你在你的网站上提到的），它是https://github.com/ncw/rclone/issues/2499。

@andrewchambers感谢您写下来，我对实际实现的样子很感兴趣。 这篇博文留下了一些有趣的地方:)

我喜欢免费软件备份程序领域将有另一个竞争者，为用户提供更多选择总是很棒的！

因此，可以使用两种 git 存储库加密机制进行有趣的并行处理。

一方面，您有git-crypt ：它使用 git smudge/clean 过滤器来（分别）加密/解密 blob 存储和签出副本之间的文件。 这运行良好并且相当优化，但它有一个明显的漏洞：git 提交本身没有加密，只有 blob 的内容，这意味着文件名、提交日志、作者、日期和其他元数据都是明文存储的。 对于许多用例来说，这是行不通的，并且仅当您有一个公共存储库（例如）您想要加密某些位（但不是全部）时才有效。

另一方面，您有git-remote-gcrypt ：它使用git 远程助手协议来加密服务器上发送的所有内容。 但这是非常低效的，因为由于特殊遥控器的工作方式，整个存储库在每次运行时都会重新加密。

现在，这些是特定于 git 的实现挑战，但我认为它们很好地映射到您在这里可能遇到的问题。 也许我在这里完全超出了我的深度，这种平行是无关紧要的，但我认为它可能在这里很有趣......

顺便说一句，目前有一个中间立场可以（可能）很容易地实现：允许将密钥存储在存储库之外。

正在解决的攻击媒介之一是攻击者获得密钥密码，然后（因为密钥存储在存储库中）他可以轻松解密密钥。

如果我们允许指定存储密钥文件的单独密钥目录会怎样？ 这个目录可以本地存储在每台需要备份的机器上，它本身可以备份到不同的云提供商，或者甚至是一个二维码（大约 500 字节足够小，可以进行二维码编码）用于冷离线存储例如，在保险箱中。

如果加密密钥从未接触过云提供商，则攻击向量将完全消失。 例如，密钥必须从物理场所泄露或被恶意软件泄露。

如果保留了存储库的本地副本，则可以在 Restic 上完成此操作——只需在运行 rclone 时将密钥目录从同步到不受信任的远程服务器中排除。 如果没有本地副本并且 restic 直接与不受信任的远程交互，则无法完成此操作。

我认为我们应该应用单一职责原则并将事情分解为两个任务：

1. 保护数据不被解密。
2. 保护数据免受未经授权的删除操作。

它们是数据安全的两个不同方面。 从技术上讲，它们不必相互依赖。

对于（1），显然我们可以“简单地添加非对称加密支持”。 对于（2），我相信有很多可能的解决方案（例如，如上所述，仅附加 S3 设置）。