Hallo Gorki Maxim,
Die Verwirrung entsteht daher, wie die Evaluationslogik der Azure Network Security Group (NSG) mit der maschinellen Lerntelemetrie von Microsoft Defender for Cloud interagiert. In einer Standard-NSG werden Regeln nach Prioritätsnummer vom niedrigsten bis zum höchsten verarbeitet. Während Ihre DenyAllVnetInBound-Regel (typischerweise auf Priorität 65000 oder 65500 gesetzt) effektiv jeglichen nicht ausdrücklich erlaubten Datenverkehr blockiert, ignoriert das Adaptive Network Hardening (ANH)-Dashboard diesen Sammelbegriff. Sein Zweck ist es, "übermäßig permissive" Erlaubnisregeln zu identifizieren, die mit höherer Priorität gelten. Wenn Sie eine Regel haben, die Verkehr auf einem bestimmten Port erlaubt, Azures Backend-Telemetrie aber zeigt, dass in den letzten 30 Tagen kein legitimer Datenverkehr diesen Port genutzt hat, kennzeichnet ANH ihn als Hochrisiko-Angriffsfläche, die geschlossen werden sollte, unabhängig von Ihrer Bottom-Tier-Ablehnungsregel.
Um das zu lösen, solltest du den Enforce-Button im Defender for Cloud-Portal verwenden. Dies löst einen automatisierten Workflow aus, der Ihre NSG anpasst, um den empfohlenen "Least Privilege"-Status basierend auf den tatsächlichen Verkehrsmustern anzupassen. Wenn Sie dies lieber manuell handhaben, um Redundanz zu vermeiden, müssen Sie die spezifischen Erlaubt-Regeln finden, die die Warnungen auslösen, und sie auf bestimmte, bekannte Quell-IP-Adressen beschränken. Sobald das Dashboard erkennt, dass die Erlaubt-Regeln so eng sind wie der tatsächliche Verkehrsfluss, lösen sich die Hochrisiko-Empfehlungen auf, weil die "permissive Lücke" zwischen Ihren erlaubten Regeln und Ihrer Catch-All-Deny-Regel geschlossen wurde.
Ich hoffe, diese Antwort hat Ihnen nützliche Informationen gebracht. Falls ja, klicken Sie bitte auf "Antwort akzeptieren". Sollten Sie Fragen haben, hinterlassen Sie gerne einen Kommentar.
VP