NAB впервые раскрыла, как она получила благословение Австралийского Органа пруденциального регулирования на работу в облаке в масштабе.
Глава отдела мониторинга, аналитики и диагностики Оливер Мерфи заявил на конференции Splunk в США на прошлой неделе, что стандарты и методы внедрения облачных технологий (CAST) банка — ранее сформулированные как способ для самого банка контролировать облачные рабочие нагрузки — также играют центральную роль в привлечении APRA.
Позиция APRA в отношении облачных технологий уже давно не склонна к риску и сдерживает планы банков и других участников финансовой отрасли, желающих перейти на облачную инфраструктуру.
Когда NAB перенесла свою первую рабочую нагрузку в AWS — которая, как показал Мерфи, была средой мониторинга Splunk enterprise банка, — она должна была доказать APRA, что ее можно безопасно перенести.
“Болевая точка, с которой мы столкнулись в 2017 году, будучи первым сервисом в AWS, заключается в том, что мы должны были доказать APRA …[и] буквально писать документы, которые были бы сложены на полпути [высоты] стола”, — сказал Мерфи на конференции Splunk .conf19 в Лас-Вегасе.
“[Это включало] архитектурные схемы и множество доказательств того, как мы собираемся мигрировать, как мы собираемся хранить эти данные и держать [все] в безопасности.
— Три или четыре человека работали над ним около полугода.
“Мы, очевидно, получили одобрение [APRA], но это просто показало, что в те дни это было количество усилий и ресурсов, необходимых для того, чтобы просто поместить одну рабочую нагрузку в AWS в Австралии в банковском секторе.
— Это было очень больно.”
Поскольку банк надеялся перенести 35 процентов своих 2500 с лишним корпоративных приложений в облако, ему нужно было найти лучший способ работы с APRA.
“Нам нужно было изменить способ, которым мы подтверждали APRA, как мы будем заботиться об этом сервисе и управлять им в AWS”, — сказал Мерфи.
“Мы должны были думать по — другому, и мы придумали — не я лично, а коллективно, там было несколько хороших умных людей в банке-с рамками, которые в основном заменили необходимость доказательства 15 000 страниц документации.”
Этот каркас ОТЛИТ.
Природа CAST была публично раскрыта только на форуме AWS executive forum в Сиднее в начале этого года — и даже тогда она не была представлена как способ, которым NAB установила комфорт с APRA для запуска облачных рабочих нагрузок в масштабе.
В тот момент CAST позиционировался как способ для самого банка “программно определить, как мы запускаем наши рабочие нагрузки в облаке” — серия автоматизированных проверок, выполняемых против любого облачного кода, чтобы убедиться, что он соответствует контролю безопасности и внутренним стандартам.
Мерфи признался, что “идея CAST состояла в том, чтобы обеспечить высокоскоростную миграцию приложений из локального решения в облако.”
Но, по его словам, “это [также] избавило нас от необходимости обращаться в APRA по каждому рабочему делу.”
“Это в основном позволило нам массово загружать и массово отправлять APRA”, — сказал он.
“Что АПРА была счастлива [с] АКТЕРСКИМ СОСТАВОМ, так это то, что мы в основном становились самоуправляющимися, самоаудитирующимися на уровне требований, которые они ожидали бы от нас самих.
“От шестимесячного процесса мы сводим его к эффективной работе примерно на неделю, и многое из того, что мы пытаемся сделать сейчас, — это автоматизировать [это].”
CAST гарантирует, что облачный код соответствует определенным принципам и стандартам, используя определенные методы.
Шесть основных принципов, которые бросают адреса, — это безопасность, архитектура, DevOps и доставка, непрерывность бизнеса, управление услугами и управление данными.
“Чтобы дать вам пример, безопасность была бы принципом, регистрация событий или регистрация безопасности были бы стандартом, и техника заключается в том, как вы подтверждаете это, в основном показывая скриншот или указывая, как у вас есть ваши журналы в вашем индексе в Splunk”, — сказал Мерфи.
