+1 on using database / user permissions to secure access to data, that's exactly what its for - and why you (should) have a DBA to manage this stuff. On the persistence thing (which surprises me) I would look at both OS and rdbms cacheing.
On 11-Nov-2017 2:32 AM, Stephen Russell wrote:
Here is a video that just starts to get into this.
https://www.youtube.com/watch?v=H2grViHAgbs
I guess you first need to identify just what walls you want enacted to block everyone and what doors are needed that allow only a few people to access the data.
We use data cubes to identify what a user can see about sales data. We scope it with their identity and are they a manager of a group or not.
Look to Power-BI as the user tool to access the cube. You load the cube from SQL Server where you are defining your Dimensions as well as fact tables in your Data Warehouse.
That one statement may be a lot more than what you thought you wanted, but it is how we do it here.
Who has access to the real SQL Data, and how? Does everyone use sa to get in, or does everyone have an individual account in the database?
This is probably what you are attempting to stop, right? "Some of their employees can steal this information and sell it to outsiders"
I can set all users the ability to query our staff and not be able to see age, payroll details, or education level. Some users, HR for instance. get the whole shebang if I want. In this case, I make one AD group for HR. You are either a part of it or not for this general lesson.
On Fri, Nov 10, 2017 at 2:18 PM, Rafael Copquin rafael.copquin@gmail.com wrote:
Thanks Stephen
That does not answer my question though. But it is illustrative of how other companies want to hide sensitive data from snooping eyes (government, nosy employees, competitors, etc) In my client's case, it is about not sharing confidential sales data, building plans and management salaries with the local staff Some of their employees can steal this information and sell it to outsiders
And yes, the databases are on a desk PC
My problem is to determine why the data persists in memory and how to prevent it
Rafael
http://www.avg.com/email-signature?utm_medium=email& utm_source=link&utm_campaign=sig-email&utm_content=webmail Libre de virus. www.avg.com http://www.avg.com/email-signature?utm_medium=email& utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
2017-11-10 16:33 GMT-03:00 Rafael Copquin rafael.copquin@gmail.com:
One of my clients uses a VFP9 app with MSSQL SERVER databases
Two databases
database A stored in the hard disk (C:) databaseB (with confidential data) stored in an external hard disk(E:)
The Sql Server Management Studio correctly shows, in each database properties windows, in the files option, that the A database resides in disk C and the B database resides in disk E
However, if I physically remove the hard disk (E:), the management studio still shows all tables of database B and select statements show data from the applicable tables.
I thought that the data resides in memory in the cache. So I disconnected the SSMS from the engine, even turned off the SSMS. Then, when the SSMS
was
up again, it would still show the database B (even if its lodging HD was disconnected and put away in a drawer) and queries would still show data from any of the tables.
What is going on?
How can I prevent this "ghost" behaviour?
It is very important that, when the external hard disk is removed, no confidential data can be read at all.
Rafael Copquin
Este correo electrónico ha sido comprobado en busca de virus por AVG. http://www.avg.com
[excessive quoting removed by server]