![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 6 of 6 total |
![]() |
Mon, Jun 28 2010 12:57 AM | Permanent Link |
Jeff Dunlop | With regard to an enterprise class application that lives in a hostile environment with customers and vendors with no scruples: Assume a very clever 3rd party vendor with physical access to an elevate server.
What are the steps necessary to prevent write access to local table files? |
Mon, Jun 28 2010 3:41 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Jeff
I know you said without a supersecret password but my initial thoughts would be: 1. add encryption 2. add engine signature 3. remove all administrator users and lock users down to the lowest access level you can at each point eg Database & table (I think that's select) I would then look at altering the server so that it only accepts connections from nominated IP addresses and alter your app so that these are passed through and checked. Finally I'd step outside your app and look at what you can do with Windows security as well. There was a bug in an earlier version of ElevateDB which effectively turned the whole database read only, unfortunately the cure was simple if you had EDBManager; dump the catalog (or it might have been config I can't remember) and recreate. Another thought just occurred. Make it a self healing database. The big problems I can see with that is the amount of processing power needed and storing the original in some way or another to allow the healing. I'll be interested in Tim's advice. Roy Lambert |
Mon, Jun 28 2010 11:25 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Jeff,
<< With regard to an enterprise class application that lives in a hostile environment with customers and vendors with no scruples: Assume a very clever 3rd party vendor with physical access to an elevate server. What are the steps necessary to prevent write access to local table files? >> Well, the problem is that once a person has physical access to the server machine hosting the ElevateDB Server, then all bets are off. Do these persons have administrator access to the Windows Server OS ? -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jun 29 2010 6:19 PM | Permanent Link |
Jeff Dunlop | Yes, physical admin access to the computer. Managing remote connections is easy enough, but how do I prevent using Manager locally? All I really want to prevent is a rogue script being run by anyone but us.
|
Sat, Jul 3 2010 9:57 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Jeff,
<< Yes, physical admin access to the computer. Managing remote connections is easy enough, but how do I prevent using Manager locally? All I really want to prevent is a rogue script being run by anyone but us. >> The easiest way is to use a custom engine signature. That will prevent them from using the EDB Manager with the EDB Server, or locally, if it is running the default engine signature. If you need to do this on an existing installation, let me know and I'll work up a utility for changing the signatures. I need to add such a utility to EDB anyways, so it's not extra work. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Jul 3 2010 11:49 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Jeff
Since Tim is also advocating a supersecret password (ie the engine signature) if you want a nifty way to hide it send me an email. For obvious reasons I'm not posting it in the open. Roy Lambert |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |