X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
   Reply to this topicStart new topic
> Basic Access-SQL Security Question, Access 2010    
post Mar 5 2018, 12:32 PM

Posts: 17
Joined: 1-June 17

Hi all,

I have built and deployed a split access database for my organization. The tables are hosted on a share drive. The problem we experience with this configuration is that some users are having very slow connection times to the share drives, resulting in very slow download speeds for some reports. My understanding from my IT department is that this is due to network infrastructure issues. They also claim that this issue can't be resolved.

So, my solution is to host the tables on SQL server. I've built a prototype SQL backend/access front end system and things seems to work great, even though the server I'm using is located on another continent. The problem is that my IT group is now telling me that there are major security concerns with using an access/SQL database, although they have thus far failed to elaborate on exactly what these issues are.

So, my question is: Are there really security issues with using Access as the front end for a SQL database, or is my IT department just blowing smoke? I should note that for my proposed solution, user access to the SQL server would be tied to each user's network login...so users would have to 1) be logged into their workstation on the company network and 2) have been given read/write access to the server to access the data.


Go to the top of the page
post Mar 5 2018, 12:42 PM

UtterAccess Editor
Posts: 16,271
Joined: 27-June 06
From: England (North East / South Yorks)


I'll not personally sit here and claim that Access is the most secure way in the world to work with server data. (COM offers potential piggy-back opportunities.)
But while the IT department have: "failed to elaborate on exactly what these... " "major security concerns " are, then I don't see what leg they have to stand on.
I'd suspect they don't actually know. They may be basing that opinion on "common knowledge" that Access is weak and insecure (thinking of a file server database such as you're already running).

Your implementation should indeed achieve that only applications on the permitted users' PCs can access the data.
If they can't argue what exactly the problem is, then they're coming across as unknowledgeable.

Edit: Have a read of Ben's contributed article here to better equip yourself against the evil IT naysayers:


Go to the top of the page
post Mar 5 2018, 01:59 PM

Posts: 17
Joined: 1-June 17

Hi LP,

Thanks for your reply. I'm, guessing that there are possibly 2 things at work here (or a combination thereof): 1) as you suggested, IT is basing their assumptions on "common knowledge" of the "shortcomings" of Access, 2) they don't want to have to deal with a system that was developed by an in-house end user (vs. an outside vendor). I should mention that we don't have an in-house application development team.

One of my IT coworkers mentioned that someone could possibly intercept data during client-server communications. I suspect that such a concern is, at best, an overstatement, particularly given our network environment.

I intend to elevate this issue to senior management to see if I can get my project moving. I just want to make sure that I'm not overlooking some compelling argument that IT may throw back at me that I didn't anticipate. I'll also read over that article you cited. Thanks for that!

This post has been edited by Dave2017: Mar 5 2018, 02:11 PM
Go to the top of the page
post Mar 5 2018, 02:16 PM

UtterAccess Editor
Posts: 16,271
Joined: 27-June 06
From: England (North East / South Yorks)


Just on the:
>> "someone could possibly intercept data during client-server communications"
At best, that requires elaboration from them. But it sounds like they're suggesting that it would be like packet interception, not faulty security at either end. I don't see why they think Access would be a particular fault here. If there's a weakness, it's on the client PC and that's under their control surely? Not the interception of data.

I think you're right to bump this upstairs. But with the caveat (pre-warning to the powers that be) that any objections from IT need to be exactly quantified with verified sources. NO hyperbole.
Since they're such data experts, I'm sure they'll be able to point to data leaks once you set up your Access test. (:-p)
But rest assured, you're far from the first to encounter an unjustified bias, a kneejerk reaction based on "common knowledge". When they're unable to justify it, perhaps they'll relax.

Cheers and good luck!

Go to the top of the page
post Mar 5 2018, 03:18 PM

UtterAccess Editor
Posts: 9,911
Joined: 7-December 09
From: Staten Island, NY, USA

As mentioned, there might be the option for some COM piggybacking (Access is an automation object, so theoretically someone can tap into the instance and steal a connection, but they really have to know what they're about to do it).

Aside from that, the only other argument that I can think of is that "modern" application architectures won't tend to connect directly to a database, but rather to an API of some sort which itself is then responsible for communicating with the database. This (allows to) keeps the database completely private on the network and allows for tighter access to the db as the API residing on the same server/network can be configured as the only one able to access it. This is particularly good at securing data at rest (one of many security facets), but really does nothing for data in transit (and has the downside of another application layer that could be insecure in itself).

For data in transit, there's nothing different about Access connecting to a remote BE versus any other client application connecting to a remote BE really.

Go to the top of the page
post Mar 5 2018, 03:19 PM

Posts: 852
Joined: 26-January 14
From: London, UK

I can think of at least three objections commonly made against using an Access application for client-server database access:

1. Not browser-based. If your organization's strategy is for intranet-based applications then Access is the wrong tool. Go for whatever browser-based development platform they prefer.

2. Not N-tier. It's very difficult to connect Access to any service-based/Java/.NET/other data access tier. Access is designed for direct connectivity to databases which means the SQL Server would have to be opened up to desktop access. Some organizations don't allow desktop applications to connect to databases at all - for good reasons of efficiency, security and ease of support. A mitigating option is to grant only execute permissions in the database and use SQL stored procedures to serve all your query and update operations from Access. If your organization's policies allow this then it may be an option worth exploring with the IT department.

3. Access as a development platform lacks many of the security and reliability features taken for granted in more modern platforms. Access almost certainly won't integrate well with your organization's test and build tools, or source control solutions, or dev-ops tools; it probably won't be able to work with existing authentication services and it is more vulnerable to arbitrary code execution and spoofing than other alternative dev tools. If these are concerns and if there are other standard tools and practices in use then it's probably best to look first at the tools the IT team recommend.
This post has been edited by nvogel: Mar 5 2018, 03:36 PM
Go to the top of the page
post Mar 6 2018, 11:23 AM

Posts: 618
Joined: 25-July 07
From: Georgia, USA

Stupid question but if everyone is saying it's slow have you:

Checked to make sure the FE and BE is compacted or at least set to compact?
Are the end users on WIFI? We keep telling people here to get off WIFI because you're trying to pass gobs of data through a connector being shared with a bunch of other people and that doesn't work.

Just asking...

I'm very optimistic about my pessimism.
Go to the top of the page
post Mar 6 2018, 12:09 PM

Posts: 932
Joined: 26-January 06
From: .....the wiregrass (either you know or you don't)

A standard access BE is not particularly secured....but if you put it into SQL SERVER (which I think is what you are talking about), then it can be made much more secure (assuming you set up the encryption and password controls).

Kindest regards, and Cheers!

A picture is worth a thousand words and a zipped DB is worth a thousand pictures.
Oh, and....please don't disappear into the Twilight Zone.... Holler back with your results!
Go to the top of the page
John Vinson
post Mar 15 2018, 05:08 PM

UtterAccess VIP
Posts: 4,233
Joined: 6-January 07
From: Parma, Idaho, US

Just to chime in... a SQL server backend is certainly going to be more secure than an Access .accdb backend; and if you're worried about hackers sniffing international packets, you can install SQL/Server (including the free Express version!) on the local LAN and lock it down as tight as you wish. (And you'll get better performance too!)

John W. Vinson
Wysard of Information
Go to the top of the page

Custom Search
RSSSearch   Top   Lo-Fi    19th June 2018 - 07:24 AM