从内存加载数据库文件

时间:2012-12-14 23:45:36

标签: c# database file memory

我可以将某些文件解密到内存中,然后在不使用硬盘的情况下将其用作常规文件吗?

更确切地说,我想用一些敏感数据解密.mdb文件,并像从磁盘加载一样操作但而不使用临时文件。 我想也许我可以从解密的字节数组中做一个File对象或流(仍然需要计算代码),但是,问题是OleDbConnection从包含文件名的字符串加载数据。

让我们试着举例:

byte[] someArrayWithTheContentsOfAdotMDBFile = getDecryptedFile();

[...]

//即使我将数组包装到文件或流中,加载过程也需要一个文件名

using (OleDbConnection connection = new OleDbConnection(@"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=.\"+ fileNameHere)) // can fileNameHere  be a File object, stream or any trick like that??

编辑:由于答案采用了这种方式,我将标题改为“加载数据库......”。我仍然有兴趣从内存加载任何文件类型,但让我们留下另一个线程

4 个答案:

答案 0 :(得分:3)

我不认为访问可以做到这一点......

但是您使用以下设置来实现目标:

  • 使用SQLite
    它可以使用内存(纯RAM)作为存储并对其进行操作

  • 使用加密的“SQLite-Dump”(即备份)作为传输机制(文件)
    当你需要对它进行操作时,将其加载到内存中,解密它,创建一个空的“SQLite内存实例”并从解密的流中“恢复”它

要注意:
您要求的方案可能是某些数据库引擎,如SQLite BUT,因为您需要解密文件,您的应用程序必须包含解密所需的密钥。
这意味着如果有人想要读取您的数据库文件,他们可以先分析您的应用程序,恢复解密密钥等 如果您使用“对称加密”(例如AES),那么他们甚至可以在您的应用程序没有注意到的情况下修改数据库文件 如果您使用“非对称加密”(例如RSA),那么他们仍然可以读取它但不能修改数据库文件。

关于安全性的一个非常重要的一点:在不受你控制的100%机器上运行的任何东西都可以“破解” - 它只取决于攻击者的能力和激励程度。

答案 1 :(得分:2)

您是否考虑过将SQL Server Compactdatabase encryption一起使用?

SQL Server Compact是一个基于文件的数据库,而不是基于服务器的,正如您在评论中所说的那样,对您来说更合适。

磁盘上的文件已加密。它在内存中解密,解密数据不存储到磁盘。

使用起来非常简单 - 只需在打开与数据库的连接时将密码放在连接字符串中。

似乎这适合您的用例。


旁边的密码/密钥管理:是的,感谢阿列克谢,我希望没有人会提到那个。 :-)这是一个棘手的问题,特别是如果我们谈论的是一个分发给你想要保护数据库的人的应用程序。

最终,它无法完成。如果您的应用程序可以打开数据库,并且您分发应用程序,则攻击者可以对您的应用程序进行反向工程并找出如何打开数据库。 .NET应用程序当然特别容易反编译。

我看到它的方式,您可以将密钥放在代码中,并接受任何反编译代码的人都会找到它;或者你可以尝试努力混淆它(将密钥分解到代码中的各个地方,编写难看的复杂代码来重建它等等)如果你这样做,它仍然会破坏 - 你只需要提高从“任何反编译代码的人”到“任何反编译代码的人都愿意花时间和努力完成混淆”。

答案 2 :(得分:1)

如果某些内容需要文件名,则无法获得公开显示的文件(无论是磁盘上的普通文件,ram磁盘还是任何其他类型的设备)。

您可以尝试:

  • 配置文件的安全性,以便只有当前用户可以打开它
  • 考虑使用delete-on-close标志创建临时文件,以便它不会保持足够长的时间
  • 找到另一个可以在内存中存储的数据库引擎。

旁注:你需要仔细考虑为什么要尝试这条路线。可能会发现,您尝试创建的限制要么不能解决您的问题,要么考虑到您的用户完全过度杀伤。

答案 3 :(得分:0)