September 19, 2016 at 10:42 am
Stored procedures do not prevent SQL Injection. SQL Injection comes when you build any string from user input. That can take place in a stored procedure if you use dynamic SQL. Not the norm, but people do this, especially for search type procedures.
Access has stored procedures - https://msdn.microsoft.com/en-us/library/office/ff845861.aspx
October 13, 2016 at 10:59 am
I would definitely go with SQL Server for your data store. The combination of Access as a front end and SQL Server can be secured pretty well if you use the Access Runtime system, which denies users direct access to tables. But since you're using ASP for your front end and are more concerned with your data store, then no, I would not use Access. Much easier securing information in SQL Server. Plus, you can use audit triggers to track who signs on and who modifies data.
I just developed a student information system using Access and SQL Server, and it was pretty tight, security-wise, as I had a nice row-level security model with multiple roles available, and the user's role dictated what menus they could use. It wasn't HIPAA/PCI, but it was partly governed by FERPA, which is similar. When a user signed on to the server, they got their own fresh copy of the database. But I had the advantage of using a hosted server and SQL Server was the only app on it: much easier to lock down something when there's only one thing going on. If you're sharing information among multiple clinicians, that might not be possible.
Access can kind of suck when you get in to really large data sets, or you have multiple people banging against it. You'd be much better off with a well-designed SQL Server database and system.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
October 13, 2016 at 5:50 pm
I was using 2003, so things may have changed. I thought MS gutted security in Access... maybe I'm wrong.
October 13, 2016 at 6:29 pm
There are other "data security" matters, as well. You need to consider backups and where they live as well as "data at rest". That goes for both SQL Server and Access and any "original" datafiles that may have been imported into the database or exported to support other things. Don't forget that any "reports" are also considered to be "exported" data and a possible security risk including the "data at rest" problem.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 14, 2016 at 3:32 pm
If you have more than two users with differing rights and/or the need to control access to specific queries or objects on a user by user basis, your job will be exponentially more difficult with Access.
October 14, 2016 at 4:32 pm
I just think SQL Server has lots better maintainability, speed optimization potential and is easy to build functions, calculated fields etc.. The fact that it has the ability to have encrypted columns should fill your security need. More important is the rules on how the data is propagated from the database. If I can query it and copy it to a text file, then you just defeated the purpose. Tools like SSRS can have security, on top of SQL Server security , on who view what reports so that non-access people do not have access to the PHI and can still get the the information they need.
----------------------------------------------------
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply