Чей-то чужой компьютер

Вопреки прогнозам, по состоянию на сентябрь 2020 мир не разделился на до и после. Произошло то, что и должно было произойти – ускорение всех процессов. Помните, как холодная война ускорила выход в космос, или появление единой валюты дало новый импульс евроинтеграции? У нас куда более скромное «достижение» – пандемия COVID-19 ускорила переход огромного количества технологических и IT-компаний на удалённый режим работы. Хотя бы отчасти. И проворачивать этот фарш обратно будет весьма непросто, да и нужно ли? Кто-то был технически готов к этому и ждал отмашки руководства, кто-то судорожно наращивал мощности своих VPN-концентраторов и разворачивал терминальные серверы, пока сотрудники паковали вещи, но в итоге все оказались примерно в одинаковом положении. А что дальше?

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

К облакам отношение меняется, но не особенно быстро. Те, кто по разным причинам считают, что доверять облачным провайдерам ни в коем случае нельзя (зато можно доверять своим сисадминам, имеющим доступ примерно ко всему), никуда не исчезли. Для всех остальных существует вот такая картинка:

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

Таким образом, строго говоря, в обмен на удобство и существенную экономию денег (не для всех конечно, совсем не для всех) мы получили новую поверхность атаки. И получение root’a для облачного сервиса это уже куда круче, чем root на отдельно взятом веб-сервере, откуда, может быть, и не получится развить атаку. Да, я в курсе, что root от AWS не рекомендуют использовать, но клиентам это ведь так удобно.

И дело даже не в том, что сами сервисы AWS могут оказаться уязвимыми (однажды окажутся, не сомневайтесь), а в том, что за видимой простотой настройки всего этого скрываются банальные ошибки конфигурирования, не заметные на первый взгляд.

К счастью, уже накоплен существенный опыт того, что делать нужно, а чего делать ни в коем случае нельзя. Причём, даже на раннем этапе, когда вы только написали свой первый шаблон Cloudformation (или Terraform, или в чём вы это делаете?), можно подключить специалистов или даже воспользоваться специальным программным обеспечением, выявляющим ошибки.

Так что там с пентестом? Пентест делать можно, причём, если раньше требовалось подавать уведомление облачным провайдерам, то сейчас можно делать всё самостоятельно, когда захочется, только не нарушать правил – https://aws.amazon.com/ru/security/penetration-testing/ или https://docs.microsoft.com/ru-ru/azure/security/fundamentals/pen-testing. Правила сводятся к «делайте со своими сервисами, что хотите, только не ломайте всё вокруг» – DNS, флудинг, отказ в обслуживании и подобное.

В следующий раз мы этим как раз и займёмся.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s