Comments 1
Как всегда, красивые диаграммы заменяют реальность. Вот, представьте себе обычный libvirt/qemu (не важно, openstack это или ещё что-то). Вот, у нас есть гипервизор. Кто гипервизор тут? Linux/kvm. И на вашей диаграмме граница ответственности проходит по гипервизору.
Допустим, неприятная CVE. Если это CVE для KVM, то это зона ответственности провайдера. А кто отвечает за версию qemu?
И вот тут начинается чудное. Провайдер, видимо, отвечает за пакетик qemu на хосте гипервизора. apt-get upgrade, всё такое. А кто отвечает за версию запущенной qemu с виртуальной машиной? Вопрос не праздный, на самом деле, потому что это well-known проблема, что qemu годами висит в процессах (не смотря на ребуты гостя) и на хосте qemu 5, а гость всё ещё на каком-нибудь 2.1 с миллионом уязвимостей. Кто за этот процесс отвечает? По вашей диаграмме — клиент, потому что "виртуальная машина" — это его зона ответственности. Но как он может за этим следить? Ух.
Используем чек-лист ENISA для проверки безопасности облачного провайдера и чтения SLA