W
enn Ihr diesen Beitrag lest, beschäftigt Euch vermutlich folgende Frage: Wie lassen sich Daten von verschiedenen Microsoft Azure-Services in Splunk einlesen? Angesichts der wachsenden Liste von Azure-Services und verschiedenen Datenzugriffsmethoden kann es etwas unklar sein, welche Daten überhaupt vorhanden sind und wie man diese in Splunk verfügbar machen kann.
In diesem Blogbeitrag will ich näher darauf eingehen, wie Microsoft Azure-Daten von Microsoft verfügbar gemacht werden, wie ihr auf diese Daten zugreifen könnt und mit welchen Out-of-the-Box Splunk Add-Ons ihr diese Daten nutzen könnt. Los geht's.
Wie macht Microsoft Azure-Daten verfügbar?
Microsoft bietet drei Verfahren, um Azure Daten verfügbar zu machen.
Storage-Konten (Storage Accounts)
In Zeiten der Markteinführung von Azure galt dieses Verfahren als der Standard. Grundsätzlich speichert Microsoft die Daten eines Service an einem separaten Speicherort, in einem sogenannten Storage-Konto (Storage Account). Benötigt Ihr also die Ereignis-Logs von virtuellen Computern, findet ihr diese in dem von Euch angegebenen Storage-Konto. Da es sich dabei um einen separaten Service und nicht um eine virtuelle Maschine (VM) handelt, bleiben die VM-Daten auch nach deren Löschung weiterhin erhalten. Auch weil für Speicher-Accounts eigene Sicherheits- und Aufbewahrungsmechanismen gelten. Ohne allzu sehr ins Detail zu gehen, so viel solltet Ihr jedoch wissen: Ein Quell-Service kann gezielt konfiguriert werden, um ausgewählte Daten in ein separates Storage-Konto für das spätere Abrufen auszulagern.
Event Hubs
Da wir gerade über Standards sprechen: Event Hubs sind der neue Standard für die meisten Azure-Services. Ich stelle mir Event Hubs gerne als einen skalierbaren und relativ kurzfristigen "Message Bus" vor. Damit beziehe ich mich auf die Eigenschaft von Azure, Daten auf einen Event Hub auslagern zu können - in der Regel über einen Service mit der Bezeichnung Azure Monitor. Ähnlich der oben vorgestellten Speicher-Account-Methode. Allerdings sind die Daten, die auf einem Event Hub landen, dazu bestimmt, von einem anderen Mechanismus abgerufen zu werden. Tatsächlich weisen Event Hubs eine recht kurze Aufbewahrungszeit für Ereignisse auf. Für gewöhnlich zwischen 24 Stunden und 7 Tagen. Außerdem lassen sich Event Hubs wahlweise hoch- oder herunterskalieren, je nach Last für das Empfangen oder Zustellen von Daten. Hierzu noch ein Hinweis: Wenn Ihr mit den Begriffen Pub/Sub, Kafka, Producer und Consumer irgendwas anfangen könnt, versucht weiterhin in solchen Begrifflichkeiten zu denken. Andernfalls könnt Ihr den letzten Satz einfach ignorieren oder nach diesen Begriffen googeln, falls ihr noch etwas tiefer in die Materie einsteigen wollt.
REST APIs
Das dritte wichtige Verfahren zur Bereistellung von Azure-Daten durch Microsoft sind sogenannte REST APIs. Und von denen gibt es eine ganze Menge. Im Zusammenhang mit Splunk sucht Ihr ja normalerweise nach den "List"-Operationen. Hier findet ihr zum Beispiel alle Operationen für Azure-VMs. Das Microsoft Azure Add-On für Splunk (mehr zu diesem Add-On folgt gleich) verwendet ebenfalls die Operation "List All" (Alle auflisten), um eine Liste aller Ihrer VMs in Azure abzurufen.Diese Informationen könnt Ihr als Entitäten sowohl in Splunk IT Service Intelligence (ITSI) als auch in Splunk Enterprise Security verwenden. Oder Ihr setzt sie zu anderen Datenquellen in Splunk in Beziehung.
Welche Daten sind verfügbar?
Da Ihr jetzt die drei Hauptverahren kennt, wie Microsoft entsprechende Azure-Daten verfügbar macht, möchte ich euch zeigenwelche Daten Euch überhaupt zur Verfügung stehen. Weil es jedoch schier unmöglich ist, eine umfassende statische Liste aller Datenquellen zu erstellen, beschränke ich mich auf einige der beliebtesten und Splunk-zentrierten Quellen.
- Aktivitätsdaten (Activity Data) [REST] or [Event Hub]: Hier wird im Grunde genommen nur erfasst, wer wann was genau getan hat. Meldet Ihr Euch bspw. beim Azure-Portal an und erstellt eine neue VM, wird dieser Vorgang in einem Aktivitäts-Log erfasst.
- Ressourcendaten (Resource Data) [REST]: Diese Datenquelle gibt an, welche Services Ihr verwendet. Am besten stellt Ihr Euch die Aktivitätsdaten als "etwas ist passiert" vor und betrachtet die Ressourcendaten als "etwas ist vorhanden". Dementsprechend lassen sich zum Beispiel alle virtuellen Maschinen (VM), Speicher-Accounts, öffentlichen IP-Adressen usw. als Ressourcen bewerten.
- Authentifizierungsdaten (Authentication Data) [REST] or [Event Hub]: Diese Daten sind ziemlich selbsterklärend. Dennoch möchte ich darauf hinweisen, dass Ihr auch Dinge wie Multi-Faktor-Authentifizierungsdaten, Daten für die Self-Service-Zurücksetzung von Kennwörtern, Daten für bedingte Zugriffsrichtlinien und einen ganzen Satz von Azure Active Directory-Daten abrufen könnt.
- NSG-Flow-Logs [Storage-Konto]: Diese Quelle ist wie ein Netzwerk-Trace. Einschließlich der Quell- und Ziel-IP-Adressen, Ports, Protokolle usw. Weitere Informationen zu diesem Thema findet Ihr in diesem Blogbeitrag.
- Web Application und App Insights [Storage-Konto]: Daten aus Web Applications beinhalten Daten von Webservern (gehostet oder freigegeben) sowie Eure gesamten Webanwendungsdaten. App Insights sind APM-Daten.
- Kosten und Nutzung [REST]: Diese Datenquelle enthält konkrete Informationen darüber, welche Daten Ihr nutzt und was diese Nutzung generell kostet. Diese Daten können auch Empfehlungen zur VM-Reservierung enthalten, um bei Euren VM-Ausgaben bares Geld sparen zu können.
- Warnmeldungen [REST] oder [Event Hub]: Sowohl Service- als auch Sicherheitsbenachrichtigungen stehen als Teil des Aktivitäts-Logs zur Verfügung. Ein Beispiel für eine Servicebenachrichtigung ist der Hinweis auf die Beeinträchtigung eines Service in einer bestimmten Region. Wenn zum Beispiel die Speicherservices in einer von Euch genutzten Region beeinträchtigt sind, werden diese Benachrichtigungen und die dazugehörigen Meldungen verfügbar gemacht. Ein Beispiel für eine Sicherheitsbenachrichtigung wäre dann die von Microsoft versendete Warnung, dass Ihr aktuell nur über einen einzigen Sicherheitsadministrator verfügt.
- Metriken [REST]: Azure stellt eine Fülle von Metriken zur Verfügung. Die vollständige Liste der verfügbaren Metriken von Microsoft könnt Ihr hier abrufen.
Wie kann Splunk auf Azure-Daten zugreifen?
Da Ihr nun wisst, wie Azure-Daten von Microsoft verfügbar gemacht werden und welche Arten von verfügbaren Daten existieren. Wie lassen sich eben diese Daten erfolgreich an Splunk übermitteln? Die einfache Antwort lautet: Add-Ons. Die beiden wichtigsten Add-Ons sind das Splunk Add-On for Microsoft Cloud Services und das Microsoft Azure Add-On for Splunk.
Sind Euch oben eigentlich die Tags [Storage-Konto], [Event Hub], und [REST] aufgefallen? Diese helfen uns bei der wichtigen Entscheidung, welches Add-On wir eigentlich verwenden sollen. Weiter geht's!
Splunk Add-on for Microsoft Cloud Services
- Aktivitätsdaten und Warnmeldungen [REST] [Event Hub]
- Authentifizierungsdaten [Event Hub]
- NSG-Flow-Logs [Speicher-Account]
- Web Application und App Insights [Speicher-Account]
Microsoft Azure Add-on for Splunk
- Ressourcendaten [REST]
- Authentifizierungsdaten [REST]
- Kosten und Nutzung [REST]
- Metriken [REST]
Ist Euch mit Blick auf die Tags ein Muster aufgefallen? Während das Splunk Add-On for Microsoft Cloud Services sowohl Event Hubs als auch Speicher-Accounts und das Aktivitäts-Log integriert, berücksichtigt Microsoft Azure Add-On for Splunk die verschiedenen REST-APIs. Aber auch das Splunk Add-On for Microsoft Cloud Services kann das Aktivitäts-Log über die REST API oder den Event Hub abrufen. In beiden Fällen handelt es sich dabei um dieselben Datensätze.
Getting Data In – Daten einlesen via GDI
Es heißt, ein Bild sagt mehr als tausend Worte: Dieses Sankey-Diagramm soll die unzähligen Worte dieses Blogbeitrags möglichst einfach visualisieren…
Hinweis: Per Klick auf die Abbildung gelangt Ihr zu einem interaktiven Diagramm.
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.
