Designing security for different client types in the same app

[Alex Glaros]

I'm writing an app that government organizations use for project management and other functionality, and, using the same app, open areas for citizen engagement, for example, crowdsourcing citizen ideas for government projects.

Citizens and government share the same data.

Everything is locked down meticulously using decorators, db.auth_group, SSL, but are there design improvements I can make to improve security, for example, only allowing citizen access via API so that they are not directly querying the shared tables?

Are there specific risks when government classified information is stored in same Postgres database that citizens use to engage with government?

thanks,

Alex Glaros

[Ron Chatterjee]

You have to use something like this most likely. 

https://en.wikipedia.org/wiki/NSA_encryption_systems

And they will need to approve that. I am guessing. 

[Massimo Di Pierro]

I do not think the question as posed has an answer and most people who have a naive understanding of data security will answer no: it is not a good idea to store data with different levels of classification in the same place.

I disagree. Who is in charge on enforcing access control? The app is. Nobody else can be in charge of this. So the real question is: is the app good enough to satisfy the access control requirements for the highest level of classification? If so, I do not see a problem in applying the same high standard to lower classification by storing all documents in the same place.

Keeping the data separate makes logging and monitoring of access easier. But that is all.

Massimo

[Alex Glaros]

agreed Massimo

my friend who made the suggestion gave me a few more details: For multiple programmer teams, he gives HTML developers access to the API only, in order to limit number of programmers writing code that access the database.

thanks,

Alex

[Niphlod]

Hello, data "guardian" here! Being the lonely DBA, I'm pretty much bored with this kind of stuff every day at work, managing nearly 2k databases ranging from simple q&a to financial to "top secret" data. Everything CAN be managed (various degrees of "complications"), but please note that there are SEVERAL variables in this "game". 

First and foremost (I know, it's silly but there are places where this key piece is missing), a "person accountable for" must be chosen. 

If that person is yourself, I'd urge to document:

- what happens if data is lost

- what happens if data is tampered

- what happens if data is stolen

First two are easy to solve: a proper backup scheme! Third is a real PITA, and must be considered individually.

If you can't trust frontend developers (sadly, you're not the only one), there's the most and effective way for sleeping like a baby every night: they shouldn't deal with data from the production environment anyways to create a frontend, so you create a dev env with sensitive data obscured, it's a simple process ^___^'

If you can't trust the backend developers, you're screwed anyways, unless you segregate permissions AND document them (e.g. bob requested access to table x for doing report y). Segregation (always in various degrees of "complications") can also be accompanied by a fixed timeframe where those credentials are valid (i.e. rotation). 

Given though you're expressing a world where an API exists, you don't have backend developers at all.

Trust this though: if you're the "gatekeeper" of the data and YOU have the (legal?!) responsibility, you need to carefully document each and every access you provide to people using that data.

If you're not the "gatekeeper" of the data but merely of the "windows" the data is seen/managed from, forcing everyone through an API is the best way to be able to audit (the "gatekeeper" of the data could/SHOULD request you the audit if something happens)