В 2011 году я начал говорить о том, как правильно входить в облака.
"Входить в облако надо с готовой стратегией выхода из него".
До санкций было еще 11 лет и я говорил в основном о том, что у вас как пользователей может поменяться мнение о качестве услуг, об их стоимости. Было еще несколько лет до CloudMouse, и даже некоторые провайдеры из ранних еще не отжигали.
Идет 2024 год. Slack добивает пользователей по признаку "получите, русские сволочи". В 2022 были убиты корпоративные аккаунты, причем некоторые серьезные компании пострадали (не будем их называть).
Недостатки - логическое продолжение достоинств. Удобство облака и возможность моментально развернуть ресурсы = возможность моментально их удалить. Ваш обиженный инженер может это сделать в отместку за невыплаченную премию. Но так же это может сделать и сотрудник провайдера, например, демонстрируя свою личную политическую или иную позицию.
Компания-провайдер может схлопнуться, а может просто взять и заблокировать вам аккаунт (Amazon vs Parler). Дальше делайте что хотите.
Мы сейчас смеемся над дурачками, которые за полкопейки в 20 лет жгут релейные шкафы РЖД, а потом получают 20 лет тюремного срока. Так кто вам сказал, что очередной такой дурачок не окажется сотрудником облака с возможностью разворотить вам все?
Повтори, а потом еще три раз повтори.
Как правильно входить в облако.
Облако - это не высшие технологии, а способ сэкономить. В том числе экономит провайдер. У вас должны быть резервные копии всего. Причем в обязательном порядке резервные копии на оборудовании, которое находится на вашей контролируемой территории (On premise). Оборудование должно быть полностью контролируемо вами, софт резервного копирования должен полностью контролироваться вами. Чтобы исключить возможность блокирования вам доступа или автоматического удаления резервной копии по команде "оттуда".
У вас должны быть в том числе оффлайновые бэкапы на "отчуждаемых носителях". CD, DVD, HDD, лента - да что угодно. То, что не требует питания и может быть закрыто в сейф на ключ.
У вас должен быть готов полный план по переключению на другое облако, запускаемый по нажатию кнопки. После чего все ваши данные, машины, контейнеры и тд переезжают / заливаются в новое облако из резервной копии.
В обязательном порядке ваше "резервное" облако должно находиться с вами в одной юрисдикции. Т.е. вы можете подать в суд на компанию и суд вас не пошлет нахрен.
Совсем в идеале у вас должен быть план по переезду из облака на on-premise. Т.е. на собственное железо, пусть хоть и не в собственную серверную, но хотя бы коммерческий ЦОД на colocation в вашей юрисдикции и где ваши инженеры могут физически дойти ногами и что то сделать с оборудованием. Если вам недоступно оборудование / ваши инженеры не имеют возможности оборудование физически потрогать в любой момент, а обслуживает его исключительно команда ЦОДа - это ничем не отличается от облака.
Если вы крупный клиент - ЦОД / облако должна одобрить ваша СБ, а им провайдер должен продемонстрировать как, кто и зачем имеет доступ, как контролируется этот доступ.
Запоминаем:
если кто-то посторонний имеет доступ к вашей инфраструктуре - это не ваша инфраструктура
если кто-то посторонний имеет доступ к вашему серверу - это не ваш сервер
если кто-то может по одному клику мышкой закрыть вам доступ к вашим данным - это не ваши данные
