protect accidental termination of OCI Compute instance and secure your data

 It is very important for any organizations to protect its resources against accidental termination and especially when it comes to compute instance. You not only secure your data but you are also ensuring that the services which are running on the compute instance are always up. In the cloud world, creation and maintenance of the resources have been made much easier. Within a click of button, one can create the resources and even terminate them easily. What if, unintentionally someone terminate the instance which was not supposed to be? All Data Gone????

Normally, when we create users in OCI, we give them some privileges through which they perform some tasks. These privileges comes through Policies. As a best practice, we should always follow the principle of giving least privileges. If the privileges are wide open, then in that case users can easily go and terminate an instance accidentally.

In the above case, user having the privileges can easily terminate, stop, reboot the instance. Basically it can perform all the instance management operations. The instance management operations are basically categorized as 

In this post, the user should not have privileges to terminate an instance. In my instance, i have a group REST_USERS and all the users except Tenancy Administrator are part of this group. Thus my policy will be like

Allow group REST_USERS to manage instance-family in tenancy

 where request.permission!='INSTANCE_DELETE'

Allow group REST_USERS to use volume-family in tenancy

Allow group REST_USERS to use virtual-network-family in tenancy

Now if the user tries to terminate the instance, he/she will get the error as below

This is how we can protect our compute instance from getting accidentally terminated. In this case, only the tenancy administrator can terminate an instance The other instance management operations such as Start, Stop, Reboot can be performed by other users and thus it is not going to hamper the daily operations.

I hope this post will help someone. Till, then happy learning cloud

Golden gate Extract is not starting because of ORA-28374: typed master key not found in wallet

We had an issue where all of a sudden after the DB bounce, extract was not coming up with errors ORA-28374: typed master key not found in wallet. This GG environment was acting a downstream mining and redo logs were coming from Source SaaS(Oracle Fusion). The first thing i did, is to go through the alert log. Found the trace file from the alert log and got the below warnings being reported.

kcrf_decrypt_redokey: dumping redo key 1344d0d94ad0a8347de7dda9e709dbff ======>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DB is looking for this key as per trace file

kcrf_decrypt_redokey: dumping mkloc 1 mkid in log header 2f4219da61094fefbfc613ba4b51407a ======>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DB is looking for this key as per trace file

kcrf_decrypt_redokey: dumping active kcbtsemkloc 1, kcbtsemkid 8655dd60aa2c4f6ebfd407dbecfd5e5b ======>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DB is looking for this key as per trace file

Now from the information above, how can we know which keys does the DB is referring to

How we can decrypt it:-

SQL> select utl_raw.cast_to_varchar2( utl_encode.base64_encode('01'||'2f4219da61094fefbfc613ba4b51407a')) from dual;

UTL_RAW.CAST_TO_VARCHAR2(UTL_ENCODE.BASE64_ENCODE('01'||'2F4219DA61094FEFBFC613B

--------------------------------------------------------------------------------

AS9CGdphCU/vv8YTuktRQHo=

Run the below command to check existing keys present in wallet

SQL> select key_id from v$encryption_keys;

KEY_ID

------------------------------------------------------------------------------

ARBCnkv3lU/qv7MNJhC2AeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AYZV3WCqLE9uv9QH2+z9XlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Thus, we can see that one key is missing and this is the reason why extract is not coming up. So, we got the keys from Source and imported it to our target database using the below command

ADMINISTER KEY MANAGEMENT IMPORT KEYS WITH SECRET "***" FROM 'path where key file have been placed' FORCE KEYSTORE IDENTIFIED BY "YOUR DB WALLET PASSWORD" with backup;

Upon importing the key to our wallet, we were able to successfully start the extract

Hope it helps someone

Monitor oci compute instance using free audit service and perform analysis on a systematic way

There is a service in OCI known as Audit service which records calls to all supported Oracle Cloud Infrastructure public application programming interface (API) endpoints as log events. By default, Audit logs are retained for 365 days. Retention period is a tenancy-level setting. The value of the retention period setting affects all regions and all compartments. The retention period cannot be changed. Currently, all services support logging by Audit.

Information in the logs includes the following:

Time the API activity occurred

Source of the activity

Target of the activity

Type of action

Type of response

In this post, we will stop the instance and through audit service, we will find the details on who did what. 

We will open the compute instance and choose the Audit option

Click on filter options

Once we click on apply, the results will be displayed in below format

Now filter with "POST" 

Click on the drop down option on the right most side,

Expand the "StatusChange" option

Now to know who did it, click on the identity option

Thus in an environment, where you have many users accessing console and doing the activities, the OCI Audit Service helps us to know the details in a much granular manner. I hope this post will be helpful for someone. Till then, happy learning cloud