How to protect data from 3rd party programmers

[JLC]

The company I'm working with has a large database (in one fp7 file), some of the data is innocuous but there is some data that the company is required to not disclose. We are in the process of outsourcing some development, where developers will access this database over a remote server - what is the typical way of handling this? Is there anyway to protect specific fields (even for users with the access required to program)? Is there any way to encrypt data, etc?

thx

Jen

[Rick Whitelaw]

The company I'm working with has a large database (in one fp7 file), some of the data is innocuous but there is some data that the company is required to not disclose. We are in the process of outsourcing some development, where developers will access this database over a remote server - what is the typical way of handling this? Is there anyway to protect specific fields (even for users with the access required to program)? Is there any way to encrypt data, etc?

thx

Jen

In my opinion there's no reason to hand over the data to your 3rd party developer. Save a clone (empty), then, if you must populate the DB with data, Google something like "artificial data" or something. I'm sorry I can't be more specific, but I DO remember doing this to test a DB. Then import the data to your empty clone. I know it will be impossible to find the exact type of data you need for each table, but it's worth a try. I don't understand why your developer needs data. He/she should, with any experience, be able to take your schema and populate it with data. Under no circumstances would I allow anyone to be privy to my confidential data such as SSN or SIN or HST numbers (I'm from Canada).

RW

[David McQueen]

The company I'm working with has a large database (in one fp7 file), some of the data is innocuous but there is some data that the company is required to not disclose. We are in the process of outsourcing some development, where developers will access this database over a remote server - what is the typical way of handling this? Is there anyway to protect specific fields (even for users with the access required to program)? Is there any way to encrypt data, etc?

thx

Jen

I have no idea what is there now. I have come into situations where things are pretty messed up. For example, the relationship diagram instead of being a series of squids is a spider web with the spider on acid resulting from a series of unplanned "updates" over the years. And it can go down hill from there. Real data is necessary to see how the program actually works ( or doesn't as the case may be).

I would recommend the following for development purposes:

1. Take a copy of the database.

2. In that copy isolate a limited subset of real data.

3. Change information to protect the innocent.

Have the developer use that for development purposes. Then he/she will be able to see how data entry really works, how reports are generated and what they look like.....

As evaluation and testing takes place, both you and the developer will have "real world data" to evaluate performance. The one thing you will not be able to evaluate is performance under load as the record set will be limited. You can simulate that to a certain extent by running the program over a WAN.

Part of your overall deployment would be to strip the false data, import the good data and do any resetting of prime keys required. You will have to make the executive decision as to whether you are competent to do this yourself or if the developer will have to have a one time look at the data.

Regarding overall security:

Let the developer know the groups of people who will be using this database, the functions you expect them to perform and the data you want them to be able to see and just as important the data you want hidden from each group. This will necessitate some time and discussion on your part as it may not always be obvious. In a set of projects that I did, I was asked to implement "Executive Director Mode". These were a group of people with the absolute right to see everything, but were neither front line operators or support staff. It was finally agreed that "Executive Director Mode" consisted of "See All and Touch Nothing". It was the only safe way to do it.

In these project, the greatest access to data on a day to day basis was the lowly front line operators. But there were whole sections of the program that they were locked out of.

Further, tie down navigation. No open status areas. No open searches. Passwords and accounts for all......

In the long term, if you are developing an ongoing relationship with the developer, you are going to want him coming into the program do do things over a WAN. It is just the most efficient and cost effective manner of working. So in choosing your developer, you would like a person of "Good and chaste" character. It is hard to know these things ahead of time. You will however have an opportunity to view how this person works as the development process unfolds.

Not the be all to end all of advice, but hopefully it helps.

[JLC]

Thank you both for your input.

So I guess I really have 2 situations;

1) Major Development

In this situation I can make a copy of the database with some relevant but fake data, host that database on our remote server and allow any developers to connect over WAN to work on the database.

So I need a strategy to import a large amount of data coming from numerous tables back into the database after programming is done. What would be the most foolproof quick and easy way to import data from numerous Tables with thousands of fields?

2) Minor Ongoing Tweaks and Maintenance

In this situation the developer will have access to the database with all of it's data. In this case I need a solution to lock down / encrypt or whatever a small selection of data (there is some data in the database that we are contractually required to not disclose). What is the best way to handle this?

[Fitch]

...a strategy to import...

UpdateManager is very handy if you're doing imports on a regular basis.

http://www.goya.com.au/updatemanager

...lock down...

Security is file-based, so if the developers have full access to the file, which they probably need, everything is open.

I suppose you could create a script to encrypt specific fields. There are plugins for this, e.g. Troi has one. However, you'd need to store the encryption seed in a separate file that you don't share.

It might be more efficient to break out the sensitive fields into their own file, which you can then protect easily with FileMaker's native security.