Oracle OCI stellt verschiedene Arten von Loginformationen zur Verfügung. Diese Loginformationen können in der OCI Console online per Source ausgewertet werden als auch über das OCI LogAnalytics aggregiert und analysiert werden. Informationen zum hier nicht weiter betrachteten LogAnalytics: https://www.oracle.com/cloud/systems-management/log-analytics.html bzw. die technische Dokumentation: https://docs.oracle.com/en/cloud/paas/management-cloud/logcs/get-started-oracle-log-analytics.html
Viele Kunden nutzen bereits andere Systeme für die Auswertung Security relevanter Ereingisse wie z.B. Splunk. Dazu könnten OCI-Seitig folgende Logquellen interessant sein:
- OCI Audit Log: das Log ist per default aktiv und nicht abschaltbar; Das Auditlog enthält alle OCI API Aufrufe, d.h. sowohl Aufrufe/Nutzung des API als auch die Nutzung der UI.
z.B (Ausschnitt aus einem Eintrag): “message”: “ChangePassword succeeded” “principalId”: “ocid1.user.oc1..aaaaaaaaw2jb3uwkk32cbsa4nhtkgkwl62gmmed35o7x4rgwuz”, “principalName”: “testLocal3”,
mehr Informationen: https://docs.oracle.com/en-us/iaas/Content/Logging/Concepts/audit_logs.htm - Service Logs:
- OCI VCN Flow Log: Pro Subnetz kann das Netzwerklogging aktiviert werden um zu sehen welche Pakete im Subnetz des Kunden fliessen. Z.B.
:2 172.16.2.139 172.16.1.107 73 89 11 102 349 1557424462 1557424510 ALLOW OK
2 172.16.2.145 172.16.2.179 82 64 13 112 441 1557424462 1557424486 REJECT OK - OCI Site-to-Site VPN: Für die VPNv2 Verbindungen
- OCI Access Logs: verschiedene Services wie das API Gateway liefern nach Aktivierung Access Logs
- und viele weitere, siehe: https://docs.oracle.com/en-us/iaas/Content/Logging/Concepts/service_logs.htm
- OCI VCN Flow Log: Pro Subnetz kann das Netzwerklogging aktiviert werden um zu sehen welche Pakete im Subnetz des Kunden fliessen. Z.B.
- neben den OCI Logs können auch Logs der Services, z.B. die DB Auditlogs angezapft werden oder eigene Logs definiert werden
https://docs.oracle.com/en-us/iaas/Content/Logging/Concepts/custom_logs.htm
Diese Logs können nun einzeln spezifiziert und in dem gleichen Schritt optional auch gefiltert werden. Das Ergebnis kann dann in verschiedenen Arten verarbeitet oder exportiert werden. Für den Fall Splunk sind folgende Wege für die meisten Kunden relevant:
- asynchron über OCI Object Store. In diesem Fall werden die Logs in die in ein File in das angegebene Bucket geschrieben. Splunk holt die Informationen dort ab.
Um auf das Schreiben des Logfiles intime reagieren zu können ist eine Auswertung des Events via Functions möglich. Eine Beschriebung findet sich hier für VCN Files: https://blogs.oracle.com/cloud-infrastructure/post/how-to-ingest-vcn-flow-logs-into-splunk
bzw. hier für die Integration der Findings des Cloud Security Posture Management der OCI, Cloud Guard: https://www.ateam-oracle.com/push-cloud-guard-problems-to-splunk-hec-with-oci-sdk - synchron über OCI Streaming. Hier wird Splunk über einen Stream mit den Loginformationen versorgt.
Eine Anleitung findet sich hier: https://docs.oracle.com/en/solutions/logs-stream-splunk/index.html
Für das Streaming wird ein auf der Splunk Siete ein sogenanntes Splunk PlugIn benötigt, dass es über einen MOS Request von Oracle zum Download angeboten wird; auf der Splunk Seite ist das Plug-In zwar verzeichnet, aber nicht zum download verfügbar.
Beispiel mit Streaming:
Schrittweise Analyse des Übertrags der gewüschten Daten:
Um den Weg der Daten nach Splunk verfolgen zu können, können die Loginformationen schon in im OCI LogViewer gelistet werden. So ist ersichtlich ob die gewünschten Daten vorhanden sind.
Die Anlayse von Daten im Objectfile, der nächste Schritt, ist trivial. HIermit wird getestet ob die Konfiguration z.B. mit Subcompartments oder gefilterten Events funktioniert. Wird z.B. ein Streaming statt Files eingesetzt, kann der Stream entweder über das UI gesehen werden (letzte Einträge) oder falls im UI keine Informationen verfügbar sind kann ein Stream über das OCI CLI oder Postman eingesehen werden (Beispiele s.u.). Erreicht Splunk dann die Streaming Endpoints sollte einem erfolgreichen Transfer nichts mehr im Wege stehen.
Beispiel zum Zugriff auf den Stream:
CLI: oci streaming stream message get –cursor eyJjdXxxx –stream-id ocid1.stream.oc1.eu-frankfurt-1.amaaaaaaop3lsadasd –endpoint https://cell-1.streaming.eu-frankfurt-1.oci.oraclecloud.com
Postman: GET https://streams.eu-frankfurt-1.streaming.oci.oraclecloud.com/20180418/streams/ocid1.stream.oc1.eu-frankfurt-1.xxxx/messages?cursor=eyJjdXxxx
Monitoring der Funktionalität:
In Splunk sollten regelmässig, wie für alle Quellen, dessen Errorlogs kontrolliert werden. Da der Streaming Client auf der Splunk Seite (das OCI Splunk Plugin) mit sogenannten Group Cursors arbeitet sollte diese Einstellung (Threads oder Partitions je nach Version) zum konfgurierten Stream passen. So wird die Parallelität optimal konfiguriert.
Im Menü von OCI zum Service Connector gibt es den Punkt “Metrics”. Dieser zeigt das Nutzungsverhalten des Servcieconnectors – hier des genutzten Streams – und auch eventuelle Fehler an. Es kann sinnvoll sein hier “Alarme” zu definieren um zeitnah reagieren zu können. Alarme werden in OCI über Notifications/Topics und Subscriptions definiert, siehe https://docs.oracle.com/en-us/iaas/Content/Notification/Concepts/notificationoverview.htm