Sentinel-RBAC-Optionen

• Default-RBAC-Rollen
• Custom-RBAC-Rollen
• Custom-RBAC-Rollen, die Tabellen zugewiesen werden
• Option für benutzerdefinierte Tabellenberechtigungen

Ich gehe davon aus, dass in Kürze weitere Optionen verfügbar sein werden, und ich gebe euch ein Update, sobald es so weit ist. Aber beginnen wir mit den aktuellen Optionen.

1.) Default-Rollen von Microsoft Sentinel

In Microsoft Azure sind viele vordefinierte RBAC-Rollen (Role-based access control) verfügbar. In dieser langen Liste gibt es einige Microsoft-Sentinel-Rollen, die in jedem meiner Projekte eine wichtige Rolle spielen. Beginnen wir also mit der Liste der Rollen und gehen danach etwas genauer ins Detail.

• Microsoft Sentinel Reader
• Microsoft Sentinel Responder
• Microsoft Sentinel Contributor
• Microsoft Sentinel Automation Contributor
• Logic App Contributor

Es gibt noch weitere Rollen, aber in der Liste oben habe ich die wichtigsten beschrieben. Schauen wir uns diese etwas genauer an.

Microsoft Sentinel Reader

Das ist die Standardberechtigung zum Ansehen in Microsoft Sentinel. Sie umfasst die folgenden Berechtigungen.

• Daten ansehen
• Incidents ansehen
• Workbooks ansehen
• Andere Microsoft-Sentinel-Ressourcen ansehen

Es ist die gängigste Berechtigung für Personen, die Microsoft Sentinel nur ansehen.

Microsoft Sentinel Responder

Das ist die Standardberechtigung zum „Arbeiten“ in Microsoft Sentinel. Sie umfasst zusätzlich zur Rolle Microsoft Sentinel Reader die folgenden Berechtigungen.

• Incidents verwalten (zuweisen, verwerfen usw.)

Es ist die gängigste Berechtigung für Security-Analysten in Microsoft Sentinel.

!WICHTIG! Damit Security-Analysten ihre Arbeit erledigen können, müsst ihr zusätzlich die Berechtigung „Logic App Contributor“ zuweisen, die weiter unten beschrieben wird.

Microsoft Sentinel Contributor

Das ist die Standardberechtigung zum „Ändern“ in Microsoft Sentinel. Sie umfasst zusätzlich zur Rolle Microsoft Sentinel Reader/Responder die folgenden Berechtigungen.

• Workbooks erstellen und bearbeiten
• Regeln erstellen und bearbeiten (Analytics, Hunting)
• Andere Microsoft-Sentinel-Ressourcen erstellen und bearbeiten

Es ist die gängigste Berechtigung für Security-Engineers in Microsoft Sentinel.

!WICHTIG! Damit Security-Engineers ihre Arbeit erledigen können, müsst ihr zusätzlich die Berechtigung „Logic App Contributor“ zuweisen, die weiter unten beschrieben wird.

Microsoft Sentinel Automation Contributor

Diese Rolle ist etwas Besonderes. Sie ist nicht für Benutzerkonten gedacht. Mit dieser Rolle gebt ihr Microsoft Sentinel die Berechtigung, Playbooks zu Automation Rules zuzuweisen.

• Playbooks zu Automation Rules hinzufügen

Sie wird von Microsoft Sentinel benötigt

!WICHTIG! Noch einmal: Sie ist nicht für Benutzerkonten gedacht!

Logic App Contributor

Diese Rolle ist nicht nur für Microsoft Sentinel konzipiert. Es ist eine Standardrolle für Azure Logic Apps, und ihr solltet sie auch in eurer Microsoft-Sentinel-Architektur verwenden. Sie wird benötigt, damit Security-Analysten und -Engineers Playbooks ausführen können

• Azure Logic Apps bearbeiten und ausführen

Sie wird von Security-Analysten und -Engineers benötigt, um SOAR (Security Orchestration, Automation, and Response) umzusetzen

Wo finde ich diese Rollen?

Okay, die Standardrollen sind im Detail beschrieben, aber wo finde ich sie? Ganz einfach: Öffnet den Bereich „Access Control (IAM)“ in der Resource Group eures Microsoft Sentinel, und ihr seht alle Rollen.

Noch ein WICHTIGER Tipp: Weist RBAC-Rollen immer einer Azure-AD-Gruppe zu. Das ist nichts Neues, aber wirklich wichtig.

Es gibt noch weitere Berechtigungen, die nicht nur für Microsoft Sentinel gelten. Das sind die „Default“-Rollen von Azure

• Owner
• Contributor
• Reader

Denkt daran: Wenn ihr eine der oben genannten RBAC-Rollen verwendet, vergebt ihr deutlich mehr Berechtigungen als nötig!

2.) Custom-RBAC-Rollen

In Microsoft Azure könnt ihr immer die (oben beschriebenen) Default-Rollen verwenden oder eigene Custom-RBAC-Rollen erstellen. Inzwischen gibt es verschiedene Möglichkeiten, Custom-RBAC-Rollen zu erstellen.

• Azure-Portal
• Über IaC (PowerShell, ARM, Bicep,)

Um Custom-RBAC-Rollenberechtigungen umzusetzen, müsst ihr wissen, welche Azure Resource Provider zur Verfügung stehen, um diese Berechtigungen zu erstellen. Die wichtigsten Resource Provider sind.

• Microsoft.OperationalInsights
• Microsoft.SecurityInsights

Die Schritte zum Definieren von Custom-Berechtigungen im Azure-Portal sind recht einfach, aber ihr müsst wissen, was ihr wollt, denn die Liste der Berechtigungen ist wirklich riesig. Hier sind die Schritte, um eine neue Custom-RBAC-Rolle umzusetzen.

Zum richtigen Bereich im Azure-Portal wechseln

Um im Azure-Portal neue Berechtigungen zu definieren, wählt eure Subscription, Resource Group oder eine andere Ebene aus und geht zum Bereich „Access Control (IAM)“. Wenn ihr „Add“ auswählt, findet ihr die Option „Add custom role“.

Die erforderlichen Basisinformationen definieren

Im ersten Abschnitt des Assistenten müsst ihr Folgendes definieren

• Name der Custom Role
• Beschreibung
• Baseline-Berechtigungen

Okay, die ersten beiden sind klar, aber beim letzten Punkt gibt es verschiedene Optionen. Schauen wir uns die Details an.

Erstens könnt ihr eine bestehende Rolle klonen. Praktisch, und diese Option nutze ich oft.

Die zweite Option ist deutlich anspruchsvoller: Ihr könnt bei null beginnen, wo nichts vordefiniert ist.

Die letzte Option ist die schwierigste, aber auch die wichtigste: Ihr könnt eure Berechtigungen aus einem JSON-Template definieren. Das Praktische daran: Es ist IaC, und ihr könnt diese Berechtigung auch in einer anderen Umgebung wiederverwenden. In unserem Fall starten wir aber bei null und erstellen eine komplett neue Berechtigung.

Die Berechtigungen für die Resource Provider definieren

Super, jetzt kommen wir zum schwierigsten Abschnitt: Wir müssen die fein granularen Berechtigungen auf Basis der Azure Resource Provider definieren. Ich zeige euch eine „kurze“ Liste der Optionen, die ihr habt. Für Microsoft Sentinel sind die beiden Resource Provider (siehe Liste oben) die wichtigsten. Überlegt also, was ihr braucht, und wählt dann die Berechtigung aus.

Denkt immer daran: Ihr könnt Berechtigungen für verschiedene „Actions“ in Microsoft Sentinel definieren.

Die Assignable Scopes definieren

Der letzte Schritt ist ebenfalls sehr wichtig. Im Abschnitt „Assignable scopes“ müsst ihr festlegen, wo die Custom-RBAC-Berechtigung verfügbar ist. Meine Empfehlung: Weist die Berechtigung immer auf Subscription-Ebene zu, oder, falls ihr sie auch in anderen Subscriptions braucht, auf Management-Group-Ebene. In manchen Situationen kann ein Azure-Resource-Group-Scope in Ordnung sein, aber das ist die Ausnahme.

3.) Custom-RBAC-Rollen, die Tabellen zugewiesen werden

Wenn ihr an Custom-Berechtigungen für Microsoft Sentinel denkt, könnt ihr Azure-Resource-Provider-„Actions“ sowohl Microsoft Sentinel zuweisen als auch den Azure-Log-Analytics-Tabellen, die von Microsoft Sentinel und seinen „Data Connectors“ automatisch erstellt werden. In diesem Abschnitt zeige ich euch, wo ihr diese Tabellen und Berechtigungen findet.

Also los: Zuerst müssen wir die automatisch erstellten Tabellen finden. Öffnet den Azure-Log-Analytics-Store, der die Grundlage von Microsoft Sentinel ist, und geht zum Bereich „Logs“.

Alle Azure-Log-Analytics-Tabellen werden angezeigt, und ihr seht verschiedene Bereiche.

Abhängig von den verbundenen Solutions oder Datenquellen in Microsoft Sentinel seht ihr immer mehr Tabellen. Eine WICHTIGE Information dazu: Auf diesem Weg könnt ihr Berechtigungen für alle Tabellen außer den Custom Logs vergeben! Mist, das ist nicht gut: Auf diesem Weg könnt ihr nur dem gesamten Bereich „Custom Logs“ Berechtigungen zuweisen, und das ist in vielen Situationen nicht wirklich gut. Aber dazu kommen wir im nächsten Abschnitt.

Wo finde ich diese Berechtigungen? Beginnt mit demselben Vorgehen, das oben unter „Custom-RBAC-Rollen“ beschrieben ist, aber sucht bei „Die Berechtigungen für die Resource Provider definieren“ nach dem Azure Resource Provider

• Microsoft.OperationalInsights

Nur dieser Azure Resource Provider enthält die Actions für Tabellenberechtigungen. Hier eine Kurzliste der Optionen, die ihr habt.

4.) Option für benutzerdefinierte Tabellenberechtigungen

Die Möglichkeiten für Berechtigungen auf benutzerdefinierten Tabellen habe ich im Abschnitt oben beschrieben, ebenso das „Problem“ damit. Wenn ihr die Berechtigungen abfragt, findet ihr die Tabellenberechtigung des Azure Resource Providers mit dem Namen

• Microsoft.OperationalInsights/workspaces/query/Tables.Custom

die die Berechtigung für alle „Custom Logs“-Tabellen insgesamt bezeichnet. Schlecht, richtig schlecht, aber es gibt eine weitere Option. Woher kommen Custom Logs „normalerweise“? Aus benutzerdefinierten Lösungen, und in vielen Situationen könnt ihr den neuen Eintrag ändern, bevor er in den Azure-Log-Analytics-Store gelangt.

In meiner Beschreibung zeige ich euch die Scripting-Option (PowerShell), die ihr habt, aber es gibt noch mehr. Denkt an die Log-Erfassung auf Basis von CEF (Common Event Format) oder Syslog. In diesem Fall müsst ihr einen oder (besser) mehrere Collectors definieren, die die Daten von On-Prem in die Cloud senden. Diese Forwarder enthalten auch die „ResourceID“ des Collectors, und das ist wichtig (das beschreibe ich in den nächsten Abschnitten). Dieses Szenario heißt „Log forwarding collection“

Bei der „Log forwarding collection“ habt ihr ein Problem! Stellt euch folgende Situation vor

Euer Unternehmen hat zwei oder mehr VMs installiert, um Syslog- oder CEF-Events On-Prem zu sammeln und diese Events an den Azure Log Analytics Workspace zu senden. Das Unternehmen hat verschiedene Firewalls an unterschiedlichen Standorten (HQ, Bo) und auch Firewall-Admins an diesen Standorten.

Nun haben wir eine schlechte Situation: Alle Logs werden über dieselben Azure-Log-Analytics-Collectors nach Azure gesendet, das heißt, alle Logs in derselben Custom-Log-Tabelle haben dieselbe resourceId.

Wenn wir nun die Umgebung so gestalten wollen, dass jeder Firewall-Admin nur seine eigenen Logs sehen kann, haben wir ein Problem. Um dieses Problem zu lösen, könnt ihr die Option „Logstash collection“ verwenden.

In meinem Blogpost möchte ich aber die Möglichkeit zeigen, die ihr mit einem selbst gebauten PowerShell-Script habt. Warum PowerShell? Aus meiner Sicht bietet euch diese Option die Flexibilität, Code zu schreiben, ohne ein Entwicklungsteam zu benötigen. Natürlich lässt sich die Anforderung auch mit einer .Net-Anwendung umsetzen, aber starten wir zunächst mit PowerShell. Wir haben folgende Situation.

Ihr betreibt On-Prem eine Anwendung, die wichtige Informationen für euer SOC-Team enthält. Es ist eine individuell entwickelte Anwendung, die die Möglichkeit bietet, die benötigten Informationen über eine API abzurufen.

Ihr schreibt ein eigenes PowerShell-Script mit geplanter Ausführung (z. B. Azure Automation) und schreibt diese Informationen in Azure Log Analytics.

Diese Anforderung lässt sich recht einfach umsetzen, denn Azure Log Analytics bietet eine API, um Daten z. B. per PowerShell zu senden. Hier ist ein Beispiel-Script (ohne die resourceID)

#region Replace with your Workspace ID
$CustomerId = "<WorkspaceID>"  
#endregion

#region Replace with your Primary Key
$SharedKey = "<WorkspaceKey>"
#endregion

# Specify the name of the record type that you'll be creating
$LogType = "CustomTablePerm "

# You can use an optional field to specify the timestamp from the data. If the time field is not specified, Azure Monitor assumes the time is the message ingestion time
$TimeStampField = ""

# Create two records with the same set of properties to create
$json = @"
[{  "StringValue": "SharedWorkbook02-Data01",
    "NumberValue": 42,
    "BooleanValue": true,
    "DateValue": "2019-09-12T20:00:00.625Z",
    "GUIDValue": "9909ED01-A74C-4874-8ABF-D2678E3AE23D"
},
{   "StringValue": "SharedWorkbook02-Data01",
    "NumberValue": 43,
    "BooleanValue": false,
    "DateValue": "2019-09-12T20:00:00.625Z",
    "GUIDValue": "8809ED01-A74C-4874-8ABF-D2678E3AE23D"
}]
"@

# Create the function to create the authorization signature
Function Build-Signature ($customerId, $sharedKey, $date, $contentLength, $method, $contentType, $resource)
{
    $xHeaders = "x-ms-date:" + $date
    $stringToHash = $method + "`n" + $contentLength + "`n" + $contentType + "`n" + $xHeaders + "`n" + $resource

    $bytesToHash = [Text.Encoding]::UTF8.GetBytes($stringToHash)
    $keyBytes = [Convert]::FromBase64String($sharedKey)

    $sha256 = New-Object System.Security.Cryptography.HMACSHA256
    $sha256.Key = $keyBytes
    $calculatedHash = $sha256.ComputeHash($bytesToHash)
    $encodedHash = [Convert]::ToBase64String($calculatedHash)
    $authorization = 'SharedKey {0}:{1}' -f $customerId,$encodedHash
    return $authorization
}

# Create the function to create and post the request
Function Post-LogAnalyticsData($customerId, $sharedKey, $body, $logType)
{
    $method = "POST"
    $contentType = "application/json"
    $resource = "/api/logs"
    $rfc1123date = [DateTime]::UtcNow.ToString("r")
    $contentLength = $body.Length
    $signature = Build-Signature `
        -customerId $customerId `
        -sharedKey $sharedKey `
        -date $rfc1123date `
        -contentLength $contentLength `
        -method $method `
        -contentType $contentType `
        -resource $resource
    $uri = "https://" + $customerId + ".ods.opinsights.azure.com" + $resource + "?api-version=2016-04-01"

    $headers = @{
        "Authorization" = $signature;
        "Log-Type" = $logType;
        "x-ms-date" = $rfc1123date;
        "time-generated-field" = $TimeStampField;
    }

    $response = Invoke-WebRequest -Uri $uri -Method $method -ContentType $contentType -Headers $headers -Body $body -UseBasicParsing
    return $response.StatusCode

}

# Submit the data to the API endpoint
Post-LogAnalyticsData -customerId $customerId -sharedKey $sharedKey -body ([System.Text.Encoding]::UTF8.GetBytes($json)) -logType $logType

Okay, und was ist nun eine resourceID? Jedes Mal, wenn ihr eine Ressource in Azure erstellt, hat diese Ressource eine eindeutige resourceID, die wie folgt aussieht.

• /subscriptions/<SubscriptionID>/resourceGroups/rg-sentinel

Genau diese könnt ihr in eurem Script verwenden, aber was sind sinnvolle Szenarien? Denkt an Folgendes.

Eure On-Prem-Lösung (oben beschrieben) und deren Events sollen von euren Kunden in Azure eingesehen werden. Ihr habt nun die Möglichkeit, diese Daten in ein separates Azure Dashboard zu bringen.

Erstellt ein neues Azure Dashboard, teilt dieses Dashboard und verwendet diese resourceID in eurem Script.

1.) Ein neues Azure Dashboard erstellen

1.) Das Dashboard teilen

Definiert eine eigene Resource Group oder verwendet die „Default“-Azure-Resource-Group, um das neue Azure Dashboard zu speichern

Kopiert nun die resourceID des neu erstellten Dashboards und fügt in die Funktion Post-LogAnalyticsData eine neue Zeile mit dem Namen “x-ms-AzureResourceId” = “<resourceid>”; ein.

#region Replace with your Workspace ID
$CustomerId = "<WorkspaceID>"  
#endregion

#region Replace with your Primary Key
$SharedKey = "<WorkspaceKey>"
#endregion

# Specify the name of the record type that you'll be creating
$LogType = "CustomTablePerm "

# You can use an optional field to specify the timestamp from the data. If the time field is not specified, Azure Monitor assumes the time is the message ingestion time
$TimeStampField = ""

# Create two records with the same set of properties to create
$json = @"
[{  "StringValue": "SharedWorkbook02-Data01",
    "NumberValue": 42,
    "BooleanValue": true,
    "DateValue": "2019-09-12T20:00:00.625Z",
    "GUIDValue": "9909ED01-A74C-4874-8ABF-D2678E3AE23D"
},
{   "StringValue": "SharedWorkbook02-Data01",
    "NumberValue": 43,
    "BooleanValue": false,
    "DateValue": "2019-09-12T20:00:00.625Z",
    "GUIDValue": "8809ED01-A74C-4874-8ABF-D2678E3AE23D"
}]
"@

# Create the function to create the authorization signature
Function Build-Signature ($customerId, $sharedKey, $date, $contentLength, $method, $contentType, $resource)
{
    $xHeaders = "x-ms-date:" + $date
    $stringToHash = $method + "`n" + $contentLength + "`n" + $contentType + "`n" + $xHeaders + "`n" + $resource

    $bytesToHash = [Text.Encoding]::UTF8.GetBytes($stringToHash)
    $keyBytes = [Convert]::FromBase64String($sharedKey)

    $sha256 = New-Object System.Security.Cryptography.HMACSHA256
    $sha256.Key = $keyBytes
    $calculatedHash = $sha256.ComputeHash($bytesToHash)
    $encodedHash = [Convert]::ToBase64String($calculatedHash)
    $authorization = 'SharedKey {0}:{1}' -f $customerId,$encodedHash
    return $authorization
}

# Create the function to create and post the request
Function Post-LogAnalyticsData($customerId, $sharedKey, $body, $logType)
{
    $method = "POST"
    $contentType = "application/json"
    $resource = "/api/logs"
    $rfc1123date = [DateTime]::UtcNow.ToString("r")
    $contentLength = $body.Length
    $signature = Build-Signature `
        -customerId $customerId `
        -sharedKey $sharedKey `
        -date $rfc1123date `
        -contentLength $contentLength `
        -method $method `
        -contentType $contentType `
        -resource $resource
    $uri = "https://" + $customerId + ".ods.opinsights.azure.com" + $resource + "?api-version=2016-04-01"

    $headers = @{
        "Authorization" = $signature;
        "Log-Type" = $logType;
        "x-ms-date" = $rfc1123date;
        "time-generated-field" = $TimeStampField;
        "x-ms-AzureResourceId" = "<resourceid>";
    }

    $response = Invoke-WebRequest -Uri $uri -Method $method -ContentType $contentType -Headers $headers -Body $body -UseBasicParsing
    return $response.StatusCode

}

# Submit the data to the API endpoint
Post-LogAnalyticsData -customerId $customerId -sharedKey $sharedKey -body ([System.Text.Encoding]::UTF8.GetBytes($json)) -logType $logType

Wenn ihr Daten zu eurem Log Analytics Workspace hinzufügt, findet ihr die neue Custom-Tabelle mit dem Eintrag _ResourceId in jeder Zeile.

Nun könnt ihr euren Kunden die Berechtigung geben, genau diese und nur diese Informationen aus eurem Azure-Log-Analytics-Store zu lesen. Das Einzige, was ihr dafür tun müsst, ist, den Kunden dem Azure Dashboard zuzuweisen und die Azure-Log-Analytics-Abfrage zum geteilten Dashboard hinzuzufügen.

Fazit

Ihr habt jetzt eine Menge über Microsoft Sentinel und die RBAC-Berechtigungen gesehen. Manche Berechtigungen sind wirklich einfach und schnell umgesetzt, andere sind komplexer. Wenn ihr die Unterschiede in einer Live-Demo sehen möchtet, schaut euch mein YouTube-Video unten an.