是否有可能在一段时间后使MDB不可读？ [英] Is it possible to make the MDB non-readable after a certain period?

问题描述

我有一个包含客户信息的数据库。为了避免它将从我们的办公室取出

，是否有可能在

a某段时间后使其不可读？

然后每一个比方说七天，我需要延长许可证，所以它将会再持续一周。


它由查询，表格和表格，格式Access 2003.


巴特

I do have a database with customer info in it. To avoid it will be
taken out of our office, is it possible to make it not-readable after
a certain period?
then every let say seven days, I needs to "extend the license", so it
will last another week.

It consists of queries, forms, and tables, format Access 2003.

Bart

推荐答案

AA Arens写道：

AA Arens wrote:

我有一个包含客户信息的数据库。为了避免它将从我们的办公室取出

，是否有可能在

a某段时间后使其不可读？

然后每一个比方说七天，我需要延长许可证，所以它将会再持续一周。


它由查询，表格和表格，格式Access 2003.


Bart

I do have a database with customer info in it. To avoid it will be
taken out of our office, is it possible to make it not-readable after
a certain period?
then every let say seven days, I needs to "extend the license", so it
will last another week.

It consists of queries, forms, and tables, format Access 2003.

Bart

制作什么不可读的？数据表？

如果某人打开了数据库，他们可以将您的表格导出到
Excel或文本文件或其他任何内容。 />

另一种选择是，在业务结束时，将其压缩并加密mdb的
。那样整个数据库;表和所有，都加密和

密码保护。解密数据库的第一个人。但

问题是有人在正常营业时间内使用数据库时需要数据库。


摘要，我不知道不这么认为。

Make what unreadable? The data tables?

If someone has the database opened, they could export your table(s) to
Excel or a text file or whatever.

An alternative is that at the close of business, zip it up and encrypt
the mdb. That way the entire database; tables and all, are encryped and
password protected. The first person in decrypts the database. But the
problem is someone taking the database while working with it during
regular business hours.

Summary, I don''t think so.

你可以在它上面放一个许可证，允许它打开一个有限的数量

的时间，但如果数据库没有加密，然后有人可以通过后门获取数据并将其导出到新数据库

，然后到期。


2月27日上午5:01，AA Arens < bartvandon ... @ gmail.comwrote：

You can put a license on it to allow it to open for a limited amount
of time, but if the database isn''t encrypted then someone can just go
through the back door to your data and export it to a fresh database
before that time expires.

On Feb 27, 5:01 am, "AA Arens" <[e-mail]:

我有一个包含客户信息的数据库。为了避免它将从我们的办公室取出

，是否有可能在

a某段时间后使其不可读？

然后每一个比方说七天，我需要延长许可证，所以它将会再持续一周。


它由查询，表格和表格，格式Access 2003.


Bart

I do have a database with customer info in it. To avoid it will be
taken out of our office, is it possible to make it not-readable after
a certain period?
then every let say seven days, I needs to "extend the license", so it
will last another week.

It consists of queries, forms, and tables, format Access 2003.

Bart

嗨Bart，


处理这类问题时，您可能会发现编码所需的复杂程度不值得付出。有代码的加密数据的方式是b / b
，这样只有经过授权的人才能看到/使用它。与此相关的警告是它实施起来真的很痛苦，并且需要很多试验才能避免不幸。

。

可能适用于您的模型是使用两层方法来加密
。例如，当用户登录应用程序时，可以为他们分配一个用户编号。如果需要

，使用DAO可以向表，列或整个数据库添加额外的属性。对于每个用户，在适合您的目的的粒度级别

，您将为用户添加一个属性

ID。然后您分配此属性的值将起作用

如下：


1 /用户有密码（例如），此密码是

哈希或加密并存储为代码中的变量。

2 /加密或哈希密码然后用作

的密码通过对称加密（例如/ AES）加密表/列/数据库的实际加密

密钥。

3 /此加密数据库/表/列密钥然后存储在该用户的

userID属性中。


通过这种方式，每个用户都可以访问他们需要的数据。如果

他们尝试在没有正确密钥的情况下读取表中的数据，或者根本没有

密钥，那么他们所看到的只是乱码。


这种方法还需要一个恢复的方法。密钥或主密钥，存储

只是针对管理员的每个Database / table /
列的另一个userID属性。用户获得访问数据库中特定组件的方式是通过管理员

解密数据库/表/列密钥（用
加密的密钥）
例如/ AES并存储在userID属性中），然后用用户哈希密码重新加密

密钥并将其存储在用户userID中

属性。由于

方法的性质，这变得相当棘手。实际上，用户必须为您提供密码

（散列与否）（或者您为其分配一个）。


数据库可以然后重新安全如果您愿意，可以每周更改数据库/表/列密钥（AES加密密钥）。在

转弯中需要为

流程重新加密整个数据库，并且可能需要很长时间，特别是如果你有一个

要处理的大量数据。


毫无疑问，这将是一个非常复杂的设计和管理问题。


我建议解决问题的更好方法是将b / b
迁移到更复杂的数据库

平台，或者反过来将应用程序与数据分开，并且如果你喜欢隐藏，那么将数据mdb存储在一个安全的位置。来自

的用户，只能通过应用程序访问。


为了了解您的环境可能有什么，我们会

需要了解更多关于它和应用程序。当然要问的另一个问题是：如果复制数据库，可能会发生什么样的威胁和可能造成的损失？b $ b损坏。它真的值得吗？b $ b加密它的努力是多么严重？从数据中简单分离

应用程序是否足够？是否有其他选项

可用于托管已经更安全的数据（例如/ SQL

服务器）？


我假设你必须问问自己这种风险是否合理。

这也可能是抽象的时候之一。整个

问题可能是一个很好的解决方案。您可以在此处使用终端服务类型

方法，这样用户实际上根本无法直接访问

数据库，只有窗口数据库。到你的b $ b所拥有的应用程序方面。这可能证明是昂贵的，这取决于你的成本和所需组件的维护费用。

甚至值得为这个应用程序走得那么远吗？如果是，并且你没有b $ b已经可以访问你可以使用的终端服务服务器，

然后我会建议可能将应用程序移动到SQL服务器是一个

更好的选择。但是，您可能需要人们支持。


最后，您必须权衡风险与成本，并确定

适合于什么您。如果这对您的公司来说是一个潜在的危险/昂贵的事情，那么也许找到一个专业的开发人员将应用程序转移到更安全的位置也是个好主意。

环境。


祝你好运，请告诉我们您的决定。


干杯


青蛙

Hi Bart,

When dealing with this type of problem you may find that the level of
complexity required in the coding is not worth the effort. There are
ways of encryting your data, with code, so that only authorised people
can see it / work with it. The warning that goes with this is that it
can be really painful to implement, and will require much trialling so
as to avoid "mishaps".

The model that might work for you is to use a two layered approach to
the encryption. As an example, when a user logs in to the application,
they can be assigned a user number. Using DAO it is possible to add
extra properties to the tables, columns, or the entire database if
necessary. For each user, at the level of granularity that is
appropriate for your purposes, you would add a property for the users
ID. The value that you then assign this property would work as
follows:

1/ the user has a password (for example), and this password is either
hashed or encrypted and stored as a variable in your code.
2/ the encrypted or hashed password is then used as a password for
encrypting via symmetric encryption (eg/ AES) the actual encryption
key for the table / column / database.
3/ this encrypted database / table / column key is then stored in the
userID property for that user.

In this way each user can be given access to the data they need. If
they try and read the data in the table without the correct key, or no
key at all, then all they will see is gibberish.

This method also needs a "recovery" key, or master key, that is stored
simply as another userID property against each Database / table /
column for the "administrator". The way that users are given access to
a particular component in the database is via the administrator
decrypting the Database / table / column key (the one encrypted with
eg/ AES and stored in the userID property), and then re-encrypting the
key with the users hashed password and storing it in the users userID
property. This gets to be rather tricky due to the nature of the
method. Effectively the user would have to supply you a password
(hashed or not) that they work with (or you assign them one).

The database can then be "re-saftey''d" weekly if you wish by changing
the Database / Table / column key (the AES encrypted one). This in
turn requires that the entire database is re-encrypted for the
process, and could take an awful long time, especially if you have a
lot of data to work with.

Make no mistake about it, this is getting to be a pretty complex
design and administrative problem.

I would suggest that a better way to solve the issue would be to
either migrate the application to a more sophisticated database
platform, or in turn to separate the application from the data and
store the data mdb in a secure location, if you like "hidden" from the
users and only accessable through the application.

In order to understand what is possible in your environment we would
need to know a little more about it, and the application. The other
thing to ask of course is: What is the level of threat and possible
damage that may occur if the database is copied. Is it actually worth
the effort of encrypting it severely? Would a simple separation of the
application from the data be sufficient? Are there other options
available for hosting the data that are already more secure (eg / SQL
Server)?

I suppose you have to ask yourself if the risk justifies the effort.
This is also one of the times when perhaps "abstracting" the whole
problem may be a good solution. You may use a Terminal Services type
approach here so that users have actually go no direct access to the
database at all, only a "window" to the application side of what you
have. That can prove expensive though, and it depends if your up for
the costs and the maintenance of the components needed for it. Is it
even worth going that far for this application? If it is, and you dont
have access already to a Terminal services server you could work with,
then I would suggest that maybe moving the app to SQL server is a
better option. Again though, you may require people to support that.

In the end, you have to weigh up the risk vs cost and determine what
is right for you. If this is a potentially dangerous / costly thing to
your company, then perhaps it is also a good idea to locate a
professional developer to shift the application to a more secure
environment.

Good luck, and please keep us posted with what you decide.

Cheers

The Frog

这篇关于是否有可能在一段时间后使MDB不可读？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！