data security for testing & development

Classic Servoy
1

I am working on a job with pretty strict privacy requirements to keep student data secure, and tonight I am working on a deployment schematic as part of the IT requirements documentation for the university.

What I envision is a setup where actual production data is mirrored to a development/test server, and a back-end model that keeps student ID’s (PK’s) in one table with a 1-1 relationship to the actual student names, addresses, phone #'s, and other sensitive personal info in a separate table.

The idea is that on the test server the Student Info table can have dummy data, and if end-users call a member of the development/support team with a question they will refer to specific students only by ID #. The support person can then connect to the test server and look up that student by ID #, test/resolve/answer the issue or question, and the student’s actual personal data is completely protected. (As an aside, I believe this is how things are handled for applications that must be HIPAA-compliant…)

What I’m having trouble visualizing for my schematic, and what I am not equipped with enough servers in my office to figure out here, is exactly how to handle repository, database connection and database naming issues.

I’m thinking that these are potential problems with the setup:

  1. the production db and test db could not share the same name (since they will be on the same network/subnet, perhaps even on the same db server), which would complicate matters when, after making changes to the repository while connected to the test db, that repository needs to be “ported” to use the production db instead. How to solve?

a. Should the test repository be kept local on Servoy Developer workstations, so that the database server connection name would not be an issue? In other words, if the db connection is named “university_db” on one machine it could point to the test database and on the actual Servoy Server a connection of the same name could be established that now points to the actual production data?
This solves the connection-naming issue but makes version management amongst the various developers a bit of a drag … I don’t like the idea of various builds being scattered among a development team (tho’ not the end of the world, to be sure, done every day I guess)

OR

b. Should there be a single repository (perhaps even multi-dev) on the Servoy Server box at the client’s with separate connections to the test db and the production db?
This would solve the version-management issues but would mean the connection to the test server and to the production server would have to have two different names, so how to export new versions from the copy of the solution that connects to the test server and import to the solution that has a differently named db connection??

OR

c. Am I overcomplicating things and perhaps there is some easier approach to a situation where:

– there are several dev’s
– they cannot be given access to actual production data when supporting end-users or modifying the solution

thanks for any help brainstorming this. How to obscure personal data while allowing developers & support personnel to serve a client is becoming more and more an issue these days. Maybe someone else has already worked through this?

kazar

2

Hi Ilyse,

kazar:

  1. the production db and test db could not share the same name (since they will be on the same network/subnet, perhaps even on the same db server), which would complicate matters when, after making changes to the repository while connected to the test db, that repository needs to be “ported” to use the production db instead. How to solve?

You can have a production and test database with different names as long as the database connection-name used in Servoy is the same.
So when you export the solution from your developer and import it into the production server it simply works.

Hope this helps.

3

well, like I thought I might be doing, I sure was complicating things too much in my mind. Thanks, Robert!

4

ROCLASI:
You can have a production and test database with different names as long as the database connection-name used in Servoy is the same.
So when you export the solution from your developer and import it into the production server it simply works.

It looks like IT rules will necessitate keeping the repository on their premises and the outsourced developers will need to set it up as a remote repository from their desktops.

The main reason for the obfuscated personal data on the “test” db server is not only “for development/testing purposes” … it is important mostly for “user support purposes”.

My idea to satisfy university data-security requirements is that when a user opens a ticket that requires Support to access their data in its current state, they will be instructed to enter only the UID of any student record they need to reference in their trouble report without giving out the student name. And devs (who will also be providing user support) will be able to connect to a mirror of the data and locate the record(s) in question by querying the student_id (but the mirror will hide names, SS#s and other stuff).

So. I hope I explained it more clearly … in order to achieve this requirement that the users access one back end and the devs/support personnel access a mirrored but obfuscated back end, when the repository/ies must be onsite at the clients … will it be necessary, then, to maintain two repository servers so that the connections can be named the same but different back ends referenced?

Hope this was clear. If not, I’ll draw up a couple possible deployment diagrams…

kazar

5

kazar:
So. I hope I explained it more clearly … in order to achieve this requirement that the users access one back end and the devs/support personnel access a mirrored but obfuscated back end, when the repository/ies must be onsite at the clients … will it be necessary, then, to maintain two repository servers so that the connections can be named the same but different back ends referenced?

First of all, yes the production server can be pointed to the production data under the same connection name. And the development team can point their connection to the test database under that same connection name.
It’s just a matter of changing the connection URL in the DB Server connection settings.

As for the repository server. It’s good practice to keep the deployment repository and the development repository separate. Of course that development repository can be a multi-development server.
And you deploy new versions of the solution simply by exporting it to a file and importing it into the production server.
Note that only the connection name is in the solution, the actually database URL is setup in the developer/server preferences so this way you can work with test data while developing and life data when deploying.

I hope this helps.

6

Thanks, Robert, for the additional clarifications. I’ll be working up some (independent) documentation for this kind of scenario, a sort of cheat-sheet for setting up a “HIPAA-like” deployment. Will post back here when it’s ready for prime time, in case anyone else could use such a thing or wishes to comment.

kazar