Are functions a good way of protecting a database?
I am developing a website with a Postgresql back end and I wish to protect the database data & schema.
I have created Postgres function for all required interactions so no SQL is required on the front end.
All I want a user to be able to see are the functions and be able to execute them.
Are functions a good way of protecting a database?
A simple question without a simple answer.
If you want portability: no. It will complicate portability to other Databases
A lot of modern applications use just CRUD operations: (https://en.wikipedia.org/wiki/Create,_read,_update_and_delete)
Yes, functions can add a secure layer to protect data and hide complexity.
My suggestion for this way: use a separate schema for functions and grant execution on that schema:
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA myschema TO myuser;
Related
I want to be able to use the variable names in Redshift which refers to my DB Objects (like schema and table names). Something like...
SET my_schema="schema":
SET my_table="table";
SELECT * from #my_schema.#my_table;
But looks like Redshift doesn't have such feature. Is there any workaround possible to achieve this?
There are a few ways you try to attack this. But first trying to use a database engine for functions beyond querying the database is a waste of horsepower and the road to db lock-in. So I'm going to focus on ways to do this before the database.
The most complete way is to use a front-end system that clients connect to and then this system in turn connects to the db. The one I've used in the past is pgbounce-rr which pools connections to the the db but also allow for modifications to the SQL before being sent on. This will do what you want but you will need a computer to perform this work.
If you use Redshift data-api you could put a Lambda function in series which performs the SQL modifications you desire (but make sure you get your API permissions right). However, I expect it is unlikely that you are looking to move to an API access model.
Many benches support variable substitution and simple replacements in the SQL can be done by the bench. However, this is very dependent on which bench you use and having all users' benches configured correctly.
Bottom line - if you want something to modify your SQL do if before it goes to Redshift.
I want to limit the type and scope of all operations that a user can make in order to protect the database.
How can I tell PostgreSQL that a given user is only allowed the execution of stored procedures, and not to read or write tables directly?
If there are better ways to do this I am also opened to suggestions :)
Thanks!
I am wondering if anyone knows a command to create a read-only user for all schemas and tables in a postgres DB. I have found ways to do it for specific tables and specific schemas but not across the board (we have many schemas and I would rather not run the command 60+ times). Thanks in advance
There is no simple way to do that in PostgreSQL.
What you should do is create a role that has read access to all tables (and yes, you'll have to run at least one GRANT statement per schema) and grant that role to all login users that need read access.
That way you have to do the work only once, and dropping the user becomes so much easier.
Relational Databases are able to set permissions for users to insert, update, delete, etc by schema or table (e.g. I can allow bob CRUD access to table someschema.XYZ but only allow read access to someschema.FooBar and no access to schema ABC)
Graph databases do not have predefined schemas but have an arbitrary set of node types. Is it possible to set restrictions on a graph database for what a user can access like you do for relational databases or does this granularity not exist in graph databases due to it's nature?
I am specifically looking at Neo4j but if this exists in other examples, then I would like to know.
Neo4j allows you to implement your own SecurityRules. A SecurityRule acts similar to a servlet filter, every request is evaluated with the SecurityRule.
However you have to implement the logic on your own which gives great flexibility but might also cause a serious amount of work.
I'd like to see a transactional history of operations that have been executed on one of my tables, and which user executed each operation. Does PostgreSQL offer any tools that allow that kind of historical lookup?
Maybe others can inform you if there are any good utilities that handle this for you, but I know triggers can be used to create audit logs of tables. If you need more complex logic for how and what you want to audit you can also write procedural functions and incorporate them in your triggers. Example: Postgres trigger function
See this link: http://wiki.postgresql.org/wiki/Audit_trigger_91plus