Перейти к содержимому
Размах

Pre-launch credentials rotation strategy

Context

После 2 weeks Phase 0 dev (research + walkthrough + infrastructure setup на razmakh-vps) Николай явно сказал: “Включив план, когда уже сервис будет готов, нужно будет ротировать пароли, так как во время разработки они много где всплывут.”

What we learned

1. Dev credentials leak в множестве surface points

  • Claude session jsonl logs (вся история bash output)
  • Терминал scrollback на dev машинах
  • bash_history
  • ssh known_hosts (host keys, не critical)
  • Password manager autofill memory
  • Browser autofill memory
  • Editor recent files / clipboard manager
  • Chat transcripts (TG, Slack, etc.)
  • Git commits если случайно (pre-commit hook ловит большинство, но не всё)
  • CI/CD logs если debug verbose
  • Backup snapshots до rotation

Заключение: невозможно guaranteed “clean” current state — единственный safe path = rotation event.

2. Password reuse antipattern легко возникает

В session 2026-05-17 Николай setup Infisical admin password = тот же что VPS root. Я не остановил это — должен был flag сразу. Each service = unique password, всегда.

3. Credentials hygiene = scheduled discipline

Single rotation перед launch недостаточно. Required ongoing:

  • CF token: annual (или immediate on incident)
  • VPS root: quarterly (или immediate)
  • Infisical encryption keys: annual (disruptive — нужно planning + downtime window)
  • WB tokens per org: 60-day auto (Infisical feature если supported)
  • DB passwords: annual + immediate если staff change

4. Phase gate = более чем feature checklist

Walkthrough приоритизировал feature blocks (1.5.1-1.5.6) + compliance (РКН/DPA/privacy/ToS/cookie). Но upgrade гигиены инфраструктуры (credentials rotation, backup restore drill, security audit) — separate gate, нельзя в feature scope.

5. Сразу documenting catches = save 100x effort later

Если бы не было explicit Николая ask — этот rotation strategy не был бы в plan, и launch happened с leaked dev creds. Сейчас зафиксировано → execute в Block 1.5.0 → clean state.

What to apply (Phase 1+)

Per-decision

  • Add to PR template: “Did this PR introduce new credentials? If yes — added to rotation runbook?”
  • Pre-commit hook expanded: flag any pattern looking like long random string (potential credential commit)
  • Infisical lifecycle hooks: alert если creation date > X months ago (rotation reminder)

Per-runbook

  • Update vps-bootstrap runbook: add note о rotation Round 1 при launch
  • Update on-call runbook (Phase 1.5+): rotation procedure if compromise suspected

Per-process

  • Credentials inventory — single source of truth file (Infisical itself + meta tracking)
  • Annual security review as scheduled task (Phase 2+)
  • Post-incident rotation — automatic trigger procedure

What to NEVER do

  • ❌ Reuse passwords между services
  • ❌ Save plain creds в Git/chat/TG long-term (только Infisical)
  • ❌ Skip pre-rotation backup
  • ❌ Rotate ENCRYPTION_KEY без backup всех secrets first
  • ❌ Skip verification после каждого rotation step
  • ❌ Assume “current creds OK” если они появлялись в session logs

Action items

  • Decision record created: razmakh-pre-launch-credentials-rotation-2026-05-17.md
  • Runbook created: razmakh-pre-launch-credentials-rotation.md
  • plan/active/1.5-multi-org-partners.md updated с Block 1.5.0
  • DECISIONS.md addendum (7th critical decision)
  • This lesson captured
  • Phase 1 PR template update — add “Credentials introduced?” question (F-01 implementation)
  • Pre-commit hook expansion (Phase 1 F-12 — security CI)
  • Infisical age monitoring script (Phase 1.5)

ID metric

  • Lesson capture time: 15 min
  • Decision + runbook + plan update + addendum + lesson: ~30 min total
  • Estimated time savings vs catching only at launch: 4-8 hours (incident response + emergency rotation + investigation)
  • Risk reduction: critical (prevents partner data exposure через compromised admin)