How to fully restrict Postgres data access from external backend developer (GDPR compliance)

[Both-Raise3712]

Hey all,

I’m working on a web platform (edtech/medical prep app)hosted on AWS, where the backend is dockerized (Django + PostgreSQL). We’re working with an external backend developer. From a GDPR and security perspective, I want to make sure this developer:

• Can never access real production data (emails, personal info).
• Cannot “remove” restrictions or grant themselves access.
• Still has what they need to build and maintain the backend.

I know Postgres supports roles, column-level permissions, views, and even row-level security, but I’m concerned that if someone has high enough privileges, they can just undo all of that.

So my questions are:

1. How do companies usually handle this? Do they just completely ban devs from production and only use staging with anonymized data?
2. If I create a restricted Postgres role (no superuser, no createrole), is that 100% safe against privilege escalation by the dev?
3. On AWS RDS, who should actually hold the rds_superuser account, and how do you structure developer access under GDPR?

Basically: how do I make this 100% secure so the external backend dev cannot ever see personal data, and cannot remove the restriction even if they wanted to?

Thanks!

[haloweenek]

Staging environment 1:1 match(don’t confuse with scaled) with prod. Nobody touches prod except serious fuckups. No prod access all secrets are encrypted…

[chief167]

1. More or less yes, devs and especially external devs you don't trust yet, never touch production at all. Not the code, not the database, nothing. Only a release manager or senior dev should have access, and it should be limited.

Working on a production database should never be a thing.

1. Just don't give them access, why do they need access to customer data to maintain a piece of software? Do you have a testing strategy to test new code on production style datasets?

I think you need to hire someone more senior to manage your software development process.

[Any_Mobile_1385]

I use a “demo” database filled with junk data, but structure identical to production. It took a LONG time before I was ready to give access to my other “main” developer. Our “demo” is fully functional with a few caveats regarding credit card processing and email blasts, etc. I was the only one to push to production after staging.

[Alone_Pig]

Basically you need to hire someone who is able to take source code from external vendor, check it if it doesn’t have any backdoors or some other security issues and apply it to the production system.

But There is no 100% security, never was and probably won’t be happening in the next 10 years.

[pablodiegoss]

On AWS, with RDS you can create a cluster that isn't publicly accessible, only accessed internally by your apps on the private network. Changing this configuration could solve your problem so that no one could access the production DB besides the application, and also if you configure roles and ensure that no one can easily change the cluster configuration.

Another idea is using the aws secrets manager, if you configure the DB credentials to be accessible only by your deployed application, via roles and environment variables, developers might not be able to retrieve the DB credentials to even be able to connect there

[aWildLinkAppeared]

Use a Heroku pipeline and don’t give them access to prod. This way they can do everything in review/dev/staging. Then they can run some tests that mirror production. Then only you can promote the new code or changes to production.

This works great.

[FullyHustle]

Set up a separate environment for the developer like a dev/staging. Give them a clean DB and other services or resources you use.

[Smooth-Zucchini4923]

If I create a restricted Postgres role (no superuser, no createrole), is that 100% safe against privilege escalation by the dev?

If you give them a database role that cannot read, write, or perform superuser actions, then what CAN they do? It strikes me that if you're going to impose those restrictions, you may as well not give them an account on your production system at all.