Вопреки прогнозам, по состоянию на сентябрь 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, флудинг, отказ в обслуживании и подобное.
В следующий раз мы этим как раз и займёмся.
Simon Says «0» 