БЕЗОПАСНОСТЬ И PRODUCTION HARDENING CONTROL CENTER Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по безопасной эксплуатации Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Инструкция формирует production baseline для authentication, RBAC, сети, TLS, secrets, backup, Audit, обновлений, Market-модулей, административного доступа и recovery. Она не заменяет требования вашей организации, но задает минимальный безопасный эксплуатационный подход. ПРИНЦИПЫ - least privilege; - deny/fail closed при неопределенности опасной mutation; - server-side permission validation; - Change/Job/Audit для значимых изменений; - отсутствие постоянных секретов в логах/скриптах/документах; - подписанные update/module artifacts; - backup + проверенный restore; - staged network changes с rollback; - HA проверяется реальными failover tests; - security controls не отключаются ради удобства настройки. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Control Center | Установлен и Healthy admin | Первоначальный пароль изменен RBAC | Доступна ролевая модель Network | Интерфейсы/зоны документированы TLS | [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемая certificate model] Backup | Настроен и протестирован restore Audit | Включен и доступен Updates | Известен поддерживаемый release channel Recovery | Есть console/OOB или иной emergency path РАЗДЕЛ 1. АУТЕНТИФИКАЦИЯ После чистой установки `admin/admin` допускается только для bootstrap. При первом входе пароль должен быть обязательно изменен, а обычная работа до смены пароля запрещена. Проверка: - новый пароль работает; - `admin/admin` не работает; - после update пароль не сбрасывается; - активные сессии можно отозвать штатно. Рекомендуется использовать персональные административные учетные записи и не выполнять повседневную работу общей учетной записью. [ТРЕБУЕТ УТОЧНЕНИЯ: MFA/WebAuthn/external IdP support текущей версии]. РАЗДЕЛ 2. RBAC И LEAST PRIVILEGE 1. Выдавайте минимальные permissions. 2. Ограничивайте scopes конкретными sites/nodes/resources. 3. Регулярно проверяйте bindings. 4. Удаляйте неиспользуемый доступ. 5. Перед удалением последнего administrator binding проверяйте recovery path. 6. Критические действия разделяйте по ролям, если версия поддерживает approval/separation of duties. Риск: Избыточная глобальная роль увеличивает blast radius компрометации. Проверка: Тестовая ограниченная учетная запись может выполнить разрешенную операцию и получает отказ на запрещенную. РАЗДЕЛ 3. СЕТЕВОЕ РАЗДЕЛЕНИЕ Разделяйте WAN, LAN и Management zones согласно документам 07–09. Критически важно: WAN+LAN не включает routing, NAT или forwarding автоматически. Production baseline: - административный доступ идет из разрешенного management scope; - firewall использует минимально необходимые rules; - нет catch-all NAT/port forwarding; - изменение management IP выполняется staged; - есть OOB/console для критических сетевых операций; - ненужные interfaces/services не публикуются наружу. Не открывайте административный Web UI напрямую всему Internet без специально предусмотренного защищенного контура. РАЗДЕЛ 4. TLS И СЕРТИФИКАТЫ Используйте TLS для административного интерфейса и межкомпонентных trust boundaries там, где это предусмотрено продуктом. Проверьте: - FQDN соответствует сертификату; - certificate chain доверена административным клиентам; - private key не хранится в открытом backup/log; - срок действия отслеживается; - renewal выполняется до expiration. [ТРЕБУЕТ УТОЧНЕНИЯ: встроенный certificate manager/ACME/import/rotation workflow]. ПРЕДУПРЕЖДЕНИЕ: Не отключайте проверку TLS certificate из-за ошибки имени или цепочки. Исправьте FQDN, trust chain или сертификат. РАЗДЕЛ 5. SECRET MANAGEMENT Секреты должны храниться через поддерживаемый Secret Store/credential reference. Никогда не помещайте secrets в: - playbooks; - shell history; - issue/comments; - Audit reason; - support bundle без необходимости; - screenshot документации; - публичные exports. Проверьте rotation/revoke procedure для: - automation credentials; - API/service credentials, если поддерживаются; - TLS keys; - module credentials; - external integrations. [ТРЕБУЕТ УТОЧНЕНИЯ: Secret Store recovery/rotation model]. РАЗДЕЛ 6. HOST/OS HARDENING Control Center должен устанавливаться только на поддерживаемую ОС. Production baseline: - устанавливайте security updates ОС по согласованной процедуре; - используйте dedicated system users/services, создаваемые штатным installer; - не меняйте permissions внутренних директорий вручную без документации; - не устанавливайте случайные сторонние packages на critical control nodes; - ограничивайте интерактивный root access; - используйте firewall и management network; - синхронизируйте NTP. [ТРЕБУЕТ УТОЧНЕНИЯ: official OS hardening matrix, package/service paths]. РАЗДЕЛ 7. BACKUP SECURITY Backup может содержать критические конфигурационные/identity данные. 1. Храните копию вне единственного защищаемого узла. 2. Используйте encryption, если поддерживается/требуется. 3. Ограничьте read/delete permissions. 4. Храните recovery keys отдельно. 5. Используйте несколько recovery points. 6. Регулярно тестируйте restore. 7. Не считайте snapshot единственным application-aware backup без подтверждения поддержки. РАЗДЕЛ 8. UPDATE SECURITY Перед update: - Health = стабильный; - backup = verified; - artifact signature = verified; - compatibility plan = passed; - Market modules = compatible. После update: - `admin` password сохранен; - старый `admin/admin` не восстановлен; - RBAC intact; - Audit/Health работают; - новый backup создан. Не отключайте signature verification. РАЗДЕЛ 9. MARKET SECURITY Перед установкой любого модуля: 1. проверьте publisher/signature; 2. compatibility; 3. requested permissions; 4. network impact; 5. capacity; 6. data/backup requirements. Устанавливайте только необходимые modules. Каждый дополнительный модуль увеличивает attack surface и operational complexity. РАЗДЕЛ 10. SOFTWARE AUTOMATION SECURITY Linux: - проверяйте SSH host identity; - не используйте параметры отключения host-key verification; - предоставляйте минимальные sudo permissions. Windows: - используйте поддерживаемую защищенную WinRM/PSRP конфигурацию; - ограничивайте firewall источниками management network; - не включайте небезопасную authentication ради быстрого запуска. Automation credentials должны быть отделены от пользовательских паролей. РАЗДЕЛ 11. PXE SECURITY - не вмешивайтесь автоматически в существующий DHCP; - ограничивайте PXE scope; - используйте проверенные images; - используйте точную endpoint identity; - destructive reimage требует явного подтверждения; - не отключайте Secure Boot универсально; - boot/image services не должны быть доступны из Internet. РАЗДЕЛ 12. DOMAIN SERVICES SECURITY - DNS/NTP исправны; - domain admin credentials отделены от обычных учетных записей; - replicas/DC не выводятся одновременно; - backup directory data проверен; - domain controller decommission выполняется штатным demotion flow; - Samba AD DC/FreeIPA выбираются по архитектуре, а не смешиваются случайно. РАЗДЕЛ 13. INVENTORY И ДАННЫЕ Inventory собирает инфраструктурные сведения. Ограничьте: - scope; - collection credentials; - retention; - exports; - доступ к asset/software data. Не запускайте сетевой discovery вне разрешенного диапазона. РАЗДЕЛ 14. AUDIT Audit должен фиксировать административные изменения и сохраняться согласно retention policy. Регулярно проверяйте: - изменения RBAC; - network/firewall; - update/restore; - Market lifecycle; - decommission; - failed administrative actions. Audit не должен содержать secret values. [ТРЕБУЕТ УТОЧНЕНИЯ: audit immutability/retention/export settings]. РАЗДЕЛ 15. DIAGNOSTICS И SUPPORT BUNDLE Перед передачей diagnostics: 1. ограничьте временной диапазон; 2. используйте preview; 3. проверьте redaction; 4. удалите/исключите необязательные sensitive данные; 5. передавайте bundle по защищенному каналу; 6. удаляйте локальную копию после утвержденного срока. РАЗДЕЛ 16. HA SECURITY HA защищает доступность, но создает дополнительные trust relationships. Проверяйте: - node identity; - enrollment certificates/credentials; - quorum; - replication; - network segmentation; - version skew; - replacement/rejoin semantics. При неожиданном возвращении старого replaced node сначала изолируйте его, чтобы исключить split-brain. РАЗДЕЛ 17. EMERGENCY ACCESS Поддерживайте независимый recovery path: - console/OOB; - контролируемая локальная admin account; - recovery documentation; - доступ к backup/recovery keys. Emergency access не должен превращаться в постоянный shared root credential без контроля. [ТРЕБУЕТ УТОЧНЕНИЯ: first-admin/account recovery flow]. РАЗДЕЛ 18. КОМПРОМЕТАЦИЯ УЧЕТНЫХ ДАННЫХ Если credential скомпрометирован: 1. ограничьте доступ затронутой identity; 2. отзовите sessions/tokens/credentials штатно; 3. смените secret; 4. проверьте Audit с момента возможной компрометации; 5. проверьте Changes/Jobs/network rules; 6. при необходимости rotate зависимые secrets; 7. документируйте incident/recovery. Не удаляйте Audit ради сокрытия следов компрометации. РАЗДЕЛ 19. PRODUCTION CHECKLIST Authentication - [ ] `admin/admin` больше не работает; - [ ] уникальный пароль установлен; - [ ] персональные admin accounts используются; - [ ] MFA/external IdP настроены, если поддерживаются и требуются. Authorization - [ ] least privilege; - [ ] scopes проверены; - [ ] нет забытых global admin bindings. Network - [ ] management network ограничена; - [ ] WAN/LAN zones корректны; - [ ] routing/NAT только явные; - [ ] firewall minimal; - [ ] OOB/console доступен. Crypto/Secrets - [ ] TLS valid; - [ ] certificate expiration monitored; - [ ] secrets не хранятся открыто; - [ ] rotation procedure проверена. Data/Recovery - [ ] backup успешен; - [ ] restore-test выполнен; - [ ] recovery keys доступны; - [ ] RPO/RTO известны. Operations - [ ] Health/Alerts работают; - [ ] Audit доступен; - [ ] update process проверен; - [ ] failover test выполнен для HA; - [ ] support bundle redaction проверена. Market - [ ] установлены только нужные modules; - [ ] signatures/compatibility проверены; - [ ] module permissions reviewed; - [ ] stateful modules имеют backup. ТИПОВЫЕ ОШИБКИ Симптом | Возможная причина | Проверка | Решение Админ-интерфейс доступен из Internet | слишком широкая firewall/NAT policy | external test/policy | ограничить management scope, убрать ненужную публикацию После update вернулся admin/admin | security regression | login/Audit | немедленно сменить пароль, проверить sessions, обновиться/исправить версию Secrets видны в логах | неправильная redaction/config | logs/support preview | revoke/rotate secret, очистить допустимым retention process, исправить redaction Потерян admin access | удален последний binding/network rule | OOB/Audit | штатный recovery; восстановить минимальный доступ Модуль запросил неожиданные права | manifest/версия/ошибка конфигурации | permissions preview | не устанавливать до проверки РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - документируйте security baseline и регулярно сверяйте Actual с ним; - проверяйте доступы и firewall минимум при каждом значимом изменении; - выполняйте restore/failover drills; - обновляйте Core и modules по поддерживаемой схеме; - ограничивайте management plane; - не храните один общий секрет для всех automation/integrations; - расследуйте drift и неожиданные Changes; - используйте staged rollout для критических изменений. ИТОГ Production hardening Control Center строится вокруг защищенной authentication/RBAC, минимальной сети, TLS/secrets, проверяемых updates, backup/restore, Audit и контролируемого Market. Безопасность не должна зависеть от отключения проверок или скрытых ручных обходов штатного lifecycle. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - MFA/WebAuthn/external IdP; - certificate manager/TLS workflow; - Secret Store recovery/rotation; - OS hardening matrix; - audit immutability/retention; - support bundle redaction; - emergency admin recovery; - session/token model; - security alert catalog; - exact network/service exposure baseline.