“仅推送”备份?

“仅推送”备份?

我有一台服务器,它将其备份推送到某个在线备份空间。入侵者(在推送到备份空间的服务器上)可以访问备份空间并破坏备份,因为凭据在服务器上。我想在不设置备份服务器的情况下解决这个问题。

有人关心这个问题吗?或者这根本就是个问题吗?

这个问题有名字吗?有哪些可能的解决方案?

答案1

您所提到的问题实际上是备份完成后如何保证其安全的问题。

  1. 解决这个问题的标准方法是使用某种定期从现场带走的可移动媒体。

    • 通常,使用 LTO 磁带介质时,您会定期将所有备份磁带轮换到场外,这样,现场唯一的备份磁带就是磁带库中用于记录备份数据的磁带。
    • 我也偶尔看到过 USB 闪存驱动器和可移动驱动器也采用这种方法。这种方法可以保护您的备份免受恶意操作和物理灾难的影响。

  2. 这种方法的稍有不同的是使用一次写入媒体,这样备份一旦完成就无法被删除。
    • 一般情况下,CD/DVD 或 WORM LTO 介质。通常,这种方法的范围会比较有限,因为它很快就会变得昂贵且费力。
      • 例如,在我工作的一个高度安全的环境中,我们编写了脚本来持续将服务器日志复制到备份服务器,然后每晚将其刻录到 DVD 上,以此作为一种机制来保存其中的信息。如果出现问题或我们被黑客入侵,删除相关服务器上的日志不会有什么用处。

如今,随着磁盘到磁盘备份系统的普及,这两种选择都不再可用或可行,但有很多方法可以实现相同的目的。它们基本上分为两类。

  1. 一个类别,正如评论中提到的,是利用公钥加密技术,在加密层面分离读写权限。
    • 其中一项服务是塔斯纳普由于使用不同的密钥来读取和写入数据,您可以将每个密钥存储在不同的地方,这样破坏您备份的攻击者就无法读取它们。
    • Tarsnap 远非唯一一家提供此类服务的公司,您甚至可以使用广泛使用的公钥加密工具推出自己的解决方案。不过,据推测,他们仍然能够“破坏”备份(销毁或破坏它们)。
    • 这在合规性情况或数据隐私很重要的情况下最有用,担心攻击者能够获取信息(读取您的备份),但不能防止攻击者破坏或损坏这些备份。

  2. 另一类是实际分割权限,以便您的备份服务器没有更改或覆盖数据所需的权限。
    • 显而易见的方法是仅在文件系统级别授予备份服务器/服务读写权限,但不授予修改或删除权限。
    • 您可以通过将备份服务器与保存备份的服务器分离来实现同样的目的,这样,破坏实际备份不仅仅涉及破坏用于创建备份的服务器。
      • 我现在为 $[corporate_overlord] 使用的方法就是如此。备份在异地复制(磁盘到磁盘系统),但主备份节点和异地节点使用不同的帐户访问,因此,一个节点受损并不会导致另一个节点受损。每个节点都可以读取其他节点的数据,但每个节点只能修改/删除自己的数据。

  3. 甚至可以将这两种方法结合起来,以达到真正两全其美的效果。

最后,即使您使用的是磁盘到磁盘方案,也没有理由不能实施一种有效地使备份脱机的解决方案。您可以设置一个系统,在备份完成后自动将存放备份的服务器/磁盘脱机,并且仅在计划进行下一次备份时才将其重新联机,或者更简单一点,将存储备份的卷重新安装为只读。这似乎比设置上述权限的工作量更大,但这是可能的。

答案2

人们显然关心这个问题,这就是为什么塔斯纳普存在。这使用单独的读取和写入密钥。

要执行备份,您只需拥有写入密钥。

您可以将读取的密钥安全地保存在远离备份系统的地方,并且仅在需要恢复文件时才可用。

在将备份发送到备份服务之前,使用密钥对备份进行加密。

答案3

我的理解是,标准 svnserve 服务器(处理 Subversion 版本控制存储库的“svn://”或“svn+ssh://”协议的服务器)允许人们将新版本提交到存储库,但实际上不可能“丢失”先前提交到存储库的版本。

(您的在线备份空间可能已经为您设置了这样的服务器)。

答案4

我们处理这个问题的方法是使用 amazon S3,它允许写入新对象但不能通过服务器上的凭据删除,然后在存储桶上使用版本控制,这样即使入侵者存储了坏备份,旧的(好的)备份仍然存在。

到目前为止运行良好。

相关内容