For security reasons i have a heroku project that should access a heroku postgresql database but user can only access some tables.
How can i do this on heroku postgresql?
The only way i can think of doing this is:
creating a web project with a postgresql dev addon. this will create a new db in a HEROKU_COLOR_X url;
creating another web project with another postgresql dev addon multiple times so that this HEROKU_COLOR_* is same as previous HEROKU_COLOR_X;
login in HEROKU_COLOR_X with user_2 (admin) create some tables as user_2 and grant access to user_1 for some tables only.
this will result in same db host (HEROKU_COLOR_X) and 2 user/pass (user_1 for web project access and user_2 for db full access).
.. but is there any better solution?
best,
I'm not sure about your theory but unfortunately, the Heroku Postgres docs state:
You cannot create or modify databases and roles on Heroku Postgres.
The SQL below is for reference only.
I'd love it if this restriction could be changed or worked around as granular permissions are a security essential.
gerryster's answer is no longer accurate as Heroku have now released support for multiple roles https://devcenter.heroku.com/articles/heroku-postgresql-credentials This should cover the OP's use case of restricting access to certain tables.
Related
I'm new to Oracle and I'm currently hardening a database.
It's a good idea to drop SYS and SYSTEM users? normally default accounts are dropped because of security reasons, I can do that on Oracle, or I will break something?
From the documentation (emphasis added):
All databases include the administrative accounts SYS, SYSTEM, and DBSNMP. Administrative accounts are highly privileged accounts, and are needed only by individuals authorized to perform administrative tasks such as starting and stopping the database, managing database memory and storage, creating and managing database users, and so on. You log in to Oracle Enterprise Manager Database Express (EM Express) with SYS or SYSTEM. You assign the passwords for these accounts when you create the database with Oracle Database Configuration Assistant (DBCA). You must not delete or rename these accounts.
And:
All base (underlying) tables and views for the database data dictionary are stored in the SYS schema. These base tables and views are critical for the operation of Oracle Database.
So no, it is not a good idea, and it would destroy your database.
normally default accounts are dropped because of security reasons, I can do that on Oracle, or I will break something?
The first documentation link above also says (emphasis added again):
All databases also include internal accounts, which are automatically created so that individual Oracle Database features or components such as Oracle Application Express can have their own schemas. To protect these accounts from unauthorized access, they are initially locked and their passwords are expired. (A locked account is an account for which login is disabled.) You must not delete internal accounts, and you must not use them to log in to the database.
And it mentions sample schema accounts, which you can choose not to install in the first place, but which could be dropped if required.
The main thing is to secure all accounts, and you should limit any accounts you create to only have the minimum privileges necessary.
You can also read more about this in the database administrator's guide,
It is a very bad idea. I don't think the database will even work without them and doubt that the drop is allowed. Make sure the accounts are safe instead.
I am new to development and learning through lot of youtube videos and oracle documentation. I have a question for which I was not able to find a solution online and was hoping someone could help answer it here..
I want to use oracle free tier cloud based autonomous transactional database and create the rest api on it using the below url as a reference.
https://oracle.github.io/learning-library/developer-library/rest-services-for-adb-appDevLive/workshops/freetier/?lab=secure-endpoints#Task1:SecuringtheRESTEndpoint
However my question is if I create a web app where I can get the user to create account using username and password, what is the best practice to store the data and retrive for auth in the oracle database for auth user.
Is there a credentials table where I can store all the username and password details or should I use a encypted table.
Also, Can someone please help advise how to create sql post method query to retrieve the user creds for validation.
Thank you for all your guidence.
Thank you!
In the database you have a schema - this is the collection of objects -
tables
views
stored procedures
rest apis
these are owned by a USER. A database user and schema in Oracle are largely synonymous and a user will have a password.
You then also have your application. Your application most likely also has users. These are completely different users than what you have in the database.
Now, your application COULD use database authentication, but that's highly not recommended. Why? Because then your application users could also theoretically go directly into the database.
It's not clear by your question if you're asking how to manage database usernames and passwords in general or if you mean in terms of your application.
For your application, we recommend you use either our OAuth2 workflows to secure your REST APIs, or you build your own authentication system...for example you could control access to your APIs in the Oracle Cloud using the API Gateway Service.
For managing passwords in the database, you should most definitely NOT store those in a table somewhere. THe user when they get their password, should securely manage that as they would the password to their online banking system.
The web interface we have would work just fine with online password managers like LastPass, but I'm not personally advocating or saying that would be good for your scenario.
Running SQL to find out someone's password isn't really what we do in Oracle. Either you already know it, or you change the password to something so that you definitely know it.
I've been trying for days but cannot find the answer to this. I am using Oracle Application Express (APEX), someone else setup the initial connection to a "Apex" database in oracle, but I am trying to connect to our production database in oracle. I am making web forms and the web forms are connected to the "Apex" database that was setup already, but I need to connect to our production database so we can create reports from the data entered through the web forms. I need the tables to show up in the create page option from the production database, currently its coming from the apex database, please help.
Create Page View with Tables (from apex)
Thank You so much in Advance!
What is the "production database"? Is it really a different database (than the one you're currently connected to), or is it a user in the same database?
if former:
you could create a database link between those two databases and create synonyms for production users' tables in one of schemas your workspace is assigned to.
another option is to install Apex onto the production database, so that you could use current installation as "development" and then deploy the application into the "production-based" Apex
if latter, you might do the same (i.e. create synonyms, just without the database link), or simply assign the production schema to your workspace
You may be interested to read Mike's response to a question with a similar misunderstanding regarding architecture.
https://community.oracle.com/thread/4135843
Once you have your head wrapped around this, you can consider the parsing schema to your application. This schema defines the table access your application has, in the normal way Oracle handles table privileges.
Then it's up to you to define who has access to what pages, using APEX Authorisation Schemes.
We're installing some Oracle XE servers (the free one) on people's desktops for development use.
What's a good default role to assign to these developers? Since these instances contain scratch data only, data security is not a concern.
If you want the developers to be able to do anything grant the DBA on the development DB. Of course there is a risk with this; if they develop and run the code as themselves they will not address the security needs of the application.
If you want the developers to work with the security context of the application grant them the same roles that the application has in Prod.
So; if you want them to be able to do anything on the Dev instance but still code in the same security context as on Prod, create 2 users for them. The first is there usual users with the same rights as the code will execute under in Prod and the second is a DBA user with teh DBA role.
Its odd to some people who are used to the Windows approach (where a domain admin user reads email, browses the web, etc with domain admin rights) but very familiar to a Unix user who redas email as a low level user but can SUDO if needed.
As a developer all I ask for on dev databases is the SYSTEM password, as well as enough space in some tablespace(s) to create my objects. That gives me enough to get going - I can create my users, grant them the access they need, and get started developing.
I'm developing an application and hosting it on Heroku. For now, I want to use the free shared database solution.
My problem is that I can't access the database.
$ heroku pg:psql
! Cannot ingress to a shared database
I've read elsewhere that I can't connect to shared databases via psql.
I can't seem to find any information on that on Heroku's Dev Center, so this leaves me with the question - how can I edit or change or do anything with my database?
If you're happy to use a beta addon then there is the Heroku Shared PostgreSQL 9.1 addon (https://addons.heroku.com/heroku-shared-postgresql) which will permit you to ingress to your database.
However, any changes to your database are usually best done with scripted migrations (in the Ruby on Rails world) rather than connecting to your database to make changes.
If you're more familiar with mySQL then there are a number of mySQL addons which permit direct access also with normal mySQL tools.