ВозможностиДокументацияЦеныPlaygroundFAQ

Политики

Правила allow/deny для контроля выполнения команд

~7 мин чтения

Архитектура

Политики хранятся в PostgreSQL и синхронизируются с агентами через WebSocket. Каждый агент получает набор правил при подключении и кэширует их локально для быстрого анализа.

Database Schema

policies— Именованные наборы правил
policy_rules— Allow/deny правила с glob-паттернами
agent_policy_bindings— Привязка политик к агентам

⚡ Real-time sync

Изменения в политике применяются к агентам мгновенно через WebSocket. Не требуется перезапуск агента.

Типы правил

ALLOW

Команда разрешена без дополнительной проверки

docker ps*

DENY

Команда заблокирована навсегда

rm -rf *

Policy DSL

Правила используют glob-паттерны для матчинга команд. Звёздочка (*) соответствует любым символам.

docker ps*ALLOW

Matches

✓ docker ps✓ docker ps -a✓ docker ps --format json

Not Matches

✗ docker run✗ docker rm
*rm -rf*DENY

Matches

✓ rm -rf /var/log✓ sudo rm -rf /tmp✓ /bin/rm -rf file.txt

Not Matches

✗ rm file.txt✗ rm -r dir✗ rm -f file
cat .env*DENY

Matches

✓ cat .env✓ cat .env.local✓ cat .env.production

Not Matches

✗ cat env.txt✗ cat .envbackup✗ cat file.env.bak
npm installALLOW

Matches

✓ npm install✓ npm install express✓ npm install --save-dev jest

Not Matches

✗ npm uninstall✗ npm update✗ yarn install

Priority System

Правила обрабатываются в порядке убывания priority. Правило с более высоким priority перезаписывает правило с низким. DENY всегда имеет приоритет над ALLOW при одинаковом priority.

Пример приоритизации

DENY*priority:100Block everything (default deny)
ALLOWdocker*priority:200Allow all docker commands
DENYdocker*rm*priority:300But block docker rm
ALLOWdocker rm -f stoppedpriority:400Except specific safe case

# Evaluation for "docker rm -f stopped":

100: DENY *

200: ALLOW docker* (matches)

300: DENY docker*rm* (matches, higher priority)

400: ALLOW docker rm -f stopped (matches, highest priority)

→ Result: ALLOW (priority 400)

API

bash
# Создать политику
curl -X POST https://flowlink.flow-masters.ru/api/v1/policies \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Production",
    "description": "Production server rules"
  }'

# Ответ: {"id": "pol_abc123", "name": "Production", ...}

# Добавить правило
curl -X POST https://flowlink.flow-masters.ru/api/v1/policies/pol_abc123/rules \
  -H "Content-Type: application/json" \
  -d '{
    "rule_type": "deny",
    "pattern": "rm -rf *",
    "priority": 200,
    "description": "Block recursive delete"
  }'

# Привязать к агенту
curl -X POST https://flowlink.flow-masters.ru/api/v1/policies/bind \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": "pol_abc123",
    "agent_id": "my-server"
  }'

# Получить все политики
curl -X GET https://flowlink.flow-masters.ru/api/v1/policies \
  -H "Authorization: Bearer YOUR_JWT_TOKEN"

# Получить правила политики
curl -X GET https://flowlink.flow-masters.ru/api/v1/policies/pol_abc123/rules \
  -H "Authorization: Bearer YOUR_JWT_TOKEN"

Default Policy

При регистрации агента автоматически создаётся Default Policy с базовыми правилами защиты. Она привязывается ко всем новым агентам.

Default Policy Rules

docker ps*ALLOW100List containers
docker imagesALLOW100List images
ls*ALLOW100List files
cat *ALLOW100Read files (no .env)
*rm -rf*DENY200Block recursive delete
*docker*privileged*DENY300Block privileged docker
*.env*DENY200Block .env access
curl * | bashDENY300Block pipe to bash

Примеры политик

Политика для Web разработки

Разрешить типичные команды для web-разработки

ALLOWnpm install*100
ALLOWnpm run*100
ALLOWyarn*100
ALLOWdocker-compose up*100
ALLOWdocker-compose build*100
DENY*rm -rf node_modules*200

Политика управления Docker

Разрешить управление Docker контейнерами

ALLOWdocker ps*100
ALLOWdocker images100
ALLOWdocker build*100
ALLOWdocker run*100
ALLOWdocker stop*100
DENYdocker*rm*200
DENYdocker*privileged*300
DENYdocker*v /:/*300

Kubernetes Policy

Безопасная работа с kubectl

ALLOWkubectl get*100
ALLOWkubectl describe*100
ALLOWkubectl logs*100
ASKkubectl apply -f*100
DENYkubectl delete*200
DENYkubectl*production*300

Тестирование политик

Используйте Playground API для тестирования политик без выполнения команд:

bash
# Тестировать политику
curl -X POST https://flowlink.flow-masters.ru/api/playground/scan \
  -H "Content-Type: application/json" \
  -d '{
    "command": "rm -rf /var/log",
    "agent_id": "my-server",
    "dry_run": true
  }'

# Ответ с анализом политики:
{
  "command": "rm -rf /var/log",
  "shield_result": {
    "level": "L4",
    "decision": "BLOCKED",
    "reason": "Destructive command: recursive force delete"
  },
  "policy_result": {
    "matched_rule": {
      "pattern": "*rm -rf*",
      "type": "DENY",
      "priority": 200,
      "policy_id": "pol_abc123"
    },
    "decision": "DENY"
  },
  "final_decision": "BLOCKED"
}

Best Practices

Use default deny

Начните с правила DENY * и добавляйте ALLOW для нужных команд

Priority spacing

Используйте шаг 100 для priority (100, 200, 300) для простоты добавления

Specific over general

Более конкретные паттерны должны иметь более высокий priority

Test in playground

Всегда тестируйте новые правила в Playground перед применением

Document policies

Добавляйте description к каждому правилу для будущей отладки

Audit regularly

Проверяйте и обновляйте политики регулярно

← ShieldПаттерны →