Mitigate public Oracle DB Link

What are you trying to mitigate?

Using SSL just encrypts the traffic, it doesn't mitigate any security issues.  Typically what you are trying to mitigate here is access to data.

Converting from public to private is simply a matter of dropping the public database link and then creating it in all the schemas that need to access it.  As long as you use the same name, there shouldn't be any issues.  Again, depending on what you are trying to mitigate, this could solve the issue or not.  If the link connects to a common user and you are trying to mitigate data access, this doesn't solve it.

Depending on what you are trying to mitigate and the auditors, you can leave them as public links as long as the connect using CONNECT TO CURRENT_USER.  Then the data access is controlled by individual privileges on the target side and that usually satisfies the auditors.

If you are trying to mitigate objects owned by PUBLIC, then just creating the private links does the trick.  You still have an issue with data access (as far as auditors are concerned), but you won't have public links.

rather than the term 'mitigate', I should use the term 'enhance the security posture' such as converting it fr public to private

Security in what sense?  Encrypting network traffic or securing data access (and/or auditing) or something else.  What is your real end goal?

If the public link connects to a specific user, and you convert all of them to private links that all connect to the same common user, you have done nothing.

If the public link connects as current user, then converting to a private link doesn't do anything either.  It could prevent some users from accessing the link, but if they don't have any access on the target database they can't get there anyway.

The thread you link to talks about security in that with private links only the link owners have access to the link.  This is access.  If using current user links (as the thread suggests), I don't see where this gets you more security.  If the user doesn't have a login on the target database or doesn't have access to an object it doesn't give them anything extra public or private.

Security on the basis of granting on a 'need-to' basis.

in that link, why is it quoted that private is more secure than public n public more secure than global?

or perhaps share what are the recommended setups that will meet audit requiremts

> using the link for?
For users in a lower-trust system to perform read+write to the
Oracle DB running in a high-trust/critical system.


Are the following comments from the above link a good practice?

Fixed User Database Links
======================
A benefit of a fixed user link is that it connects a user in a primary database to a remote database with the security context of the user specified in the connect string. For example, local user joe can create a public database link in joe's schema that specifies the fixed user scott with password tiger. If jane uses the fixed user link in a query, then jane is the user on the local database, but she connects to the remote database as scott/tiger. Fixed user links have a username and password associated with the connect string. The username and password are stored with other link information in data dictionary tables.

Current User Database Links
========================
Current user database links make use of a global user. A global user must be authenticated by an X.509 certificate or a password, and be a user on both databases involved in the link. The user invoking the CURRENT_USER link does not have to be a global user. For example, if jane is authenticated (not as a global user) by password to the Accounts Payable database, she can access a stored procedure to retrieve data from the hq database. The procedure uses a current user database link, which connects her to hq as global user scott. User scott is a global user and authenticated through a certificate over SSL, but jane is not.