在内存中存储敏感数据 [英] Storing sensitive data in memory

查看:84
本文介绍了在内存中存储敏感数据的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的应用程序需要访问一些敏感数据(在本例中为加密密钥).在这一点上,我将它们存储在文件中,以便在处理脚本时可以读取它们.

I have application with needs to have access to some sensitive data(in this case cryptographic keys). At this point I'm storing them in file so they can be read while script is proccessed.

然而,根据我必须遵循的安全标准,它不够安全,因为如果服务器 root 帐户被盗用,某人可能很容易阅读 &复制它们.

However it's not safe enough according to security standards I have to follow, because if server root account is compromised someone may easily read & copy them.

典型的解决方案是挂载包含密钥的外部存储器,启动应用程序,卸载内存并让缓存在内存中的数据运行.当然,因为它是 PHP 是不可能的.

Typical solution is to mount external memory containg keys, start application, unmount memory and let in run with data cached in ram. Of course since it's PHP it's not possible.

还有其他解决办法吗?在这一点上,我唯一的想法是将提供密钥的小型应用程序,但我不确定它应该如何工作以确保安全.

Is there any other solution? At this point my only idea is small side application with will serve keys however I'm not sure how should it work to be safe.

推荐答案

如您所知,无论您做什么,如果应用程序可以使用该密钥,那么获得 root 访问权限的恶意代码肯定可以使用它在服务器上,并且很可能是获得了对应用程序运行所使用的 UID 的访问权限的代码.这只是一个有多容易的问题.

As you know already, no matter what you do, if the key is available to the application, it will certainly be available to malicious code that has gained root access on the server, and most probably to code that has gained access to the UID under which the application runs too. It's just a question of how easy it is.

购买,因为您的应用程序不是长期运行的,听起来您将不得不接受超出此范围的风险.

Buy since your application is not long-running, it sounds like you will have to accept a level of risk beyond that.

您的想法是使用某种守护进程,将密钥保存在 RAM 中,并且可由应用程序查询.这是可行的,但您可能已经意识到,如果您的应用程序可以查询它,那么恶意代码也可以查询它.如果您仍然选择该选项,请考虑使用 memcached(为什么要重新发明轮子?).

Your idea is to use a daemon of some sort which keeps the keys in RAM and can be queried by the application. That works, but you probably already realise that if your application can query it, then malicious code can query it too. If you choose that option anyway, consider using memcached (why reinvent the wheel?).

我能想到的唯一其他选择是编写一个 Apache 模块(用 C 语言),在系统启动时加载机密(之后卸载机密的持久副本)和一个 PHP 扩展(用 C 语言)从位于同一进程中的 Apache 模块获取秘密.这假设您将 PHP 用作 Apache 模块,而不是用作外部进程.但对我来说,这听起来有点矫枉过正,因为它非常复杂,实际上并没有消除风险.

The only other option I can think of would be to write an Apache module (in C) that loads the secret at system startup time (after which the persistent copy of the secret is unmounted) and a PHP extension (in C) to get the secret from the Apache module that lives in the same process. That assumes you're using PHP as an Apache module, not as an external process. But to me this sounds like overkill, because it is quite complex and it doesn't actually remove the risk.

您是否考虑过如何处理交换空间?您可以使用 mlock 或类似(在 C 中)来防止机密被写入到交换中,如果它在一个受限的位置,但是一旦它被移交给它就很难以这种方式保护它PHP 解释器.所以你最好在没有交换的情况下运行系统.

Have you considered what to do about swap space? You can use mlock or similar (in C) to keep the secret from being written to swap if it's in a confined location, but it would be difficult to protect it in this way once it's been handed over to the PHP interpreter. So you had better run the system without swap.

考虑进行设计更改,将机密限制在长时间运行的守护程序(可能不是用 PHP 编写的)中的单个位置,并让 PHP 应用程序将需要访问机密的加密函数委托给该守护程序.

Consider a design change that will confine the secret to a single location in a long-running daemon (probably not written in PHP) and have the PHP application delegate the cryptographic functions that need access to the secret to this daemon.

这篇关于在内存中存储敏感数据的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆