Generally you do not strictly import. Far too much trouble to maintain as you have to constantly re-import. So you link or use pas-through queries.
 
As to security there is a built-in users/passwords section in Access. Under Tools>Security. And trying to use Access to actually populate data back into DBA is NOT an easy feat, so you don't really need to be too worried about it. However, to make certain, when we design Access apps we use the linked table to get the information and then a query off the linked table which is a make-table query which creates a local table and THAT table is the one that we actually work off.

When you create a link in Access through ODBC you specify the tables for that particular link so NO they will not be able to go and look at any old table they want.
 
As far as security, the security in Access is totally separate from that of the local machine and/or their network security. There IS a way to create the ability to control security in an Access app through the network or local logon, but it has to be done in VB code as an Access module (programming in simpler words).
 
Also, that is why when we design Access apps for clients we do it as a multi-step process where the linked table feeds to a make-table query which provides a locally (in the Access app) stored table that all other queries/reports/forms, etc. work from. This table then gets re-created each time through a macro.