Elasticsearch-Sicherheit

Elasticsearch-Sicherheit für KI-Agenten — Bulk-Deletes blockieren, _reindex gaten

Q: Werden Painless-Skripte inspiziert?

Die Body-Inspektion markiert Requests mit script und script_score . Markieren bedeutet warn oder höher; Sie können geskriptete Queries auf Produktionsquellen hart blockieren.

Elasticsearch-Sicherheit für KI-Agenten inspiziert HTTP-Methode, Pfad und Request-Body. DELETE und _delete_by_query werden blockiert, _bulk und _reindex erfordern Approval, und FutrixData erkennt zusätzlich unbegrenzte Queries (match_all, tiefes from + size, Aggregationen ohne Skript-Filter).

macOS herunterladen Zur Dokumentation

Warum Elasticsearch andere Kontrollen braucht

In Elasticsearch versteckt sich Risiko oft in HTTP-Methode, API-Pfad und Request-Body. Ein POST kann ein Search oder ein Bulk-Write sein; ein _search kann zu einem unbegrenzten Scan werden; eine Aggregation ohne Filter kann Milliarden Dokumente scannen. FutrixData behandelt Elasticsearch als HTTP-API — und parst Pfad, Methode und JSON-Body — statt eigenständige Profile-API-Queries zu fahren (die selbst teuer wären).

Eingebaute Elasticsearch-Regeln

Operation	Standardaktion
`GET`, `HEAD`, `POST _search`, `POST _count`	allow
`DELETE`-Requests	block
`POST _delete_by_query`	block
`_bulk`, `_reindex`, `_update_by_query`	require_approval
Konfiguration — `_settings`, `_mapping`, `_aliases`, Templates, Pipelines, ILM/SLM	require_approval
Routine-`PUT`, `PATCH`, Non-Search-`POST`	warn

Body-Analyse

Über Methode und Pfad hinaus inspiziert FutrixData den Request-Body auf:

Breite Queries — match_all, wildcard, regexp, fuzzy.
Searches ohne query-Feld.
Aggregationen ohne Filter.
Übermäßiges size oder tiefe Paginierung über from + size.
script und script_score.
Tief verschachtelte Aggregationen.
Terms-Aggregationen ohne gesetztes size.

Regeln auf Index-Pattern-Ebene

Regeln können nach Index-Pattern, Methode und Pfad gescopt werden. Beispiele:

DELETE auf audit-* verbieten.
Approval für _reindex gegen Produktions-Indices verlangen.
Filterlose Aggregationen für Analysten-Komfort auf Warning-Level halten.

Beispiele

Bulk-Delete abgefangen

// Agent attempts:
POST /orders-2024/_delete_by_query
{ "query": { "match_all": {} } }

// FutrixData response:
{ "ok": false, "risk": "block", "rule": "es.delete_by_query" }

Reindex erfordert Approval

// Agent attempts:
POST /_reindex
{ "source": { "index": "orders-2023" }, "dest": { "index": "orders-archive" } }

// FutrixData response:
{ "ok": false, "risk": "require_approval", "rule": "es.reindex" }

Häufig gestellte Fragen

Funktioniert das mit OpenSearch?

Ja. FutrixData spricht die Standard-Elasticsearch-HTTP-API; OpenSearch antwortet auf dieselben Routen. Regeln gelten identisch.

Kann ich _bulk auf Staging erlauben?

Ja — pro Datenquelle und Trust-Modus. Setzen Sie den Staging-Cluster auf Trusted, sodass _bulk automatisch ausgeführt wird; halten Sie Produktion auf Cautious, sodass Approval erforderlich ist.

Werden Painless-Skripte inspiziert?

Die Body-Inspektion markiert Requests mit script und script_score. Markieren bedeutet warn oder höher; Sie können geskriptete Queries auf Produktionsquellen hart blockieren.

Was ist mit ILM/SLM?

ILM- und SLM-Endpunkte landen standardmäßig auf require_approval — sie ändern Retention- und Snapshot-Policies und sollten nicht aus einem Agenten-Kontext ohne explizite Bestätigung editiert werden.

Cluster-Authentifizierung?

FutrixData verbindet sich mit den von Ihnen konfigurierten Credentials (Basic Auth, API-Key, mTLS für OpenSearch). Diese Credentials verlassen den Host, auf dem FutrixData deployt ist, nie.

Probieren Sie FutrixData mit Ihrer eigenen Datenbank aus

Kostenlose Desktop-App für macOS, Windows und Linux. Self-hosted Enterprise Edition für produktive Deployments.

Desktop-App herunterladen Zur Dokumentation