Надежность предоставляемых в «облаке» ИТ-услуг может сильно влиять на финансовые показатели компании и производительность сотрудников. Поэтому оценка используемых служб и частоты их отказов — критический фактор при принятии решения о переходе в «облако» и выборе поставщика. Недавно два известных отказа Microsoft Azure, связанных с многофакторной проверкой подлинности и случившихся в течение восьми дней, негативно повлияли на работу пользователей таких служб на основе Azure, как Office 365, Active Directory и Dynamics. Подобные ситуации, если между ними проходит много месяцев, кажутся приемлемыми. Однако, когда они происходят одна за другой, возникает повод для дискуссий о нашей зависимости от «облачных» продуктов и услуг.
Компания Microsoft позволяет отслеживать все отказы Microsoft Azure и другие проблемы со службой на странице журнала состояния Azure (https://azure.microsoft.com/en-us/status/history/). Здесь представлены все сведения о протекании отказа и предварительная оценка основной причины; меры, предпринятые Microsoft для смягчения последствий отказа, и дальнейшие шаги, связанные с неполадками. К последним обычно относится план действий для предотвращений аналогичных отказов в будущем. В журнале за ноябрь прошлого года содержится 10 записей, за октябрь — 13, а за сентябрь — 7 записей. Проблемы охватывают широкий круг «облачных» служб; подробные сводки и планируемые решения открыты и прозрачны. Компания Amazon имеет собственный журнал для служб Amazon Web Services (https://status.aws.amazon. com/), а Google — для Google Cloud Platform (https://status.cloud.google. com/).
Они могут быть очень полезны для потенциальных пользователей «облачных» служб, желающих выяснить не только как часто в компании происходят сбои, но и как она реагирует на них. Такого рода связь важна для пользователей «облачных» служб не только Microsoft, но и Google, Amazon и других поставщиков. Если ИТ-специалист не может своевременно выяснить, почему не работает та или иная служба, трудно ожидать доверия к этим службам.
Все «облачные» поставщики имеют соглашения об уровне обслуживания (SLA), в которых оговариваются обязательства компании по времени доступности службы и параметрам связи. Компания Microsoft представляет соглашение (https://azure. microsoft.com/en-us/support/legal/sla/) для служб Azure, Google имеет центральное соглашение (https://cloud.google.com/terms/sla/) для своей «облачной» платформы; Amazon располагает аналогичной центральной страницей (https://aws.amazon.com/de/legal/service-level-agreements/). В этих соглашениях содержатся гарантии времени доступности каждой службы и обычно оговариваются компенсации для потребителей, если данный показатель не соблюдается. Это юридически обязывающие документы и их непременно следует учитывать, принимая решения о перемещении части или всех своих служб в «облако».
К решению положиться исключительно на «облачные» службы, выбрать гибридный или чисто локальный продукт нельзя относиться легкомысленно. «Облачные» технологии внедряются стремительными темпами, и, чтобы понять причины этого, достаточно взглянуть, насколько положительно влияют соответствующие службы на финансовые показатели предоставляющих их компаний. В настоящее время вопрос, похоже, заключается не в том, совершит ли ваша компания переход в «облако», а в том, когда это случится.
Однако на выбор также влияет уровень риска, с которым вы готовы мириться при доступе к своим службам. Отказы случаются во всех трех перечисленных выше сценариях, но когда служба, относящаяся к безопасности, отказывает дважды за очень короткий промежуток времени, многие задумаются о последствиях полного перехода в «облако».
Я побеседовал о недавних простоях Microsoft Azure с Джессикой Ортега, аналитиком по интернет-безопасности в компании SiteLock, и она отметила несколько аспектов проблемы: «Упускают из виду серьезность отказа многофакторной проверки подлинности Azure и его значение для любых компаний, использующих Azure, от малых предприятий до крупных корпораций. Из-за отказов пользователям не удавалось получить доступ к Office 365, от которого зависит их бизнес. Речь идет о рабочей электронной почте, отчетах и хранении данных. Все это перестало работать и оказалось недоступным. В результате деятельность компании может прекратиться».
Относительно конкретных отказов Microsoft Azure Ортега сказала, что компаниям было бы полезно обдумать, что лучше — использовать локальный физический ключ или «облачную» многофакторную проверку подлинности для защиты учетных записей. Между прочим, все три крупных «облачных» игрока (Microsoft, Google и Amazon) поддерживают использование физического ключа безопасности в качестве второго фактора проверки подлинности. Применение, если это возможно, обоих вариантов — хороший способ уменьшить потенциальный риск «облачных» отказов многофакторной проверки подлинности на платформе любого поставщика.
Однако альтернативная учетная запись администратора, не использующая многофакторную проверку подлинности, едва ли удачный способ избежать подобной ситуации в будущем. Такая идея витала в социальных сетях и других каналах после первого сбоя многофакторной проверки подлинности Microsoft Azure.
«Это определенно возможно, но в результате вы открываетесь для потенциально уязвимой учетной записи администратора, у которой в настоящее время только один уровень защиты. То есть такое возможно, но лишь как временная мера на случай повторного сбоя»,?— считает Ортега.
На данном этапе компании должны начать сопоставлять выигрыш в стоимости с риском при использовании менее надежных методов.
«Если только вы не можете позволить себе простой в течение целого рабочего дня, который пришлось испытать ряду компаний в результате двух отказов, то вам придется сопоставить свою уязвимость с потерями от простоя в течение дня. Спросите себя, убытки от проникновения злоумышленника в альтернативную учетную запись меньше, больше или равны упущенной выгоде и потерям продуктивности в течение дневного простоя?» — предлагает Ортега.
На вопрос, не слишком ли много доверия компании и даже конечные пользователи оказывают поставщикам услуг, удовлетворяясь только стопроцентной доступностью, Ортега ответила:
«С одной стороны, время доступности 99,99999% и выше чрезмерно для любого другого бизнеса, но именно так устроен мир. Даже если хранилище данных полностью локальное, погоду еще никто не отменял. Можно сказать, что показатель чрезмерен для любых других случаев применения, но в отношении к техническим гигантам существуют иные ожидания, поскольку эти компании сформировали их. Они делали смелые заявления, а теперь мы надеемся, что они выполнят обещания благодаря своим бесконечным ресурсам, которых нет ни у кого другого».
Поэтому внедрение «облака» прошло так быстро: бизнес рассматривал его как возможность использовать чужие ресурсы с выгодой для себя и при этом экономить деньги. В конечном итоге, принимая решение о переходе в «облако», каждый владелец процесса в сфере бизнеса должен сам оценить все риски.
В данной статье речь шла об отказах многофакторной проверки подлинности в Microsoft Azure, но аналогичные проблемы могут затрагивать и других крупных игроков в отрасли. По большей части прогнозируемые условия обслуживания изложены в лицензиях SLA, а в случае сбоев поставщики предусматривают компенсацию.
Таким образом, определяющим фактором является приемлемый для вашей компании уровень риска в случае, если одна из «облачных» служб перестанет функционировать на какое-то время. Учитывая все сопутствующие обстоятельства, решение о переходе в «облако» или отказе от него не может быть быстрым или простым.