[AccessD] Access 2013 -- MDB Back Ends Dead?

Jim Lawrence accessd at shaw.ca
Tue Jul 24 11:55:48 CDT 2012


Talking MS Access; the FE never had security and the MDB BE security was
almost irrelevant. So that makes a real SQL BE to Access the only position
of security. 

Users can not have the ability to administrate their own BE on a server as
they will end up deleting more than they should or just basically screwing
it up. If you are connected to a company like Amazon they couldn't care less
unless you are paying them to do the administration and that same thought
extends to any system. 

Real administration can not be automated and administrator rights can not be
given away as we all know where that ends.

Jim  

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, July 24, 2012 7:26 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Access 2013 -- MDB Back Ends Dead?

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
>>
>>
>>

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list