Комментарии 25
Если предполагается, что этот EC2-instance имеет доступ к этим данным для своей работы, то он будет иметь доступ и к ключу шифрования.
То есть получая доступ к хранилищу, сами данные нужно будет дешифровать.
Вот только в описанном случае атакующая не просто "получила доступ к хранилищу", а получила доступ к инстансу, у которого была роль для доступа к хранилищу. Предположительно, если инстансу дали доступ на чтение, то он должен что-то с данными делать, а если так — то он будет их и расшифровывать, поэтому доступ к ключу у него тоже будет.
Расшифровка идет в памяти.
В памяти того же инстанса? С помощью чего?
(Но вообще, по умолчанию, AWS S3 работает не так — вы передаете ключ в запрос к хранилищу и получаете уже расшифрованные данные)
С помощью собственного алгоритма, или стороннего crypto service provider.
Собственный алгоритм — зло, выкидываем. Остаются стандартные алгоритмы, ключи от которых хранятся где?
Тоесть получение привелегий учетной записи, под которой работает инстанс приложения, не должен давать доступ к данным.
Это невыполнимое требование, потому что если инстанс имеет доступ к этим данным, то эти данные из него можно достать.
Внутреннее шифрование сужает доступ до приложения (как владельца ключа).
В случае стандартного развертывания на EC2 приложение — и есть инстанс, вы ничего не можете "сузить".
Собственный алгоритм — зло, выкидываем. Остаются стандартные алгоритмы, ключи от которых хранятся где?
В случае стандартного развертывания на EC2 приложение — и есть инстанс, вы ничего не можете «сузить».
Это, действительно, важный момент. В моей практике есть только ПО, которое работает на Windows Server. Там в качестве хранилища можно использовать как встроенный контейнер сертификатов, так и стороннее ПО типа Крипто API. Доступ к ключу будет иметь определенный аккаунт под которым работает ПО.
Обычно под конкретное приложение дается отдельный аккаунт. Т.е. в этом случае надо получать доступ именно к нему. То есть слабым звеном остаюся администратор, который имеет доступ к хранилищу сертификатов и учетная запись, под которой крутится сервис-приложение.
В случае с EC2 приложением, наверное да, только использование встроенных в AWS сервисов.
Доступ к ключу будет иметь определенный аккаунт под которым работает ПО.
Правильной параллелью со случившимся будет "скомпроментирован такой аккаунт". И далее становится понятно, что шифрование не поможет.
От инсайда, как в этом примере спасет, если только инсайдер не имеет доступ к сертификатам.
Неа. Потому что "инсайд как в этом примере" — это кто-то нашел способ залогиниться на инстанс под учетной записью, которая там была установлена. Если бы для этой учетной записи соблюдали правила безопасности, это бы ничем не отличалось от вашего случая.
Если злоумышленник залогинился в инстансе под root'ом, то он сможет сделать все что угодно:
- Перехватить трафик
- Достать ключи/пароли из памяти
- Подменить сервисы/приложение
И этот список можно продолжать долго.
По этому, в конечном случае, шифрование здесь не спасет. Оно, конечно, усложнит жизнь и придется постараться чуть больше чем просто вызвать s3cmd sync s3://..., но принципиально это не решение проблемы.
Что удивляет больше — это абсолютно не связанный с чем-либо пассаж о том что нужно идти в облако (хотя, вероятно, это просто реклама AWS), несмотря на то что в данном случае именно сотрудница облачного провайдера стала причиной проблемы.
Не боится.
* О сообщении узнают полтора технаря на хабре.
* Инвесторам говорите «Ой извините. Это были хакиры. В вот у нас зато занавески красивые.»
* Продолжаешь грести бабло.
Пока ещё ни одной конторки не закрыли за утечку. Чего бояться-то? Вот утечка туалета в офисе — это гораздо страшнее.
Сейчас справа от меня сидит человек, который до этого работал в МФЦ (это где все ваши персданные, паспорта и прочие документы хранятся). Я уже даже не смеюсь, когда он рассказывает, что безопасности там нет в принципе. Все данные валяются как половые тряпки по углам. Можно просто прийти с ноутом, воткнуться в сетку и всё скопировать. Это ещё в лучшем случае. Ноль контроля, ноль ответственности, ноль желания что-то менять.
В статье есть некоторые неточности. Можно почитать на Кребсе. Если коротко:
- Никто не попадал на EC2, уязвимость в firewall-e "всего лишь"позволяла взломщику "trick the firewall into relaying requests to a key back-end resource on the AWS platform"
- К сожалению, этот back-end resource который называется метадата сервис, возвращает пароли присвоенные вышеупомянутому EC2.
- Дальше вы берете эти пароли и используете их откуда угодно
Проблема с метадата сервисом известна давно, просто тут для Capital One звезды улеглись — №1 это точно недосмотр, ну и слишком широкие права доступа у инстанса (тот самый S3 к которому совершенно необязательно firewall-у иметь доступ)
Короче сочетание разгильдяйства и документированных недостатков AWS.
Никакой конечно не inside job
Технические детали взлома банка Capital One на AWS