We are planning to enable ORACLE TDE in our database for all the tablespaces.
I would like to know what impact it would have on my shell and Perl scripts that run on a client machine. The shell and Perl have username and passwords to connect and execute queries and procedures. Would it not work if I turn on TDE? will I have to use wallets instead of username and password once I enabled TDE?
TDE should be transparent (hence the "T") to applications that are accessing the data. The use of wallets etc is more within the scope of the DBA operations for opening/closing the database, and encrypting the data.
Normal application queries should be unimpacted, and user names and passwords are similarly not affected.
There is a very good FAQ on TDE here
http://www.oracle.com/technetwork/database/security/tde-faq-093689.html
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.
This has gotten so bad I have to ask if there is a newer feature in ssis (like maybe vs 2017) that handles oracle and teradata passwords. We work in a secure organization. They don't want us leaving passwords in the packages for security reasons (I understand that ssis encrypts passwords it knows are passwords in the .dtsx file) so we have to clear them when development is done. We also use what might be called a password vault for oracle and teradata passwords for our run time jobs which makes the transition from client development to batch job difficult. Can anyone tell me why it would ever be useful for ssis to attempt a login to Oracle or Teradata when ssis knows the password it has is null or blanks? A more paranoid part of me might think that Microsoft, with Windows Auth, is trying to drive their users off of Oracle or Teradata. So is there some ssis job level parameter I can set that instructs ssis not to attempt an oracle or teradata access for metadata unless it has a password? Some of our jobs access oracle or teradata in 5 or 10 different places, running in there to set Work Offline or Delay Validation for each one of those accesses is difficult. And I don't want to be told to set Oracle and Teradata to use Windows Auth (if that's even possible). I don't control that and I need something that I, as an etl developer, control. I can't believe SSIS competes with products like Datastage with the situation concerning Oracle and Teradata passwords being so bad.
We are connecting to Oracle using KornShell (ksh) scripts, which use SQL*Plus to connect to Oracle. The Oracle database is on the same Solaris box. Currently, we are storing Oracle user id and password (plain text) in a file in the .ssh folder of the connecting user, with 400 permission bits.
The DBAs are objecting to this way of working, citing the fact that we are using plain text password for authentication. When we offered that we would encode the password using base64, they still did not like the idea, citing that we would still decrypt the password in the shell script and transmit the password over network.
Now, I want to understand this-
I have been reading that Oracle encrypts/hashes the password string, before transmitting it. I can not find the reference right now though, however, I still want to confirm my understanding. Is it really like this? We are on 11g r2, would that make a difference?
Would I be able to login to SQL*Plus without decrypting the password hash? e.g., DBAs set a password, pass on the hash to me. I put that in a file, and supply to SQL*Plus as a parameter. Is there some way by which this kind of authentication work? I know some tools do allow that, if you encode using their tool, they are able to decrypt the value and use it for authentication. Does Oracle?
Help me fellas.
Its been a while since doing this (and I don't have a linux box handy atm), but you can try this to hide details from ps:
echo password | sqlplus -s username#database #myscript.sql
Note that -s is silent mode for sqlplus. I believe you can also put the password in a "protected" file (I use the term loosely, but set bits to 400) and cat the file, piping to sqlplus as above.
Edit:
If the DBAs are really concerned with passwords, then how about using NO passwords. You can try OS authentication, but you need some setup first. For example:
--in Oracle, create new user
create user ops$batch_user IDENTIFIED EXTERNALLY;
grant connect to ops$batch_user;
-- in Unix (login as batch_user, or use su command)
export ORACLE_HOME=/app/oracle/product/11.2
export PATH=$PATH:$ORACLE_HOME/bin
export ORACLE_SID=DEV
sqlplus /
Note that no passwords are used since the user is authenticated by the os. This is less complicated than Oracle wallet imo, but not perfect either.
How exactly are you connecting to the db? If you use sqlplus user/password#database from your commandline/script then you indeeed have a problem. The reason is, that you can easily see the password with the ps command.
Obfuscating it with Base64 is not really an encryption, because Base64 is a known algorithm for transfering binary data over the wire. This might baffle some, but certainly is not a safe way of sending a password.
What I do in this case, to avoid the password being shown int he process list, is that I write the password to a textfile with read only permission for the local user. Then I run sqlplus with nohup or in the background sqlplus user#db < pwdfile and immediately delete the file again.
You can use Oracle Wallets for DB authentication.
Example of tuning may be found here.
How can I execute 'conn / as sysdba' using jsp.
Using
PreparedStatement stmt = conn.prepareStatement(sql);
shows java.sql.SQLException: SQL string is not Query?
How can I do it using jsp?
conn is a SQL*Plus command, not a SQL statement. So it can only be used in SQL*Plus (or another client tool that happens to have some support for SQL*Plus commands). You can't use it via JDBC.
conn / as sysdba tells SQL*Plus to use operating system authentication to connect to the database as the user SYS with the SYSDBA role enabled. Operating system authentication in this case would require that SQL*Plus was being invoked on the server where the database is installed and that the user was logged in as the operating system user "oracle". It seems exceedingly unlikely that it would be appropriate and/or possible for a JSP page to use operating system authentication like this-- that would, at a minimum, require that the application server that is running your JSP code is installed on the same server that Oracle is installed on and that it is running as the same operating system user as the Oracle database. Neither of those are particularly likely. Connecting to the database as SYS with the SYSDBA role enabled would also be very odd for a JSP page-- it is exceedingly rare that you would want JSP code to be running with those sorts of privileges. Generally, Oracle databases do not allow connections as SYS from anything other than the machine that Oracle is running on because, in general, only a DBA would be logging in with that account and then only to perform a very small set of tasks that actually require that sort of elevated access.
It should be possible to configure Oracle to accept remote connections for the user SYS with the SYSDBA role. And it should be possible to configure the connection string in your JSP code to use the appropriate password for that account. But it would be so exceedingly rare to want to do both, and would open such a substantial security hole, that I would seriously question whether that's really what you want to do. Can you explain a bit more about the problem you're trying to solve?
Yes, sql is the Query, but you need resultQuery = stmt.executeQuery() to save the result.
Also, take a look to the driver connection, the name of the machine where the DB is and the user name and password.
We want to allow DB access (Oracle) to our users only through our own application - let's call it "ourTool.exe", installed locally on the users computers. Currently, the users must provide username/password whenever they start "ourTool". The provided password password gets decrypted and we use username/decrypted-password to finally log in to the Oracle DB. This approach prevents the users from directly accessing our DB using third party tools (SQLplus, Excel, Access, ...) and everything in the DB is guaranteed to have been entered/edited using "ourTool".
Now, one of our clients wants to allow its users "single sign-on" (with SmartCards/Oracle PKI). With this, the user will be able connect to our DB without providing any password every time they start "ourTool". But the same will be true for the potentially dangerous tools like SQLplus, Excel, Access, etc.
Is there a way to prevent this? How can we make sure that every record in our DB is only created/edited/deleted using "ourTool" in this scenario?
Since it's your application and you have control of the source, you can use either password protected database roles or Secure Application Roles that are enabled from ourTool.exe. (see http://www.oracle.com/technology/obe/obe10gdb/security/approles/approles.htm ).
For example, with a password-protected database role, the initial connection would be with only the CREATE SESSION privilege, and then ourTool.exe would issue the SET ROLE with password known only to you. Any other application doesn't have the information to set the role. Obviously, the privileges are granted only to the role and not directly to the user in this configuration.
By default, OCI transmits the calling application EXE name and you can access it by querying v$session:
SELECT program
FROM V$SESSION
, which you can do in an AFTER LOGON trigger.
But this can be easily overriden and should not be relied upon.
I renamed my sqlplus.exe to myTool.exe and after making a connection with myTool.exe
SELECT program
FROM V$SESSION
where username = 'SYSTEM';
Returns:
myTool.exe
So be aware, as Quassnoi said: although usable in some circumstances it's certainly not bullit proof.