Как меняется архитектура после больших утечек и громких сбоев доверия
Yahoo, LinkedIn, Dropbox - 2016 год показал, что утечки случаются у всех. Вот что это меняет в том, как компании должны думать об архитектуре доверия.
2016 год стал годом крупных раскрытий. Yahoo объявила об утечке данных более 500 миллионов аккаунтов - причём выяснилось, что инцидент произошёл ещё в 2014 году. LinkedIn подтвердил, что утечка 2012 года затронула не 6,5 миллионов учётных записей, как считалось, а более 117 миллионов. Dropbox сообщил об утечке 68 миллионов хэшей паролей.
Это не истории об особой безалаберности этих компаний. Это истории о том, что даже крупные, технически сильные организации с большими командами безопасности работают в условиях, где компрометация рано или поздно происходит. Вопрос не "произойдёт ли", а "что происходит после".
Что изменилось в модели угроз
До нескольких лет назад доминирующая модель безопасности строилась на периметре: есть граница сети, за ней - доверенная зона. Всё, что внутри, в целом доверенно. Задача безопасности - защищать периметр.
Эта модель не работает по нескольким причинам. Периметр размылся: облачные сервисы, удалённая работа, мобильные устройства, подрядчики с доступом. Внутренняя сеть больше не является безопасной зоной по умолчанию.
Большие утечки 2016 года добавляют ещё одно измерение: компрометация учётных данных. Когда 117 миллионов хэшей паролей оказываются в открытом доступе - это означает, что у атакующих есть инструмент для попытки входа в огромное количество сервисов, потому что люди повторно используют пароли. Логичный следующий шаг: разграничить, что может сделать аккаунт даже при правильном пароле.
Что такое архитектура нулевого доверия
"Zero trust" - термин, который получил распространение несколько лет назад, но сейчас становится практически важным. Основная идея: не доверяй ничему по умолчанию - ни внешнему трафику, ни внутреннему. Каждый запрос на доступ верифицируется: кто запрашивает, с какого устройства, в какое время, к какому ресурсу, и соответствует ли это нормальному поведению.
Это не продукт и не технология - это принцип, который реализуется через набор практик.
Несколько конкретных следствий для организации:
Многофакторная аутентификация для всех критичных систем. Если пароль скомпрометирован - второй фактор делает его недостаточным для входа.
Минимальные привилегии. Каждый аккаунт имеет доступ только к тому, что нужно для работы. Утечка одного аккаунта не даёт доступ ко всему.
Сегментация доступа. Даже внутри организации - разные системы, разные уровни доверия. Компрометация одного сегмента не означает компрометации всей инфраструктуры.
Мониторинг аномалий. Если аккаунт бухгалтера внезапно начинает обращаться к инженерным базам данных в три часа ночи - это должно быть замечено.
Что это означает для компаний, которые не Yahoo
Реакция "у нас не такие масштабы, это нас не касается" - неправильная.
Масштаб влияет на привлекательность цели, но не на применимость принципов. Небольшая компания, у которой скомпрометированы данные клиентов, несёт репутационный и регуляторный ущерб пропорционально своему масштабу, а не масштабу Yahoo.
Более важный практический вопрос: что происходит в вашей компании, когда один аккаунт скомпрометирован? Что он может сделать? До каких данных дотянуться? Как быстро это будет обнаружено?
Минимальный список вопросов для оценки
- Включена ли многофакторная аутентификация для почты, VPN и критичных приложений?
- Есть ли у нас понимание, у каких учётных записей есть административные права - и действительно ли всем им это нужно?
- Как хранятся пароли в наших системах - и каков план действий, если хэши окажутся в открытом доступе?
- Есть ли процесс обнаружения аномальной активности в учётных записях?
- Что произойдёт, если один подрядчик с доступом окажется скомпрометирован?
Большие утечки 2016 года - это не повод для паники. Это повод пересмотреть допущения, на которых стоит текущая архитектура доступа.