Security..Is there another way?
- Thread starter marianne
- Start date
the code what I am digging for is not a replacement to ULS but an OPTION ONLY to those who may want to opt to. Hopefully someone may provide it for us novice and other who may need it.
Moreover, the resulting CODE may be posted in our forums CODE REPOSITORY for others as reference.
Moreover, the resulting CODE may be posted in our forums CODE REPOSITORY for others as reference.
Last edited:
- Local time
- Today, 23:12
- Joined
- Sep 12, 2006
- Messages
- 16,006
Not sure if thus is what you mean
ULS is secure as far as other users go
if you (as an Admin) set up users without admin privileges, there is no way they can modify the user rights. Just keep the admin password safe and private. You can mess with user permissions programmatically - i don't though, other than to let users change their own ULS password.
I must say, I don't see the problem with letting users being able to get to tables
among other reasons
a) sometimes its useful for problem solving
b) most commercial apps expose all their data eg via ODBC links - you can see all the fields and interact directly with all the data.
i use all these at startup (in the first form loaded) to prevent users seeing the DBS window (and other things) - while still being able to interact with all the objects normally
change property is a small sub to setproperty for each of these (these settings change depending on who logs in)
ChangeProperty "StartupShowDBWindow", dbBoolean, False 'hide the dbwindow
ChangeProperty "AllowBreakIntoCode", dbBoolean, False 'show code after error
ChangeProperty "AllowSpecialKeys", dbBoolean, False 'special keys
ChangeProperty "AllowBypassKey", dbBoolean, False 'bypass key
ChangeProperty "StartupShowStatusBar", dbBoolean, True
ChangeProperty "AllowFullMenus", dbBoolean, False
ChangeProperty "AllowShortCutMenus", dbBoolean, True
ChangeProperty "AllowBuiltinToolbars", dbBoolean, False
ULS is secure as far as other users go
if you (as an Admin) set up users without admin privileges, there is no way they can modify the user rights. Just keep the admin password safe and private. You can mess with user permissions programmatically - i don't though, other than to let users change their own ULS password.
I must say, I don't see the problem with letting users being able to get to tables
among other reasons
a) sometimes its useful for problem solving
b) most commercial apps expose all their data eg via ODBC links - you can see all the fields and interact directly with all the data.
i use all these at startup (in the first form loaded) to prevent users seeing the DBS window (and other things) - while still being able to interact with all the objects normally
change property is a small sub to setproperty for each of these (these settings change depending on who logs in)
ChangeProperty "StartupShowDBWindow", dbBoolean, False 'hide the dbwindow
ChangeProperty "AllowBreakIntoCode", dbBoolean, False 'show code after error
ChangeProperty "AllowSpecialKeys", dbBoolean, False 'special keys
ChangeProperty "AllowBypassKey", dbBoolean, False 'bypass key
ChangeProperty "StartupShowStatusBar", dbBoolean, True
ChangeProperty "AllowFullMenus", dbBoolean, False
ChangeProperty "AllowShortCutMenus", dbBoolean, True
ChangeProperty "AllowBuiltinToolbars", dbBoolean, False
While I agree that moving the data into a RDBMS with a daemon to manage the file access is a step in right direction, by itself, is not sufficient. After all, you can just open the file then choose to export out the linked table's content.
Simply because users shouldn't be toying with the table directly and bypassing whatever validation we have put in place in the forms. There's no validation mechanisms with the table.
In my case, I need to be the best buddy with the DBA; if he looks upon me favorably, then my job is much easier for it so I make an effort to not piss the DBA off by doing something stupid, including doing unnecessary table scans and allowing users to get to the tables directly. So I do feel I have a obligation to at least not store password in the linked tables definition so it cannot be accessed outside of the application, and when compiled into MDE, it would be very difficult to bypass the validation logic in place. The worst thing they can do is export the table out once they've authenticated and that requires a high level of understanding which is not available to most Joe Sixpack.
You are right, it's not that uncommon that anyone can just go to ODBC Manager and create a new link to their company database, so far it seems to be unrestricted to me and not really a topic of contention. I can only assume because the employees have an incentive to keep the whole system working and play within the bound voluntarily; those who go out of bound are at risk for termination. That goes back to the earlier assertion made by the_Doc_Man that sometime the security problem is not a technical issue but actually personnel issue and needs to be addressed as such.
Well, if I do have spare time, I may make a little prototype but even so, we must be mindful of the fact that ULS is deprecated from the new ACCDB format, and to be frank, I have little incentive in developing with ULS, especially when the password-secured linked tables and MDE in conjunction with hashing already are more than sufficient to protect unwanted access to the data.
Dave thanks for the reply and for the property code you gave me. I want you to know however that I am already using that code as part of my security in my project.
Banana, I know, probably, the you will have nothing or less incentive in developing with ULS. And I know that ULS is deprecated from the new accdb format, BUT what about for us those who still uses mdb format?
Banana, PLEASE KINDLY have a spare time to make the prototype code. This is really IMPORTANT and BADLY NEEDED for me and or for us who may came across this problem. As I have noted we can post this code in the forum code repository for future reference. And also the fact that this is the forum that we seek for solutions for the programming needs in MS Access.
Please Banana, I have googled and searched the web and other forums but still found none. Help me with this one. Kindly.
Banana, I know, probably, the you will have nothing or less incentive in developing with ULS. And I know that ULS is deprecated from the new accdb format, BUT what about for us those who still uses mdb format?
Banana, PLEASE KINDLY have a spare time to make the prototype code. This is really IMPORTANT and BADLY NEEDED for me and or for us who may came across this problem. As I have noted we can post this code in the forum code repository for future reference. And also the fact that this is the forum that we seek for solutions for the programming needs in MS Access.
Please Banana, I have googled and searched the web and other forums but still found none. Help me with this one. Kindly.
NigelShaw
Registered User.
- Local time
- Today, 23:12
- Joined
- Jan 11, 2008
- Messages
- 1,575
Hi,
sorry in the delay.........
i use an encrypted password. very long. my front end has a standard password that goes through an encryption procedure to generate the password and the database on the other end receives it.
nigel
Marianne-
While I really would love to write up a prototype & add to the code repository, I don't have enough free times on hand to dedicate to this, which is why I said earlier when I had the time, I would look into it. Maybe someone else may be willing to take up the challenge, or you can try it out yourself, write out some code and post what you have post and we can pass back suggestions and guidance.
NigelShaw-
Ah, yes. Same thing I described and used in my last project, though I didn't bother with making front-end readonly or use macros. Good to know about a variant, though.
While I really would love to write up a prototype & add to the code repository, I don't have enough free times on hand to dedicate to this, which is why I said earlier when I had the time, I would look into it. Maybe someone else may be willing to take up the challenge, or you can try it out yourself, write out some code and post what you have post and we can pass back suggestions and guidance.
NigelShaw-
Ah, yes. Same thing I described and used in my last project, though I didn't bother with making front-end readonly or use macros. Good to know about a variant, though.
Hi banana,
I have found this article http://support.microsoft.com/support/access/content/secfaq.asp?SD=gn&LN=en-us&gssnb=1#_Toc493299663
it talks about containers and document objects and it provide codes on how to manipulate thru VBA.
can you assist me on this one?
I have found this article http://support.microsoft.com/support/access/content/secfaq.asp?SD=gn&LN=en-us&gssnb=1#_Toc493299663
it talks about containers and document objects and it provide codes on how to manipulate thru VBA.
can you assist me on this one?
- Local time
- Today, 17:12
- Joined
- Feb 28, 2001
- Messages
- 30,231
I think it would be instructive to talk about theory and the issues you describe. Maybe you knew all of this, maybe you didn't. Maybe it will jog you into an understanding you didn't have before, maybe it won't. I'm merely casting my bread on the waters, as the Biblical phrase goes.
First item of theory: The farther away you go from something, the harder it is to protect that something, and the less detailed control you retain.
From inside Access, you can place permissions and such on individual objects. Once you are outside Access (say, the file system of the server), you have only three viable options: The user can do nothing, or the user can read the database, or the user can modify the database. You've just lost all granularity on individual tables and other elements.
From another system, those permissions get even less granular because of the other access rights required to even be able to use Access. The directories cannot be tightly protected and still allow you to open the DB, so if you have access at all, the network will make it wide open to you.
Second item of theory: While you may be clever, the utility itself will always be closer to the problem than you are. (Exception: If you are a licensed developer who has a source kit, but don't hold your breath on that one.)
Using ULS means you are using features built-in and hard-coded into Access that occur even before you get to see or touch the data elements in your code, queries, etc.. Doing your own security cannot take away what Access does. It will only be another layer to something that happens before you can get there. There is nothing wrong with that idea, but added layering quickly builds up costs and responsiveness, not to mention complexity for future maintainers.
Just remember, all of the code you write isn't executed until Access is ready to talk to you - which means all the ULS is done, all the access arbitration is done, all of the permissions are set (or cleared). Once Access says you have no rights, code won't help. So the ONLY approach any extra layers would have would be to make decisions to DENY permissions after Access decided to grant access.
Third, ULS is still somewhat broad-brush in specific ways. You can lock an object, but you lock the whole object. That had better be what you wanted to do. Because a table is the lowest level of object that ULS locks, that had better be what you wanted to lock, because that's all you CAN lock with ULS. Not records in a recordset. ULS won't lock fields. ULS won't lock controls. You have to do that on your own if ULS isn't good enough.
Fourth, the issue of hooks. You can hook into events in things like forms and reports. Your code can be implemented in general or class modules. Macros aren't very secure. Tables and queries are even less secure. Why? Events!
You are perhaps feeling that tables and queries are not very secure. This is because you have no table-level or query-level events in which to place your "hooks" that stop unwanted events from occurring. The solution to this is to find a database package that lets you tie in via Access and ODBC, in which case if that database package supports TRIGGER events, you can add protection inside the back-end. You can implement audit trails more easily in an advanced back-end. This is the source of advice we give security-minded folks when we tell them, "Don't let your users see your tables." No events, no hooks, no protection beyond ULS, which for a given table is no access, read access, or wreak havoc access.
You plead with us to find a better way, but you need to understand the craftsman's rule. If all you've got is a hammer, you had better be working with nails.
Access is what it is. If you are willing to work like heck with VBA and also to work like heck to block direct table and query visibility, you might make some headway. But ULS is too broad brush and too simple-minded. Either "Yes" or "no" to a particular level of accessibility. That's the nature of access arbitration in secure environments.
If you want more than this, either you need another tool besides Access or you need to lower your expectations. One or the other, or both if you can find a level of compromise that makes sense.
First item of theory: The farther away you go from something, the harder it is to protect that something, and the less detailed control you retain.
From inside Access, you can place permissions and such on individual objects. Once you are outside Access (say, the file system of the server), you have only three viable options: The user can do nothing, or the user can read the database, or the user can modify the database. You've just lost all granularity on individual tables and other elements.
From another system, those permissions get even less granular because of the other access rights required to even be able to use Access. The directories cannot be tightly protected and still allow you to open the DB, so if you have access at all, the network will make it wide open to you.
Second item of theory: While you may be clever, the utility itself will always be closer to the problem than you are. (Exception: If you are a licensed developer who has a source kit, but don't hold your breath on that one.)
Using ULS means you are using features built-in and hard-coded into Access that occur even before you get to see or touch the data elements in your code, queries, etc.. Doing your own security cannot take away what Access does. It will only be another layer to something that happens before you can get there. There is nothing wrong with that idea, but added layering quickly builds up costs and responsiveness, not to mention complexity for future maintainers.
Just remember, all of the code you write isn't executed until Access is ready to talk to you - which means all the ULS is done, all the access arbitration is done, all of the permissions are set (or cleared). Once Access says you have no rights, code won't help. So the ONLY approach any extra layers would have would be to make decisions to DENY permissions after Access decided to grant access.
Third, ULS is still somewhat broad-brush in specific ways. You can lock an object, but you lock the whole object. That had better be what you wanted to do. Because a table is the lowest level of object that ULS locks, that had better be what you wanted to lock, because that's all you CAN lock with ULS. Not records in a recordset. ULS won't lock fields. ULS won't lock controls. You have to do that on your own if ULS isn't good enough.
Fourth, the issue of hooks. You can hook into events in things like forms and reports. Your code can be implemented in general or class modules. Macros aren't very secure. Tables and queries are even less secure. Why? Events!
You are perhaps feeling that tables and queries are not very secure. This is because you have no table-level or query-level events in which to place your "hooks" that stop unwanted events from occurring. The solution to this is to find a database package that lets you tie in via Access and ODBC, in which case if that database package supports TRIGGER events, you can add protection inside the back-end. You can implement audit trails more easily in an advanced back-end. This is the source of advice we give security-minded folks when we tell them, "Don't let your users see your tables." No events, no hooks, no protection beyond ULS, which for a given table is no access, read access, or wreak havoc access.
You plead with us to find a better way, but you need to understand the craftsman's rule. If all you've got is a hammer, you had better be working with nails.
Access is what it is. If you are willing to work like heck with VBA and also to work like heck to block direct table and query visibility, you might make some headway. But ULS is too broad brush and too simple-minded. Either "Yes" or "no" to a particular level of accessibility. That's the nature of access arbitration in secure environments.
If you want more than this, either you need another tool besides Access or you need to lower your expectations. One or the other, or both if you can find a level of compromise that makes sense.
