Jump to content



Photo

secure a file - view but not copy


  • Please log in to reply
23 replies to this topic

#16 OP Reb0ot

Reb0ot

    Neowinian

  • Joined: 15-July 08
  • Location: London
  • Phone: iphone 5

Posted 28 February 2014 - 17:14

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?




#17 OP Reb0ot

Reb0ot

    Neowinian

  • Joined: 15-July 08
  • Location: London
  • Phone: iphone 5

Posted 28 February 2014 - 17:18

Nevermind my question about logs, I see that http://www.nirsoft.n...ivity_view.html would do it.



#18 sc302

sc302

    Neowinian Senior

  • Tech Issues Solved: 36
  • Joined: 12-July 05
  • Location: NJ, USA

Posted 28 February 2014 - 17:19

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



#19 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 6
  • Joined: 25-March 04
  • Location: England, UK

Posted 01 March 2014 - 03:20

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.



#20 sc302

sc302

    Neowinian Senior

  • Tech Issues Solved: 36
  • Joined: 12-July 05
  • Location: NJ, USA

Posted 01 March 2014 - 13:40

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.

#21 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 6
  • Joined: 25-March 04
  • Location: England, UK

Posted 01 March 2014 - 16:17

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?



#22 sc302

sc302

    Neowinian Senior

  • Tech Issues Solved: 36
  • Joined: 12-July 05
  • Location: NJ, USA

Posted 01 March 2014 - 16:33

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..

#23 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 6
  • Joined: 25-March 04
  • Location: England, UK

Posted 01 March 2014 - 19:52

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



#24 OP Reb0ot

Reb0ot

    Neowinian

  • Joined: 15-July 08
  • Location: London
  • Phone: iphone 5

Posted 06 March 2014 - 14:31

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