Seguridad de Elasticsearch para agentes de IA — Bloquea borrados masivos, controla _reindex
La seguridad de Elasticsearch para agentes de IA inspecciona método HTTP, ruta y cuerpo de la solicitud. DELETE y _delete_by_query se bloquean, _bulk y _reindex requieren aprobación, y FutrixData también detecta consultas sin límite (match_all, from + size profundos, agregaciones sin script).
Por qué Elasticsearch necesita controles distintos
En Elasticsearch, el riesgo a menudo se oculta en el método HTTP, la ruta de la API y el cuerpo de la solicitud. Un POST puede ser una búsqueda o una escritura masiva; un _search puede convertirse en un escaneo sin límite; una agregación sin filtros puede escanear miles de millones de documentos. FutrixData trata Elasticsearch como una API HTTP — parseando ruta, método y cuerpo JSON — en lugar de ejecutar consultas con la API _profile_ (que en sí mismas serían costosas).
Reglas integradas de Elasticsearch
| Operación | Acción por defecto |
|---|---|
GET, HEAD, POST _search, POST _count | allow |
Solicitudes DELETE | block |
POST _delete_by_query | block |
_bulk, _reindex, _update_by_query | require_approval |
Configuración — _settings, _mapping, _aliases, plantillas, pipelines, ILM/SLM | require_approval |
PUT, PATCH rutinarios, POST que no son de búsqueda | warn |
Análisis del cuerpo de la solicitud
Más allá del método y la ruta, FutrixData inspecciona el cuerpo de la solicitud en busca de:
- Consultas amplias —
match_all,wildcard,regexp,fuzzy. - Búsquedas que carecen del campo
query. - Agregaciones sin filtros.
sizeexcesivo o paginación profunda mediantefrom + size.scriptyscript_score.- Agregaciones profundamente anidadas.
- Agregaciones de términos sin
sizeestablecido.
Reglas por patrón de índice
Las reglas pueden acotarse por patrón de índice, método y ruta. Ejemplos:
- Prohibir
DELETEsobreaudit-*. - Requerir aprobación para
_reindexcontra índices de producción. - Mantener las agregaciones sin filtros en nivel de advertencia para comodidad de los analistas.
Ejemplos
// Agent attempts:
POST /orders-2024/_delete_by_query
{ "query": { "match_all": {} } }
// FutrixData response:
{ "ok": false, "risk": "block", "rule": "es.delete_by_query" }// Agent attempts:
POST /_reindex
{ "source": { "index": "orders-2023" }, "dest": { "index": "orders-archive" } }
// FutrixData response:
{ "ok": false, "risk": "require_approval", "rule": "es.reindex" }Preguntas frecuentes
¿Esto funciona con OpenSearch?
Sí. FutrixData habla la API HTTP estándar de Elasticsearch; OpenSearch responde a las mismas rutas. Las reglas aplican de forma idéntica.
¿Puedo permitir _bulk en staging?
Sí — por fuente de datos y modo de confianza. Pon el cluster de staging en Trusted para que _bulk se autoejecute; mantén producción en Cautious para que requiera aprobación.
¿Inspecciona scripts Painless?
La inspección de cuerpo marca solicitudes que contienen script y script_score. Marcar significa warn o superior; puedes bloquear de forma dura las consultas con script en fuentes de producción.
¿Qué pasa con ILM/SLM?
Los endpoints de ILM y SLM caen en require_approval por defecto — cambian políticas de retención y snapshots, y no deberían editarse desde el contexto de un agente sin confirmación explícita.
¿Autenticación del cluster?
FutrixData se conecta con las credenciales que configures (basic auth, API key, mTLS para OpenSearch). Esas credenciales nunca abandonan el host donde se despliega FutrixData.
Prueba FutrixData con tu propia base de datos
Aplicación de escritorio gratuita para macOS, Windows y Linux. Enterprise Edition autoalojada para despliegues en producción.