Введение
Не секрет, что мы наблюдаем бурное развитие облаков aka Clouds. Все и вся переезжает в эти самые облака. Но какую пользу (и вред) мы из этого можем извлечь с точки зрения ИБ? Рассмотрим новые возможности и новые угрозы.
И начнем мы с облачных хранилищ.
Облачные хранилища
Хранилища, в отличие от сервисов — касаются всех и каждого.
Все эти Google Drive и К появляются как грибы после дождя лишь потому, что если у вас уже есть 100 000 активных клиентов, то следующие 100 000 не принесут так уж много уникального контента. А заплатят — как за первый раз.
У вас есть терабайтная коллекция музыки? Залейте ее в облако. В типичном случае (обычная попса, собранная уже в цифровом виде) это займет на самом деле на (нужное подставить)-драйве ноль байт.
Ноль!
Все эти композиции уже залили до вас, вы выслали хэши файлов и счетчики на совпадающие файлы увеличились на единичку.
Как правило, уникального контента от каждого не так уж много. Это текст (в разных форматах), иллюстрации и фотографии.
Ваш «уникальный» контент — как не спалиться
Из этого вытекают интересные следствия.
Например — такое. Заливайте ваш пиратский контент на наш драйв, и оплачивайте кредиткой. Нам это нравится. Только хэши сравнить, и автоматически рассылаем правообладателям список тех, у кого они совпали.
А маркетинговый отдел расскажет вам про «суровое шифрование» и «только для технических нужд».
Стеганография — новые неочевидные ограничения
Для любителей прятать информацию в картинки наступают тяжелые времена. Использовать стеганографию в облаке — это то же самое, что повесить себе фонарь на шею, чтобы было издалека вас лучше видно.
Говорите, залили фотки Памелы Андерсон? А почему ни один хэш не совпал с миллионом фоток, залитых на этот же ? В глаза смотреть!
А вылавливается — статистикой.
Поэтому придется заливать еще и шум — картинки обычные.
Шифрование
Наше, родное, ручное шифрование контента — это спасение. Хранилища вас невзлюбят — нету с вас прибыли. Ни контент сжать, ни склеить с таким же.
Только не забываем отделять шифрование от хранилищ. Пока нас, параноиков, мало — это роли не играет.
Но если вдруг каждый второй начнет шифровать — (нужное подставить)-драйву придется ваш ключ на сервер положить. Не для того, чтобы получить несанкционированный доступ — а для того, чтобы получить свою прибыль.
И тут появляется тот же момент, что и со стеганографией — а вам зачем самому файлы шифровать, вы арабский террорист? Не забудьте взять справку, что вы параноик!
Облачные сервисы
Теперь перейдем к сервисам (на примере 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 порядка — это сильно. И доступнее.
Хабраэффекты и близкие к ним виды атак
Тут тоже достаточно очевидно — CloudWatch поднимет столько front-end нодов в балансер, сколько потребуется, всего лишь вопрос грамотного прописывания ограничений. И сам их положит, когда нужда отпадет.
S3/CloudFront выдержат любое количество желающих «посмотреть еще этих шикарных фоток».
А SQS / Beanstalk не дадут пропасть заявкам на long-time operations.
Вопрос по сути упрется в настройки кластера БД и его стоимость. Полноценный MySQL Cluster с синхронной репликацией весьма недешев.
Выводы
Новые возможности — новые реалии. Безопасности на просторах интернета!
Автор: viklequick
