Policy Engine

Типы политик, условия, действия, порядок оценки, кастомные политики и ML-генерация предложений

Обзор

Policy Engine — это ядро системы безопасности FlowLink. Он анализирует каждую команду перед выполнением, сопоставляя с набором правил (политик). Политики определяют, разрешена, заблокирована или требует одобрения команда. Дополнительный ML-модуль анализирует поведение агентов за 7-30 дней и генерирует предложения по оптимизации политик с confidence score.

Типы действий

allow, deny, require_approval

Все тарифы

Условия

Command, agent, tag, time, env

Все тарифы

ML предложения

Auto-generated на основе паттернов

Team+

Evaluation order

deny → allow → require_approval

Все тарифы

Как работает Policy Engine

Каждая команда проходит через Pipeline: Shield scan (L1-L4 risk detection) → Policy evaluation → Decision. Policy Engine обрабатывает правила в строгом порядке: сначала deny-правила (безопасность по умолчанию), затем allow (whitelist), затем require_approval (если не покрыто другими правилами). Первое совпавшее правило определяет результат.

# Pipeline оценки политики

1. DENY правила (pattern match)

Если команда совпадает с deny-паттерном → немедленная блокировка

2. ALLOW правила (whitelist)

Если команда совпадает с allow-паттерном → выполнение без доп. проверок

3. REQUIRE_APPROVAL правила

Если команда совпадает → запрос на согласование администратору

4. DEFAULT → deny (если нет совпадений)

Типы политик

DENYПриоритет: 1

Блокировка команды. Вызывается первым. Pattern matching по команде и условиям. Поддерживает glob и regex.

Пример: rm -rf *, * > /dev/shm/*

ALLOWПриоритет: 2

Разрешение команды. Whitelist для безопасных команд. Пропускает через Shield scan (но не блокирует).

Пример: git status, docker ps, ls *

REQUIRE_APPROVALПриоритет: 3

Запрос согласования. Команда ставится в очередь ожидания. Администратор должен подтвердить или отклонить в течение timeout.

Пример: kubectl apply *, docker restart *

Условия политик

Каждая политика может содержать набор условий. Все условия внутри правила объединяются через AND. Для OR-логики создайте отдельные правила.

Условие	Тип	Описание
command	glob \| regex	Паттерн команды (обязательное)
agent_id	string \| glob	ID агента или паттерн
tags	array	Массив тегов агента (AND/OR)
time_range	cron \| range	Временное окно (например, рабочие часы)
env	key:value	Переменные окружения на агенте
risk_score	min:max	Диапазон risk score команды
executed_by	string	Кто инициировал команду

Конфигурация

yaml

1# Полный пример конфигурации политик
2policy_engine:
3  enabled: true
4  default_action: "deny"              # deny | allow | require_approval
5  
6  # ML генерация предложений
7  ml_proposals:
8    enabled: true
9    analysis_period_days: 14
10    min_executions_for_proposal: 10
11    confidence_threshold: 0.7
12    auto_notify: true
13    notification_channels: [telegram, email]
14  
15  # Approval настройки
16  approval:
17    timeout_seconds: 300              # 5 минут на согласование
18    expire_action: "deny"             # deny | allow (по истечении timeout)
19    notify_channels: [telegram]
20  
21  # Rate limiting
22  rate_limits:
23    default_per_minute: 60
24    per_agent_per_minute: 30

API Reference

Создание политики

bash

1curl -X POST "https://api.flowlink.io/v1/policies" \
2  -H "Authorization: Bearer $TOKEN" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "name": "Deny destructive commands",
6    "action": "deny",
7    "priority": 1,
8    "enabled": true,
9    "conditions": {
10      "command": { "pattern": "rm -rf *", "match_type": "glob" },
11      "tags": ["env:production"]
12    },
13    "description": "Block recursive force delete in production"
14  }'

json

1{
2  "id": "pol_deny_destructive",
3  "name": "Deny destructive commands",
4  "action": "deny",
5  "priority": 1,
6  "enabled": true,
7  "conditions": {
8    "command": { "pattern": "rm -rf *", "match_type": "glob" },
9    "tags": ["env:production"]
10  },
11  "description": "Block recursive force delete in production",
12  "created_at": "2026-01-15T14:00:00Z",
13  "created_by": "admin@example.com",
14  "match_count": 0,
15  "last_matched_at": null
16}

Список политик

bash

1curl -s "https://api.flowlink.io/v1/policies?action=deny&limit=50" \
2  -H "Authorization: Bearer $TOKEN" | jq

json

1{
2  "policies": [
3    {
4      "id": "pol_deny_destructive",
5      "name": "Deny destructive commands",
6      "action": "deny",
7      "priority": 1,
8      "enabled": true,
9      "match_count": 47,
10      "last_matched_at": "2026-01-15T13:55:00Z"
11    },
12    {
13      "id": "pol_allow_readonly",
14      "name": "Allow read-only commands",
15      "action": "allow",
16      "priority": 2,
17      "enabled": true,
18      "match_count": 15200,
19      "last_matched_at": "2026-01-15T14:00:00Z"
20    }
21  ],
22  "total": 2
23}

Обновление политики

bash

1curl -X PATCH "https://api.flowlink.io/v1/policies/pol_deny_destructive" \
2  -H "Authorization: Bearer $TOKEN" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "enabled": true,
6    "conditions": {
7      "command": { "pattern": "rm -rf *|mkfs.*|dd if=*", "match_type": "regex" }
8    }
9  }'

Удаление политики

bash

1curl -X DELETE "https://api.flowlink.io/v1/policies/pol_deny_destructive" \
2  -H "Authorization: Bearer $TOKEN"

Dry-run проверки

bash

1curl -X POST "https://api.flowlink.io/v1/policies/dry-run" \
2  -H "Authorization: Bearer $TOKEN" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "command": "rm -rf /tmp/build",
6    "agent_id": "agent-prod-01"
7  }'

json

1{
2  "command": "rm -rf /tmp/build",
3  "agent_id": "agent-prod-01",
4  "result": "deny",
5  "matched_policy": {
6    "id": "pol_deny_destructive",
7    "name": "Deny destructive commands",
8    "action": "deny"
9  },
10  "evaluation_order": [
11    { "policy_id": "pol_deny_destructive", "matched": true, "action": "deny" }
12  ]
13}

ML-генерация предложений

ML-модуль анализирует историю команд и генерирует предложения по оптимизации политик. Каждое предложение имеет confidence score на основе 4 факторов. Предложения НЕ применяются автоматически.

confidence = (f1 + f2 + f3 + f4) / 4

f1: execution_frequency (0-1) — как часто используется команда

f2: approval_rate (0-1) — доля одобренных выполнений

f3: risk_trend (0-1) — снижающийся тренд риска

f4: agent_trust (0-1) — исторический trust level агента

API предложений

bash

1curl -s "https://api.flowlink.io/v1/policy-proposals?status=pending" \
2  -H "Authorization: Bearer $TOKEN" | jq

json

1{
2  "proposals": [
3    {
4      "id": "prop_xyz789",
5      "type": "allow_command",
6      "agent_id": "agent-prod-01",
7      "command_pattern": "docker ps*",
8      "description": "docker ps blocked 47 times, 100% legitimate uses",
9      "confidence": 0.95,
10      "factors": {
11        "execution_frequency": 0.9,
12        "approval_rate": 1.0,
13        "risk_trend": 0.95,
14        "agent_trust": 0.95
15      },
16      "status": "pending",
17      "suggested_policy": {
18        "match": { "command": "docker ps*" },
19        "action": "allow",
20        "tags": ["env:production"]
21      },
22      "created_at": "2026-01-15T14:00:00Z"
23    }
24  ]
25}

bash

1# Применить предложение
2curl -X POST "https://api.flowlink.io/v1/policy-proposals/prop_xyz789/apply" \
3  -H "Authorization: Bearer $TOKEN"
4
5# Отклонить предложение
6curl -X POST "https://api.flowlink.io/v1/policy-proposals/prop_xyz789/reject" \
7  -H "Authorization: Bearer $TOKEN" \
8  -d '{"reason": "Too broad pattern"}'

Устранение неполадок

Команда заблокирована, хотя не должна

Используйте POST /policies/dry-run для проверки. Проверьте evaluation_order — deny-правила обрабатываются первыми. Проверьте что условия (tags, agent_id) корректны.

Policy не срабатывает

Проверьте что enabled: true. Убедитесь что приоритет корректен. Проверьте match_type — glob использует * и ?, regex требует валидного выражения.

Лучшие практики

Default deny

Установите default_action: deny для security by default. Явно разрешайте только безопасные команды.

Используйте tags для группировки

Разделяйте агентов по окружениям (env:production, env:staging) и применяйте разные политики для разных групп.

Тестируйте с dry-run

Перед созданием политики проверьте её через dry-run. Это предотвратит случайную блокировку легитимных команд.

Регулярно просматривайте ML-предложения

ML предложения могут выявить неправильно настроенные политики. Высокий confidence (0.8+) означает, что команда стабильно легитимна.

Documentar политики

Заполняйте description для каждой политики. Это критично для audit и для понимания why команда заблокирована.

← Risk Scores Forensics →

Оценка рисков

Canary Tokens

Edit this page