- Issue created by @cemproduction
- π¬π§United Kingdom alexpott πͺπΊπ
@cemproduction the better way to do this is to only give the developer access to a database that does not have production data in. Drush has sanitise commands to do this but my preferred way to do this is to not have databases going anywhere and have developers install the site from configuration and use the default content module to provide any content that's needed.
- π·πΊRussia a.sinitsa
I have the same problem too. Unfortunately, there is no way to prevent access to the prod server for developers and engineers
Use pubkey_encrpyt to encrypt the data, create a second role, e.g. "dev" and give full access to that role. Since the encrypted data is not tied to "dev" role, he can do all the maintenance without access to the sensitive data.
- π·πΊRussia a.sinitsa
Thanks for the solution. But this option is not suitable because with ssh access you can easily log in as any user with any role.
- π―π΅Japan ptmkenny
With SSH access to the server, I don't think there's much you can do to restrict access to the key; even with something like the Lockr module β , you can still poke around when you have command-line access.
If developers must have production access, perhaps a next-best solution is to log all ssh sessions and audit what the developer is doing?
- Status changed to Closed: duplicate
27 days ago 12:27am 19 October 2024 - π―π΅Japan ptmkenny
When π Fail gracefully when decrypt/encrypt fails Active is committed, you will be able to delete the key and decryption will fail but there will be no WSOD.
So I'm going to close this in favor of π Fail gracefully when decrypt/encrypt fails Active .