敏感信息被放置在可公开访问的文件夹中。谁负责以及如何进行?

信息安全 应用安全 Web应用程序 权限
2021-08-20 10:45:13

背景

我们有一名 IT 人员管理我们的服务器,还有一名 Web 开发人员不在 IT 人员中,并且没有对服务器的 root 访问权限。所有相关人员都完成了非常高质量的工作,我认为这种失误并不特别严重,因为没有确保这些信息安全的后果相对较小。我主要有兴趣从这次经历中学习。

上周,我们的 Web 开发人员向我和 IT 人员发送了一封电子邮件:

我没有意识到 [project1] 和 [project2] 已直接放在 [my-server] 上的 /var/www 内,但我认为它们已放在可公开访问的空间之外。我已经更正了权限以防止访问任何敏感内容,但它们不应该在 /var/www 中,因为只有“公共”文件夹需要链接到那里。

因此,自项目启动以来,[project1] 和 [project2] 项目中的所有文件都可以通过 Web 访问。这样人们就可以访问项目中的所有文件,甚至可以访问存储在那里的数据库转储和日志。值得知道是否有人曾经访问过“path/to/project1/db_backups”、“path/to/project1/config”、“path/to/project1/db”、“rails/project2”中的任何文件/db', 'rails/project2/config' 文件夹作为存储的密码可以在这些文件夹中找到。

问题

  1. 假设 IT 人员或 Web 开发人员应该处理这个问题,我有错吗?
  2. 谁负责确保敏感信息得到妥善保护?
  3. 除了检查日志之外,还有其他我应该采取的步骤吗?
4个回答

我不愿意分担责任,尤其是当这显然是一个诚实的错误时。过分关注某一事件的责任会毒化井,使人们更不愿意在未来报告安全事件。即使不涉及任何责任,不得不报告您搞砸了并且可能导致安全漏洞已经足够令人尴尬。我喜欢你说的“我主要有兴趣从这次经历中学习”——我认为这是一种非常健康和建设性的态度,我鼓励你广泛地重复它,让所有参与的人都知道,并以相应的方式行动。

顺便说一句,您可以将此视为一个模拟您如何应对安全问题的机会。文化不是由公司领导者所说的话决定的,而是由他们的行为方式决定的——尤其是他们在困境中的行为方式。模仿“这不是责备,而是从经验中学习”的态度似乎是为健康文化做出贡献的好方法,这种文化将在未来为您提供良好的服务。

回到你的核心问题。我认为这个问题的主要答案可能是:沟通。第一步是让相关人员讨论这个问题,并就谁的责任达成一致。网络管理员是否有责任确认放在公共网络服务器上的所有内容是否真的打算公开?这是发布内容的人的责任吗?这些人怎么知道是谁的责任?

也许你可以考虑的一个可能的教训是:小心你在公共网络服务器上挂载的文件系统/挂载点/共享目录。您可能希望有一个分离的经验法则:每个文件系统/共享目录要么是(a)公共的,要么是(b)内部的,并相应地标记文件系统/共享目录。在这种方法下,您将避免使用包含一些公共文件和一些非公共文件的文件系统——当您将新的文件系统/共享目录添加到公共网络服务器时,您可能会进行快速的健全性检查以查看是否文件系统确实被标记为公共的。这只是一个想法,当然,它可能适合也可能不适合您。不要太拘泥于这个特定想法的细节;如果听起来没有帮助,请忽略它。更重要的一点是考虑一下可以帮助您避免这些错误的流程 - 而不会让自己陷入不必要的官僚主义。您将最清楚贵公司的文化和要求是什么样的;您应该能够集思广益,并开始与您的同事进行对话。

假设 IT 人员或 Web 开发人员应该处理这个问题,我有错吗?

通常,您会尽量让外部世界无法访问内部事务。任何投入生产的东西都必须经过检查和验证(至少由管理员)。好吧,然后仔细检查。

谁负责确保敏感信息得到妥善保护?

取决于组织的规模和内部政策。这可能是系统管理员、软件开发人员、首席信息官等。

除了检查日志之外,还有其他我应该采取的步骤吗?

是的!永远,永远不要存储纯文本或加密密码。密码在持久化到数据库之前必须经过哈希处理和加盐处理。通知您的客户有关泄漏并提供更改其私人数据的方法。如果您有真正的客户,这可能会变得非常严重,请咨询律师。

更改您的敏感配置,如果之前尚未完成,则加密其私有部分。

检查搜索引擎以查看您的内容是否已兑现。

除了检查日志之外,还有其他我应该采取的步骤吗?

尽管我确定您会问应该做哪些具体的操作来确保敏感材料没有被披露或更改,但我将在更高的抽象层次上回答这个问题。

在这种情况下,我喜欢问自己五个为什么从事件中追溯并确定根本原因。听起来您已经取得了一些进展,但还没有完全完成。

例如,如果您正在回溯事件并确定您的开发团队无意中将敏感的开发材料放入了生产环境,那么这说明您的配置管理系统周围的安全控制出现了失误。

建立一个新的(或更改您现有的)配置管理系统,以确保您的生产环境不会被开发组更改。拥有一个开发区和一个生产区被认为是一种最佳实践(至少;其他环境,例如测试、集成或暂存区也是可能的环境)。开发人员无法访问生产环境,也没有工具可以让他们在不经过一些可审计过程的情况下更改生产环境。

听起来审计也有失误,这可能是一个更大的安全问题。您可能想了解为什么(同样,5 个为什么)您不知道是谁把它放在那里的。也许是因为每个人都使用root帐户。找到另一种获得所需权限的方法(例如 sudo)。

哦。并更改您的密码。

首先要了解的是,即使在最好的系统中也会发生错误。好消息是,您的 Web 开发人员在识别问题并及时报告方面做得很好。

“我的假设有错吗”-您还记得他们对假设的看法吗?认为....

保护公司资产(所有类型)是高层管理人员的职责,应由您的内部审计部门进行验证。

“谁负责确保敏感信息得到妥善保护?” 首席执行官和董事会。这是一项不可委派的责任。对于上市公司来说,CEO 可以为无知辩护的日子随着萨班斯-奥克斯利法案而告终。

“除了检查日志之外,还有其他我应该采取的步骤吗?” 事后检查日志(事后的任何事情)为时已晚。您需要做的是制定政策和程序来保护您的资产并进行合规性审计。