No security implementation is complete without monitoring. It is an important validation step to make sure the governance model is functioning. From a governance perspective, two essential services to observe and monitor Oracle Cloud are Cloud Guard and OCI logging/auditing.
Cloud Guard is an Oracle Cloud Infrastructure service that helps customers monitor and maintain a strong security posture on Oracle Cloud. Cloud Guard has three essential elements.
Detector Recipe is a set of rules/checks to identify potential security problems. Oracle has created some baseline detector recipes for services like object storage buckets, compute instances, VCN instances, IAM users and groups, Load balancers, Security lists, network security groups. While you cannot update the recipe rule for Oracle-managed recipes, you can clone Oracle-managed recipes and create new recipes known as user-managed detector recipes.
Some detector recipes check resource configuration, knows as Configuration Detector recipe. For example, check if the storage bucket is public or check if there is a NAT gateway or Internet Gateway created in a VCN. Other detector recipes detect activity like creating a dynamic group or adding a VNIC to the VM.
A Responder Recipe is a set of rules to either remediate the problem detected or send a notification. The default responder recipe does not give an option to remediate every problem. You can, however, address that by invoking functions from events, as shown in the diagram above. You take corrective measures or remediate the problem from the OCI function.
Like detector recipes, there are Oracle-managed responder recipes and customer-managed responder recipes. Customer-managed responder recipes are a clone of Oracle-managed recipes where you can disable some of the responder rules.
A target defines the scope of what Cloud Guard should check. It consists of a list of compartments. When you add a compartment as a target, the Cloud Guard checks all the sub-compartments as well. Thus, targets are where compartments, detector recipes, and responder recipes tie together.
When you bootstrap the tenancy with the CIS landing zone, it enables Cloud Guard service. That, by default, starts monitoring the root compartment and all the child compartments. Cloud guard starts monitoring the tenancy, provides insights into security issues, and provides a tenancy risk score. If you follow the CIS landing zone compartment structure, then the Cloud Guard automatically monitors those compartments. If you create any other compartments, then add those compartments as targets in cloud guard.
The Oracle Cloud Infrastructure Logging service is a highly scalable and fully managed single pane of glass for all the logs in your tenancy. Logging provides access to logs from Oracle Cloud Infrastructure resources. These logs include critical diagnostic information that describes how resources are performing and being accessed.
Use Logging to enable, manage, and search logs. The three kinds of logs are the following:
Audit logs: Logs related to events emitted by the Oracle Cloud Infrastructure Audit service. These logs are available from the Logging Audit page or are searchable on the Search page alongside the rest of your logs.
Service logs: Emitted by OCI native services, such as API Gateway, Events, Functions, Load Balancing, Object Storage, and VCN Flow Logs. Each of these supported services has pre-defined logging categories to enable or disable your respective resources.
Custom logs: Logs that contain diagnostic information from custom applications, other cloud providers, or an on-premises environment. Custom logs can be ingested through the API or by configuring the Unified Monitoring Agent. They are supported in both a virtual machine and a bare metal scenario.
A log is a first-class Oracle Cloud Infrastructure resource that stores and captures log events collected in a given context. For example, if you enable Flow Logs on a subnet, it has its dedicated log. Each log has an OCID and is stored in a log group. A log group is a collection of logs stored in a compartment. Logs and log groups are searchable, actionable, and transportable.
Log groups are logical containers for organizing logs. They are used to define/limit access to logs to a limited group of users. You can create different log groups based on the sensitivity of log data. For example, create three log groups: security log group, Network log group, and Application log group. Then for each one of those log groups, create IAM policies to provide admin users access to read blogs from log groups.
Allow group AppOps to read log-content in compartment logging where target.loggroup.id=’ocid1.loggroup.oc1. .<OCIRegion>..<ApplicationLogGroupUniqueID>
Oracle Cloud Logging Analytics is a cloud solution in Oracle Cloud Infrastructure that lets you index, enrich, aggregate, explore, search, analyze, correlate, visualize and monitor all log data from your applications and system infrastructure.
Oracle Cloud Logging Analytics provides multiple ways of gaining operational insights from your logs. You can:
The interactive visualizations provide several possibilities to slice and dice the data. Use the Cluster feature to reduce millions of log entries down to a small set of interesting log signatures, making it easy for you to review. The Link feature enables you to analyze logs in a transaction or identify anomalous patterns using the grouped view.
This is the last blog in a series of four blogs on the governance model. Links to other blogs are