14 min read
Der Schlüssel zu produktiver Softwareverwaltung: winget & PowerShell
Steigere die IT-Effizienz mit Winget und PowerShell! Lies, wie du Installationen, Updates und die Verwaltung von...
ScriptRunner Blog
Hacker. Spammer. Phishing. Oh weh! (Okay, das war ein Klischee.)
Aber mal in Ernst: Exchange Online ist einer Vielzahl von Angriffen, Angriffsvektoren und Übeltätern ausgesetzt. Der Job eines Administrators ist mit dem Wechsel zu Cloud-Diensten in Bezug auf die Sicherheit schwieriger geworden. Unternehmen wie Microsoft bemühen sich jedoch, diese Ängste zu zerstreuen und Exchange Online-Admins Tools zur Verfügung zu stellen, mit denen sie diese Bedrohungen bewältigen können. In diesem Artikel sehen wir uns an, wie Sie PowerShell nutzen können, um Sicherheit für Exchange Online zu gewährleisten.
Zunächst werfen wir einen Blick auf das Konzept der Authentifizierung:
Basic Authentication verwendet eine Passwort-Abfrage/Antwort für jede Interaktion mit einer Ressource in Exchange Online. Weitere Zugriffsanforderungen sind nicht implementiert. Wenn eine Verbindung zu Exchange Online nicht sicher ist, könnte das Kennwort abgefangen werden.
Modern Authentication basiert auf der Verwendung von OAUTH 2.0 und ADAL (Active Directory Authentication Library) unter Verwendung von Token-basierter Authentifizierung, die wesentlich mehr Sicherheit bietet.
Bei älteren Tenants ist Modern Auth möglicherweise deaktiviert, während es bei neueren Tenants standardmäßig aktiviert ist. Wir können unseren Tenant überprüfen, indem wir diesen Einzeiler in der Exchange Online PowerShell ausführen:
Get-OrganizationConfig | Ft OAuth2ClientProfileEnabled
Die nachfolgende Ausgabe zeigt, dass Modern Authentication aktiviert ist:
Wäre dies false, wäre Modern Auth ausgeschaltet, was gegen die Best Practices für Office 365 verstößt und auch keine sehr sichere Haltung darstellt. Stellen Sie sicher, dass dies aktiviert ist. Beachten Sie, dass dies nicht verhindert, dass sich Basic Auth-Clients mit Exchange Online verbinden. Es gibt andere Möglichkeiten, dies zu tun.
Der nächste Schritt ist das Blockieren von Basic Auth!
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
und überprüfen Sie die Änderungen:
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.
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:
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.
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.
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.
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.
Kostenloses Webinar
Gibt es bei Ihnen häufig wiederkehrende Aufgaben im täglichen Betrieb von Exchange / Exchange Online? Hier erfahren Sie, wie Sie:
In Office 365 gibt es auch einige Möglichkeiten, wie wir MFA für Anwender in einem Tenant aktivieren können. Wir können Conditional Access, Security Defaults verwenden oder sie individuell zuweisen. In diesem Artikel werden wir als Beispiel dafür, wie wir Anwender in einem Tenant absichern können, ausführen, wie dies über die individuelle Zuweisung geschieht.
Bevor wir uns damit befassen, lassen Sie uns zunächst erläutern, warum die Multi-Faktor-Authentifizierung verwendet werden sollte:
Microsoft bietet zahlreiche Ressourcen zu diesem Thema. Hier finden Sie eine gute Anlaufstelle dazu.
Um MFA auf Benutzerebene zu aktivieren, müssen wir uns zunächst über ein PowerShell-Modul mit dem MSOL-Dienst verbinden.
Wenn Sie dieses nicht installiert haben, holen Sie das nach, indem Sie Folgendes ausführen:
Install-Module MSOnline
Connect-MsolService
$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$st.RelyingParty = "*"
$st.State = "Enabled"
$sta = @($st)
Set-MsolUser -UserPrincipalName damian@practicalpowershell.com -StrongAuthenticationRequirements $sta
(Get-MsolUser -UserPrincipalName Damian@practicalpowershell.com).StrongAuthenticationRequirements | Fl
Jetzt müssen wir die ganze Prozedur nur noch für alle Benutzer, die MFA benötigen wiederholen. Sobald wir damit fertig sind, können wir mit diesem Code überprüfen, welche Benutzer die Einstellung jetzt besitzen:
Get-MsolUser -All | Where {$_.StrongAuthenticationRequirements -ne $Null} |ft DisplayName, UserPrincipalName,StrongAuthenticationRequirements
Damit können wir überprüfen, ob unsere Benutzer MFA auf Benutzerbasis aktiviert haben.
Wenn wir uns die oben durchgeführten Konfigurationseinstellungen ansehen, können wir einige Schlussfolgerungen über Sicherheit, PowerShell und Exchange Online ziehen:
Um ein umfassenderes Verständnis der obigen PowerShell-Funktionen und der durchgeführten Sicherheitsmaßnahmen zu erhalten, sollten Sie die Docs-Seiten von Microsoft zu den einzelnen Themen lesen. Mit diesem Artikel und den Docs-Seiten werden Sie in der Lage sein, die oben genannten Aufgaben zu bewältigen und sie sicher für Ihren Mandanten zu konfigurieren. Sicherheit ist der Schlüssel in Exchange Online, also vergewissern Sie sich, dass Sie die oben genannten Funktionen auf Ihren Tenant anwenden.
Dez 19, 2024 by Jeffery Hicks
Steigere die IT-Effizienz mit Winget und PowerShell! Lies, wie du Installationen, Updates und die Verwaltung von...
Dez 19, 2024 by Damian Scoles
Mit Microsoft Purview verstehst und verwaltest du Daten in deinem gesamten Datenbestand – wie kannst du PowerShell...
Dez 17, 2024 by Sonny Jamwal
Erweitere PowerShell mit .NET für eine leistungsstarke Ereignisautomatisierung. Systemereignisse wie ein Profi...
Damian Scoles ist ein zehnfacher Microsoft MVP mit Spezialisierung auf Exchange, Office 365 und PowerShell, der über 25 Jahre Erfahrung in der IT-Branche mitbringt. Er ist im Großraum Chicago ansässig und begann mit der Verwaltung von Exchange 5.5 und Windows NT. Im Laufe der Jahre hat er mit Office 365 seit BPOS gearbeitet und darüber hinaus Erfahrung mit Azure AD, Security and Compliance Admin Centers und Exchange Online. Zu seinem Engagement in der Community gehören Beiträge in TechNet-Foren, die Erstellung von PowerShell-Skripten, die in seinen Blogs zu finden sind, das Schreiben von ausführlichen PowerShell/Office365/Exchange-Blogartikeln, Tweets und die Erstellung von PowerShell-Videos auf YouTube. Er hat fünf PowerShell-Bücher geschrieben und arbeitet außerdem aktiv an dem Buch "Microsoft 365 Security for IT Pros".