Die Microsoft 365 Defender Advanced Hunting API ist eine Goldgrube für Bedrohungsjäger. Sie können in KQL (Kusto Query Language) Tage oder sogar Wochen von Sicherheitsereignissen abfragen, die auf den Arbeitsstationen und Servern eines Unternehmens aufgezeichnet wurden.
Allerdings birgt es, wie jedes leistungsstarke Werkzeug, Risiken. Bei einem Managed Service Provider (MSSP), der seine Anfragen über mehrere Mandanten (Tenants) hinweg automatisiert, kann eine schlechte Verarbeitung von API-Aufrufen dazu führen, dass Microsoft den Dienst vorübergehend blockiert. Hier ist dieRatenbegrenzung(Ratenbegrenzung) wird zu einer wesentlichen Sicherheitsarchitektur.
Das Risiko unbegrenzter API-Abfragen (Drosselung)
Microsoft schützt seine Cloud-Infrastruktur, indem es strenge Quoten für Advanced Hunting-Anfragen über Microsoft Graph oder die Defender-API festlegt. Diese Grenzwerte beziehen sich auf beides:
- Frequenz:Die Anzahl der pro Minute und Mandant gesendeten Anfragen.
- Ressourcen:Die Berechnungszeit (CPU) und die Größe der zurückgegebenen Daten.
Was passiert, wenn ein Junior-SOC-Analyst eine nicht optimierte KQL-Abfrage schreibt (z. B. eine Volltextsuche ohne Datumsfilter für die sehr große Tabelle)?DeviceNetworkEvents) und führt es in einer Schleife auf 50 verschiedenen Clients aus?
Ohne einen Kontrollmechanismus wird die Microsoft API einen HTTP 429-Fehler („Too Many Requests“) auslösen. Der Client-Mandant wird vorübergehend blockiert (gedrosselt). Berechtigte Anfragen zur Bedrohungssuche und manchmal sogar einige automatisierte Warnungen werden abgelehnt, was zu einem kritischen blinden Fleck bei der Sicherheitsüberwachung führt.
Der SOC-Ansatz von Akuity: Schutz des Kunden und des Analysten
Um ein leistungsstarkes globales, mandantenfähiges Ausführungsterminal bereitzustellen, ohne jemals die Integrität der Microsoft-Kontingente Ihrer Kunden zu gefährden, integriert der Akuity SOC Orchestrator ein erweitertes Abfragelebenszyklusmanagement.
1. Integrierte asynchrone Ratenbegrenzung
Unsere Plattform leitet die KQL-Anfrage des Analysten nicht einfach gedankenlos an Microsoft weiter. Die Ausführungs-Engine (Backend) fängt den Befehl ab. Es verwaltet eine intelligente Warteschlange (Queueing) und wendet eine strikte Ratenbegrenzung an, die nativ die vom Herausgeber festgelegten Kontingente berücksichtigt.
Wenn mehrere Analysten gleichzeitig intensive Suchvorgänge für denselben Mandanten starten, glättet Akuity die Anfragen im Laufe der Zeit, um Spitzeneffekte zu vermeiden, die eine Blockierung auslösen würden (HTTP 429).
2. Visuelles Feedback und Ladebildschirm
Die Benutzererfahrung (UX) ist von entscheidender Bedeutung, um zu verhindern, dass der Analyst hektisch auf die Schaltfläche „Ausführen“ klickt und denkt, das System sei abgestürzt.
Während der asynchronen Ausführung der KQL-Abfrage zeigt die Bearbeitungskonsole einen durchsichtigen Ladebildschirm an. Der Betreiber weiß, dass seine Anfrage berücksichtigt, ggf. in die Warteschlange gestellt und vom Microsoft-Backend bearbeitet wird.
3. Umgebungsisolation (PostgreSQL RLS)
Bei der Laufzeitsicherheit geht es nicht nur um Microsoft-Kontingente. Wir müssen sicherstellen, dass ein Analyst keine KQL-Abfrage an einen Mieter senden kann, der ihm nicht gehört.
Dank des Mechanismus vonSicherheit auf Zeilenebene (RLS)Integriert in unsere PostgreSQL-Datenbank wird die Validierung der Mitgliedschaft des Zielmandanten im Arbeitsbereich des Analysten physisch überprüft, bevor die Microsoft-API überhaupt angefordert wird.
Optimieren Sie Ihre KQL-Abfragen: Best Practices
Selbst mit der besten Ratenbegrenzung der Welt bleibt die Qualität der KQL-Abfrage von entscheidender Bedeutung. Hier sind einige goldene Regeln, die in unsere „Schnellvorlagen“ integriert sind, um Ihre Quoten zu wahren:
- Verwenden Sie immer einen Zeitfilter (
TimeGenerated):Begrenzen Sie die Suche auf die letzten 7 oder 14 Tage. - Vor dem Formatieren filtern:Verwenden Sie die Klausel
whereso früh wie möglich in Ihrem KQL-Skript, um das Datenvolumen zu reduzieren, bevor Sie Verknüpfungen anwenden (join) oder Zusammenfassungen (summarize). - Zielspezifische Tabellen:Suchen Sie nicht blind in allen Tabellen nach einer schädlichen Domäne. Ziel
DeviceNetworkEventsfür Netzwerkverkehr undDeviceProcessEventsfür Auftragszeilen.
Fazit: Orchestrierung mit völliger Sicherheit
Die Automatisierung der Bedrohungssuche ist für die Skalierung notwendig, sollte jedoch nicht auf Kosten der Stabilität der Infrastruktur Ihrer Kunden gehen. Durch die Einbettung von Fluss- und Warteschlangenkontrollmechanismen ermöglicht eine moderne SOC-Plattform Ihren Teams, Bedrohungen mit Zuversicht aufzuspüren.
Sind Sie bereit, Ihre Abfragen ohne Blockierungsrisiko bereitzustellen?> Entdecken Sie, wie unsere KonsoleZentralisiertes KQL für die Bedrohungssuche für MSSPverwaltet nativ die Geschwindigkeit Ihrer Untersuchungen.