Утечка метаданных Capital One: когда конфигурация облака стала цепочкой ответственности

Кратко

• Capital One заявила, что посторонний человек воспользовался уязвимостью конфигурации 22 и 23 марта 2019 года. Уголовные и регуляторные материалы описывают более длинную цепочку контроля: из-за ошибочной конфигурации межсетевого экрана уровня приложений команды могли достигать облачной среды, были получены учётные данные роли, с их помощью можно было перечислять и копировать объекты хранилища, а мониторинг не превращал подозрительную активность в своевременную локализацию.
• Управление валютного контролёра (OCC) не охарактеризовало событие как единичную инженерную ошибку. В согласительном предписании регулятор проследил корни до миграции банка в облако в 2015 году и выявил неэффективную оценку рисков, недостаточный сетевой контроль и контроль предотвращения потери данных, плохую обработку оповещений, пробелы внутреннего аудита и бездействие совета директоров, не привлёкшего руководство к ответственности.
• Ответственность существовала на нескольких уровнях, но не была юридически взаимозаменяемой. Федеральный суд присяжных признал Пейдж Томпсон виновной в уголовном деянии. Capital One приняла штраф OCC в $80 млн, не признав и не опровергнув выводы регулятора. Иски потребителей к Capital One и Amazon частично пережили стадию рассмотрения ходатайств о прекращении дела и позже были урегулированы, так что гражданское дело не дало судебного распределения вины между банком и облачным провайдером.
• Урок для суверенитета данных не в том, что выбор локального облачного региона решает вопросы защиты данных. Пострадали около шести миллионов человек в Канаде, в том числе примерно у миллиона были скомпрометированы номера социального страхования. Локация, срок хранения, права на идентификацию, доступ к метаданным, право управления шифрованием, логирование и доступ регуляторов к доказательствам должны управляться как единая система.

Утечка, описанная слишком узко

Знакомая версия утечки Capital One компактна: межсетевой экран был настроен с ошибкой, злоумышленник получил доступ к данным в Amazon Web Services, и была похищена информация, связанная более чем со 100 миллионами человек. Каждая часть этой формулировки указывает в правильном направлении. Но как описание ответственности она слишком узка. Она делает событие похожим на одну плохую настройку на периметре в остальном контролируемой среды.

Официальные материалы описывают нечто более структурное. Взаявлении от 29 июля 2019 года, поданном в SEC, Capital One сообщила, что 19 июля установила: посторонний человек получил персональные данные, воспользовавшись конкретной уязвимостью конфигурации. Компания отнесла существенный несанкционированный доступ к 22 и 23 марта, сообщила, что 17 июля поступило уведомление в рамках ответственного раскрытия, и объяснила, что исправила конфигурацию и работала с федеральной полицией. Она также заявила, что облачная операционная модель помогла компании быстро диагностировать и устранить проблему, когда о ней стало известно.

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

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

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

На текущейстранице Capital One об инцидентесообщается, что пострадали примерно 100 млн человек в США и около 6 млн в Канаде. Крупнейшая категория данных — сведения, которые потребители и малый бизнес указывали при подаче заявок на кредитные карты с 2005 года до начала 2019 года: имена, адреса, почтовые индексы, номера телефонов, адреса электронной почты, даты рождения и самостоятельно указанный доход. Часть данных о кредитных клиентах включала баллы, лимиты, остатки, историю платежей, контактные данные и фрагменты данных о транзакциях за 23 дня в 2016, 2017 и 2018 годах.

Компания сообщила о примерно 140 тыс. номеров Social Security в США, около 80 тыс. номеров связанных банковских счетов и примерно одном миллионе канадских номеров социального страхования среди скомпрометированных данных. Она заявила, что номера кредитных карт и учётные данные для входа не были скомпрометированы.

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

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

Хронология и меняющаяся форма ответственности

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

Кажущееся расхождение между 12 и 22 марта — не противоречие, которое нужно втиснуть в одну дату.Дополнительное обвинительное заключение 2021 годавменяло более широкий период несанкционированного доступа к компьютерам начиная примерно с 12 марта. В объявлении Capital One фигурировали 22 и 23 марта как даты доступа к данным, центрального для описания инцидента. Хронология должна сохранять это различие между вменяемым курсом действий и описанием вывода данных компанией.

Та же дисциплина нужна и с численностью. Первоначальное объявление компании называло примерно 100 млн пострадавших в США и 6 млн в Канаде. Администратор урегулирования в США позднее описывал примерно 98 млн американских потребителей в составе коллективного иска. Ни одну из цифр не следует молча превращать в точный универсальный показатель. Они принадлежат разным документам, разным стадиям и разным определениям.

Как граница метаданных стала границей учётных данных

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

Настранице Министерства юстиции по делу Capital Oneвторжение описывается как произошедшее через неправильно настроенный межсетевой экран уровня приложений. Дополнительное обвинительное заключение, поданное до суда, утверждало, что Томпсон создавала и использовала сканеры для поиска облачных клиентов, чьи конфигурации межсетевого экрана уровня приложений позволяли внешним командам достигать их серверов и выполняться на них. Утверждалось, что эти команды получали учётные данные безопасности для клиентских аккаунтов или ролей; затем учётные данные использовались для перечисления бакетов хранилища и копирования объектов, к которым у роли было разрешение.

В обвинительном заключении использовался нейтральный термин «облачная вычислительная компания», но открытые материалы гражданского дела и собственные документы Capital One называют среду AWS.

Служба метаданных экземпляра EC2 существует, чтобы программное обеспечение на виртуальной машине могло узнавать о своей среде выполнения и получать временные учётные данные, связанные с прикреплённой ролью. Это полезная альтернатива хранению долгоживущих ключей доступа в файлах. Однако конструкция предполагает, что доступ из экземпляра имеет значение. Если веб-компонент можно заставить выполнять произвольные внутренние запросы, «локально для экземпляра» больше не равно «авторизованному коду рабочей нагрузки».

Вобъяснении AWS 2019 года о IMDSv2адрес метаданных назван link-local конечной точкой и объясняется, что метаданные могут включать временные учётные данные роли, прикреплённой к экземпляру. Версия 2 требует, чтобы программное обеспечение сначала выполнило HTTP PUT-запрос для установления сессии и получения секретного токена, а затем предъявляло этот токен в последующих запросах к метаданным. AWS спроектировала протокол так, чтобы добавить устойчивость против распространённых открытых межсетевых экранов уровня приложений, открытых обратных прокси, уязвимостей SSRF и некоторых ошибок межсетевого экрана уровня 3 или трансляции сетевых адресов. Клиенты могли требовать версию 2 или полностью отключать доступ к метаданным.

Важный аналитический вывод не в том, что пересмотр протокола задним числом доказывает дефект, и не в том, что конфигурация клиента освобождает разработчика платформы от всякой ответственности за конструкцию. Он в том, что локальное доверительное допущение можно укрепить более чем на одном уровне. Capital One могла ограничить WAF, закрыть исходящий доступ к конечной точке метаданных, сузить роль, ограничить достижимое хранилище, обнаруживать необычное использование API и сократить сохраняемые данные. AWS могла сделать протокол метаданных менее пригодным для повторного использования через прозрачные прокси и пути SSRF.

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

Межсетевой экран уровня приложений — не вся утечка

Называя инцидент ошибкой конфигурации межсетевого экрана, можно скрыть три отдельных вопроса. Во-первых, почему недоверенный запрос мог заставить межсетевой экран или компонент за ним достичь внутреннего адресата? Во-вторых, какая учётная запись была раскрыта, когда это произошло? В-третьих, что эта учётная запись могла делать?

Первый — вопрос приложения и сетевого пути. Межсетевой экран уровня приложений обычно понимается как средство контроля, фильтрующее враждебный ввод до того, как он достигнет приложения. В этом инциденте соответствующая конфигурация сделала его частью маршрута к внутренним ресурсам. Эта инверсия должна изменить то, как облачные команды тестируют пограничные средства контроля. WAF — не только набор правил на публичном периметре; это код с контекстом выполнения, исходящей достижимостью, заголовками, методами и прикреплённой учётной записью.

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

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

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

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

Поэтому эффективная проверка не должна завершаться фразой «WAF исправлен». Она должна реконструировать полный граф привилегий: публичный запрос к прокси; прокси к конечной точке метаданных; конечная точка метаданных к сессии роли; роль к перечислению хранилища; перечисление к чтению объекта; чтение объекта к пути расшифровки; вызов API к сетевому выходу. У каждого ребра должны быть владелец, бизнес-обоснование, превентивные меры контроля и телеметрия. Удаление одного ошибочного правила останавливает известный маршрут. Оно не доказывает, что архитектура учётных записей и данных была соразмерной.

Шифрование защищало носители, а не авторизованное злоупотребление

Capital One сообщила, что шифровала данные как стандартную практику и токенизировала отдельные поля, особенно номера Social Security и номера счетов. Она также заявила, что обстоятельства позволили расшифровать полученные данные, в то время как токенизированные данные остались защищены, потому что токенизация использовала другой метод и ключи. Это важная поправка к распространённому утверждению, что «данные были зашифрованы» и это решает вопрос контроля.

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

Это не аргумент против шифрования. Это аргумент за разделение полномочий. Роль, доступная публичному контролю, не должна нести широкие права чтения данных и использования ключей. Особо чувствительные поля должны быть токенизированы или зашифрованы под сервисной границей, которую общая роль чтения хранилища не может пересечь. Политики ключей, политики данных и политики ролей должны рассматриваться как одно решение об авторизации. Иначе три по отдельности правдоподобные конфигурации могут пересечься и предоставить доступ, которого не намеревался ни один из их владельцев.

Событие также показывает, почему отчёты о контроле должны отличать покрытие от последствий. «100% объектов зашифровано» может быть правдой, пока риск конфиденциальности остаётся высоким. Более полезный показатель для совета директоров показал бы, какая доля чувствительных объектов доступна для чтения каждой среде выполнения, какие учётные записи могут вызывать расшифровку, присутствует ли публичная рабочая нагрузка на этих путях и как часто роль читает за пределами своего обычного префикса, тома, региона или временного паттерна.

Обнаружение подвело до того, как сработало реагирование

Программа ответственного раскрытия Capital One сработала, когда ею воспользовался внешний человек. Компания сообщила, что получила уведомление 17 июля, подтвердила утечку 19 июля, исправила проблему, связалась с ФБР, объявила об инциденте 29 июля и способствовала быстрому аресту. Это значимые факты реагирования. Они не отвечают на вопрос, почему внутренняя система контроля не довела мартовскую активность до разрешения.

Выводы OCC касаются этого пробела на более высоком уровне. Всогласительном предписании о гражданско-правовом денежном штрафеКонтролёр установил, что Capital One не создала надлежащее управление облачными рисками, включая адекватные меры предотвращения потери данных и эффективную обработку оповещений. Capital One не признала и не опровергла эти выводы. «Обработка» — это не просто генерация оповещения. Это процесс, который определяет, является ли событие безвредным, эскалируется ли оно, локализуется ли или закрывается с доказательствами.

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

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

OCC сочла утечку провалом управления миграцией

Самая сильная публичная запись об ответственности — не технический разбор. Это пакет правоприменительных мер OCC 2020 года. Вобъявлении агентства о штрафеговорится, что банк не создал эффективные процессы оценки рисков до перевода значительных технологических операций в публичное облако и не исправил недостатки своевременно. Агентство наложило штраф в $80 млн, признало уведомление банка и меры по исправлению и заявило, что ответственные инновации по-прежнему требуют надлежащего управления рисками и внутреннего контроля.

Согласительные выводы необычно конкретны. OCC установила, что примерно в 2015 году банк не создал эффективную оценку рисков до миграции. Она выявила недостатки в проектировании и внедрении мер сетевой безопасности, предотвращении потери данных и обработке оповещений. Она установила, что внутренний аудит не выявил многочисленные слабости и пробелы контроля, неэффективно сообщал о выявленных слабостях в комитет по аудиту, а совет директоров не принял эффективных мер, чтобы привлечь руководство к ответственности за некоторые проблемы, поднятые аудитом.

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

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

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

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

Требования к тестированию контроля особенно важны. Capital One должна была составить реестр значимых облачных средств контроля, согласовать с ним план тестирования на основе рисков, отслеживать пробелы, устранять их или официально принимать риск. Внутренний аудит должен был проверить полноту и точность реестра технологических активов, настраиваемых устройств и программного обеспечения, созданного руководством; сопоставить свою аудиторскую вселенную с вопросами проверок; учесть уроки анализа корневых причин утечки; пересмотреть охват аудита; оценить квалификацию персонала; и улучшить отчётность комитету по аудиту.

Эти обязательства отвечают на повторяющуюся ошибку облачного управления. У предприятия могут быть каталог контролей и план аудита, но не быть надёжной связи между ними. Каталог контролей содержит то, что, по мнению руководства, существует. Реестр активов содержит то, чем, по мнению команд, они управляют. Аудиторская вселенная содержит то, что аудит ожидает проверить. Если эти множества не сверены, публичная роль, путь метаданных, бакет хранилища или механизм конфигурации могут оказаться между моделями владения. Предписание OCC требовало доказательств, что множества согласованы.

Подотчётность совета директоров — это доказательства, а не частота заседаний

Вматериалах для собрания акционеров Capital One за 2020 годсказано, что руководство незамедлительно сообщило об инциденте совету директоров после обнаружения 19 июля. Независимые члены нескольких комитетов и полный совет собирались более 20 раз в связи с инцидентом и реагированием. Совет привлёк внешних экспертов, получал отчёты о корневых причинах и исправлении, усилил надзор и возложил на комитет по рискам ведущую роль в пересмотре усиленного киберуправления. Руководство создало старший комитет по корпоративным киберпроблемам и эскалации.

Это легитимные реакции управления, но количество заседаний не может доказать, что контроль работает. Выводы OCC были сосредоточены на периоде до утечки, когда слабости аудита предположительно не доводились до сведения эффективно, а руководство не привлекалось к ответственности за некоторые открытые пробелы. Поэтому полезное сравнение — не «мало заседаний до, много после». Оно в том, изменилась ли информация, доходившая до директоров, с отчётности о деятельности на доказательства контроля.

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

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

По каким облачным аудиторским проблемам пропущены целевые сроки, и какой руководитель принял остаточный риск?

Ни один из этих вопросов не требует от директоров настраивать межсетевой экран. Они спрашивают, может ли руководство продемонстрировать заявленную операционную границу. Это различие между администрированием и надзором. Директорам не нужно знать каждый параметр API, но нужна система отчётности, которая делает опасные сочетания видимыми раньше, чем это сделает внешний исследователь.

Разделённая ответственность — это карта контроля, а не отказ от ответственности

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

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

Провайдер делает возможными более безопасные настройки по умолчанию; клиент должен перенести существующие рабочие нагрузки и обеспечивать их соблюдение.

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

Разделённую ответственность поэтому нужно переводить в матрицу контроля, достаточно точную для проверки. По каждому контролю матрица должна указывать, кто его проектирует, кто настраивает, кто эксплуатирует, кто получает оповещение, кто проверяет эффективность, какие доказательства сохраняются и кто действует, когда доказательств нет. Ярлык «ответственность клиента» — не владелец контроля. В крупном банке «клиент» может означать платформенную инженерию, команды приложений, облачную безопасность, управление данными, инженерию идентификации, корпоративный риск, внутренний аудит, юридическую службу или поставщика.

Неоднозначность внутри организации клиента может быть опаснее неоднозначности между клиентом и провайдером.

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

Уголовная, регуляторная и гражданско-правовая ответственность

Публичная запись поддерживает несколько форм ответственности, каждая с разным юридическим статусом.

Уголовная ответственность — самая ясная. Вобъявлении Министерства юстиции о приговореговорится, что федеральное жюри признало Томпсон виновной в мошенничестве с использованием электронных средств, пяти эпизодах несанкционированного доступа к защищённому компьютеру и повреждении защищённого компьютера. Прокуроры показали, что она сканировала облачные аккаунты на предмет ошибок конфигурации, использовала их для получения данных и вычислительных мощностей и получила доступ к более чем 30 организациям. Её приговорили к сроку, уже отбытому под стражей, и пяти годам испытательного срока. Это установленное уголовное деяние не следует смягчать до случайной находки.

Регуляторная ответственность была сосредоточена на банке. Предписание о штрафе OCC — окончательное согласительное предписание, но Capital One не признала и не опровергла выводы Контролёра. Всогласованном объявлении Федеральной резервной системысказано, что холдинговая компания должна усилить управление рисками, корпоративное управление, кибербезопасность и контроль информационной безопасности. В приложенномсогласительном предписании ФРСтребовалось, чтобы совет материнской компании использовал свои ресурсы для обеспечения соблюдения банками предписаний OCC и представил письменный план надзора со стороны совета.

Гражданско-правовая экспозиция была шире, но менее определённой по конечной вине. Потребители подали иски к Capital One и Amazon по основаниям небрежности, договора, неосновательного обогащения, уведомления и защиты прав потребителей. В сентябре 2020 года окружной суд частично удовлетворил и частично отклонил ходатайства ответчиков о прекращении дела. Большинство исков о небрежности пережили эту стадию, в то время как иски по праву Вашингтона и несколько теорий небрежности как таковой (negligence per se) были отклонены.

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

Поскольку при рассмотрении ходатайства о прекращении дела хорошо сформулированные утверждения принимаются как истинные, решение установило, что иски могут продолжиться; оно не установило, что Capital One или Amazon совершили вменяемые действия.

Дело завершилось мировым соглашением, а не судом по существу. Вопределении об окончательном утвержденииутверждён фонд $190 млн без возврата неиспользованных средств, услуги защиты и восстановления идентичности и обязательства по деловой практике. Соглашение урегулировало требования к Capital One и Amazon. Утверждение означало, что суд счёл согласованное решение справедливым, разумным и адекватным по правилам коллективных исков. Оно не распределяло процент ответственности за утечку между банком, AWS и злоумышленником.

Это различие важно, потому что вопрос «кто был ответственен?» может провоцировать один ложный ответ. Томпсон осуждена за уголовные действия. Capital One понесла регуляторные санкции на основе согласительных выводов и приняла корректирующие обязанности. Capital One и Amazon столкнулись с гражданскими исками, которые частично пережили отказные ходатайства и были урегулированы. Более поздние изменения конструкции провайдера значимы для предотвращения, но не являются признанием юридической вины. У каждого утверждения есть источник и процессуальное положение. Соединять их в один обобщённый вердикт было бы неточно.

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

AWS представила IMDSv2 в ноябре 2019 года, менее чем через четыре месяца после того, как Capital One раскрыла утечку. Вуведомлении AWS о запускеновая версия описывалась как эшелонированная защита от несанкционированного доступа к метаданным. Клиенты могли требовать усиленный метод запроса на новых или работающих экземплярах или полностью отключать доступ к метаданным. Версия 1 оставалась доступной для совместимости.

Сессионный токен IMDSv2 создаёт трение против нескольких путей «запутанного заместителя». Прокси, пересылающий простые GET-запросы, может не позволить исходный PUT. Обратный прокси, вставляющий пересылающий заголовок, может быть отклонён при создании токена. Токен привязан к экземпляру и не может быть просто воспроизведён с произвольной машины. Ограничения количества переходов (hop limits) могут ограничить, как далеко ответ метаданных проходит по сетевым уровням. Это ценные протокольные средства контроля, потому что снижают последствия ошибок приложений и прокси.

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

У настроек по умолчанию есть и временное измерение. В 2019 году клиентам приходилось выбирать и обеспечивать более сильный метод после его появления. AWS позже объявиладорожную карту IMDSv2 по умолчанию, которая переводила быстрые старты консоли и новые типы экземпляров на версию 2, сохраняя опции совместимости. Эта эволюция иллюстрирует дилемму управления платформой. Немедленное обязательное изменение может сломать существующее программное обеспечение; длительная опциональность оставляет старые допущения на месте. Провайдеры должны делать миграцию измеримой, предоставлять принудительное применение на уровне аккаунта, показывать остаточное использование версии 1 и задавать ясное направление.

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

Для советов директоров урок — спрашивать о «долге настроек по умолчанию». Сколько рабочих нагрузок всё ещё зависят от устаревшего режима метаданных? Почему? Что сломается, если его отключить? Какие приложения не переносят более низкий лимит переходов? Какая организационная политика запрещает новые исключения? Как компания узнаёт, что приобретённый аккаунт или среда разработки не отклонились? Безопасная функция, которая доступна, но не измеряется, даёт меньше гарантий, чем программа миграции, связанная с реестром активов и принудительным применением.

Локализация данных не сдержала логический доступ

Утечка затронула людей по обе стороны границы США и Канады.Управление уполномоченного по вопросам конфиденциальности Канадыначало расследование после того, как Capital One сообщила, что пострадали шесть миллионов канадцев, включая некоторых, чьи номера социального страхования были доступны злоумышленнику. Канадскаястраница Capital One об инцидентепредоставила уведомления и поддержку для конкретной страны. Трансграничное воздействие превращает локализацию из абстрактного вопроса закупки облачных услуг в вопрос ответственности.

Рассмотренные здесь источники не устанавливают точный регион AWS каждого затронутого объекта и не показывают, что канадские записи хранились в отдельном канадском регионе. Это отсутствие нужно сохранить. Было бы безответственно выводить место хранения из гражданства субъекта данных или из глобального бренда облака. Что запись устанавливает, так это то, что один инцидент затронул большие группы населения, подчинённые разным правовым и регуляторным системам.

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

Локация отвечает на вопрос, где сервис настроен хранить или обрабатывать данные при нормальной работе. Безопасность также должна отвечать, кто может заставить сервис раскрыть данные, где могут использоваться учётные данные, куда идут логи и резервные копии, как контролируется доступ поддержки и могут ли экспортированные данные пересечь выбранную границу. В цепочке Capital One учётные данные API были более значимы, чем физическая близость к диску. Как только роль принималась как авторизованная, хранилище могло выдавать объекты через сервисный интерфейс. Внутренний регион сам по себе не предотвратил бы этот логический путь.

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

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

Инцидент также показывает, что география субъектов данных может иметь значение, даже когда география инфраструктуры неопределённа. Канадские регуляторы, пострадавшие лица, практики уведомления и потребности в восстановлении идентичности не исчезли из-за того, что Capital One находится в США. Международная облачная программа должна сопоставлять наборы данных с людьми и обязательствами, которые они представляют, а не только с аккаунтом и регионом, в которых их видят инженеры.

Срок хранения превратил путь доступа в историческое досье

Capital One сообщила, что крупнейшая затронутая категория включала данные заявок с 2005 года до начала 2019 года. Этот промежуток меняет анализ рисков. У кредитной заявки есть немедленная цель: оценить право, соблюсти закон, предотвратить мошенничество и открыть счёт. Со временем часть информации может оставаться необходимой для обслуживания, юридических обеспечительных мер, регуляторных обязанностей, управления моделями, разрешения споров или анализа мошенничества. Но необходимость должна быть подтверждена по полю, цели и периоду.

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

Подходящий контроль — не просто «удаляйте старые данные». Это защитимая жизненная линия: определить цель сбора; указать правовое и бизнес-основание для хранения; отделить активные операционные данные от ограниченных архивов; минимизировать поля; токенизировать долгоживущие идентификаторы; обеспечивать удаление; сохранять только записи, подпадающие под документированное исключение; и проверять, не остаются ли удалённые данные в репликах, производных наборах, кэшах, снапшотах и копиях для разработки. У каждого исключения должны быть владелец и пересмотр срока действия.

Архитектура данных также должна уменьшать агрегацию. Одна роль не должна получать доступ к широкому историческому массиву только потому, что однажды это понадобилось одной задаче обработки. Разделение по назначению, чувствительности, временному периоду и юрисдикции даёт политике доступа что-то значимое для применения. Без таких границ принцип минимальных привилегий вынужден работать на уровне очень большого бакета или озера данных, и разница между «может запускать это приложение» и «может читать историю этого учреждения» становится опасно малой.

Зависимость от облака включает зависимость от доказательств

Capital One не просто арендовала удалённые диски. Как и любой крупный облачный клиент, она зависела от определённой провайдером семантики идентичности, поведения метаданных, логирования API, конструкций регионов, контроля хранилища, доступности сервисов, документации и способности провайдера сохранять и объяснять доказательства. Это более широкая зависимость, чем время безотказной работы.

Инцидент 2019 года не вызвал длительного публичного сбоя основных банковских сервисов Capital One. Вопросом непрерывности были конфиденциальность и доверие. Компании пришлось расследовать большой облачный массив, выявить затронутые записи, уведомить людей в двух странах, работать с правоохранителями и регуляторами, предоставить мониторинг, защищаться в судах и исправлять контроль, продолжая работу. Это непрерывность при скомпрометированных доказательствах: сервисы могут оставаться доступными, пока учреждение должно определять, можно ли по-прежнему доверять его записям, процессам идентификации и коммуникациям с клиентами.

Вформе 10-K за 2019 годCapital One сообщила о дополнительных расходах на реагирование и исправление в $72 млн за 2019 год, частично компенсированных страховыми возмещениями в $34 млн. Компания ожидала оказаться у нижней границы ранее объявленного диапазона $100–150 млн совокупных корректирующих статей инцидента, при этом некоторые расходы выйдут за пределы 2019 года. Она предупреждала о регуляторном вмешательстве, судебных разбирательствах, расходах на исправление, репутационном вреде и потере доверия.

Эти цифры предшествовали штрафу OCC в $80 млн и более позднему фонду коллективного урегулирования в $190 млн, и их не следует небрежно складывать, поскольку страхование, сроки, охват соглашения и бухгалтерский подход различаются.

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

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

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

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

Что урегулировали мировые соглашения и что они оставили открытым

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

Соглашение не установило, что каждое утверждение в изменённом иске истинно. Оно не превратило материалы стадии ходатайств в выводы после исследования доказательств. Оно не определило, что конструкция метаданных AWS вызвала конкретный процент вреда или что конфигурация Capital One вызвала остаток. Оно не стёрло уголовную ответственность Томпсон и не отменило отдельные регуляторные выводы и предписания OCC.

Нераспределённая ответственность сама по себе является уроком управления. Фирмы не могут ждать, пока суд назначит аккуратный процент, прежде чем улучшать общий контроль. Провайдер платформы может не иметь установленной ответственности и всё же добавить более безопасный протокол. Клиент может оспаривать выводы регулятора и всё же принять предписание и перестроить контроль. Совет может сохранять юридические возражения, считая операционные факты срочными. Юридическая позиция и позиция исправления могут различаться без противоречия.

OCC позже объявила, чтоотменяет предписание о прекращении противоправных действий 2020 годас 31 августа 2022 года. Отмена — важная конечная точка для этого конкретного предписания. Она не отменяет штраф, не переписывает исторические выводы и не доказывает, что облачный риск стал статичным. Она означает, что формальное предписание больше не действует. Зрелый совет должен превратить дисциплину реестра контролей, тестирования, аудита и отчётности из предписания в обычное управление, а не позволять ей истечь вместе с регуляторным надзором.

Пакет доказательств для рисков метаданных, учётных данных и локализации

Материалы Capital One поддерживают практичный пакет доказательств для организаций, которые эксплуатируют чувствительные рабочие нагрузки в публичном облаке.

Сопоставьте публичные пути с внутренними полномочиями.Инвентаризуйте каждый доступный из интернета прокси, балансировщик нагрузки, WAF, API-шлюз и приложение. Для каждого покажите исходящие адресаты, доступность метаданных, прикреплённые учётные записи, разрешённые методы и заголовки и максимальные полномочия по данным, достижимые через эту учётную запись. Проверяйте путь с точки зрения злоумышленника, а не только против предполагаемой архитектурной схемы.

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

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

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

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

Владейте журналом аудита.Направляйте события идентичности, метаданных, хранилища, ключей, сети и предотвращения потери данных в независимо администрируемую среду логирования. Защищайте логи от ролей рабочих нагрузок. Коррелируйте получение учётных данных, операции перечисления, чтение объектов, расшифровку и исходящий трафик. Измеряйте, расследуются ли оповещения до подтверждённого вывода, а не просто генерируются ли они.

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

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

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

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

Этот пакет требователен, потому что риск комбинаторен. WAF может соответствовать базовым требованиям. Служба метаданных может работать как задокументировано. Роль может иметь бизнес-обоснование. Бакет может быть приватным. Объекты могут быть зашифрованы. Логи могут существовать. И всё же пересечение может позволить публичному запросу стать авторизованным экспортом. Ответственность живёт на пересечениях.

Главный критерий

Утечка Capital One остаётся полезным кейсом об облачной ответственности, потому что сопротивляется двум удобным историям. Первая говорит, что утечку вызвало публичное облако. Это игнорирует контролируемую клиентом конфигурацию, разрешения, архитектуру данных, мониторинг и прямые выводы OCC о программе облачных рисков банка. Вторая говорит, что разделённая ответственность целиком возлагает вопрос на клиента. Это превращает схему провайдера в конец анализа конструкции и упускает ценность более сильной защиты службы метаданных, более безопасных настроек по умолчанию, телеметрии провайдера и контрактных доказательств.

Лучшее объяснение следует по цепочке. Публичный контроль мог ретранслировать непредусмотренный запрос. Запрос достиг доверительной границы метаданных. Полученная временная учётная запись имела достаточно прав, чтобы перечислять и копировать хранимую информацию. Шифрование не помешало учётным данным, принятым как авторизованные, читать данные. Внутренний мониторинг не привёл к своевременной локализации. Долгий срок хранения увеличил раскрытый массив. Одно и то же событие затронуло людей в правовых режимах конфиденциальности США и Канады.

Аудит и отчётность совета не заставили устранить более широкие пробелы облачного контроля, выявленные регулятором.

Ответственность затем разделилась по инстанциям. Злоумышленница осуждена. Банковские регуляторы наложили на Capital One согласительные обязательства и штраф. Потребители преследовали и Capital One, и Amazon; иски частично пережили отказные ходатайства и были урегулированы без судебного распределения вины. AWS представила более защитный протокол метаданных. Capital One описала исправления, усиленный надзор совета и понесла существенные расходы на реагирование, правоприменение и урегулирование.

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

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