安全 - 比我想象的更复杂 [英] Security - more complex than I thought
问题描述
再次大脑罢工！
我为什么这样做？当我遇到客户并且在某些时候，他们含糊地问他们是否最终有可能让一些人能够读取数据，而有些人却无法读取数据。但是现在它并不重要。
我说，''当然，我们以后可以这样做'。
所以现在我'我开发了一款不考虑安全性的应用程序，我正在尝试
之后应用它。哇！嗯！和三倍doh！
我最近用NT权限进行了很多实验。并且以为我有它
所有人都怀疑。我认为我几乎有，NT明智，除非我实际上想要（基本上）2个NT组，readonly和readwrite，我现在发现那里
是吨甚至在readonly组中的东西，他们仍然需要
后端的写权限。错误日志表是一个（因此'$
必须转到单独的文件）。更新在Open或
Current表格事件上运行的查询。等等。添加打开完全空白的新表单
（因为用户没有权限追加？）所以隐藏了我的任何
导航按钮。等等。
快速而肮脏的方法...
我虽然设置了用户和组，但是主要是给我点东西给b $ b抓住了。然后在大多数表格的OnOpen中检查用户是哪个组是
成员并使表单允许为假等等。这种方法实际上会给我一个更精细的粒度级别，因为我还可以禁用
表格/交换机上的某些控件等等。所有这些都可以替代
使用所有用户/组权限。
其他人使用什么方法？
除了计划安全性之外开始，当然是正确的。
TIA，Mike MacSween（感觉就像一个笨蛋）
S**t for brains strikes again!
Why did I do that? When I met the clients and at some point they vaguely
asked whether eventually would it be possible to have some people who could
read the data and some who couldn''t but that it wasn''t important right now.
And I said, ''sure, we can do that later''.
So now I''ve developed an app without any thought to security and am trying
to apply it afterwards. Doh!, doh! and triple doh!
I''ve experimented a lot recently with NT permissions. And thought I had it
all sussed. Which I think I almost have, NT wise, except that if I actually
want (basically) 2 NT groups, readonly and readwrite, I find now that there
are tons of stuff in even the readonly group where they will still need
write permissions on the back end. The error log table being one (so that''ll
have to go out to a separate file). Update queries that run on the Open or
Current event of forms. And so on. Add new forms which open completely blank
(because the user hasn''t got permission to append?) so hiding any of my
navigation buttons. etc. etc.
As a quick and dirty approach...
I though I''d set up users and groups, but mainly to give me something to
grab hold of. Then in the OnOpen of most forms check which group the user is
a member and make the form allowedits false and so on. That approach would
actually give me a finer level of granularity, as I could also disable
certain controls on the forms/switchboard etc. All this as an alternative to
using all the user/group permissions.
What approaches does anybody else use?
Apart from planning security from the beginning, properly, of course.
TIA, Mike MacSween (feeling like a chump)
推荐答案
你不幸地做出了一个你无法有效保证的承诺 -
AT ALL。您可以做的最好的事情是指出行业已知的限制
的Jet / Access（许多大型组织，如HIPPA，
银行业和其他公司承认）并指责他们因为这不会是b $ b工作。
-
MichKa [MS]
NLS整理/区域设置/键盘开发
全球化基础设施和字体技术
此帖子按原样提供。
无保证，并且不授予任何权利。
Mike MacSween < MI ****************** @ btinternet.com>在消息中写道
news：3f *********************** @ news.aaisp.net.uk ..。
You have unforturnately made a promise that you cannot effectively keep --
AT ALL. The best thing you can do is point to the industry-known limitations
of Jet/Access (acknowledged by many large organizations like HIPPA, the
banking industry, and others) and blame them for the fact that this will not
work.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
This posting is provided "AS IS" with
no warranties, and confers no rights.
"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. .
S ** t再次大脑罢工！
为什么我这样做？当我遇到客户的时候，他们甚至模糊地询问是否最终有可能让一些b $ b的人能够读取数据，而另一些人则不可能，但这并不重要现在是
。我说，''当然，我们可以在以后做到这一点'。
所以现在我开发了一款不考虑安全性的应用程序，我正在尝试之后应用它。哇！嗯！和三重doh！
我最近用NT权限进行了很多实验。并且以为我拥有它
所有的怀疑。我认为我几乎有，NT明智，除非我想b $ b实际上想要（基本上）2个NT组，readonly和readwrite，我现在发现
甚至在readonly组中还有很多东西他们仍然需要在后端写入权限。错误日志表是一个（所以
'必须出去一个单独的文件）。更新在Open或
Current表单事件上运行的查询。等等。添加完全打开
空白的新表单（因为用户没有权限追加？）所以隐藏了我的任何导航按钮。
作为一种快速而肮脏的方法...
我虽然设置了用户和群组，但主要是为了给我一些东西。抓住了。然后在大多数表单的OnOpen中检查用户
是哪个组成员，并使表单允许为false等等。这种方法实际上会给我一个更精细的粒度级别，因为我还可以禁用窗体/交换机等上的某些控件。所有这些都是使用所有用户/组的替代
权限。
其他人使用什么方法？
除了从一开始就正确地规划安全性，当然还有。
TIA，Mike MacSween （感觉就像一个笨蛋）
S**t for brains strikes again!
Why did I do that? When I met the clients and at some point they vaguely
asked whether eventually would it be possible to have some people who could read the data and some who couldn''t but that it wasn''t important right now. And I said, ''sure, we can do that later''.
So now I''ve developed an app without any thought to security and am trying
to apply it afterwards. Doh!, doh! and triple doh!
I''ve experimented a lot recently with NT permissions. And thought I had it
all sussed. Which I think I almost have, NT wise, except that if I actually want (basically) 2 NT groups, readonly and readwrite, I find now that there are tons of stuff in even the readonly group where they will still need
write permissions on the back end. The error log table being one (so that''ll have to go out to a separate file). Update queries that run on the Open or
Current event of forms. And so on. Add new forms which open completely blank (because the user hasn''t got permission to append?) so hiding any of my
navigation buttons. etc. etc.
As a quick and dirty approach...
I though I''d set up users and groups, but mainly to give me something to
grab hold of. Then in the OnOpen of most forms check which group the user is a member and make the form allowedits false and so on. That approach would
actually give me a finer level of granularity, as I could also disable
certain controls on the forms/switchboard etc. All this as an alternative to using all the user/group permissions.
What approaches does anybody else use?
Apart from planning security from the beginning, properly, of course.
TIA, Mike MacSween (feeling like a chump)
如果是真实的安全性不是问题（我的意思是一些真正的破解者可能会想要破坏你的BE数据库），而你只想为普通用户提供一些安全性
，您可以尝试以下方法：
1.让您受密码保护
2.将其链接到前端应用
3.在前端应用程序中，您可以摆脱Access内置安全性和
实现您自己的安全模型：组，用户和限制
4.制作您的应用程序MDE并设置适当的属性以跳过
启动时转移。
这将阻止普通用户侵入您的数据。
但是，正如我所说，这不适合那些真正的人。想要进入你的
数据。
我没有找，但我听说互联网上有工具可以破解
访问数据库密码，以及MDE的反编译器，所以...
用户所属团体
限制可以通过以下方式定义：
限制名称（例如禁用客户视图表单或禁用
$ b $ b打印X报告，或隐藏Z信息或其他内容）
对于每个限制，您可以创建一些逻辑（它应该是数据驱动的，以
可以通过添加新限制轻松扩展，因为它们是必需的）
将禁用/隐藏所需的控件/表单/菜单条目/报告/
whatsever。
然后，在每个for和report的OpenEvent中，你应该调用一个函数，
将检查已登录用户的相应权限，并充当app ropriate
（要么阻止加载或隐藏/禁用控件的形式）。
例如，假设您有一个名为Employees的表单，其中包含标签控制
有两页（一个用于个人数据，一个用于就业数据），如果你想要一个小组无法查看个人数据标签页面
我已经开发了一次这样的模块，所以如果你对此感兴趣，请
联系我。
问候，
Bogdan
-----原始消息-----
来自：&＃; Mike MacSween" < mi ****************** @ btinternet.com>
新闻组：comp.databases.ms-access
发送时间：2003年11月10日星期一上午10:16
主题：安全 - 比我想象的更复杂
Hi,
If the "real" security isn''t a concern (I mean some real crackers who might
want to break your BE database), and you just want to provide some security
for regular users, you can try the following:
1. Make you BE password-protected
2. Link it to front-end app
3. In front-end app, you can get rid of Access build-in security and
implement your own security model : groups, users and restrictions
4. Make your application MDE and also set appropriatre properties to skip
Shift at startup.
This will prevent regular users to break into your data.
But, as I told, this is not for guys who "really" want to get into your
data.
I didn''t looked for, but I heard there are tools on internet who can break
Access database password, and also decompilers for MDE, so...
Few thoughts about implementation:
Users belongs to groups
Restrictions can be defined by this:
Restriction name (like "Disable view of Customerts form", or "Disable
Printing of X report", or "Hiding Z information" or whatsever)
For each restricton you can create some logic (it should be data-driven, to
be easily extended by adding new restrictions, as they are required) which
will disable / hide the required controls / forms / menu entries / reports /
whatsever.
Then, in OpenEvent of every for and report, you should call a function which
will check appropriate permissions for logged user, and act as appropriate
(either prevent form for loading or hiding / disabling controls on it).
As an example, suppose you have a form called Employees, with a tab control
with two pages (one for personal data and one for employment data), anf you
want a group to not be able to view PersonalData tab
I have developed such module once, so if you are interested in this, please
contact me.
Regards,
Bogdan
----- Original Message -----
From: "Mike MacSween" <mi******************@btinternet.com>
Newsgroups: comp.databases.ms-access
Sent: Monday, November 10, 2003 10:16 AM
Subject: Security - more complex than I thought
S ** t因为大脑再次罢工！
为什么我这样做？当我遇到客户的时候，他们甚至模糊地询问是否最终有可能让一些b $ b的人能够读取数据，而另一些人则不可能，但这并不重要现在是
。我说，''当然，我们可以在以后做到这一点'。
所以现在我开发了一款不考虑安全性的应用程序，我正在尝试之后应用它。哇！嗯！和三重doh！
我最近用NT权限进行了很多实验。并且以为我拥有它
所有的怀疑。我认为我几乎有，NT明智，除非我想b $ b实际上想要（基本上）2个NT组，readonly和readwrite，我现在发现
甚至在readonly组中还有很多东西他们仍然需要在后端写入权限。错误日志表是一个（所以
'必须出去一个单独的文件）。更新在Open或
Current表单事件上运行的查询。等等。添加完全打开
空白的新表单（因为用户没有权限追加？）所以隐藏了我的任何导航按钮。
作为一种快速而肮脏的方法...
我虽然设置了用户和群组，但主要是为了给我一些东西。抓住了。然后在大多数表单的OnOpen中检查用户
是哪个组成员，并使表单允许为false等等。这种方法实际上会给我一个更精细的粒度级别，因为我还可以禁用窗体/交换机等上的某些控件。所有这些都是使用所有用户/组的替代
权限。
其他人使用什么方法？
除了从一开始就正确地规划安全性，当然还有。
TIA，Mike MacSween （感觉就像一个笨蛋）
" Mike MacSween" < MI ****************** @ btinternet.com>在留言中写道
新闻：3f *********************** @ news.aaisp.net.uk ..大脑再次罢工！
为什么我这样做？当我遇到客户的时候，他们甚至模糊地询问是否最终有可能让一些b $ b的人能够读取数据，而另一些人则不可能，但这并不重要现在是
。我说，''当然，我们可以在以后做到这一点'。
所以现在我开发了一款不考虑安全性的应用程序，我正在尝试之后应用它。哇！嗯！和三重doh！
我最近用NT权限进行了很多实验。并且以为我拥有它
所有的怀疑。我认为我几乎有，NT明智，除非我想b $ b实际上想要（基本上）2个NT组，readonly和readwrite，我现在发现
甚至在readonly组中还有很多东西他们仍然需要在后端写入权限。错误日志表是一个（所以
'必须出去一个单独的文件）。更新在Open或
Current表单事件上运行的查询。等等。添加完全打开
空白的新表单（因为用户没有权限追加？）所以隐藏了我的任何导航按钮。
作为一种快速而肮脏的方法...
我虽然设置了用户和群组，但主要是为了给我一些东西。抓住了。然后在大多数表单的OnOpen中检查用户
是哪个组成员，并使表单允许为false等等。这种方法实际上会给我一个更精细的粒度级别，因为我还可以禁用窗体/交换机等上的某些控件。所有这些都是使用所有用户/组的替代
权限。
其他人使用什么方法？
除了从一开始就正确地规划安全性，当然还有。
TIA，Mike MacSween （感觉就像一个笨蛋）
S**t for brains strikes again!
Why did I do that? When I met the clients and at some point they vaguely
asked whether eventually would it be possible to have some people who could read the data and some who couldn''t but that it wasn''t important right now. And I said, ''sure, we can do that later''.
So now I''ve developed an app without any thought to security and am trying
to apply it afterwards. Doh!, doh! and triple doh!
I''ve experimented a lot recently with NT permissions. And thought I had it
all sussed. Which I think I almost have, NT wise, except that if I actually want (basically) 2 NT groups, readonly and readwrite, I find now that there are tons of stuff in even the readonly group where they will still need
write permissions on the back end. The error log table being one (so that''ll have to go out to a separate file). Update queries that run on the Open or
Current event of forms. And so on. Add new forms which open completely blank (because the user hasn''t got permission to append?) so hiding any of my
navigation buttons. etc. etc.
As a quick and dirty approach...
I though I''d set up users and groups, but mainly to give me something to
grab hold of. Then in the OnOpen of most forms check which group the user is a member and make the form allowedits false and so on. That approach would
actually give me a finer level of granularity, as I could also disable
certain controls on the forms/switchboard etc. All this as an alternative to using all the user/group permissions.
What approaches does anybody else use?
Apart from planning security from the beginning, properly, of course.
TIA, Mike MacSween (feeling like a chump)
"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. . S**t for brains strikes again!
Why did I do that? When I met the clients and at some point they vaguely
asked whether eventually would it be possible to have some people who could read the data and some who couldn''t but that it wasn''t important right now. And I said, ''sure, we can do that later''.
So now I''ve developed an app without any thought to security and am trying
to apply it afterwards. Doh!, doh! and triple doh!
I''ve experimented a lot recently with NT permissions. And thought I had it
all sussed. Which I think I almost have, NT wise, except that if I actually want (basically) 2 NT groups, readonly and readwrite, I find now that there are tons of stuff in even the readonly group where they will still need
write permissions on the back end. The error log table being one (so that''ll have to go out to a separate file). Update queries that run on the Open or
Current event of forms. And so on. Add new forms which open completely blank (because the user hasn''t got permission to append?) so hiding any of my
navigation buttons. etc. etc.
As a quick and dirty approach...
I though I''d set up users and groups, but mainly to give me something to
grab hold of. Then in the OnOpen of most forms check which group the user is a member and make the form allowedits false and so on. That approach would
actually give me a finer level of granularity, as I could also disable
certain controls on the forms/switchboard etc. All this as an alternative to using all the user/group permissions.
What approaches does anybody else use?
Apart from planning security from the beginning, properly, of course.
TIA, Mike MacSween (feeling like a chump)
" Michael（michka）Kaplan [MS]" < MI ***** @ online.microsoft.com>写在
消息新闻：3f ******** @ news.microsoft.com ...
"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com...
你有一个不可靠的承诺，你不能有效地保持 -
AT ALL。您可以做的最好的事情是指出Jet / Access行业所知的
限制（许多大型组织，如HIPPA，
银行业和其他组织都承认），并责怪他们这一事实将
无效。
You have unforturnately made a promise that you cannot effectively keep --
AT ALL. The best thing you can do is point to the industry-known limitations of Jet/Access (acknowledged by many large organizations like HIPPA, the
banking industry, and others) and blame them for the fact that this will not work.
当然，访问并非100％安全。那我不担心。我从哪里开始就没有计划安全性。我认为访问安全性可能会比人们想象的要困难得多。因为我已经发布了几个
次，但只有一个人回复了。将它与NT
权限相结合。
您使用什么方法来访问安全性？内置型号或者你好吗？b $ b''滚动你自己''
干杯，迈克MacSween
Sure, Access isn''t 100% secure. That doesn''t worry me. Where I f****d up was
not planning security from the start. I think that Access security can
probably be made a lot harder than people imagine. As I''ve posted a couple
of times but only one person has responded. By combining it with NT
permissions.
What approach do you use to Access security? The built in model or do you
''roll your own''
Cheers, Mike MacSween
这篇关于安全 - 比我想象的更复杂的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
