RWOP查询后端secuirty：easy / hard？慢快？ [英] RWOP queries for back-end secuirty: easy/hard? slow/fast?

问题描述

我正在创建一个在我们公司内部使用的新数据库，我希望

能够合理安全（缺少真正的基于服务器的解决方案）。由于易于打开，链接和/或导入，因此基于非服务器的数据库的后端似乎是最大的b $ b b安全漏洞。 />
直接来自后端数据库的原始数据。我已经阅读了信息

表示将后端表锁定给所有者，然后使用前端的RWOP查询

有助于关闭此漏洞有点，

但是从代码创建SQL语句时可能会有问题，并且

除了简单的Access查询之外的其他查询数据的方法。

I我们还看到了基本上为

后端中的每个表格在前端创建一个简单的select *>
查询和RWOP查询的建议，然后使用这些查询作为前端其他

查询的记录源代替表本身。我的问题

是双重的：这个策略是否完全消除了

RWOP查询的问题？然后我可以继续在代码中创建SQL语句，

指向RWOP查询，而后者又指向

后端的表格？那么一切都工作就好像我直接指向后端表吗？
？在我的真实（有条件）

查询和表格之间是否存在任何性能损失或额外的查询层缺陷？这种方法是否提供了真正的安全性？b $ b是否真正阻止链接或导入原始数据，或者至少为普通用户提供合理的障碍在

这样做？


谢谢！

I am creating a new database for use within our company, that I''d like
to make reasonably secure (short of a true server based solution). The
back-end of a non-server based database seems to be the biggest
security hole, due to the ease of opening, linking, and/or importing
raw data directly from the back-end database. I''ve read information
that indicates that locking down the back-end tables to the owner, then
using RWOP queries in the front end, helps to close this hole somewhat,
but can be problematic when creating SQL statements from code, and
other methods of querying data beyond a straightforward Access query.
I''ve also seen suggestions to basically create a simple "select *"
query with RWOP in the front end for each and every table in the
back-end, and then use those queries as the record source for other
queries in the front end in lieu of the tables themselves. My question
is two-fold: does this tactic completely wipe out the problems with
RWOP queries? Can I then continue to create SQL statements in code,
pointing to the RWOP queries, which in turn point to the tables in the
back-end? Does everything then work just as if I was pointing directly
to the back-end tables? Are there any performance penalties or other
drawbacks of an extra layer of query between my real (conditional)
queries and the tables? Does this method provide a real security
benefit... i.e. does it truly prevent linking or importing the raw
data, or at least provide a reasonable hindrance to the average user in
doing so?

Thanks!

推荐答案

在线评论

go****@darincline.com 写道：

我正在创建一个在我们公司内部使用的新数据库，我希望
能够合理安全（缺少真正的基于服务器的解决方案）。基于非服务器的数据库的后端似乎是最大的安全漏洞，因为它可以直接从后面打开，链接和/或导入原始数据 - 数据库。我已阅读信息
表示将后端表锁定到所有者，然后使用前端的RWOP查询，有助于稍微关闭此漏洞，
但是可以从代码创建SQL语句时有问题，以及在简单的Access查询之外查询数据的其他方法。
我也看到了基本上创建一个简单的select *的建议。 >在前端使用RWOP查询
后端中的每个表，然后使用这些查询作为前端其他查询的记录源代替表本身。我的问题是双重的：这个策略是否完全消除了RWOP查询的问题？


是的，RWOP查询可以在其他查​​询中使用，就像你使用表格一样使用
。


我还为某些字段或

某些用户组限制某些记录的情况创建了RWOP查询。


字段限制示例;如果只允许经理看到员工

支付金额，但每个人都需要知道员工PayGroup是什么
in。创建两个RWOP查询：


rwopPayManager：SELECT EmpID，FromDate，ToDate，PayGroup，BasePay

FROM Pay

rwopPayEmployee：SELECT EmpID，FromDate，ToDate，PayGroup

来自支付


然后你可以给经理组授予rwopPayManager的权限和

每个人对rwopPayEmployee的许可。然后，报告或表单（在Open

事件中）需要检查当前用户是否在

Manager组中，然后选择一个查询或另一个查询作为RecordSource。


记录限制示例;如果用户在主管组中，那么他们需要只看到他们监督的员工：


rwopEmployeeSupervisor：SELECT * FROM Employee

WHERE SupervisorID = CurrentUser（）

然后我可以继续在代码中创建SQL语句，
指向RWOP查询，而RWOP查询又指向

是

那么一切都工作就好像我直接指向后端表吗？


是

在我的真实（有条件的）查询之间是否存在性能损失或额外查询层的其他缺点和表？


不是我曾经注意到的。在链接

ODBC表的情况下，额外的层可能是导致

访问的最后一根稻草，以确定查询过于复杂而无法发送到服务器

等因此决定提取所有数据以在本地运行查询。你会

必须测试每个查询才能看到。当这个

发生时，通常非常明显。查询将花费一个数量级（或两个！）来运行

比它应该更长。

这种方法是否提供真正的安全性好处..即是否真的阻止链接或导入原始数据，或者至少为普通用户提供合理的障碍？

I am creating a new database for use within our company, that I''d like
to make reasonably secure (short of a true server based solution). The
back-end of a non-server based database seems to be the biggest
security hole, due to the ease of opening, linking, and/or importing
raw data directly from the back-end database. I''ve read information
that indicates that locking down the back-end tables to the owner, then
using RWOP queries in the front end, helps to close this hole somewhat,
but can be problematic when creating SQL statements from code, and
other methods of querying data beyond a straightforward Access query.
I''ve also seen suggestions to basically create a simple "select *"
query with RWOP in the front end for each and every table in the
back-end, and then use those queries as the record source for other
queries in the front end in lieu of the tables themselves. My question
is two-fold: does this tactic completely wipe out the problems with
RWOP queries?
Yes, the RWOP query can be used in other queries the same way that you
would use a table.

I also create RWOP queries for situations where either some fields or
some records are restricted for certain user groups.

Field restriction example; if only Managers are allowed to see Employee
Pay amounts, but everyone needs to know what PayGroup the Employee is
in. Create two RWOP queries:

rwopPayManager: SELECT EmpID, FromDate, ToDate, PayGroup, BasePay
FROM Pay
rwopPayEmployee: SELECT EmpID, FromDate, ToDate, PayGroup
FROM Pay

Then you can give the Manager group permissions to rwopPayManager and
everyone permission to rwopPayEmployee. The Report or Form (in Open
Event) then needs to check the currentuser to see if they are in the
Manager group and then pick one query or the other as the RecordSource.

Record restriction example; If a user is in the Supervisor Group then
they need to see only the Employees that they supervise:

rwopEmployeeSupervisor: SELECT * FROM Employee
WHERE SupervisorID=CurrentUser()
Can I then continue to create SQL statements in code,
pointing to the RWOP queries, which in turn point to the tables in the
back-end?
Yes
Does everything then work just as if I was pointing directly
to the back-end tables?
Yes
Are there any performance penalties or other
drawbacks of an extra layer of query between my real (conditional)
queries and the tables?
Not that I''ve ever noticed. It might be possible in the case of linked
ODBC tables that the extra layer could be the last straw that causes
Access to decide that the query is too complicated to send to the server
and so decides to pull all the data to run the query locally. You would
have to test each query to see. It is usually VERY obvious when this
happens. A query will take an order of magnitude (or two!) longer to run
than it should.
Does this method provide a real security
benefit... i.e. does it truly prevent linking or importing the raw
data, or at least provide a reasonable hindrance to the average user in
doing so?

如果有人链接到你应用程序之外的后端表，他们将会对表没有权限。
没有权限。如果没有破解工作组

的安全性，就应该没有办法（假设所有正确的

步骤来保护它已经完成）。


所有这一切，我从来没有做过一个应用程序，我用每个表格

。我在需要特定安全性的所有表格上执行此操作

无法通过标准用户/组权限处理。请记住

将权限应用于BE MDB以及

FE中的链接。仅在链接上设置权限不会保证BE不会被打开或链接，而必须单独完成。


-

Bri

If someone links to the backend tables outside of your app, they will
not have permissions to the tables. Without cracking the Workgroup
security, there should be no way in (assuming that all of the proper
steps to secure it have been done).

All this being said, I have never done an app where I did this with
every table. I do it on all of the tables that require specific security
that can''t be handled by the standard User/Group permissions. Remember
to apply the permissions to the BE MDB as well as to the Links in the
FE. Putting permissions only on the links will not secure the BE from
being opened or linked, that must be done separately.

--
Bri

非常感谢您的回复！这听起来像RWOP查询（当然，与
结合，具有适当的用户级安全性）是合理保护后端的良好方式。考虑到我做的事情

偶尔有一些非常毛茸茸的查询，有时通过

代码查询数据，我想确保实现不会破坏

在走这条路之前的任何事情。听起来我可以简单地将
重新命名为FE中的所有表链接别名，然后基于那些与表链接同名的表创建RWOP查询

用于

，并且所有代码/查询/记录集应该像以前一样运行？


显然，任何时候有更简单的方法，总是得到

点头。考虑到这一点，在新闻组中做了一些研究，由Joan Wild发表了一篇感兴趣的帖子。线程/帖子太旧

直接回复，但可以通过以下搜索找到：

http://groups.google.com/group/micro...3b208744c74661


在该帖子中，她建议使用与
相关联的工作组文件删除用户创建

新数据库的能力。
数据库我正在努力保护。如果我阻止用户直接打开后端数据库（通过自动执行代码并禁用转换旁路的
），并禁止用户创建新的

数据库基于相同的工作组文件（因此无法创建一个可以访问后端数据的
），那么它就是

对我来说这也是相对安全的，而且比在前端创建和使用所有RWOP查询更简单。

但是，我不明白如何做到这一点。我已经查看了MS安全常见问题解答中的

相关信息，但这似乎是在讨论

限制用户在数据库中创建新对象/>
将代码插入。但是什么阻止用户只需加入

共享工作组文件，打开Access，并创建一个新数据库

而无需打开包含该文件的FrontEnd.mde文件代码为

限制创建新对象？

Thank you very much for your reply! It sounds like RWOP queries (in
conjunction with appropriate user level security, of course) are a good
way to reasonably secure a back-end. Considering that I do
occasionally have some very hairy queries, and sometimes query data via
code, I wanted to make sure that implementing that wouldn''t break
anything before going down that road. It sounds like I could simply
re-name all my table link aliases in the FE, then create RWOP queries
based on those tables with the same names as the table links USED to
be, and all the code/queries/recordsets should run as it was before?

Obviously, any time there is a simpler method, that always gets the
nod. With that in mind, doing some research in the newsgroups turned
up a post by Joan Wild that interested me. The thread/post is too old
to reply to directly, but it can be found with the following search:

http://groups.google.com/group/micro...3b208744c74661

In that post, she suggests simply removing a user''s ability to create
new databases using the workgroup file that is associated with the
database I''m trying to secure. If I prevent a user from directly
opening up the back-end database (through autoexec code and disabling
the shift-bypass), and if users are restricted from creating NEW
databases based on the same workgroup file (therefore not being able to
create a database that has access to data within the back-end), then it
SEEMS to me that this would also be relatively secure, while being much
simpler than creating and using all the RWOP queries in the front end.
However, I don''t understand how this can be done. I''ve looked at the
relevant info in the MS Security FAQ, but that seems to talk about
restricting users of creating new ojects in the database that you
insert the code into. But what prevents a user from simply joining the
shared workgroup file, opening up Access, and creating a new database
without ever opening up the FrontEnd.mde file that contains the code to
restrict creating new objects?

2006年2月10日06:11:57 -0800， go **** @ darincline.com 写道：

On 10 Feb 2006 06:11:57 -0800, go****@darincline.com wrote:

我正在创建一个新的数据库供在我们公司，我希望
能够合理安全（缺少真正的基于服务器的解决方案）。基于非服务器的数据库的后端似乎是最大的安全漏洞，因为它可以直接从后面打开，链接和/或导入原始数据 - 数据库。我已阅读信息
表示将后端表锁定到所有者，然后使用前端的RWOP查询，有助于稍微关闭此漏洞，
但是可以从代码创建SQL语句时有问题，以及在简单的Access查询之外查询数据的其他方法。
我也看到了基本上创建一个简单的select *的建议。 >在前端使用RWOP查询
后端中的每个表，然后使用这些查询作为前端其他查询的记录源代替表本身。我的问题是双重的：这个策略是否完全消除了RWOP查询的问题？然后我可以继续在代码中创建SQL语句，
指向RWOP查询，而后者又指向
后端的表格吗？那么一切都工作就好像我直接指向后端表吗？在我的真实（有条件）查询和表格之间是否存在任何性能损失或额外查询层的其他缺点？这种方法是否提供了真正的安全性好处......即它真的可以防止链接或导入原始数据，或者至少为普通用户提供合理的阻碍吗？

谢谢！

I am creating a new database for use within our company, that I''d like
to make reasonably secure (short of a true server based solution). The
back-end of a non-server based database seems to be the biggest
security hole, due to the ease of opening, linking, and/or importing
raw data directly from the back-end database. I''ve read information
that indicates that locking down the back-end tables to the owner, then
using RWOP queries in the front end, helps to close this hole somewhat,
but can be problematic when creating SQL statements from code, and
other methods of querying data beyond a straightforward Access query.
I''ve also seen suggestions to basically create a simple "select *"
query with RWOP in the front end for each and every table in the
back-end, and then use those queries as the record source for other
queries in the front end in lieu of the tables themselves. My question
is two-fold: does this tactic completely wipe out the problems with
RWOP queries? Can I then continue to create SQL statements in code,
pointing to the RWOP queries, which in turn point to the tables in the
back-end? Does everything then work just as if I was pointing directly
to the back-end tables? Are there any performance penalties or other
drawbacks of an extra layer of query between my real (conditional)
queries and the tables? Does this method provide a real security
benefit... i.e. does it truly prevent linking or importing the raw
data, or at least provide a reasonable hindrance to the average user in
doing so?

Thanks!

我几年前编写了这个实用程序，用于转换已完成的应用程序以使用RWOP

查询并设置各种启动选项以锁定数据库。它可能有你可以使用的
。


它在A97中，所以可能需要转换为你的Access版本。


使用你的Fe / Be的COPIES（为安全起见），将实用程序

中的所有对象导入你的FE并运行afrmLockDatabase。

http://www.bestfitsoftware.com.au/ut...tilityRWOP.zip

Wayne Gillespie

Gosford NSW Australia

I wrote this utility several years ago to convert a finished app to use RWOP
queries and set the various startup options to lockup the db. It may have
something you can use.

It is in A97 so may need converting to your version of Access.

Using COPIES (for safety) of your Fe/Be, import all objects from the utility
into your FE and run afrmLockDatabase.

http://www.bestfitsoftware.com.au/ut...tilityRWOP.zip
Wayne Gillespie
Gosford NSW Australia

这篇关于RWOP查询后端secuirty：easy / hard？慢快？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！