secure a file - view but not copy


Recommended Posts

Hi guys and girls,

 

I hope this is the right section to post this question.

 

is it possible to secure a file, such as an access database, where you could have a master account that is able to have full rights of the file as well as a slave account that is only able to view content on it? As well as locking the file from being copied (file copy, save as, copy content within the file, export, etc...)

 

I know the user would be able to do screenshots though, but we can ignore this as I imagine this would be a tricky way of blocking access to this.

 

I hope someone knows of a solution.

 

I was looking at Folder Lock, which is able to encrypt files and has a master account active on it to unlock files, but its a shame that it doesnt have a slave account to just lock users from copying things.

Link to comment
Share on other sites

no, if you can view it that mean you can read it,

and the program that read it, and store the information that was reads into memory/ram,

so to copy it, it just matter to write what was in ram into another storage location.

Link to comment
Share on other sites

yeah thats what I have in mind, but surely there must be a way to secure things.

 

How do banks control their databases from members of staff stealing their data?

Same applies to other corporations?

Link to comment
Share on other sites

"How do banks control their databases from members of staff stealing their data?"
 
They hire staff that they trust, but there has been many cases of staff stealing info..  If I can view it what keeps me from taking a picture of it on the screen with my phone say?
 
You can set permissions in say a pdf that you can not print, save or copy from it etc.

 

post-14624-0-08697800-1393590297.png

 

See how print and save are grayed out - but I can still take a screenshot of the page in the pdf and and then print that or save that ;) Or lets say that sort of feature is disabled on the terminal - who says I can not whip out my phone and take a picture of the info?
 
http://www.wfmz.com/lisbhett-diaz-steals-sells-bank-customers-information-officials-say/-/121798/20160560/-/bskihr/-/index.html
READING, Pa. - A former bank employee was arrested Wednesday on charges she stole and sold the identities of bank customers.

Link to comment
Share on other sites

absolutely true budman, I know re the screenshot/printscreen functionality, which one can disable with a lock key anyways, so not to worried about this key.

The photograph through a phone would be a problem indeed.

 

But if we concentrate only on software content locking, like the way the PDF is locked, and even though there are apps to crack the passwords of such files, i am looking for a way to secure an access database.

 

So not sure if maybe its best to import the data in a CRM and make sure the crm encrypts the visible data and uses javascript to disable right clicks and pressing of keys such as ctrl.

Link to comment
Share on other sites

How do banks do it? They don't give access to the local computer. How I did it was remove access to usb and local drives through group policy. There was no access to right click, command prompt, or any other utilities that would give them access. Even the network drives were locked down where they could not delete but they could copy.

Link to comment
Share on other sites

What would they copy it to. Any manipulation software was denied access to. Can't email, can't put it in paint, can't usb it. Great it it's in the computer memory, can't get it out. They would have to physically take pictures of the screen.

Link to comment
Share on other sites

If you recorded with a GoPro or similar you could catch the information scrolling past quite quickly I should think. I think James Kingston used a chest mounted GoPro for one of his runs at least.

Link to comment
Share on other sites

That would work and could open you up to a lawsuit.

My job was to secure the machine from being able to copy to anywhere but the intended location. How they handle other proposed issues was not my concern.

Link to comment
Share on other sites

sc302 makes some valid points about preventing access to other media on the local machine they are using to prevent copy to portable media they can walk out with, etc.

 

There is nothing built into ntfs permissions that can prevent copy - if you allow read, now you can prevent writing data in locations - so where does the user copy it to is one method of mitigation.

 

Now access has some features that can prevent copy of the database

http://office.microsoft.com/en-us/access-help/overview-of-access-security-mdb-HP005188226.aspx

 

Need to look into that on your own, I have not had anything to do with access for years and years and years.  Its not really an enterprise sort of solution, great for small smb or something.  Normally you would limit the access user has, and prevent access to it all at once.  Users limited to specific form that gives them say limited access to only the aspect of the data they need, in small chunks, etc.  Common security practice of least privilege - show the user only the data they need access to perform their function.  

Link to comment
Share on other sites

It is easier with ad because you can lock out the individual pc and what the individual user has access to as far as programs go and have a storage location that would give them access to be able to read or read/write to. With everything self contained on a pc it is a bit hard to lock out the hard drive.  You could still lock out the usbs and CD/DVD drive to prevent copy to, but it is a bit harder to lock out the rest of the computer as you need it to save to and you need storage locations. 

 

We could even lock it down to the point that when you logon it runs a specific application and you have no access to the windows gui at all other than ctrl/alt/del menu for shutdown access and change password access. If the application needs access to see the folders on the c drive, denying access to the c drive in explorer would be useless.

 

How I would do it with AD GPO is give a specific user group that would need limited access a desktop and startup folder redirection to a read only folder with the icons I wanted them to access.  I would also disallow access to the c drive in explorer, disable task manager, disable run, and disable the command prompt.  I could put an icon that points to a script to shutdown the computer, or give the user ctrl alt del rights to shut down the computer. 

 

If the computer only needed to access one specific program, say either microsoft terminal services client or the citrix ica client, I would change the shell=explorer.exe to shell=mstsc.exe or shell=ica32t.exe, which would bring up the application....if needed I created a script to call the executable after it was closed so that it would be in an endless loop if a user accidentally closed out of the application.  the only way to shut down the computer in this case would be to ctrl alt del and shutdown the computer or hit the power button to shut down the computer. 

Link to comment
Share on other sites

Cool sc302 :)

 

Ill think about making a proper AD environment of it though, but for now they are all on just normal workstations setup as home.

 

Might be worth also integrating a logging system of what the user does on the computer? Are you guys familiar with any solution for this?

Link to comment
Share on other sites

that is borderline spying, but you could use a utility from http://www.spectorsoft.com .  Works great and is invisible to end users.  You can capture as much or as little information that you want.  Again it is borderline spying.  US really has no laws against something like this as businesses own the computers and network that you are on and with byod end users should be using that to stay private.

 

edit: Couldn't wait 10 min, huh? :P

Link to comment
Share on other sites

There's a great deal of discussion here about locking down the system to prevent copying of the MS Access database file, and very little considering alternate database solutions... (Not saying that locking things down would be unnecessary with another database solution).

 

@OP. MS Access is something mostly used only by students, home users and some small businesses; there are far better packages out there such as PostgreSQL /  MySQL / MS SQL Server, some of which are free btw. Do you know/understand the differences between these and MS Access? I'll assume not...

 

A (standard) MS Access database, as you know, is contained in a single file, which you can treat like an excel/word document, being free to move it around, copy it to and open it on other systems easily (only requiring MS Access being installed); you double click the file itself to open it. It doesn't scale where multiple employees need to modify data at the same time (presuming there's no sharing mechanism built in that I've never bothered to explore).

 

In contrast, with a "real" DBMS (database management system) package: The DBMS software package is usually installed on a server, not an employee's work machine. Creation and management of databases is either done (typically by an IT admin) via the command line, or perhaps an application with a gui interface (which may be bundled with the standard DBMS package but sometimes is downloadable separately). Each database you create with the package is contained in one or more files somewhere on the system. Such files can obviously be copied from one system to another but can it be more difficult/involved to then get them up and running on the new system. You do not double click a database file to open it, you simply have the DBMS software running and interact with a database through the DBMS. The functionality provided by MS Access for designing/creating "forms" with which users/employees can interact with the database does not exist here with a "proper" DBMS (at least with the set of packages I am familiar with), instead the DBMS software sits there listening, often on a network port, waiting for interaction via network communications from other applications (this is one form of "inter-process communication"!). A separate business desktop/web application must exist (bought off the shelf or custom built) which provides an interface and interacts with the database through the DBMS.

 


yeah thats what I have in mind, but surely there must be a way to secure things.

 

How do banks control their databases from members of staff stealing their data?

Same applies to other corporations?

 

A bank or other large organisation, using a "proper" database, will have a DBMS package, such as MS SQL Server installed on a server. The employees will use either a desktop application, or a web application, either of which will communicate with the DBMS package over the network to store/retrieve data entered into or displayed in the application respectively. It should be expected that only a very small number of trusted IT admins will have such access to the server where the DBMS is installed that they could copy the files containing the database. Furthermore the entire database may be heavily encrypted.

 

Most employees will have no means of simply copying a single file to steal a copy of the data, they are limited via what functionality for viewing/exporting data is provided to them through the software (CRM) they use that in turn interacts with the database. This may mean that they are limited to a painstaking process of taking screenshots of individual data records.

 

Note that above I was careful to describe the MS Access database as a "standard" one, by which I mean a typical single file which contains all of the data and any form interfaces. It is actually entirely possible for the data to exist outside of this MS Access file. See here! So an option available to you here, if you are unable to switch completely away from MS Access for whatever reason is to move the data to an external database within an ODBC compatible DBMS package such as MS MSQL Server, leaving the MS Access file, which would be modified to use the external data source via ODBC, as simply providing an interface via any forms you have created. I.e. the MS Access file then just acts as an alternative to a proper OTS/custom-built desktop/web application. You can do this should cost/OTS-functionality/custom-build-dev-time/whatever be prohibitive, or at least as a stop gap solution. What I am assuming here is that when the MS Access file is closed, it does not save any cached copy of the data within it (I haven't tried, so I don't know for certain).

 


absolutely true budman, I know re the screenshot/printscreen functionality, which one can disable with a lock key anyways, so not to worried about this key.

The photograph through a phone would be a problem indeed.

 

But if we concentrate only on software content locking, like the way the PDF is locked, and even though there are apps to crack the passwords of such files, i am looking for a way to secure an access database.

 

So not sure if maybe its best to import the data in a CRM and make sure the crm encrypts the visible data and uses javascript to disable right clicks and pressing of keys such as ctrl.

 

CRM encrypting the visible data? But if it's encrypted then it's useless to display it to the employee... I'm not sure I understand what you're getting at...

Using javascript to try to lock things down such as preventing access to context menus is far from fool proof. All you have to do is disable javascript in the browser and boom, you've defeated it. You're never going to prevent a knowledgeable employee from getting your data with little tricks like that. Granted, if you can lock down their computer, you're potentially in a more powerful position.

Link to comment
Share on other sites

You presume to understand sql but don't understand access. That is good.

A database in itself is basically a spreadsheet with tables and rows and columns. Have you ever seen a graphical representation of a database...it lays out very similar to a spreadsheet. The point of a database is so that multiple users can modify data at the same time. While the user may have access to the mdb file and in sql they generally do not, a front end can be built for access so that the users do not have direct access to the mdb file to be able to manipulate directly.

I was working for a bank that was piloting a csr and teller program, the front end was a c++ designed application and the backend was a access db that they were able to manipulate on their commuters with a administration password similar to a sa user and password. I would sit with the programmers and threw in my two cents when it came to networking and Windows. I worked for the bank they worked for ncr. They eventually sold the system to their competitor which I believe fiserv purchased and its currently rolling out.

I highly doubt it is access based any more but access is far from just a single user db.

Link to comment
Share on other sites

You presume to understand sql but don't understand access. That is good.

A database in itself is basically a spreadsheet with tables and rows and columns. Have you ever seen a graphical representation of a database...it lays out very similar to a spreadsheet. The point of a database is so that multiple users can modify data at the same time. While the user may have access to the mdb file and in sql they generally do not, a front end can be built for access so that the users do not have direct access to the mdb file to be able to manipulate directly.

I was working for a bank that was piloting a csr and teller program, the front end was a c++ designed application and the backend was a access db that they were able to manipulate on their commuters with a administration password similar to a sa user and password. I would sit with the programmers and threw in my two cents when it came to networking and Windows. I worked for the bank they worked for ncr. They eventually sold the system to their competitor which I believe fiserv purchased and its currently rolling out.

I highly doubt it is access based any more but access is far from just a single user db.

 

You're replying to me I presume... Yeah I really don't need the elementary description of a representation of a database, thank you though :p rofl.gif

 

To be in a way pedantic, the point of a database is not as you put it "so that multiple users can modify data at the same time", the point is simply to store data. Or more correctly, a database by definition is fundamentally just a collection of data (even a collection of documents in a file system is technically a database, as pointed out by one of my university lecturers, who I believe had a PhD in the subject, in a module specifically on database system management). As such I would argue that there is no universal point to a database. A DBMS on the other hand has a point, which is to provide an interface to the database including the provision of management facilities. One common property/function/facility provided by a DBMS is simultaneous multi-user access, which brings ACID and locks into the picture. But I digress.

 

I haven't used MS Access since I was at school a decade ago. If a MS Access database file can as you suggest be used as a backend data store with a separate front-end application (or separate MS Access file) providing an interface, in the manor I described in my previous post, providing reliable simultaneous multi-user access, then fair enough. However, the primary point of my post still stands; rather than focusing on locking down an employee work machine to try to prevent the employee from pilfering a copy of a MS Access file containing an entire database, let's consider splitting the data out to an external database held on a server, whether it be MS Access or one of the other packages I mentioned.

 

@OP, what are your thoughts on this?

Link to comment
Share on other sites

You can store data in any file. You can make a spreadsheet a data file that contains the same information as a database, you can even import spreadsheets into a database because they are so similar. The issue that arises is that the data file becomes locked to one user and then requires that user to be out for another to be able to enter data. Databases allow for a central depository for users to collaborate and share information. They can access information in real time after another user has entered it. If I enter a piece of information another user can search for it and see the information I entered. You can not do that with a flat file without a database hook behind it like SharePoint or Google docs, nor can you do it by itself.

But I digress, a database is an area where multiple users can input information into at the same time. That is the fundamental explanation of what a database is...any database. Otherwise it would just be a file. Do you ever wonder why a access database file ends with mdb and a sql database file also had the same extension of mdb, why do you think that is? You studied this and have far more school book knowledge than I do, enlighten me..

Link to comment
Share on other sites

You can store data in any file. You can make a spreadsheet a data file that contains the same information as a database, you can even import spreadsheets into a database because they are so similar. The issue that arises is that the data file becomes locked to one user and then requires that user to be out for another to be able to enter data. Databases allow for a central depository for users to collaborate and share information. They can access information in real time after another user has entered it. If I enter a piece of information another user can search for it and see the information I entered. You can not do that with a flat file without a database hook behind it like SharePoint or Google docs, nor can you do it by itself.

But I digress, a database is an area where multiple users can input information into at the same time. That is the fundamental explanation of what a database is...any database. Otherwise it would just be a file. Do you ever wonder why a access database file ends with mdb and a sql database file also had the same extension of mdb, why do you think that is? You studied this and have far more school book knowledge than I do, enlighten me..

 

No, that is not the correct fundamental explanation of what a database is.

 

Okay firstly, to what do you refer by "sql database file"? Do you refer to a database file created specifically by MS SQL Server, or do you instead refer to a database file created by any SQL type DBMS software package? Whether MS SQL Server uses the *.mdb (presumably short for "Microsoft Database") file extension, I cannot presently confirm (I don't have a copy installed, and I can't be bothered to try and research it). As to why they might have chosen it if they did, maybe because it's simple and has an 'm' for Microsoft? If you're under the mistaken belief that all SQL based DBMSs use the *.mdb extension, I can categorically state that this is not true; I have a database in a MySQL installation right here which actually uses *.frm and *.ibd files for instance. Furthermore *.mdb is not the only file extension used by MS Access, it is one of many (see here). *mdb is simply the file extension used by MS Access 2003 and below for the most common file type, replaced by *.accdb in version 2007 onwards where new file formats were introduced.

 

Let's recognise that sometimes words are misused, just as people may call any tablet computer an "iPad", or a vacuum cleaner a "hoover", the term "database" is commonly and incorrectly used instead of DBMS or perhaps simply "database system", even by myself at times. I'm trying to be accurate here in distinguishing between a database and a DBMS / database system. A database is a collection of data. A DBMS (database management system) / database system is a software package providing an interface (including "management" functionality) to a database. A "flat file" can indeed be considered a database (see here). A spreadsheet could technically be labelled as a database. A set of simple files in a folder may perhaps be considered a database. The database files created by a DBMS are in essence just flat files - files containing related data with a specific structure.

 

Here are a few references from books I have here on my book shelves:

 

"Understanding Computer Science, for advanced level" by Ray Bradley, page 562:

The modern database

Put simply, a database is a collection of interrelated data - rarely (perhaps on a simple micro system) containing just a single file, but more often containing a collection of several or even many files. If a database can work only on one file at a time, then it is called a flat-file database. In addition to these basic files which can be modelled in a variety of ways, there would be some program or a set of programs to carry out operations such as data entry, and generate queries which can extract a variety of information specified by the users of the system. At the most basic level, an 'address book', or even a 'list containing telephone numbers' could be regarded as examples of very simple databases. However, in this particular chapter, we will take a general look at the DataBase Management Systems (DBMS)...

When databases are undertaken within the DBMS environment, computerisation should ensure that the database is much more convenient to operate. The DBMS should also ensure that it's more efficient to enter and extract the data...

 

"The essence of Databases" by F.D.Rolland, page 1 (not the most clear of texts, but recommended reading):

1.1 What is a database system?

A database system is any computer-based information system where the data that supports that system may be shared. By 'shared', we mean that the data can be used by a wide variety of applications and is not arranged in such a way that it can only support one particular application.

 

1.2 Database systems and file processing systems

Computers store data in files. A file is a collection of records on a common theme. For instance, we can have a stock file consisting of stock records, a customer file consisting of customer records and so on. Each record consists of data that is subdivided into fields. For instance, we could have a book file consisting of book records, with each book record having fields for ISBN number, title, and author. In a traditional file processing system, specific sets of files are created and manipulated by specific applications. A database system is different. With a database system, files are not tied to and maintained by specific applications. Instead, they are integrated in such a way that the data within them may be shared by an indeterminate set of applications.

 

Same book, page 4:

 

A fundamental characteristic that distinguishes a database system from a traditional file processing system is that a database system allows many different uses to be made of the same data. The use of the data is not tied to or controlled by any single application. Instead, it is shared amongst different applications. This is achieved by removing the responsibility for creating and maintaining the stored data away from the individual applications and passing this to an underlying layer of software known as a 'database management system' (DBMS). The DBMS acts as a controlling layer between the users of the applications and the data itself.

 

Note that in the latter two references the author is describing a database SYSTEM (DBMS), not simply a database!

 

So as you can see, no mention whatsoever of multiple users in any sense. Let's consider a simple hypothetical example where we have a data file which two applications wish to modify. To write to the file, they have to obtain write access via the OS. Only one application can get write access at any time. This is the common/fundamental multi-access problem you described. A simple flat file database (which can truly be considered a database as shown with the above references), still has this exact same problem. A modern DBMS however will typically have been built to provide a solution to this problem. The file access is done only by the DBMS application, and the interface provided by the DBMS to applications provides a means for simultaneous read/write access. For reliability, the DBMS will typically be built to be ACID compliant, including features suck as locks and transactions.

 

While multi-user/application access (simultaneous or otherwise) is a fundamental feature of a DBMS and a major objective behind there creation (to combat data duplication present in using completely independent applications), it is not a fundamental component of any and all databases, by the correct definition of a database.

 

I can also feel the urge to be pedantic about your use of the term "real time", but I'll resist it, it's not important. tongue.png

Link to comment
Share on other sites

whoa this has gotten out of hand, no need for wars here.

 

I understand both MS ACCESS as well as Database packages such as MS SQL, Mysql and others.

 

My question was just whether there was a way to secure access of an Access DB in a network environment, thats all.

Just so that users are not able to copy content from it and steal business data.

 

I only presumed that MS SQL, Mysql would have been a way to do this in a way, as I can see no real macros that could be coded into MS Access to restrict the access of the user from copying data.

 

At the end of the day, most of the users are not familiar with reading or decrypting code from a web source (if we convert the access db into a mysql db with a UI), or well we would have to assume that most of them would not be able to do this.

So we are trying to minimize the number of people that would be able to do it.

 

It might just be as simple as disabling USB on the computer, plus importing a macro that would disable the ctrl key on access and save as option I guess

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.