I have created multiple Databases in Clickhouse and a new User, and now can I restrict that newly created user to be able to access a particular database.
In users.xml in 'user' (near profile, quota...) you could specify optional section
<allow_databases>
<database>default</database>
<database>test</database>
</allow_databases>
If there is no 'allow_databases' section - it means that access to all databases is allowed.
Access to database 'system' is always allowed (because system database is used to process queries).
User could list all databases and tables (using SHOW queries or system tables), even if there is no access.
Database access limits are completely unrelated to 'readonly' settings. There is no possibility to provide full access to one database and readonly access to another.
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.
Taking a course on Oracle database security, I have learned profiles are being created to restrict access of some users to some resources.On the other hand, we have functions and policies, which can restrict users too, but I cannot clear the difference between these two. Why we use profiles while we can create policies for users?
A Profile restricts how much system resource a user is allowed: how many concurrent sessions they can have, how much CPU they can use, etc. We can also use Profiles for password management: how many failed logins they're allowed, how long a password lasts, etc.
So a Profile defines the broad bounds of system usage. It governs hardware and database access.
By "policy" I assume you mean Fine-Grained Access Control. These policies set limits to what a user can see of an individual table: what rows they can see and what columns. So we could.use FGAC policy to allow a manager to see all the details for their direct reports but only certain information for all other employees.
So a Policy applies further restrictions to a table which a user already has access to. Which highlights the missing P from your question.
A Privilege grants a user permission to do a specific thing. By default a user cannot do anything in a database. They can't even connect to it without the CREATE SESSION privilege. There are two levels of Privilege. A System Privilege allows a user to do general activities like create a table, execute any procedure, query the data dictionary, etc. A Table Privilege allows a user to do something with a specific object owned by a different user, such as select from my.employee_table, execute her.string_function, etc.
So you can see how Privileges and FGAC Policies interact. I might grant you select and update on my.employee_table but enforce a policy that only allows you to update records for department 40.
To summarise. There are four levels of user restrictions.
In descending order of breadth:
Profile
System Privilege
Table (i.e. Object) Privilege
FGAC Policy
Note: 12c introduced some called an Audit Policy. Clearly that is relevant to the general topic of Oracle database security but I don't think it's pertinent here.
My question is kind of straightforward and so should be the answer.
Talking about ORACLE databases in SQL Developer, we can create connections to users' schemes.
The connection needs to specify the username and the password, and that allows to access the schema of that user. Below the connection, I usually see all the elements of the schema shown within folders like Tables, Views, Indexes, Packages and so on.
But then I also see the folder Other Users just next to those from above. This folder contains a list of other usernames (different from the one you are currently connecting to). Exploring each of these, you see in turn a schema (like a set of elements as from above).
What is this design about? Are they different users sharing the same schema (tables, views, packages, indexes etc..) but with different grants? When we do that?
Your connection details determines which SCHEMA you will be browsing when you expand the connection tree.
The other users node allows you to browse additional schemas. Your connection user's privileges will determine what you can or can't see in other schemas.
A database object is owned by a single user, or exists in a single schema (which is really the collection of objects owned by a user.) There are no shared objects.
I have created a workspace with APEX, but the password is invalid now.
Then I logged in to the workspace and changed the password. However, the other password for login is not changed.
I am very confused with all these terms in oracle.
I have database username, workspace username, database password, workspace password. Also there is a user manager in the workspace, and these users are different from the other two mentioned. Some of the users can be seen in all_users table, some cannot.
What's the relation between all these kinds of users, and where does this information stored? I have read some material of Oracle, but none mentioned these basic terms.
It is confusing because there are two different (though complimentary) technologies being used here:
1) Oracle Database Server has the concept of database "users" which you can see by querying dba_users and all_users - these are owners of database objects and each automatically gets a schema of the same name. Each of these database users has a password, managed by the database. In the old days we used to provision a separate database user for each end user; nowadays we don't generally. These users are stored in the database data dictionary and are manipulated only using database commands such as CREATE USER and ALTER USER.
2) Oracle Application Express has the concept of "workspaces", each of which may have one or more "users". These users can be ordinary end users, developers or Apex administrators. Each of these users has a password, managed by Apex. These are not related to schemas on the database. These users are stored in the Apex data dictionary, and are manipulated using the Apex admin interface, or via calls to the Apex API (in PL/SQL).
Each apex Workspace is associated with a database schema (= database user) which holds the database objects (e.g. tables, views, etc) needed by the workspace. (Note: a workspace can be associated with more than one database schema).
To make things more confusing, in the default version of Apex that is pre-installed in OracleXE (the free version of the database), the Apex user SYSTEM has the same password as the database SYSTEM user.
By default, Apex applications use the Apex authentication scheme which authenticates users against the Apex data dictionary (as per (2) above). You can, however, use alternative authentication schemes which authenticate users against other repositories (such as LDAP, SSO, or custom schemes).
An application needs to access various Oracle database. Some databases have tables in Schemas, some don't - there's no control over this.
If a database has a schema in use, the applicable won't work unless the user enters a schema. I'd like it to be able determine via a SQL query if a schema is required to access the tables so the user can be alerted to this.
I'm aware of the question - How do I obtain a list of schemas that an Oracle user has access to - but that only tells me what schema's can be accessed, not if use of the schema is required to access tables.
Is there an SQL query to one of the system tables that can do this with that user's rights?
Note: The application only has login credentials and doesn't know any table details.
Hope that's clear. Thanks.
Question is confusing. For most part in Oracle, you can consider LOGIN == USER == SCHEMA. When you login into your database with your user, you are able to see and access all objects in that user's schema.
Objects in other schemas (on same database server) can be accesed by SCHEMA2.TABLE1 if connected user has privileges to acces table (there are different privileges...). As already stated in some comments, you do not need to prefix table if synonym exists. Your user can access even tables on some remote server if exists appropriate database link.