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.
Related
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).
I've been testing a software I helped develop, which resides on a 32-bit application server. It is to connect to a 64-bit database server, which uses IBM DB2 v10.1.
I was the one to setup the DB2, but I'm pretty sure it has since been modified; I am no longer able to connect using the Username/Password: db2admin/db2admin.
Instead, I have to use Administrator/p#ssw0rd. I do not recall creating that user myself - it is a local account on the computer itself - but from my ODBC tests, it can connect to the database.
However, it appears it doesn't have any privileges. My attempts to see where this 'user' is using Data Studio 3.2.0 have failed, though given my experience (lack thereof) with DB2, this is not surprising.
My concerns are two-fold:
To find where this 'Administrator' resides.
And to modify its privileges to replicate that of db2admin, which, iirc, is a Database Administrator.
My attempts to research the problem on the net was met with failure - either the so called solution doesn't work, or it is too complex for me to understand if it did work (it didn't).
I have tried the following:
Modifying the Database directly via Data Studio 3.2.0; Right clicking on the database, selecting Manage Privileges, and checking everything I could find - note that I did not find any 'Administrator', just a 'PUBLIC', 'DB2ADMIN', 'SYSDEBUG'. Also, it doesn't seem to save.
'Select * from SYSCAT.DBAUTH where GRANTEE = 'Administrator'; This produces a long list of tables, I guess. Don't know what to do with them, but if I replace 'Administrator' with 'db2admin', I get exactly the same result.
Creating a new user called 'Administrator' using Data Studio;
Please, I'd like some light shed on this; DB2 is an extremely frustrating database. I'm using DB2 v10.1, Data Studio 3.2.0, and Windows Server 2008.
DB2 authentication relies on an external mechanism, such as OS security or ldap. If your case, it seems it is Windows security.
DB2 authorisation is internal, so any grant is inside the database, with some exceptions.
There are several authorities in DB2, some at instance level and other at database level. Those at database level, you can find them inside the database, by querying the catalog, and they can be assigned to a user or to a group.
The other authorities, at instance level, are associated to a OS group (external mechanism)
The highest authority in a database is DBADM, and the highest authority at an instance level is SYSADM. Every user in the associated group to SYSAMD becomes automatically DBADM in all database inside the instance.
Well, this is just a short explanation of how DB2 security is. It means that you 'Administrator' user has the 'connect' privilege (sometime 'connect' privilege is public, it means, any user can connect), but it does not have any other privilege, nor authority.
Finally, in Windows environment, there is another security layer, that associates users in two groups DB2ADMNS and DB2USERS. For more information check this link http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.sec.doc/doc/c0023391.html
Well, I solved it, but it remains to be seen why this occurred in the first place;
After creating the user 'Administrator', I modified the privilege by checking everything. It seemed to work.
you have to GRANT a SELECT on the TABLE to the USER.
GRANT SELECT, INSERT ON mytable TO USER peter
"db2 is not frustrating!"
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.
...and how should those permissions be granted. I work in a large IT dept with 70+ applications, some in SQL server and most in oracle. Each system has a prod, QA and Dev instance. We (I'm a developer) have readonly access to prod/qa, which I'm fine with. In SQL server development instances devs are given db_owner, which works totally fine. The debate is over what permissions I should have in the DEV oracle databases.
I recognize that best case would be to have each dev run their own instance on their workstation for development, but because of the size of the databases this has not been considered an option.
I'm also interested in HOW these permissions should be applied. In oracle permissions granted via a role are not active during PL/SQL execution so roles (even the "dba" role) are not useful. That leaves using a built in account (system) or creating dozens of users accross dozens of database and directly granting dozens of permissions to each.
In my mind just letting the devs login as system is making a lot of sense, but our DBAs claim that's a bad idea.
We used to just give developers access to the application account. This works for small shops but rapidly gets out of hand as the number of developers increase.
Here's what we do now:
the Application has it's own account (aka schema).
Developers have their own accounts
Data resides in the application schema
We have an ant build script to build code into whatever schema you want.
code includes views, packages, objects etc..
the build script includes a step to run a stored procedure to grant explicit rights to developers to the application data
Developers make changes in their own schema
When happy they check that into subversion
The Application's dev schema is built from the new subversion build.
Developers can check out and rebuild their own environments.
DDL changes to table structures are done via the DBA
these can be scripted as well
This has the benefit of ensure any front end application is not broken by database developers constantly rebuilding everything.
I assume that there are a relatively small number of application accounts that own the actual objects. So one or more logical applications are comprised of tables owned by a particular Oracle user. This would not by SYSTEM or SYS, it would not be any of the accounts that Oracle the company delivers. It would be an account that your DBAs created. If you are familiar with the Oracle sample schemas, the HR user owns all the tables in the HR schema which comprise the back end for an HR application.
Starting from the principle of "the simplest thing that could possibly work," my first thought would be to see if the developers could log in directly to those application accounts. This isn't the securest possible configuration, and you are opening up the possibility that a developer accidentally or intentionally does some damage that may be difficult to track or easily resolve. But it can work reasonably well depending on the organization. Privilege management is trivial-- the application owner account already has all the privileges it needs most likely.
The next step up would be giving every developer a separate schema to develop in, presumably in conjunction with a load of public synonyms in the database and an absence of schema qualifiers in the application code, so that any object created in the developer's schema automatically overrides the shared version of that object. This provides much better isolation. Permissions are generally granted by either creating scripts that contain all the grants a developer needs or by creating a script that copies all the privileges from a "known good" account to the new account. Neither is particularly difficult to write-- you just have to make sure that all the developers end up with the same set of privileges, which is generally just another script that gets run when a new privilege is granted.
If you are developing stored PL/SQL objects, then the schema owning those objects needs, as you mentioned, explicit grants on the objects used. If you have a single 'data' schema but are developing code in your own individual schemas then you should get the ability to grant access on the data schema objects to your development schemas. Normally I'd expect username/password for the data schema.
In regards to system privileges (eg CREATE), I'd expect CREATE TABLE, TYPE, VIEW, PROCEDURE TRIGGER, SYNONYM. Others may be appropriate (eg CONTEXT) depending on what you do. The DBA may rule out CREATE DIRECTORY as that could be damaging if mis-used. Ditto for privileges with ANY in them (eg SELECT ANY TABLE, DELETE ANY TABLE)
For performance tuning / system monitoring, on a dev database SELECT_CATALOG_ROLE is good. If the DBA is risk-averse, you may have to negotiate grants on individual views. Go through the REFERENCE guide for your version and ask for any you may use.
One of the DBA's jobs is to manage user privileges. I don't think system is a good idea for a few reasons, not the least being the ability to drop an entire schema which I am sure you don't want. That being said, I think it is perfectly fine to grant all to your users and let the DBAs manage these permissions no matter how many dozens of accounts there may be. Most DBAs will have scripts they can use to manage these permissions anyway.
Listen to your DBAs, they generally know what they are talking about.
If it's just a dev instance; i'd have all users have individual accounts added to the admin role. That way you can still log activity on a per-user basis; but give the devs enough breathing room to do their thing.
My group supports about 100 apps with about 20 of them having their own Oracle schema. We have gone down the road of every developer has the password to the schema and it is convenient. However, in hindsight I would recommend that each developer use their own Oracle account to develop. The main reason is auditing.
I recognize that best case would be to
have each dev run their own instance
on their workstation for development,
but because of the size of the
databases this has not been considered
an option.
Is there a way to deal with this, maybe by reducing the amount of data in your personal copies? This seems like the ideal solution, since it would allow you to make any changes you need. Then you could submit them to the DBA when you're ready, and have him update the shared development server.
What are the differences between the Oracle SYS and SYSTEM built in accounts?
Edit: Apart from 3 letters!
SYS owns the oracle data dictionary. Every object in the database (tables, views, packages, procedures, etc. ) all have a single owner. For the database dictionary, and a whole lot of special tables (performance views and the like) are all owned by the SYS user.
The SYSTEM user is supposed to be the master DBA user, with access to all of these object. This reflects an early, and long time, Oracle security design philosophy. You build the application using one user, then create a second with access (select, update, delete) but not drop privileges. This gives you a "super-user" access to your schema without being able to destroy it accidentally. Over the years, thing have been added to the SYSTEM account that may have needed to be in the SYS account. But very few people want to give out access to their SYS account if they don't have to.
SYS can connect AS SYSDBA, SYSTEM cannot.
SYSDBA privilege is required to perform certain administrative tasks, like CREATE DATABASEand DROP DATABASE, and query any tables despite GRANT'ed permissions on them.
In fact, whenever you connect as SYSDBA, you become a SYS.