Security of Your Logs in Logging Analytics

Oracle Logging Analytics provides secure data transfer and storage for your logs. The service leverages the various security features that are inherently available in Oracle Cloud Infrastructure (OCI) and extends them to secure your logs.

Security of Logs In-Transit

When your data is in transit, all the communication from outside the OCI to inside OCI happens over https protocol which has encryption layer enabled. This ensures sensitive data protection from MitM phishing attacks.

Security of Logs At-Rest

The following features ensure that your logs remain safe while at rest in OCI, be it active or archived data:

  • AES-256 server-side encryption: OCI always encrypts and decrypts all block volumes, boot volumes, volume backups, and object storage on server-side by using the Advanced Encryption Standard (AES) algorithm with 256-bit encryption. See Object Storage Encryption and Block Volume Encryption in Oracle Cloud Infrastructure Documentation.

    Encryption is enabled by default and cannot be turned off. By default, Oracle manages the master encryption key.

  • AES/GCM 256-bit client-side encryption: The OCI SDK for Python and SDK for Java support client-side encryption, which encrypts your data on the client side before storing it locally or using it with other OCI services. See Oracle Cloud Infrastructure Documentation: Client Side Encryption.
  • Customer-provided encryption keys: Oracle Logging Analytics enables you to use your own encryption key that you have stored in OCI Vault to encrypt your logs. After you place your request for the encryption using your own keys by contacting Oracle Support, based on the size of your log data, Oracle creates a dedicated block volume or object storage bucket. This ensures that your data is separated and can be selectively encrypted.

    When you enable the feature, you can select to use your encryption key on block volumes for active data or object storage for archival data. After the feature is enabled, your older log data which resides in a different location will continue to be encrypted using OCI managed encryption keys.

    Using OCI Vault, you can manage vaults, keys and secrets. From time to time, you can also rotate the master encryption key. See Oracle Cloud Infrastructure Documentation: Managing Keys.

    To check the current master encryption key used, call the following GET REST API:

    /namespaces/{namespaceName}/storage/encryptionKeyInfo

    To enable the encryption with specific master encryption key, call the following POST REST API:

    /namespaces/{namespaceName}/storage/actions/assignEncryptionKey

    Ensure that the required IAM policy statements are created for key management, accessing data from your dedicated resources, and allowing Oracle Logging Analytics to use your encryption key on your logs. See Allow the Use of Customer-Provided Keys for Encrypting Logs.

    To disable or re-enable the feature, contact Oracle Support.

Allow the Use of Customer-Provided Keys for Encrypting Logs

Oracle Logging Analytics enables you to use your own encryption key that you have stored in OCI Vault to encrypt your logs. After you place your request for the encryption using your own keys by contacting Oracle Support, based on the size of your log data, Oracle creates a dedicated block volume or object storage bucket. This ensures that your data is separated and can be selectively encrypted.

To successfully use your keys for encrypting the log data, you must first provide the following permissions for the various services to access and use the keys:

  1. Define the Logging Analytics tenancy where the data is stored, for example, logan_tenancy.

  2. Define a dynamic group of resources which can be used for performing encryption operations, for example, encr_app_tier_group_of_logan.

  3. Allow the service Block Storage to use your encryption keys and vaults stored in a specific compartment in your tenancy, for example, encryptionTier compartment.

  4. Allow service Object Storage to use your encryption keys and vaults stored in a specific compartment in your tenancy, for example, encryptionTier compartment.

  5. Allow the dynamic group defined in step 2 to associate your encryption keys with volumes.

  6. Allow the dynamic group defined in step 2 to associate your encryption keys with volume-backups.

  7. Allow the dynamic group defined in step 2 to use key delegation.

  8. Allow the dynamic group defined in step 2 to associate your encryption keys with Object Storage buckets.

  9. Allow the dynamic group defined in step 2 to have READ access to your encryption keys.

  10. Allow the dynamic group defined in step 2 to have READ access to the vaults.

The following example IAM policy statements map to the above definitions:

Define tenancy logan_tenancy as ocid1.tenancy.oc1..aaaaaaaa...
Define dynamic-group encr_app_tier_group_of_logan as ocid1.dynamicgroup.oc1..aaaaaaaa...
allow service blockstorage to use keys in compartment encryptionTier
allow service objectstorage to use keys in compartment encryptionTier
Admit dynamic-group encr_app_tier_group_of_logan of tenancy logan_tenancy to associate keys in compartment encryptionTier with volumes in tenancy logan_tenancy
Admit dynamic-group encr_app_tier_group_of_logan of tenancy logan_tenancy to associate keys in compartment encryptionTier with volume-backups in tenancy logan_tenancy
Admit dynamic-group encr_app_tier_group_of_logan of tenancy logan_tenancy to use key-delegate in compartment encryptionTier
Admit dynamic-group encr_app_tier_group_of_logan of tenancy logan_tenancy to associate keys in compartment encryptionTier with buckets in tenancy logan_tenancy
Admit dynamic-group encr_app_tier_group_of_logan of tenancy logan_tenancy to read keys in compartment encryptionTier
Admit dynamic-group encr_app_tier_group_of_logan of tenancy logan_tenancy to read vaults in compartment encryptionTier

Make sure to replace logan_tenancy, encr_app_tier_group_of_logan, encryptionTier, and the example OCIDs in the above IAM policy statements with the actual values.