jwcolby
jwcolby at colbyconsulting.com
Tue Jul 24 09:26:23 CDT 2012
I think that again we are talking apples and oranges. The conversation continues to veer off to "look at amazon" when in fact this list is about Access FEs talking to (in this case) SQL Server. How I would handle security for an Amazon or an Ebay is just not the same as how I would handle working with Access. I actually do have several databases, different (small) companies coming into SQL Server over the internet. Each one has it's own database and each one can only see it's own db. This is not a theoretical, this is actual practice. I have another database that isn't a "company" at all, just a bunch of users of the database, volunteers who need to get at a database for their use. We all know that Access is not very secure and the best you can do is the best you can do. If we are going to discuss Access FEs then it is helpful to be realistic. "Insertion attacks" are not generated by hackers stealing a laptop, discovering that there is an access database on it, learning enough about Access to figure out how to go attack it and then hacking into that database. If you suspect that the database in question is valuable or high profile enough that someone is going to do that then you have no business even discussing an Access FE. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 7/24/2012 9:53 AM, Charlotte Foust wrote: > Maybe I'm missing something, but it doesn't seem like the two concepts are > mutually exclusive. Roles are created on the database side and users log > into those roles through the FE login. Or is the assumption that the > database roles will be individually assigned based on network login? > > Charlotte > > On Tue, Jul 24, 2012 at 5:45 AM, Arthur Fuller <fuller.artful at gmail.com>wrote: > >> I think that I disagree on that point, JC. I much prefer to assign users to >> Roles on the database level. I have even found that Roles are additive, or >> perhaps cumulative is a better word. For example, within a given database, >> you could create a Role called Sales, with just enough rights to create new >> sales orders and look up existing sales. Above that, you could have another >> Role called SalesManager, with all the Sales rights and some additional >> ones such as the ability to view the performance reports on all Sales >> people. And above that, a SeniorManagement Role that can do everything >> Sales and SalesManager can do, plus some additional stuff. >> >> The main reason I like to do it this way is >> >> In a multi-company scenario, Company A's Roles could be restricted >> completely to that company's database, and similarly for Companies B and C. >> >> And meanwhile, godlike being that you are, you can do Anything. >> >> A. >> >> On Mon, Jul 23, 2012 at 9:07 PM, jwcolby <jwcolby at colbyconsulting.com >>> wrote: >> >>> Not so fun however when you are giving unknown / barely known users / >>> machines access to your business server. Better to have an Access Fe >>> installed on the user's machine coming in under a single SQL Server user >> / >>> group which is precisely controlled what it is allowed to do. >>> >>> >>> >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> >> >> Website: http://www.databaseadvisors.com >> >> >>