SRE и безопасность (DevSecOps и SRE): кто отвечает за security?¶
Надежность и безопасность - это две основы устойчивости системы. Их часто (вернее, всегда) разводят по разным командам, что создает риски.
Представьте два сценария:
- Сбой: из-за ошибки в конфигурации базы данных вся нагрузка падает на один сервер. Он перегревается и отключается. Каскадный отказ приводит к простою в четыре часа со всеми вытекающими последствиями.
- Атака: злоумышленники находят уязвимость на том же сервере. Они проводят DDoS-атаку, чтобы его перегрузить, или внедряют ransomware, чтобы его зашифровать. В результате тот же простой в четыре часа, но с требованием выкупа и утечкой данных.
Для бизнеса и пользователя результат идентичен: сервис недоступен, деньги теряются, доверие подорвано. Но реакция инженерных команд традиционно разная: SRE борются со сбоями, ИБ с атаками. Их инструменты, процессы и даже языки различаются. Эта искусственно созданная граница - самая опасная уязвимость.
Как сблизить мир надежности (reliability) и мир безопасности (security), создав единый фронт устойчивости (resilience)?
Близнецы-братья или почему у SRE и Security одна и та же цель¶
У них общие цели: устойчивость и целостность системы¶
SRE стремятся к тому, чтобы система работала корректно при любых условиях (нагрузка, отказы железа, человеческие ошибки). Security стремятся к тому, чтобы система работала исключительно так, как задумано, и ни у кого не было возможности заставить ее работать иначе (злонамеренные атаки, утечки).
Обе дисциплины борются за конфиденциальность, целостность и доступность (CIA Triad), но с разным акцентом. SRE традиционно фокусируются на доступности (availability), security — на конфиденциальности (confidentiality) и целостности (integrity), но все же понимают, что в современном мире эти аспекты неразделимы.
У них общие враги: сложность и изменения¶
Главная причина инцидентов у SRE: изменения (деплой, конфигурация). Главная причина уязвимостей у security: изменения (новый код, закрытие зависимостей). Любое изменение это потенциальный риск как для стабильности, так и для безопасности.
У них общие методы: автоматизация, измерение, культура¶
SRE автоматизируют деплой и восстановление. Security автоматизируют сканирование уязвимостей и применение патчей. SRE оперируют SLO и Error Budget. Security оперируют метриками времени на исправление уязвимостей, количеством инцидентов. И SRE, и современная security (DevSecOps) стремятся к blameless-культуре, где важно найти первопричину в системе, а не наказать человека.
Точки конфликта SRE и security¶
Непонимание возникает из-за разных аксиом: - Аксиома security: "мир враждебен. Систему будут атаковать. Доверять нельзя никому и ничему. Запретить всё рискованное." - Аксиома SRE: "сбои неизбежны в сложных системах. Нужно принимать риски, чтобы двигаться вперед. Быстро восстанавливаться важнее, чем пытаться всё предотвратить."
Ярчайшие примеры: 1. Security: "немедленно раскатить критический патч! Уязвимость CVE 9,8!" SRE: "этот патч не тестировался в нашей среде. Его установка потребует перезагрузки 3000 серверов и может вызвать несовместимость библиотек. Нарушим SLO." Security видят бездействие как неприемлемый риск. SRE видят действие как гарантированный инцидент.
-
SRE: "нам нужен root ко всем продакшен-серверам для быстрой диагностики и восстановления." Security: "root на проде никто не должен иметь. Все действия через утвержденные инструменты с аудитом. Заводите сервера за PAM и делайте заявки". Борьба между MTTR и аудитом безопасности.
-
Security: "все внутренние коммуникации между микросервисами должны быть зашифрованы по TLS 1.3". SRE: "Шифрование добавляет 5-10ms задержки на каждый межсервисный вызов. Наша цепочка из 10 сервисов не уложится в SLO по времени ответа." Компромисс между защитой данных и пользовательским опытом.
DevSecOps и SRE. Кто за что отвечает?¶
Современный подход это не разграничение, а интеграция. Модель называется DevSecOps, и SRE становятся ее "девсекопсами" в инфраструктуре.
Новая модель ответственности: «Каждый отвечает за Security, но по-своему»¶
| Практика / Область | Роль Security-команды | Роль SRE-команды | Совместный результат |
|---|---|---|---|
| Управление уязвимостями | Определяют политику: Какие CVE критичны, SLA на патчи. Сканируют, находят. | Интегрируют патчи в инфраструктуру: Создают безопасный, автоматизированный конвейер обновлений (с откатом!). Измеряют риск для SLO. | Уязвимости закрываются быстро, без незапланированных простоев. Security SLO: «95% критических уязвимостей должны быть закрыты за 72 часа без нарушения SLO по доступности». |
| Конфигурация и Compliance | Определяют «золотой образ» (hardened image), стандарты CIS. Пишут политики (например, в Terraform). | Внедряют стандарты как код: Инфраструктура как код (IaC) с проверками безопасности. Обеспечивают неизменность (immutable infrastructure). | Инфраструктура развертывается безопасной «по умолчанию». Дрейф конфигурации исключен. |
| Инцидент-менеджмент | Расследуют утечки данных, инциденты безопасности. Юридическая и коммуникационная часть. | Обеспечивают техническое восстановление сервиса (remediation). Используют те же процессы и инструменты (Incident Commander, статус-панели). | Единый процесс на все инциденты. Быстрое восстановление работоспособности и минимизация ущерба. |
| Наблюдаемость (Observability) | Внедряют и анализируют логи безопасности (SIEM), детектируют аномалии. | Предоставляют платформу телеметрии (метрики, логи, трейсы), настраивают алертинг. | Единая панель стеклянного стола: Аномальный скачку ошибок 500 виден SRE, аномальный скачок попыток входа — Security. Контекст объединяется. |
| Дизайн системы | Участвуют в threat modeling (моделирование угроз). Требуют безопасные паттерны. | Проектируют отказоустойчивые, деградируемые системы. Внедряют паттерны (retry, circuit breaker, rate limiting), которые защищают и от сбоев, и от атак. | Resilient-архитектура: Система устойчива и к пикам нагрузки, и к DDoS, и к сбоям зависимостей. |
SecSRE / Security Reliability Engineer¶
Это естественная эволюция, инженер, живущий на пересечении двух миров. Он говорит на языках и SRE, и security, строит платформы безопасности, которые не мешают разработке и эксплуатации: безопасный секрет-менеджмент, security-сканирование в CI/CD без блокировки пайплайна и т.п. и помогает рассчитать Security Error Budget - допустимый уровень риска, который бизнес готов принять в обмен на скорость.
Исторически безопасность была функцией контроля и запрета ("нельзя!"), SRE функцией скорости и принятия риска ("давайте, но осторожно").
Будущее за синтезом: безопасностью как инженерной дисциплиной устойчивости (resilience engineering).
Мы не можем предотвратить все атаки, так же как не можем предотвратить все аварии. Поэтому мы строим системы, которые: 1. Устойчивы (Resilient): выдерживают и сбои, и атаки, деградируя изящно. 2. Наблюдаемы (Observable): позволяют быстро отличить атаку от сбоя по единым телеметрическим данным. 3. Восстанавливаемы (Recoverable): имеют предсказуемые, отточенные и безопасные процедуры восстановления из любых инцидентов.
Когда SRE и Security перестают быть соседними королевствами, охраняющими каждый свои границы и становятся единым инженерным братством, отвечающим за устойчивость бизнеса в цифровом мире, вот тогда компания получает, как минимум, надежный или безопасный продукт.