Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

You use sensitive geographic data every day. What are your strategies to protect them in your geographical information systems? What kind of architecture do you use? What encryption method do you use? What do you do for users who export sensitive data from your databases?

Thank you very much.

share|improve this question

6 Answers 6

Ok, so sometimes I do manage sensitive data and it can't be separated into public and private bits, the geometry gives it all away. A good example of this are raptor nests (peregrin falcon chicks fetch great prices on the black market) and salt licks (why get all cold and miserable hunting if I can just sit and wait for the prey to walk into my sights of its accord?).

In this case our strategies are to fuzz the data: buffer the points using large units and a random offset or centroid, only show or share the maps and not the raw data. Sometimes we drop the point the geometry and join the attributes with a larger parent polygon, e.g. "somewhere within the polygon bounded by these 2 rivers and that highway there's a salt lick" and that's what is shared outside the unit.

share|improve this answer

With a multi-user geospatial database, you can implement Row Level Security (RLS). You can do this with PostgreSQL (and PostGIS), Oracle and MS SQL Server, and probably others. I've seen it implemented up to the QGIS and SDE levels. What RLS does is implement privileges on the rows (GIS features) that individual users or user groups can select/update/delete.

For example, user "bob" can log-in to a geospatial database using an encrypted connection, and pull up a GIS layer showing only the features that he is authorized to see and edit. While user "sue" can load up the same GIS layer and see a different view of the GIS features she is authorized to see and edit.

share|improve this answer

These strategies apply in several companies that I know

  1. Allow access to data sources only in area of interest of the current project
  2. Use WEB services like WMS & WFS instead of direct access to file data & databases
  3. All users work on Terminal Server with restricted access to network resources
share|improve this answer
    
Good idea with WMS and WFS but for the export of vector data ? –  gistack.ca Apr 3 '12 at 12:35
    
Export is limited to limit of quered features in WFS (near 2000 by default). Export issue can be overcome by providing the only client like JS/Silverlight/Flash/Desktop application that lacks export functionality, and making services secured –  megadrofan Apr 3 '12 at 15:15
    
Also you can develop your limited web services for editing data which use WFS, and use them in your client application. Although developing custom apllication & services require a lot of coding. –  megadrofan Apr 3 '12 at 15:22

I have an out of band answer: simply, I go out of my way to not handle sensitive data if I can at all help it.

Okay, so on the face if it that's not a very helpful response. Let's make it more so. I've learned that a lot of the time when clients come to me and say they need to protect data such-n-such that a careful exploration of their data and goals will reveal that there isn't as much to protect as initially thought. Sometimes the truly private stuff can be separated without too much trouble. You keep that table of birthdays and home address locations over there, in your private file system. I'll keep the geometry over here in the shared workgroup space, and you can join them when needed using this ID column.

The basic principle is: keep the responsibility for managing the security as close to the source, to home, as possible.

This way even though I might manage the spatial data, I actually know next to nothing about it, and thus can never be a vector for it's potential exposure. I think of it as akin to the basic computer security protocol that a sysadmin can reset your password or lock the account, but not actually read it.

share|improve this answer

There is an interesting article describing and evaluating several approaches to protect privacy:

MP Armstrong, Rushton G, Zimmerman DL. Geographically masking health data to preserve confidentiality. Stat Med.1999; 18:497–525.

(Full text)


Although focused on health related data, many of the approaches discussed can be relevant in other disciplines.

National Research Council. Putting People on the Map: Protecting Confidentiality with Linked Social-Spatial Data. Washington, DC: The National Academies Press, 2007.

(Full text)

Another good all-round resouce discussing theoretical, ethical and also technological aspects of health related spatial data.


For a large collection of papers discussing methods and implications of handling sensitive spatial data have a look at SEDAC's Selected Documents on Confidentiality and Geospatial Data page.

share|improve this answer

I use postgresql with postgis capabilities.

Data can be encrypted and accessed via user accounts with explicit database permissions; ie, superuser vs non-priviledged.

Data requests can be handled with simple or complex SQL queries therefor subsets and relevent data gets distributed while protecting sensitive (non-distributable) informations.

It supports running on a closed LAN or fully networked environment and with or without a multiuser environment.

There are of course, several other RDBMS, but postgresql is open-source.

share|improve this answer
    
The strategies here are applicable to any decent RDBMS. The particular db technology is irrelevant unless referring to specific features only applicable in product X. It would be a better answer, vis a vis the question, if it weren't postgis specific. (it's still a good answer, just not as good as it might be.) –  matt wilkie Apr 13 '12 at 20:09
    
Does PostGreSql supports column level security and/or row level security? If so does it play nicely with PostGIS? and then, if so, does it play nicely with ArcSDE? –  Kirk Kuykendall Apr 13 '12 at 20:43
    
You can encrypt columns with postgresql, and postgis should support those as long as they are being accessed by the authorized user/group/role. I haven't explored ArcSDE compatibility with postgresql encryption or the other way around... –  SaultDon Apr 13 '12 at 21:03
    
@KirkKuykendall PostgreSQL does support column and row level security. PostGIS simply provides the spatial extensions for PostgreSQL, so if you have PostGIS, you already have PostgreSQL. As for SDE, I know that PostgreSQL is a supported RDBMS backend. Hope this helps. –  Get Spatial Apr 17 '12 at 15:18
    
@Russell Thanks for the info. Do you know if implementing row or column level security breaks SDE? –  Kirk Kuykendall Apr 17 '12 at 15:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.