Цели безопасности и модель угроз
Ведущий напоминает, что девятая глава — последняя, по объёму такая же, как остальные, и разбита на шесть частей: введение, криптография, аутентификация, авторизация, доверие в распределённой системе и мониторинг. Во введении авторы противопоставляют негативную цель — предотвратить любые атаки — и позитивную: выдавать доступ конкретным сущностям; первая практически недостижима, со второй работать проще. Затем они возвращаются к dependability из первых глав, где были доступность, надёжность, safety и удобство сопровождения, и добавляют конфиденциальность и целостность: данные не должны утекать неавторизованным участникам и не должны меняться так, чтобы стать невалидными. Участники вспоминают фидбэк знакомого безопасника: классическая триада на практике сегодня работает не очень, а есть более современная — про распределённое и эфемерное. Самого безопасника на выпуске нет, поэтому клуб идёт академическим путём — через модель угроз, которая, по словам ведущего, понятнее разработчику.
Игорь замечает: у людей, не работавших в безопасности, мировоззрение идеалистическое — они хотят систему, безопасную во всех случаях, а исходить надо из ограничений и модели того, как всё устроено. Модель угроз он раскладывает на три блока: неавторизованный доступ и похищение информации, неавторизованная модификация данных и атаки на доступность, после которых сервис просто перестаёт работать. Дальше авторы разделяют политики и механизмы — сквозной приём Таненбаума: если их смешать, система перестаёт быть конфигурируемой, и любое изменение поведения требует правок в коде. Механизмов четыре: шифрование, аутентификация, авторизация и аудит. Аудит работает постфактум, но делает систему защищённее — атакующему приходится тратить больше усилий, чтобы скрыть присутствие. Один из участников рекомендует книгу инженеров Google, продолжающую их серию про надёжность: без нормальных инструментов наблюдения реагировать на инцидент всё равно что вести машину с заклеенным чёрной плёнкой лобовым стеклом.
Принципы, культура открытости и данные
К принципам безопасного проектирования авторы идут от сборника 1975 года: там их, по памяти участников, восемь, а разобраны пять. Fail-safe defaults — про безопасные умолчания: пара admin/admin, с которой до сих пор пускает множество роутеров, и базы данных, открытые в сеть сразу после установки. Open design — не строить защиту на сокрытии реализации, хотя авторы признают, что современные системы сложны и без всякого сокрытия. Отсюда отсылки к простоте и две книжные рекомендации: нетехническая книга про простые и сложные решения и книга о философии проектирования от преподавателя, одного из авторов Raft, который на работах студентов показывает, к чему приводит кривая декомпозиция. Separation of privilege — не отдавать все доступы одной сущности: ключ, по воспоминаниям участника, раздают трём держателям, и расшифровать базу могут, например, двое из трёх. Least common mechanism напоминает DRY: продублированный протокол безопасности придётся чинить в двух местах.
Игорь смотрит на принципы практически: их нарушают не по злобе, а потому что так удобнее — дефолты попроще в тестовом окружении, нежелание дробить работу ради разделения привилегий, лень выверять минимальные права. Лучше, когда ограничение накладывает платформа и приложение работает обычным процессом без прав root, иначе проще всего выдать root и не думать ни о чём. Другой участник добавляет про открытый дизайн: код и документацию часто прячут не ради безопасности, а потому что стесняются показывать их публично, особенно в коммерческих компаниях. К этому добавляют, что дело и в культуре: если код лежит в десятке мест, а документацию не вели, открытость ничего не даст. Из свежих примеров в главе — таблица активностей вокруг персональных данных: чтобы отдать пользователю его данные, их нужно уметь выгружать, а запрет хранить вечно закрывается TTL и регулярным удалением. Участник, застав внедрение регулирования, вспоминает: сначала это была юридическая история, а теперь набор технических практик.
Криптография, авторизация и итоги книги
Криптографию проходят по верхам: Алиса, Боб и злоумышленник, который слушает канал, меняет сообщения и вставляет свои; симметричное и асимметричное шифрование; вопрос, откуда взять общий ключ. При общих секретах число ключей растёт как граф связей; центр распределения превращает схему в звезду, где каждый доверяет центру, а оптимизация с тикетом позволяет Алисе самой переслать Бобу кусок, зашифрованный его ключом. Публичная криптография центр снимает, но требует удостоверяющих центров и цепочек доверия — про эту инфраструктуру, замечают участники, за последний год многие узнали сильно больше. Отдельный сюжет: понятная оптимизация протокола ломает его — объединение шагов даёт reflection attack, когда одинаковый ответ можно переиспользовать. Один из участников сравнивает это с сеансом одновременной игры, где гроссмейстер отражал ходы двух соперников и выиграл у обоих. Поэтому используют сессионные ключи: они уменьшают радиус поражения при утечке.
В авторизации авторы дают модель с субъектом, объектом и монитором обращений, а участники признаются, что разницу между защитой операций и контролем доступа в контур системы до конца не поняли. Дальше модели: мандатная с уровнями секретности, дискреционная, где доступ определяет владелец, как права на файлы в Unix, ролевая и атрибутная — самая гибкая и самая тяжёлая. Матрица прав разрежена, поэтому её сворачивают: по колонкам выходят списки контроля доступа, по строкам — списки возможностей. На практике модели комбинируют: роли на управление базами данных, а на доступ к самим данным — точечные списки, потому что делать всех разработчиков админами над пользовательскими данными плохо. Через неделю клуб обещает разобрать модель на основе отношений: гибче ролевой, проще атрибутной. Главу закрывают системы обнаружения вторжений — от сигнатур к аномалиям и коллаборативным базам событий, которые тюнят между полнотой и точностью, чтобы команда не перестала реагировать на алерты. Итог девяти недель: по оглавлению, как говорил Александр в первом выпуске, можно построить курс по архитектуре, ценность — в ссылках на другие материалы, а претензии — к устаревшим примерам и нелёгкому чтению. Дальше будут статьи и новые книги.
Что стоит унести с собой
- 01Негативную цель — предотвратить любые атаки — авторы считают недостижимой: работать проще с позитивной, а к dependability добавляются конфиденциальность и целостность.
- 02Разделение политик и механизмов — сквозная идея Таненбаума: смешав их, систему нельзя перенастроить без правок в коде; механизмов четыре — шифрование, аутентификация, авторизация и аудит.
- 03Из восьми принципов 1975 года авторы оставили пять, и least common mechanism — тот же DRY: продублированный протокол безопасности придётся чинить в двух местах.
- 04Разреженную матрицу прав сворачивают в списки контроля доступа по колонкам или списки возможностей по строкам, а на практике ролевую модель комбинируют с точечными списками.