Files
AWatch-rus/docs/powershell-analysis.md
T
igor04091968andDevin <158243242+devin-ai-integration[bot]@users.noreply.github.com> 9e5cb144d4 fix(windows): standardize config paths to AWatch-rus and add bucket hostname filter
- Replace default config paths from C:\ProgramData\ActivityWatch to C:\ProgramData\AWatch-rus
  in dlp-endpoint-signals-collector.ps1 and email-outbound-collector.ps1
- Add isLikelyClientHost() function to reject IP/localhost as valid hostname
  for bucket selection in aw-ru-patch.js
- Add docs/dlp-reliability-roadmap.md and docs/powershell-analysis.md
- Update README.md with links to new documentation

Generated with [Devin](https://cli.devin.ai/docs)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
2026-05-04 23:24:49 +03:00

4.2 KiB
Raw Blame History

Анализ DLP-скриптов PowerShell (работоспособность)

Дата анализа: 2026-05-04 (UTC)

Проверенный scope

  • windows/dlp-endpoint-signals-collector.ps1
  • windows/file-operations-collector.ps1
  • windows/dlp-policy.example.json
  • windows/web-category-rules.example.json

Ключевой итог

DLP-скрипты в целом рабочие по архитектуре (heartbeat в ActivityWatch, policy-driven правила, cooldown, enforcement), но есть критичный риск misconfiguration и несколько эксплуатационных рисков.


Что точно хорошо

  1. В обоих коллекторах включены Set-StrictMode -Version Latest и $ErrorActionPreference = 'Stop'.
  2. Есть отправка событий в отдельные bucket’ы (aw-dlp-endpoint-signals_*, aw-dlp-incidents_*, aw-file-operations_*).
  3. В endpoint-коллекторе реализованы:
    • правила по буферу обмена / USB / печати,
    • suppression через cooldown (Should-EmitByCooldown),
    • опциональный screenshot capture при инциденте.
  4. В file collector есть наблюдение за Desktop/Documents/Downloads через FileSystemWatcher.

Найденные проблемы и риски

1) Критично: дефолтный путь конфига в endpoint-скрипте не совпадает с проектом

  • dlp-endpoint-signals-collector.ps1 использует по умолчанию:
    • C:\ProgramData\AWatch-rus\deployment-config.json
  • Остальной проект использует namespace AWatch-rus (C:\ProgramData\AWatch-rus\...).

Риск: endpoint-коллектор может стартовать без нужного deployment-конфига и работать с неверными/пустыми параметрами.

2) Нет строгой проверки HTTP-результата в file collector

В file-operations-collector.ps1 POST выполняется через HttpClient, но код ответа не валидируется (IsSuccessStatusCode не проверяется), ошибки частично только логируются.

Риск: «тихая» потеря telemetry при 4xx/5xx.

3) Watcher не снимает event subscriptions явно

Есть Register-ObjectEvent, но в finally disposal только watcher-объектов; отписка событий (Unregister-Event) явно не делается.

Риск: при рестартах/долгой работе возможно накопление подписок в сессии.

4) Screenshot/GUI-зависимость для enforcement

Capture-IncidentScreenshot и balloon notification завязаны на System.Windows.Forms/System.Drawing.

Риск: в non-interactive / service context часть enforcement UX может не работать (событие уйдёт, но скриншот/уведомление может не сформироваться).


Рекомендации (приоритет)

  1. P1: выровнять дефолтный ConfigPath в dlp-endpoint-signals-collector.ps1 на C:\ProgramData\AWatch-rus\deployment-config.json.
  2. P1: добавить проверку response.IsSuccessStatusCode в file-operations-collector.ps1 и логировать body/status при ошибках.
  3. P2: сохранить subscription-объекты Register-ObjectEvent и делать Unregister-Event в finally.
  4. P2: для enforcement/UI добавить fallback режим «headless» (только лог + heartbeat).

Что не удалось проверить в текущей среде

В этом контейнере отсутствует pwsh, поэтому не выполнены:

  • синтаксический parse всех *.ps1/*.psm1 через PowerShell parser;
  • Test-ModuleManifest;
  • smoke-run на Windows API (Get-WinEvent, Get-Partition, Get-Disk, Set-Clipboard, Win32_PrintJob).