Building Secure and Reliable Systems (short summary)

Эта книга полезна тем, что отказывается разводить безопасность и надёжность по разным комнатам: в реальной системе они ломаются вместе.

Глава показывает, как практики Google связывают Zero Trust, эшелонированную защиту, безопасный жизненный цикл разработки, реагирование на инциденты и культуру безопасности в единую операционную модель.

На интервью она дает сильную рамку для разговора о многоуровневой защите, обучении на инцидентах и том, почему хорошая архитектура безопасности неотделима от эксплуатационной зрелости.

Практическая польза главы

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

Проектируйте защиту и надёжность вместе: границы доверия, минимальные привилегии, эшелонированную защиту и безопасные настройки по умолчанию.

Качество решений

Проверяйте не только наличие контролей, но и то, как система обнаруживает инцидент, ограничивает радиус поражения и восстанавливает доверие.

Аргументация на интервью

Стройте ответ вокруг цепочки: угроза, мера защиты, отказоустойчивость, наблюдаемость, реагирование и обучение после инцидента.

Формулировка компромиссов

Явно обсуждайте цену строгой защиты: задержку проверок, сложность эксплуатации, скорость выпуска изменений и удобство команды.

Официальный сайт

Бесплатная версия

Книга доступна бесплатно на сайте Google SRE — команды инженерии надёжности сервисов.

Перейти на сайт

Building Secure and Reliable Systems (Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google)

Авторы: Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield
Издательство: O'Reilly Media, Inc.
Объём: 555 страниц

Практики Google SRE: Zero Trust, эшелонированная защита, безопасный жизненный цикл разработки, реагирование на инциденты и культура безопасности.

Оригинал

Перевод

«Building Secure and Reliable Systems» — книга команды Google о том, как проектировать безопасность и как единую инженерную дисциплину. Авторы показывают, что эти качества нельзя развести по разным командам: сбой защиты часто превращается в сбой доступности, а слабая эксплуатация ослабляет защиту.

В этой главе связывается с , , , , и снижением .

Структура книги

Part I

Введение

Где пересекаются безопасность и , зачем нужна и как помогает .

Part II

Проектирование систем

Принципы проектирования: , и .

Part III

Реализация систем

Безопасный код, тестирование, и .

Part IV

Сопровождение систем

, восстановление, и .

Part V

Организация и культура

Команды, обучение, и понятная ответственность за защиту системы.

Безопасность и надёжность: общий подход

Связь

SRE Book

Базовые практики инженерии надёжности сервисов (SRE): целевой уровень сервиса (SLO), бюджет ошибок и сокращение ручного операционного труда.

Читать обзор

Почему эти дисциплины связаны?

Общие цели:

Защита системы от внутренних сбоев и внешних атак.
Снижение при инцидентах.
Быстрое обнаружение, оценка влияния и реагирование.
Восстановление сервиса и доверия пользователей после сбоя.

Общие практики:

.
.
Мониторинг, оповещения и аудит действий.
реагирования.

Ключевая идея

Снаружи атака и отказ выглядят одинаково: сервис деградирует, данные под риском, пользователи теряют доверие. Если защиту и эксплуатационную устойчивость проектируют разные команды по разным критериям, стыки между ними и становятся самым слабым местом. Дешевле держать оба свойства в одной архитектуре.

Принципы безопасного проектирования

Минимально необходимые привилегии

означают, что пользователь, сервис или процесс получает только те права, которые нужны для конкретной задачи.

Примеры:

с минимальными ролями IAM.
: запрет по умолчанию и явные разрешения.
вместо долгоживущих ключей.
для привилегированных операций.

Эшелонированная защита

Один барьер однажды пробьют — вопрос только когда. ставит несколько независимых слоёв так, чтобы пробой одного не открывал систему целиком, а упирался в следующий.

Периметр

, защита от и ограничение частоты запросов.

Приложение

Проверка входных данных, аутентификация, авторизация и шифрование.

Данные

Шифрование, аудит доступа и резервные копии.

Безопасные настройки по умолчанию

Большинство систем живёт на значениях по умолчанию — их меняют редко. переносят риск на правильную сторону: чтобы ослабить защиту, нужно явное решение, а не забытый флаг.

Неудачно:

Публичные бакеты объектного хранилища по умолчанию.
Открытые порты для 0.0.0.0/0 без причины.
Слабые правила паролей и многофакторная аутентификация как опция.

Лучше:

Закрытые buckets и явное разрешение публичного доступа.
Запрет сетевого доступа по умолчанию и точечные исключения.
Обязательная многофакторная аутентификация и сильные правила входа.

Безопасный отказ

Когда сервис проверки прав сам недоступен, у системы остаётся два пути: пропустить всех или не пропустить никого. Для контроля доступа правильный — : потеря доступности дешевле, чем тихо открытая дверь.

// Небезопасно: отказ с сохранением доступа
if (authService.isDown()) {
  return allowAccess();
}

// Безопаснее: отказ с блокировкой доступа
if (authService.isDown()) {
  return denyAccess();
  // + оповещение дежурному
}

Архитектура нулевого доверия

Принципы архитектуры нулевого доверия (Zero Trust)

Старая модель доверяла периметру: попал внутрь сети — считаешься своим. Один скомпрометированный сервис превращал это допущение в свободное перемещение по системе. Нулевое доверие убирает само допущение: каждый запрос проверяется заново, даже внутренний трафик.

1. Явно проверять каждый запрос

Аутентификация и авторизация учитывают идентичность, расположение, устройство, сервис и классификацию данных.

2. Выдавать минимально достаточный доступ

Доступ по запросу, минимально достаточное администрирование, краткоживущие учётные данные и политики с учётом риска.

3. Исходить из возможной компрометации

Радиус поражения уменьшается через сегментацию, сквозное шифрование и непрерывный мониторинг.

Аутентификация между сервисами

Запрос разрешён

Сервис A

Клиент

Сервис B

Ресурс

Идентичность

SPIRE / CA

Политика

OPA / Cedar

Сервис A

Клиент

Сервис B

Ресурс

Идентичность

SPIRE / CA

Политика

OPA / Cedar

Запрос разрешён

Проверка прошла, доступ выданПолитика отклонила запрос + идентичность + политика

Безопасный жизненный цикл разработки

Проверки безопасности на каждом этапе

Этап	Что проверяем	Инструменты
Проектирование	и ревью архитектуры безопасности.	STRIDE, attack trees
Код	Безопасная разработка, ревью кода и SAST.	Semgrep, CodeQL
Сборка	Проверка зависимостей, и контроль состава артефакта.	Snyk, Dependabot
Тестирование	DAST, fuzzing и проверка критичных сценариев атаки.	OWASP ZAP, Burp Suite
Развёртывание	Проверка контейнеров, и политики допуска перед выпуском.	Trivy, Checkov
Эксплуатация	Мониторинг, и .	SIEM, SOAR

Моделирование угроз

Угрозу, найденную на доске, исправляют правкой схемы. Ту же угрозу в проде исправляют инцидентом. Разбор на этапе проектирования и нужен, чтобы перенести цену ошибки на стадию, где она ещё дешёвая.

STRIDE:

Spoofing — подмена личности.
Tampering — несанкционированное изменение.
Repudiation — отказ от совершённого действия.
Information disclosure — раскрытие информации.
Denial of service — отказ в обслуживании.
Elevation of privilege — повышение привилегий.

Безопасность цепочки поставки ПО

Свой код можно прочесть на ревью, а чужой код приходит в сборку через зависимости, реестр артефактов и конвейер доставки. Скомпрометируй любое из этих звеньев — и вредоносный код попадёт в прод подписанным и проверенным.

Практики:

.
и .
и файлы фиксации зависимостей.
Приватные .
Соответствие уровням SLSA там, где это нужно для критичных артефактов.

Реагирование на инциденты

Связь

Release It!

Паттерны устойчивости: размыкатель цепи, изоляция по отсекам и тайм-ауты.

Читать обзор

Жизненный цикл инцидента безопасности

Обнаружение

Мониторинг, правила оповещения и . остаётся критичной метрикой.

Первичный разбор

Оценка , масштаба, влияния и состава команды реагирования.

Сдерживание

Изоляция затронутых систем, блокировка вредоносного трафика и .

Устранение

Устранение , установка исправлений и удаление .

Восстановление

Возврат сервисов, проверка целостности и усиленный мониторинг признаков повторной атаки.

Разбор после инцидента

, и улучшение процессов.

Культура безопасности

Представители по безопасности в командах

Команда безопасности не масштабируется на каждый пул-реквест. переносит ответственность ближе к коду — туда, где решения принимаются каждый день.

Проводит ревью кода и архитектурных изменений с учётом рисков.
Участвует в моделировании угроз вместе с командой.
Обучает коллег практикам безопасной разработки.
Связывает продуктовую команду и специалистов по безопасности.

Культура разбора без поиска виноватых

Наказывают за ошибку — и в следующий раз о ней просто молчат, пока она не станет инцидентом. держит фокус на починке системы, а не на поиске виноватого, чтобы о проблемах узнавали рано.

Поощрять сообщения об уязвимостях и небезопасных настройках.
Проводить разборы инцидентов без обвинений.
Сохранять прозрачность фактов и решений по инциденту.
Превращать каждый инцидент в улучшение архитектуры и процессов.

Сравнение с другими книгами

Книга	Фокус	Связь
SRE Book	Надёжность, /	Базовая эксплуатационная дисциплина.
Release It!	Паттерны устойчивости	Как система выдерживает сбои и нагрузку.
DDIA	Распределённые системы	Модель данных, согласованность и отказоустойчивость.
Эта книга	Безопасность и надёжность	Как объединить защиту, эксплуатацию и культуру.

Применение на интервью по системному дизайну

Практика

API Gateway

Реализация аутентификации и авторизации на уровне шлюза API (API Gateway).

Читать обзор

1. Аутентификация и авторизация

Упоминайте , между сервисами, / для пользователей и / для решения о доступе.

2. Защита данных

Обсуждайте шифрование при хранении и передаче, , и работу с .

3. Снижение радиуса поражения

Показывайте изоляцию микросервисов, сетевую сегментацию, и ограничение частоты запросов.

4. Наблюдаемость и расследование

Используйте журналирование событий безопасности, аудит, обнаружение аномалий и для .

Ключевые выводы

✓Безопасность и надёжность — одна дисциплина: разнесёте по разным командам — и стыки между ними станут слабым местом. Общие практики: , минимальные привилегии и безопасный отказ.
✓: никому не доверять по умолчанию и проверять даже внутренний трафик.
✓Безопасные настройки по умолчанию: защита включена сразу, а ослабление требует явного решения.
✓Раннее встраивание безопасности: проверки появляются на этапах проектирования, кода и сборки, а не после релиза.
✓Разбор без поиска виноватых: цель — улучшить систему, процессы и обучение команды.

Связанные главы

Site Reliability Engineering (short summary) - Дает базовые практики : , и , которые эта книга объединяет с инженерией безопасности.
Показатель уровня сервиса (SLI), целевой уровень сервиса (SLO), соглашение об уровне сервиса (SLA) и бюджет ошибок - Помогает формализовать надёжность через метрики и управлять риском изменений в промышленной среде.
Zero Trust (нулевое доверие): современный подход к безопасности архитектуры - Расширяет идеи главы про , явную проверку каждого запроса и снижение .
Supply Chain Security - Дополняет защитой зависимостей, артефактов сборки и цепочки поставки ПО.
Release It! (short summary) - Показывает устойчивость под нагрузкой и сбоями, что напрямую связано с и восстановлением.

Где найти книгу

Оригинал

oreilly.com

Building Secure and Reliable Systems

Перевод

piter.com

Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google