Введение
Не секрет, что мы наблюдаем бурное развитие облаков aka Clouds. Все и вся переезжает в эти самые облака. Но какую пользу (и вред) мы из этого можем извлечь с точки зрения ИБ?
Рассмотрим новые возможности и новые угрозы.
Вот, тезисные посылки, чтобы уменьшить сумбурность изложения.
1. Хранить в облаках — небезопасно.
1.1. Не надо хранить там ваши пиратские коллекции.
1.2. Прятать надо грамотно, разбавляя шумом.
1.3. Толика здоровой паранойи не помешает, шифруем сами.
2. Обрабатывать в облаках — выгодно.
2.1. Для этого надо строить облачные сервисы по-новому.
2.2. Пережить атаки теперь проще.
3. Злым хакерам теперь тоже проще — собрать ферму для взлома паролей может каждый.
3.1. Используем пароли побезумнее и подлиннее, не из словаря.
3.2. Используем Keepass и аналоги для управления паролями.
3.3. Везде где можно — переходим на ключи.
Облачные хранилища
Хранилища, в отличие от сервисов — касаются всех и каждого.
Все эти Google Drive и К появляются как грибы после дождя лишь потому, что если у вас уже есть 100 000 активных клиентов, то следующие 100 000 не принесут так уж много уникального контента. А заплатят — как за первый раз.
У вас есть терабайтная коллекция музыки? Залейте ее в облако. В типичном случае (обычная попса, собранная уже в цифровом виде) это займет на самом деле на (нужное подставить)-драйве ноль байт. Ноль!
Все эти композиции уже залили до вас, вы выслали хэши файлов и счетчики на совпадающие файлы увеличились на единичку.
Как правило, уникального контента от каждого не так уж много. Это текст (в разных форматах), иллюстрации и фотографии.
Ваш «уникальный» контент — как не спалиться
Из этого вытекают интересные следствия.
Например — такое. Заливайте ваш пиратский контент на наш драйв, и оплачивайте кредиткой. Нам это нравится. Только хэши сравнить, и автоматически рассылаем правообладателям список тех, у кого они совпали.
А маркетинговый отдел расскажет вам про «суровое шифрование» и «только для технических нужд».
Медиаконтент — он такой, да.
Стеганография — новые неочевидные ограничения
Для любителей прятать информацию в картинки наступают тяжелые времена. Использовать стеганографию в облаке — это то же самое, что повесить себе фонарь на шею, чтобы было издалека вас лучше видно.
Говорите, залили фотки Памелы Андерсон? А почему ни один хэш не совпал с миллионом фоток, залитых на этот же хостинг? В глаза смотреть!
А вылавливается — статистикой.
Поэтому придется заливать еще и шум — картинки обычные.
UPD: Этот вопрос вызвал вопросы, поэтому поясняю про статистику подробнее.
Опасность тут не в самом использовании картинок или там медиафайлов. А в использовании тех же самых файлов, которые аналогов в хранилище не имеют.
Типовые use-cases с фотографиями выглядят так
- Скачал у кого-то (постер, демотиватор, фотку кошечки, нужное подставить) и залил себе. Результат? Правильно, еще 100500 таких же лежит 1-в-1. Хэши — совпадают. И больше не меняется. Write once.
- Щелкнул айфоном, донес до компа сразу пачку, откропал и залил. Совпадений нет, но файлы больше не меняются. Write once.
Чем это отличается от ситуации «я в картинку прячу»? Тем, что наш уникальный контент начинает постоянно изменяться. Он перестает быть write once. Это и позволяет легко взять на карандаш тех, кто стеганографией увлекается.
Поэтому, чтобы под такой стат-анализ не попасть, надо почаще имена картинок менять, оставляя рядом старые версии. И заливать не по одной штуке, а в компании новых фоток с айфона. В этом случае этот use pattern уже выглядит как «я снимаю все что вижу», а не «я тут под фонарем прячусь».
Что в общем-то знатно добавляет возни на ровном месте.
Шифрование
Наше, родное, ручное шифрование контента — это спасение. Хранилища вас невзлюбят — нету с вас прибыли. Ни контент сжать, ни склеить с таким же.
Только не забываем отделять шифрование от хранилищ. Пока нас, параноиков, мало — это роли не играет.
Но если вдруг каждый второй начнет шифровать — (нужное подставить)-драйву придется ваш ключ на сервер положить. Не для того, чтобы получить несанкционированный доступ — а для того, чтобы получить свою прибыль.
И тут появляется тот же момент, что и со стеганографией — а вам зачем самому файлы шифровать, вы арабский террорист? Не забудьте взять справку, что вы параноик!
Облачные сервисы
Теперь перейдем к сервисам (на примере Amazon) — это полезнее.
Очевидно, что можно этими сервисами пользоваться в стиле «а я поставил себе PHP на микроинстансе и оно мне заменило шаред хостинг». В этом случае пользы от облаков будет немного, а именно — другу Васе сложнее заDoSить ваш phpbb, и падения реальных железок вам не грозят.
Однако, если подходить с умом, возможностей значительно больше. Это и балансер, и CloudWatch, и конечно же — самое вкусное! — S3 и CloudFront.
Вот те сервисы, которые как правило используются в типовом проекте, рассчитанном на 500k+ активных пользователей.
- EC2 (как правило это пачка специализированных серверов + RoR, JBoss, etc)
- S3
- CloudFront
- CloudWatch
- RDS (MySQL или Oracle — в зависимости от модели данных)
- Beanstalk или SQS (коммуникация между серверами EC2)
- SES и/или SNS (рассылка почты и push-to-talk)
Чем большая ожидается нагрузка — тем более активно используются S3 и CloudFront, и тем большее количество EC2 нам требуется под различные Apache Solr и К.
Опытный взгляд не обнаруживает в списке ElastiCache aka memcached, и это ясно почему. Потому что при наличии JBoss Cache или Oracle Coherence, которые и так идут в стеке используемых технологий, еще один кэш просто не потребуется.
Вместо этого большая часть результатов работы специализированных сервисов при помощи S3/CloudFront API принудительно заливается на сервера Amazon. Поэтому видео, картинки и прочие отчеты не только не надо каждый раз строить, но даже хостить у себя, запоминая в БД лишь их UIDы.
Я столь подробно остановился на этом типовом случае, поскольку именно такая архитектура дает предпосылки использовать всю мощь облаков в деле защиты.
DDoS уходит в прошлое
Примером может быть известная история с Wikileaks.
DDoSили Ассанжеево творение, DDoSили и не заDDoSили. Забить полностью одну из крупнейших сетей мира, расположенную на четырех континентах — это из области фантастики.
Перебор паролей — дурная мощь под капотом
Однако и черные шляпы тоже получают преимущество.
Теперь не нужно строить спец-устройства и датацентры, с 7значными расходами (не в рублях). Всего лишь арендовать пару тройку тысяч оn-demand EC2 с John нашим The Ripper, предпочтительнее с теслами на борту, и сумма уже пятизначная.
Удешевление брутфорса на 2 порядка — это сильно.
И доступнее.
Отсюда выводы очевидны:
- Используем пароли побезумнее и подлиннее, не из словаря.
- Используем Keepass и аналоги для управления паролями.
- Везде где можно — переходим на ключи.
Хабраэффекты и близкие к ним виды атак
Тут тоже достаточно очевидно — CloudWatch поднимет столько front-end нодов в балансер, сколько потребуется, всего лишь вопрос грамотного прописывания ограничений. И сам их положит, когда нужда отпадет.
S3/CloudFront выдержат любое количество желающих «посмотреть еще этих шикарных фоток».
А SQS / Beanstalk не дадут пропасть заявкам на long-time operations.
Вопрос по сути упрется в настройки кластера БД и его стоимость. Полноценный MySQL Cluster с синхронной репликацией весьма недешев.
Выводы
Новые возможности — новые реалии. Безопасности на просторах интернета!