PowerShell und Exchange Online-Sicherheit

Authentifizierungsrichtlinie

Das Blockieren von Basic Auth für Exchange Online kann über mindestens zwei verschiedene Methoden erfolgen. Eine davon ist der bedingte Zugriff, auf den wir nicht näher eingehen werden (aber er kann mit PowerShell durchgeführt werden!), und die andere Methode ist eine sogenannte Authentifizierungsrichtlinie. Mit einer Authentifizierungsrichtlinie können wir steuern, welche Aspekte von Exchange Online Basic Auth verwenden oder nicht verwenden können. Zunächst einmal, was ist die Standardkonfiguration für eine Authentifizierungsrichtlinie? Nun, eigentlich keine!

Get-AuthenticationPolicy | fl

Okay. Nun, wenn es keine Richtlinie gibt, was können wir dann tun? Wir erstellen eine. Mit PowerShell ODER durch eine Änderung im M365 Admin Center. Wie stellen wir das an? Zuerst müssen wir die Standard-Authentifizierungsrichtlinie finden. Die Authentifizierungsrichtlinie befindet sich im M365 Admin Center unter Settings→ Org Settings → Modern Authentication, wo wir Folgendes vorfinden:

Damit die Richtlinie in der PowerShell erscheint, entfernen wir einfach ein Häkchen bei einem Punkt, sagen wir IMAP, speichern die Einstellungen und warten 15-30 Sekunden. Nach dem Warten können wir Folgendes ausführen:

Get-AuthenticationPolicy | fl

um die vorgenommene Änderung zu sehen:

Beachten Sie, dass AllowBasicAuthIMAP deaktiviert ist. Um Basic Auth für alle diese Protokolle zu blockieren, können wir diesen Einzeiler ausführen:

Set-AuthenticationPolicy -Identity 'BlockBasic637530830181380023' -AllowBasicAuthActiveSync:$False -AllowBasicAuthAutodiscover:$False -AllowBasicAuthImap:$False -AllowBasicAuthMapi:$False -AllowBasicAuthOfflineAddressBook:$False -AllowBasicAuthOutlookService:$False -AllowBasicAuthPop:$False -AllowBasicAuthReportingWebServices:$False -AllowBasicAuthRest:$False -AllowBasicAuthRpc:$False -AllowBasicAuthSmtp:$False -AllowBasicAuthWebServices:$False -AllowBasicAuthPowershell:$FalsengWebServices $False -AllowBasicAuthRpc $False -AllowBasicAuthSmtp $False -AllowBasicAuthWebServices $False -AllowBasicAuthPowershell $False

Get-AuthenticationPolicy | fl

Wir haben jetzt Basic für die gesamte Liste der Verbindungstypen deaktiviert, die für die Verbindung mit Exchange Online verfügbar sind.

Protokoll-Einschränkungen

Für Exchange Online bietet Microsoft viele Protokolle für Endanwender an, um eine Verbindung zu ihrem Postfach herzustellen. Wir haben IMAP, POP, ActiveSync, ECP, MAPI, OWA und mehr. Typischerweise wollen wir weniger sichere Protokolle wie IMAP4 und POP3 blockieren, damit die Anwender diese nicht einsetzen, um sich mit einem Postfach zu verbinden. Wir können diese Verbindungen mit den CasMailboxPlan-Cmdlets steuern. Im Allgemeinen gibt es in Exchange Online vier Haupt-CAS-Postfachpläne, aber diese Anzahl kann je nach Lizenzierungsmodell variieren.

Für unser Beispiel haben wir einen Exchange Online-Tenant mit entweder E3- oder E5-Lizenzierung.

Wenn wir Get-CasMailboxPlan| Ft Name

ausführen, werden diese Pläne angezeigt:

1. Deskless
2. Regular
3. Enterprise und
4. Essentials

Wir können anzeigen, was in einem dieser Pläne verfügbar ist, indem wir dieses Cmdlet ausführen:

Get-CASMailboxPlan ExchangeOnlineEnterprise-a198b3f1-d047-49ed-b00d-b9ae84d0390a | Fl *Enabled

Wenn wir nun Protokolle deaktivieren müssen, IMAP und POP sind die besten Kandidaten, können wir dies wie folgt tun:

Set-CASMailboxPlan -Identity ExchangeOnlineEnterprise-a198b3f1-d047-49ed-b00d-b9ae84d0390a -IMAPEnabled $False -POPEnabled $False

Mit diesem Einzeiler können wir diese Änderung für alle Pläne auf einmal vornehmen:

Get-CASMailboxPlan | Set-CASMailboxPlan -IMAPEnabled $False -POPEnabled $False

Damit haben wir nun die Angriffsmöglichkeiten für den Zugriff auf Exchange Online-Postfächer reduziert.

OWA Offline-Modus

Eine der oft übersehenen Funktionen von Webmail, bekannt als OWA, ist die Funktion des Offline-Modus. Diese Funktion hinterlässt eine unverschlüsselte Kopie der letzten 500 E-Mails auf Ihrem Gerät, auf die Sie einfach zugreifen können, während Sie nicht verbunden sind. Die Theorie ist, dass Vielreisende in der Lage sind, mit ihren letzten E-Mails zu arbeiten, Antworten zu erstellen und mit den in den letzten E-Mails enthaltenen Informationen zu arbeiten. Allerdings ist die fehlende Verschlüsselung die Achillesferse dieses Setups.

Wir können uns das mit der PowerShell für die OWA Mailbox Policies wie folgt ansehen:

Get-OwaMailboxPolicy | Ft AllowOfflineOn

Wir sehen, dass sie tatsächlich eingeschaltet ist. Wie schalten wir sie nun aus? Nun, wir haben drei Optionen für AllowOfflineOn – PrivateComputersOnly, NoComputers oder AllComputers.

Der Wert, den wir brauchen, ist „NoComputers“, daher benötigt man zum Deaktivieren den Namen der Richtlinie und die Parameter für AllowOfflineOn:

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -AllowOfflineOn NoComputers

Wenn wir mehr als eine OWA-Mailbox-Richtlinie haben, können wir sie für alle auf einmal deaktivieren:

Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -AllowOfflineOn NoComputers

Die Anwender können den Offline-Modus nun nicht mehr für OWA verwenden und ihre E-Mails sind sicherer.

Nachrichtenfluss – EOP und Microsoft Defender für Office 365 (ehemals ATP)

Abhängig von der Lizenzierung und den in Exchange Online aktivierten Funktionen können EOP und Defender für Office 365 eine vielschichtige Verteidigung gegen bösartige E-Mails bieten. Diese Schichten umfassen Anti-Spam, Anti-Phishing und mehr.

Um zunächst zu beurteilen, wo wir uns befinden, können wir ein PowerShell-Modul namens ORCA verwenden, um nach Lücken zu suchen. ORCA ist eine Abkürzung für „Office 365 ATP Recommended Configuration Analyzer Report“, der so genannt wurde, bevor Microsoft das gesamte Namensschema für seine Produkte geändert hat.

Genauer gesagt prüft dieses Script nun Ihren Defender auf Office 365-Konfiguration. Wir können dieses Modul installieren, indem wir ein Windows PowerShell-Fenster öffnen und diesen Code eingeben:

Install-Module ORCA

Get-ORCAReport

Eine ähnliche Funktion können wir auch im Security and Compliance Center unter dem Namen „Configuration Analyzer“ sehen. Bemerkenswert ist, dass die Problembehebung hier vollständig in der GUI liegt. Bei der großen Anzahl von Validierungsprüfungen (über 60) wäre eine Scriptlösung zur Behebung dieser Probleme für die meisten Admins unerreichbar.

Dieses PowerShell-Modul sollte für einmalige oder automatisierte Berichte über den aktuellen Stand des Schutzes verwendet werden. Die Problem-Behebung über PowerShell liegt aufgrund der Komplexität der Konfiguration und des Umfangs der Funktionen / PowerShell-Cmdlets, die für diese Aufgabe erforderlich sind, außerhalb des Rahmens dieses Artikels.

Wenn ein Tenant aus irgendeinem Grund nicht über eine Lizenz für Defender für Office 365 verfügt, sollten die Funktionen getestet werden, um den Wert des Produkts zu beurteilen.

Wir können den Testmodus im Security and Compliance Center aktivieren → Threat Management → Policy → Evaluate Defender for Office 365.

Die Demo bleibt bis zu 90 Tage lang aktiv und das Reporting ist in der Evaluierung enthalten.

Role Based Access Control (RBAC)

Exchange war eines der ersten Produkte, das das Konzept der rollenbasierten Zugriffskontrolle erhielt, bei dem Operationen und Funktionen in Exchange über Rollengruppen und Verwaltungsrollen gewährt werden.

Management-Rollen sind die detaillierteren Berechtigungen für den Zugriff auf Exchange-Funktionen wie Journaling, Legal Hold und mehr. Rollengruppen hingegen sind Gruppierungen dieser Managementrollen, um logisch eine Jobfunktion oder eine Rolle zu erstellen, die jemand erfüllen kann, um legitime Aufgaben in Exchange zu erledigen.

Jetzt sind diese Konzepte von Exchange zu Exchange Online übergegangen.

Write-Host " Role Group Members "

Write-Host "----------------------"

$RoleGroup = Get-RoleGroup

Foreach ($Group in $RoleGroup) {

    $Name = $Group.Name


    $Members = Get-RoleGroupMember -Identity $Name

    If ($Null -ne $Members) {

        Write-Host "$Name "+": "

        Foreach ($Member in $Members) {

                $MemberName = $Member.Name

                write-Host " - $MemberName"

        }

        Write-Host ''

    } Else {

        Write-Host "** $Name hat keine Mitglieder."

        Write-Host ''
    }
}

Im gegebenen Fall hat keine Gruppe mehr als drei Benutzer in einer Rollengruppe. Für die meisten Szenarien ist dies eine gute Zahl, mit der man arbeiten kann.

Nachdem der Bericht ausgeführt wurde, sollte jede Gruppe auf gültige Konten geprüft werden und ob der betreffende Benutzer noch in dieser Rollengruppe sein muss. Wenn nicht, sollten die Konten entfernt werden. Zusätzlich sollte eine Überprüfung dieser Zuweisungen regelmäßig in Verbindung mit anderen Sicherheitsüberprüfungen stattfinden.