![]() ![]() In a situation, such as this, it is possible to write a query at SQL level, which limits the record-set to a specified district. ![]() ![]() For instance users may only need to view customer records for their district. SQL Views can be used to limit which datasets a user sees. With Active Directory controls at SQL level, all Access requires is the use of Windows NT authentication – SQL will do the rest.īeyond using Active Directory Security, there are other ways that one can control access to data. In addition – by using Active Directory - ODBC Data Connectors are more secure, because you can get rid of saved login strings with user names and passwords.Permissions can restrict which tables users are allowed to see, to edit, etc… Create roles to designate permissions for logged in users.Determine which user is logged into the database.This means Active Directory security can be used to: Specifically you can use SQL Server Active Directory Security. By moving all of your Access data to a SQL Server backend database, you can immediately take advantage of the robust SQL Server Security capabilities. The benefit of Improved Security is highly important. The linked article is well worth your read. In the linked article, Microsoft lists many benefits of upsizing Access data to a SQL Server backend. Most of my clients are using a SQL Server backend database with Access as the frontend file. Then you link the SQL Server tables back to the MS Access frontend file. In short, when you upsize an Access Database to SQL Server, you’re moving all Access tables and data to the more robust Microsoft SQL Server database. This makes it much easier to administer complex security schemes. Improved security Using a trusted connection, SQL Server can integrate with Windows system security to provide a single integrated access to the network and the database, employing the best of both security systems. You may want to read this Microsoft Knowledge Base article on upsizing Access Data.įrom the article: Benefits of upsizing a database to SQL Server Even if security in Access was limited to native Access tools, one would have to look long and hard at a policy which allows so much exposure to data through Excel, but then limits the use of Access.īeyond the obvious problem described above, what most people don’t know – and never get to in their assessment of Access as an option for sensitive data – is that Access can be upsized to incorporate the use of SQL Server. But, for some reason storing the same data in an Access database (with more controls than a spreadsheet) is forbidden. for end users to copy/paste spreadsheets of sensitive data to in-secure locations (like their desktops). They’ll dump their export into Excel, save the Excel file to a personal folder (or worse yet their desktop). For example – and I see this on a regular basis – users will download sensitive data from a secure enterprise software solution. Many organizations fault MS Access Security, but have no problem with storing sensitive data in Excel spreadsheets, created by end users and stored in folders that may (or may not be) secure. Following are some things to take into consideration, about data security and the use of Microsoft Access. But, this is a simplistic understanding of the issue. If the MS Access database is using native tables, then it isn’t any more secure than an Excel Spreadsheet. To be fair, the misconception has some grounding in fact. One of the biggest misconceptions about MS Access, is that it isn’t a secure database. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |