ANZ Banking Group использует созданный Google контроль безопасности под названием binary authorization для предотвращения развертывания в производство несанкционированного кода и изображений контейнеров.
Бинарная авторизация находится в публичном бета-тестировании с тех пор, как она была анонсирована на прошлогодней конференции Google Cloud Next, хотя ожидается, что вскоре она станет общедоступной.
Ведущий специалист банка по разработке омниканальных платформ Майк Берри рассказал на конференции Google Cloud Next в Сан-Франциско, что ANZ использует два общедоступных бета-инструмента для защиты сервисов и приложений, работающих в облаке.
ANZ впервые раскрыла подробности о внедрении контейнеризации и автоматизированного развертывания кода в прошлом году.
Берри развил эту мысль на конференции Google на прошлой неделе, кратко обсудив, как безопасность включается в эти процессы.
ANZ использует сервисы Google как для того, чтобы попытаться поймать ошибки безопасности на самом раннем этапе создания нового контейнерного приложения, так и для того, чтобы обеспечить запуск в производство только одобренного кода и изображений контейнеров.
Берри сказал, что ANZ использует функции сканирования уязвимостей в Cloud Build, которая представляет собой управляемую непрерывную интеграцию и непрерывную доставку Google (CI/CD).
Сканирование уязвимостей — часть API анализа контейнеров — используется для обеспечения “быстрой обратной связи о потенциальных угрозах и выявления проблем, как только ваши контейнеры будут построены”, — сказал Google в прошлом году.
“Наш исходный код перемещается в облачную сборку и делает все обычные вещи, которые мы делаем в сборке, но в то же время мы запускаем сканирование уязвимостей”, — говорит Берри.
“Если это сканирование уязвимостей не удается, то сразу же у нас есть «красная» сборка, и разработчик может войти, посмотреть на нее и выяснить, в чем проблема.
“Это подчеркнет для вас серьезность и то, какой пакет пострадал, так что вы можете пойти и сделать исправление или исправление — все, что требуется — и исправить это.”
Берри сказал, что раннее сканирование уязвимостей было разработано для того, чтобы избежать замедления процесса позже.
“Когда вы обнаруживаете эти вещи, как они происходят, и сразу же исправляете их, это помогает нам поддерживать нашу скорость, когда мы работаем над развитием”, — сказал он.
Берри сказал, что ANZ также приняла соответствующий контроль безопасности-двоичную авторизацию.
В прошлом году Google заявила, что “сканирование уязвимостей интегрировано с бинарной авторизацией”, последнюю из которых она описала как “инструмент безопасности цепочки поставок”, который гарантирует, что только доверенные образы контейнеров развертываются на движке Kubernetes без какого-либо ручного вмешательства.”
“Сканирование на наличие уязвимостей-это один из наших процессов, но у нас есть много других инструментов безопасности и процессов тестирования”, — сказал Берри.
ANZ рассматривал двоичную авторизацию как способ применения политик безопасности, для которых код и изображения контейнеров разрешены в производстве.
Он делает это, автоматически проверяя, прошел ли код или образ внутренние проверки, установленные для различных этапов развертывания.
“Двоичная авторизация видит, что ваше изображение приходит, и ищет подтверждение, которое прилагается к нему”, — сказал Берри.
“Таким образом, это способ прикрепить сертификат, чтобы сказать: «это прошло нашу политику, и у нас есть сертификат, чтобы доказать, что этот образ подходит нам».”
Берри сказал, что бинарная авторизация эффективна не только как способ обеспечения соблюдения политики безопасности, но и как демонстрация ее соблюдения для групп внутреннего аудита.
“Представьте себе, что у вас есть команда внутреннего аудита, которая приходит к вам и говорит:” Нам нужно понять ваши меры контроля и политики, поэтому мы собираемся организовать встречу на пару часов, и мы вместе прочитаем документацию и поймем, как работают ваши политики», — сказал Берри.
— Ты такой: “Это звучит очень весело, но как насчет того, чтобы сделать демо? У меня есть образ, который никто не одобрял, никто не тестировал, и я даже не знаю, откуда он взялся, и я собираюсь развернуть его в производство.”
“Вы нажимаете кнопку развертывания и показываете своей аудиторской команде: «Смотрите, это не может быть развернуто в производство».
— Мы здесь не просто говорим о безопасности, мы укрепляем нашу безопасность. И поэтому мы заботимся о том, чтобы эти вещи могли пройти, потому что они одобрены.”
Берри сказал, что двоичная авторизация может быть использована для обеспечения соблюдения нескольких политик безопасности и обеспечения того, чтобы код или изображения контейнеров проходили несколько аттестаторов.
“Представьте себе, что в одном кластере вы говорите: «Все, что должно произойти здесь, это то, что нам нужна экспертная оценка, а затем вы можете развернуться в этом кластере».
“Но для производственного кластера, возможно, вы хотите получить экспертную оценку, возможно, вы хотите, чтобы он прошел определенную фазу тестирования, и, возможно, вы хотите добавить [одобрение] команды или даже человека”, — сказал он.
