Re: Connecting remotely - multi tier - Mailing list pgsql-interfaces
From | Cedar Cox |
---|---|
Subject | Re: Connecting remotely - multi tier |
Date | |
Msg-id | Pine.LNX.4.21.0011031027420.27193-100000@nanu.visionforisrael.com Whole thread Raw |
In response to | Re: Connecting remotely - multi tier (Bob Kline <bkline@rksystems.com>) |
List | pgsql-interfaces |
This is my point exactly. Our setup is a single Linux server w/ win9x clients. The users, of course, have accounts on the Linux server. Because of our simi-open environment, I treat everything outside the server as the 'world', and also because client machines will eventually be connected through the internet or some other non-secure route. I guess the issue is that the middle tier shouldn't allow anything more (as far as modifying data) then the front end is capable of. The front end would therefore be a fairly small, limited application. The middle tier is (should be) in a controlled environment whereas the front end is not. The front end could be modified (security bypassed, hacked). Middle tier modification would require hacking of the server on which it resides before even getting to it, then again, the same with the backend. Basically, you want to make sure that whatever does security checks is itself secure. Sounds simple, but look at it this way: If your frontend does things such as check the format of new data in a field, for example, the user could hack or bypass the frontend in order to get incorrectly formatted data into a table. (Paranoid? Yes, that's what security is for..) This may not sound like a big risk, but then again, this is not an extremely important check (or is it?). The perhaps proper way would be to put checks like this in the backend or middle tier so that there is no way to bypass it. Again, this would mean that most of your work would go into the backend or middle tier programming, which is perhaps to your advantage if you want to replace/add another frontend, less work to do. Overall, I think the expandability and security benefits are worth putting work into a middle tier or backend programming. I don't claim to be correct as I am speaking with little experience, but these are the security issues I see. Thoughts? (..sorry if I rambled) -Cedar ... Is this thread beginning to discuss a book about database security that should be read? ;) On Thu, 2 Nov 2000, Bob Kline wrote: > On Thu, 2 Nov 2000, Adam Lang wrote: > > > But if you are an inhouse developer and the database is only in huse > > and the client is only in house and the database is not open to the > > public, do you still have to use development time to build that > > "middle tier" just so you can roll out an app that uses the company > > database? > > Uh, weren't you the one who originally wondered out loud about the > danger of your users obtaining direct access to your dbms? Even if you > weren't, it's not a good idea to assume there are no security issues > just because you're working inside an intranet. > > -- > Bob Kline > mailto:bkline@rksystems.com > http://www.rksystems.com > >
pgsql-interfaces by date: